cleveragents/cleveragents-core

Fork 3

Actor configuration validation incorrectly requires top-level provider field #4300

New issue

Closed

opened 2026-04-07 17:38:10 +00:00 by CoreRasurae · 3 comments

CoreRasurae commented

2026-04-07 17:38:10 +00:00

Member

Current Behavior

When adding an actor configuration via agents actor add --config <file>, the validation fails with:

Wrapping unexpected exception: BadParameter: provider is required
Error [500] INTERNAL: An unexpected error occurred

This occurs even when the provider field is correctly specified nested inside the actor's LLM configuration, exactly as documented in the specification. The validation incorrectly looks for provider at the root level of the configuration file, contradicting the documented format.

Expected Behavior

According to docs/specification.md (Actor Configuration Examples), the provider field should be nested inside actors.<actor-name>.config, not at the root level. The validation should check the correct location and allow properly formatted configurations to be registered successfully.

Example of correct format (per spec):

name: local/fpga-strategist
actors:
  strategist:
    type: llm
    config:
      provider: anthropic      # <-- correct location per spec
      model: claude-3.5-sonnet

Root Cause

The implementation's validation logic is checking the wrong configuration path for the provider field. It should validate that each actor definition has a provider in its LLM config, not that the root YAML contains a provider field.

Acceptance Criteria

Actor configurations with provider nested correctly in actors.<actor-name>.config.provider are accepted without error
The validation error message is clear if provider is actually missing from an LLM actor config
The fix aligns with the documented format in docs/specification.md (minimal-chat.yaml, code-reviewer.yaml examples)
All existing actor configurations continue to work correctly

Supporting Information

Specification Reference:

docs/specification.md - Actor Configuration Examples (minimal-chat.yaml, code-reviewer.yaml)
docs/adr/ADR-010-actor-and-agent-architecture.md - Actor definition requirements

Reproduction Steps:

Create actors/fpga-strategist.yaml with provider nested in actor config (as shown above)
Run: agents actor add --config actors/fpga-strategist.yaml
Observe: BadParameter validation error

Metadata

Commit Message: fix(cli): validate actor provider field at correct config nesting level
Branch: fix/actor-provider-validation

Subtasks

Locate actor configuration validation logic in codebase
Identify where provider field validation occurs
Update validation to check actors.<actor-name>.config.provider instead of root-level provider
Add test case(s) for actor registration with nested provider field
Verify all existing actor configurations still validate correctly
Test the fix with agents actor add --config <file> command

Definition of Done

This issue is complete when:

The validation logic correctly accepts actor configurations with provider nested in the actor LLM config
No workaround (top-level provider field) is required
All subtasks are completed and checked off
A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly
The commit is pushed to the remote on the fix/actor-provider-validation branch
A pull request is submitted to master, reviewed, and merged

## Current Behavior When adding an actor configuration via `agents actor add --config <file>`, the validation fails with: ``` Wrapping unexpected exception: BadParameter: provider is required Error [500] INTERNAL: An unexpected error occurred ``` This occurs even when the `provider` field is correctly specified **nested inside the actor's LLM configuration**, exactly as documented in the specification. The validation incorrectly looks for `provider` at the **root level** of the configuration file, contradicting the documented format. ## Expected Behavior According to `docs/specification.md` (Actor Configuration Examples), the `provider` field should be nested inside `actors.<actor-name>.config`, not at the root level. The validation should check the correct location and allow properly formatted configurations to be registered successfully. Example of correct format (per spec): ```yaml name: local/fpga-strategist actors: strategist: type: llm config: provider: anthropic # <-- correct location per spec model: claude-3.5-sonnet ``` ## Root Cause The implementation's validation logic is checking the wrong configuration path for the `provider` field. It should validate that each **actor definition** has a provider in its LLM config, not that the **root YAML** contains a provider field. ## Acceptance Criteria - [ ] Actor configurations with `provider` nested correctly in `actors.<actor-name>.config.provider` are accepted without error - [ ] The validation error message is clear if `provider` is actually missing from an LLM actor config - [ ] The fix aligns with the documented format in `docs/specification.md` (minimal-chat.yaml, code-reviewer.yaml examples) - [ ] All existing actor configurations continue to work correctly ## Supporting Information **Specification Reference:** - `docs/specification.md` - Actor Configuration Examples (minimal-chat.yaml, code-reviewer.yaml) - `docs/adr/ADR-010-actor-and-agent-architecture.md` - Actor definition requirements **Reproduction Steps:** 1. Create `actors/fpga-strategist.yaml` with provider nested in actor config (as shown above) 2. Run: `agents actor add --config actors/fpga-strategist.yaml` 3. Observe: BadParameter validation error ## Metadata - **Commit Message**: `fix(cli): validate actor provider field at correct config nesting level` - **Branch**: `fix/actor-provider-validation` ## Subtasks - [ ] Locate actor configuration validation logic in codebase - [ ] Identify where provider field validation occurs - [ ] Update validation to check `actors.<actor-name>.config.provider` instead of root-level `provider` - [ ] Add test case(s) for actor registration with nested provider field - [ ] Verify all existing actor configurations still validate correctly - [ ] Test the fix with `agents actor add --config <file>` command ## Definition of Done This issue is complete when: - The validation logic correctly accepts actor configurations with `provider` nested in the actor LLM config - No workaround (top-level provider field) is required - All subtasks are completed and checked off - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly - The commit is pushed to the remote on the `fix/actor-provider-validation` branch - A pull request is submitted to `master`, reviewed, and merged

CoreRasurae referenced this issue

2026-04-07 18:32:15 +00:00

ActorRegistry.add() fails to extract provider and model from nested actor config #4321

CoreRasurae commented

2026-04-07 18:32:19 +00:00

Author

Member

This bug is related to Issue #4321 ("ActorRegistry.add() fails to extract provider and model from nested actor config").

Both issues stem from the same root problem: the system expects provider and model fields at the root level of actor YAML configuration, when according to the specification they should be nested inside the actor LLM configuration.

Issue Relationship:

#4300: Validation layer (actors actor add) incorrectly looks for provider at root level
#4321: Registry layer (ActorRegistry.add()) fails to extract provider/model from nested config

Both issues prevent custom actors from being properly registered and executed. They should be fixed together as part of a comprehensive actor configuration alignment fix.

Root Cause Chain:

Actor validation (this issue) rejects or accepts wrong config format
Registry extraction (Issue #4321) doesn't find provider/model in correct location
Plan execution fails with "Unknown provider type: local"

All three failures need to be fixed in a coordinated way.

## Related Issue This bug is related to **Issue #4321** ("ActorRegistry.add() fails to extract provider and model from nested actor config"). Both issues stem from the same root problem: **the system expects `provider` and `model` fields at the root level of actor YAML configuration, when according to the specification they should be nested inside the actor LLM configuration.** ### Issue Relationship: - **#4300**: Validation layer (actors actor add) incorrectly looks for `provider` at root level - **#4321**: Registry layer (ActorRegistry.add()) fails to extract `provider/model` from nested config Both issues prevent custom actors from being properly registered and executed. They should be fixed together as part of a comprehensive actor configuration alignment fix. ### Root Cause Chain: 1. Actor validation (this issue) rejects or accepts wrong config format 2. Registry extraction (Issue #4321) doesn't find provider/model in correct location 3. Plan execution fails with "Unknown provider type: local" All three failures need to be fixed in a coordinated way.

HAL9000 referenced this issue

2026-04-08 11:15:18 +00:00

ActorRegistry.add() fails to extract provider and model from nested actor config #4321

HAL9000 commented

2026-04-08 11:15:21 +00:00

Owner

Issue reviewed and triaged.

This issue is well-formed: it has clear root cause analysis, expected behavior, acceptance criteria, complete metadata (commit message + branch), subtasks, and a Definition of Done. The related issue #4321 has been noted.

Priority: High — agents actor add --config fails with a validation error for correctly-formatted configurations per spec; blocks all custom actor registration.
Story Points: 2 (S) — targeted fix to the validation logic to check the correct nested path.
Related: #4321 (ActorRegistry.add() provider extraction) — these two issues share the same root cause area. Fixing #4300 (validation) and #4321 (extraction) together would be efficient.
Next step: This issue is now verified and ready for implementation.

Transitioning to State/Verified.

Automated by CleverAgents Bot
Supervisor: Human Liaison | Agent: human-liaison

Issue reviewed and triaged. This issue is well-formed: it has clear root cause analysis, expected behavior, acceptance criteria, complete metadata (commit message + branch), subtasks, and a Definition of Done. The related issue #4321 has been noted. - **Priority**: High — `agents actor add --config` fails with a validation error for correctly-formatted configurations per spec; blocks all custom actor registration. - **Story Points**: 2 (S) — targeted fix to the validation logic to check the correct nested path. - **Related**: #4321 (ActorRegistry.add() provider extraction) — these two issues share the same root cause area. Fixing #4300 (validation) and #4321 (extraction) together would be efficient. - **Next step**: This issue is now verified and ready for implementation. Transitioning to `State/Verified`. --- **Automated by CleverAgents Bot** Supervisor: Human Liaison | Agent: human-liaison

HAL9000 referenced this issue

2026-04-08 11:17:49 +00:00

agents actor list returns empty after fresh agents init — built-in LLM actors not seeded or auto-resolved #4215

HAL9000 referenced this issue

2026-04-08 11:30:25 +00:00

ActorRegistry.add() fails to extract provider and model from nested actor config #4321

HAL9000 commented

2026-04-08 11:30:28 +00:00

Owner

Issue triaged by project owner:

State: Verified ✅ — Clear bug in actor config validation requiring top-level provider field
Priority: High ✅ (already set) — Blocks actor configuration with nested provider/model
Milestone: v3.5.0 (M6: Autonomy Hardening) — Actor configuration is fundamental
Story Points: 3 — M — Requires investigation of validation logic
MoSCoW: Must Have — Actor configuration must accept all valid formats per spec
Assignee: HAL9000

This is related to #4321 and the actor CLI test failures. May share a root cause.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner

Issue triaged by project owner: - **State**: Verified ✅ — Clear bug in actor config validation requiring top-level provider field - **Priority**: High ✅ (already set) — Blocks actor configuration with nested provider/model - **Milestone**: v3.5.0 (M6: Autonomy Hardening) — Actor configuration is fundamental - **Story Points**: 3 — M — Requires investigation of validation logic - **MoSCoW**: Must Have — Actor configuration must accept all valid formats per spec - **Assignee**: HAL9000 This is related to #4321 and the actor CLI test failures. May share a root cause. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

HAL9000 added the

Points

label

2026-04-08 11:31:27 +00:00

HAL9000 added this to the v3.5.0 milestone

2026-04-08 11:31:31 +00:00

HAL9000 added the