forked from HAL9000/cleveragents-core
freemo
a321fb3b37
- What was implemented
- Added PLAN_ROLLED_BACK event type to the EventType enum at src/cleveragents/infrastructure/events/types.py to properly represent successful rollbacks in the domain model.
- Implemented rollback_plan(plan_id: str, checkpoint_id: str) -> RollbackResult in PlanLifecycleService (src/cleveragents/application/services/plan_lifecycle_service.py) with:
- Plan state validation: rejects rollback when the plan is in terminal APPLIED or CANCELLED states.
- Delegation to CheckpointService.selective_rollback() to perform the actual rollback logic and obtain a RollbackResult.
- Emission of PLAN_ROLLED_BACK as a domain event to reflect the completed rollback.
- checkpoint_service is accepted as an optional constructor parameter; if not provided, a PlanError is raised to preserve backward compatibility.
- Updated CLI behavior in src/cleveragents/cli/commands/plan.py so agents plan rollback routes through PlanLifecycleService.rollback_plan() rather than calling CheckpointService.selective_rollback() directly.
- Updated PlanLifecycleService module docstring to include rollback_plan in the documented API.
- Added Behave feature file features/plan_lifecycle_rollback.feature with 11 scenarios covering state validation, domain events, and delegation.
- Added step implementations in features/steps/plan_lifecycle_rollback_steps.py to support the new scenarios.
- Key design decisions
- rollback_plan returns RollbackResult (the same result type produced by CheckpointService.selective_rollback) so the CLI can display rollback details consistently.
- Terminal states APPLIED and CANCELLED are disallowed for rollback to prevent inconsistent or invalid state transitions.
- checkpoint_service is optional in the PlanLifecycleService constructor; when omitted (None), a PlanError is raised to retain backward compatibility while signaling explicit dependency requirements.
- CLI UI remains powered by CheckpointService for metadata enrichment (e.g., confirmation prompts), but the actual rollback action is performed via PlanLifecycleService to ensure proper domain workflow and event emission.
- Technical implications
- All rollback logic now flows through the domain service layer (PlanLifecycleService) to preserve invariants and emit domain events, rather than allowing ad-hoc UI routes to bypass service validation.
- The UI can still retrieve checkpoint metadata for user confirmation, but the operation that modifies state uses the new rollback_plan pathway.
- Tests and behavior coverage were expanded via the new Behave feature and step implementations to validate state handling, events, and delegation.
- Affected modules/components
- src/cleveragents/infrastructure/events/types.py
- src/cleveragents/application/services/plan_lifecycle_service.py
- src/cleveragents/cli/commands/plan.py
- PlanLifecycleService module docstring
- features/plan_lifecycle_rollback.feature
- features/steps/plan_lifecycle_rollback_steps.py
ISSUES CLOSED: #3677
48 lines
2.6 KiB
Gherkin
48 lines
2.6 KiB
Gherkin
Feature: Validation attach uses --key value named option format for extra arguments
|
|
As a CleverAgents user
|
|
I want the "agents validation attach" command to accept extra arguments
|
|
as named options in the format "--key value" (e.g. "--coverage-threshold 90")
|
|
So that the CLI is consistent with the specification and other commands
|
|
|
|
Background:
|
|
Given a validation attach type guard test runner
|
|
And a validation attach type guard mocked environment
|
|
|
|
# --- Spec-compliant named option format ---
|
|
|
|
Scenario: Attach accepts a single named option argument
|
|
Given a genuine validation "local/run-tests" is registered with tool_type "validation"
|
|
When I invoke validation attach with named option "--coverage-threshold" "90" for "local/run-tests" to "local/api-repo"
|
|
Then the validation attach should succeed
|
|
|
|
Scenario: Attach accepts a named option with hyphenated key
|
|
Given a genuine validation "local/lint-check" is registered with tool_type "validation"
|
|
When I invoke validation attach with named option "--max-line-length" "120" for "local/lint-check" to "git-checkout/my-repo"
|
|
Then the validation attach should succeed
|
|
|
|
Scenario: Attach accepts multiple named option arguments
|
|
Given a genuine validation "local/coverage-check" is registered with tool_type "validation"
|
|
When I invoke validation attach with named options "--threshold" "80" "--strict" "true" for "local/coverage-check" to "local/api-repo"
|
|
Then the validation attach should succeed
|
|
|
|
# --- Rejection of old positional key=value format ---
|
|
|
|
Scenario: Attach rejects positional key=value argument format
|
|
Given a genuine validation "local/run-tests" is registered with tool_type "validation"
|
|
When I invoke validation attach with positional arg "coverage_threshold=90" for "local/run-tests" to "local/api-repo"
|
|
Then the validation attach should be rejected
|
|
And the rejection output should contain "Invalid argument format"
|
|
|
|
Scenario: Attach rejects bare positional argument without equals sign
|
|
Given a genuine validation "local/run-tests" is registered with tool_type "validation"
|
|
When I invoke validation attach with positional arg "badarg" for "local/run-tests" to "local/api-repo"
|
|
Then the validation attach should be rejected
|
|
|
|
# --- Named option missing value ---
|
|
|
|
Scenario: Attach rejects named option without a value
|
|
Given a genuine validation "local/run-tests" is registered with tool_type "validation"
|
|
When I invoke validation attach with dangling option "--coverage-threshold" for "local/run-tests" to "local/api-repo"
|
|
Then the validation attach should be rejected
|
|
And the rejection output should contain "Missing value"
|