Files
cleveragents-core/features/plan_cli_spec_alignment.feature
T
freemo fc7e47f66b
CI / lint (pull_request) Successful in 21s
CI / typecheck (pull_request) Successful in 49s
CI / quality (pull_request) Successful in 41s
CI / security (pull_request) Successful in 1m1s
CI / build (pull_request) Successful in 17s
CI / helm (pull_request) Successful in 23s
CI / unit_tests (pull_request) Successful in 6m45s
CI / e2e_tests (pull_request) Successful in 17m7s
CI / integration_tests (pull_request) Failing after 23m11s
CI / docker (pull_request) Successful in 1m24s
CI / coverage (pull_request) Successful in 10m54s
CI / status-check (pull_request) Failing after 1s
CI / benchmark-publish (pull_request) Has been skipped
CI / benchmark-regression (pull_request) Successful in 56m52s
fix(cli): remove --namespace/-n from agents plan list command
Remove the --namespace/-n option from the agents plan list CLI command
as it is not defined in the specification. The spec defines:

  agents plan list [--phase <PHASE>] [--state <STATE>]
                   [--project <PROJECT>] [--action <ACTION>] [<REGEX>]

Namespace filtering is already supported via the positional <REGEX>
argument (e.g. 'agents plan list "^myteam/"').

Changes:
- Remove namespace parameter from lifecycle_list_plans() function
- Remove namespace=namespace from service.list_plans() call
- Remove Namespace row from TUI Filters panel
- Update docstring examples to remove --namespace references
- Update filter panel condition to exclude namespace check
- Remove 4 namespace-related scenarios from plan_cli_spec_alignment.feature
- Remove corresponding step definitions from plan_cli_spec_alignment_steps.py

ISSUES CLOSED: #2986
2026-04-05 08:38:26 +00:00

119 lines
4.9 KiB
Gherkin

Feature: Plan CLI spec alignment
As a developer
I want the plan CLI commands aligned to the v3 spec
So that plan use/list/status flags are consistent with the specification
Background:
Given a plan spec alignment CLI runner
And a plan spec alignment mocked lifecycle service
# ---- plan use: multiple projects (positional) ----
Scenario: Plan use with multiple positional projects
Given a plan spec alignment action exists
When I run plan use with positional projects "proj-a" and "proj-b"
Then the plan spec use should succeed
And the plan spec use should link projects "proj-a" and "proj-b"
# ---- plan use: --automation-profile ----
Scenario: Plan use with --automation-profile
Given a plan spec alignment action exists
When I run plan use with automation profile "trusted"
Then the plan spec use should succeed
And the plan spec output should contain "Automation Profile"
# ---- plan use: --invariant (repeatable) ----
Scenario: Plan use with repeatable --invariant
Given a plan spec alignment action exists
When I run plan use with invariants "No warnings" and "Keep compat"
Then the plan spec use should succeed
And the plan spec use should pass invariants to service
# ---- plan use: actor override flags ----
Scenario: Plan use with strategy-actor override
Given a plan spec alignment action exists
When I run plan use with strategy actor "openai/gpt-4"
Then the plan spec use should succeed
And the plan spec output should contain "Strategy Actor"
Scenario: Plan use with execution-actor override
Given a plan spec alignment action exists
When I run plan use with execution actor "anthropic/claude-3"
Then the plan spec use should succeed
And the plan spec output should contain "Execution Actor"
Scenario: Plan use with estimation-actor override
Given a plan spec alignment action exists
When I run plan use with estimation actor "openai/gpt-4"
Then the plan spec use should succeed
And the plan spec output should contain "Estimation Actor"
Scenario: Plan use with invariant-actor override
Given a plan spec alignment action exists
When I run plan use with invariant actor "openai/gpt-4"
Then the plan spec use should succeed
And the plan spec output should contain "Invariant Actor"
# ---- plan use: --arg name=value ----
Scenario: Plan use with --arg name=value
Given a plan spec alignment action exists
When I run plan use with arg "target_coverage=80"
Then the plan spec use should succeed
And the plan spec use should pass argument "target_coverage" with value 80
# ---- plan list: filter combinations ----
Scenario: Plan list with --phase filter
Given plan spec alignment plans exist
When I run plan list with phase "strategize"
Then the plan spec list should succeed
Scenario: Plan list with --state filter
Given plan spec alignment plans exist
When I run plan list with state "queued"
Then the plan spec list should succeed
Scenario: Plan list with --processing-state filter
Given plan spec alignment plans exist
When I run plan list with processing-state "complete"
Then the plan spec list should succeed
Scenario: Plan list with --project filter
Given plan spec alignment plans exist
When I run plan list with project "proj-a"
Then the plan spec list should succeed
Scenario: Plan list with --action filter
Given plan spec alignment plans exist
When I run plan list with action "local/test-action"
Then the plan spec list should succeed
Scenario: Plan list with regex filter
Given plan spec alignment plans exist
When I run plan list with regex "test-action"
Then the plan spec list should succeed
Scenario: Plan list with combined filters
Given plan spec alignment plans exist
When I run plan list combining phase "strategize" with project "proj-a"
Then the plan spec list should succeed
# ---- plan status: output fields ----
Scenario: Plan status renders all required fields
Given a plan spec alignment plan exists for status
When I run plan status for the plan
Then the plan spec status should succeed
And the plan spec status should contain "Action"
And the plan spec status should contain "Phase"
And the plan spec status should contain "Processing State"
And the plan spec status should contain "Projects"
And the plan spec status should contain "Arguments"
And the plan spec status should contain "Automation Profile"
And the plan spec status should contain "Created"
And the plan spec status should contain "Updated"
# ---- plan cancel: --reason ----
Scenario: Plan cancel with --reason
Given a plan spec alignment plan exists for cancel
When I run plan cancel with reason "Requirements changed"
Then the plan spec cancel should succeed
And the plan spec cancel output should contain "Requirements changed"