freemo
55aee7cf22
CI / lint (pull_request) Successful in 18s
CI / quality (pull_request) Successful in 21s
CI / benchmark-publish (pull_request) Has been skipped
CI / build (pull_request) Successful in 14s
CI / security (pull_request) Successful in 49s
CI / typecheck (pull_request) Successful in 56s
CI / integration_tests (pull_request) Successful in 2m35s
CI / unit_tests (pull_request) Successful in 14m30s
CI / docker (pull_request) Successful in 55s
CI / benchmark-regression (pull_request) Successful in 21m11s
CI / coverage (pull_request) Successful in 34m22s
CI / lint (push) Successful in 12s
CI / build (push) Successful in 16s
CI / quality (push) Successful in 17s
CI / security (push) Successful in 29s
CI / typecheck (push) Successful in 1m0s
CI / benchmark-regression (push) Has been skipped
CI / integration_tests (push) Successful in 4m54s
CI / benchmark-publish (push) Successful in 11m48s
CI / unit_tests (push) Successful in 16m30s
CI / docker (push) Successful in 28s
CI / coverage (push) Successful in 25m45s
The step_register_skills_table step called add_skill in a loop but only committed once at the end. Because SkillRepository.create() obtains a new session per call and only flushes (never commits), the intermediate sessions could be garbage-collected before the final commit, rolling back their transactions on the shared SQLite :memory: connection. Moving _commit_pending inside the loop ensures each skill is durably committed before the next session is created. ISSUES CLOSED: #418
92 lines
4.7 KiB
Gherkin
92 lines
4.7 KiB
Gherkin
Feature: Plan CLI cancel, revert, and lifecycle-list rich coverage
|
|
As a developer
|
|
I want to exercise the uncovered cancel_plan, revert_plan,
|
|
and lifecycle_list_plans rich table rendering paths
|
|
So that coverage for plan.py lines 1817, 1821-1822, 1845-1855, 1878-1888 is achieved
|
|
|
|
Background:
|
|
Given a CLI runner for cancel-revert coverage
|
|
And a mocked lifecycle service for cancel-revert coverage
|
|
|
|
# ---------- lifecycle-list rich table rendering (lines 1817, 1820-1822) ----------
|
|
|
|
Scenario: lifecycle-list in rich format renders created_at timestamp
|
|
Given the service returns plans with project links and timestamps for rich list
|
|
When I invoke lifecycle-list in rich format for cancel-revert coverage
|
|
Then the cancel-revert command should succeed
|
|
And the cancel-revert output should contain "Lifecycle Plans"
|
|
|
|
Scenario: lifecycle-list in rich format renders automation profile column
|
|
Given the service returns plans with an automation profile for rich list
|
|
When I invoke lifecycle-list in rich format for cancel-revert coverage
|
|
Then the cancel-revert command should succeed
|
|
And the cancel-revert output should contain "Lifecycle Plans"
|
|
|
|
Scenario: lifecycle-list in rich format renders multiple project links
|
|
Given the service returns a plan with three project links for rich list
|
|
When I invoke lifecycle-list in rich format for cancel-revert coverage
|
|
Then the cancel-revert command should succeed
|
|
And the cancel-revert output should contain "more"
|
|
|
|
Scenario: lifecycle-list in rich format renders invariant count
|
|
Given the service returns plans with invariants for rich list
|
|
When I invoke lifecycle-list in rich format for cancel-revert coverage
|
|
Then the cancel-revert command should succeed
|
|
|
|
# ---------- cancel_plan (lines 1845-1855) ----------
|
|
|
|
Scenario: cancel_plan succeeds in rich format without reason
|
|
Given the service can cancel a plan for cancel-revert coverage
|
|
When I invoke cancel in rich format without reason for cancel-revert coverage
|
|
Then the cancel-revert command should succeed
|
|
And the cancel-revert output should contain "Plan cancelled"
|
|
|
|
Scenario: cancel_plan succeeds in rich format with reason
|
|
Given the service can cancel a plan for cancel-revert coverage
|
|
When I invoke cancel in rich format with reason "no longer needed" for cancel-revert coverage
|
|
Then the cancel-revert command should succeed
|
|
And the cancel-revert output should contain "Plan cancelled"
|
|
And the cancel-revert output should contain "no longer needed"
|
|
|
|
Scenario: cancel_plan succeeds in JSON format without reason
|
|
Given the service can cancel a plan for cancel-revert coverage
|
|
When I invoke cancel with format "json" and no reason for cancel-revert coverage
|
|
Then the cancel-revert command should succeed
|
|
And the cancel-revert output should contain "plan_id"
|
|
And the cancel-revert output should not contain "cancel_reason"
|
|
|
|
Scenario: cancel_plan succeeds in JSON format with reason
|
|
Given the service can cancel a plan for cancel-revert coverage
|
|
When I invoke cancel with format "json" and reason "obsolete" for cancel-revert coverage
|
|
Then the cancel-revert command should succeed
|
|
And the cancel-revert output should contain "cancel_reason"
|
|
And the cancel-revert output should contain "obsolete"
|
|
|
|
# ---------- revert_plan (lines 1878-1888) ----------
|
|
|
|
Scenario: revert_plan succeeds in rich format with default phase
|
|
Given the service can revert a plan for cancel-revert coverage
|
|
When I invoke revert in rich format with default phase for cancel-revert coverage
|
|
Then the cancel-revert command should succeed
|
|
And the cancel-revert output should contain "Plan Reverted"
|
|
And the cancel-revert output should contain "Reversion count"
|
|
|
|
Scenario: revert_plan succeeds in rich format with reason
|
|
Given the service can revert a plan for cancel-revert coverage
|
|
When I invoke revert in rich format with reason "constraints too strict" for cancel-revert coverage
|
|
Then the cancel-revert command should succeed
|
|
And the cancel-revert output should contain "Plan Reverted"
|
|
|
|
Scenario: revert_plan succeeds in JSON format
|
|
Given the service can revert a plan for cancel-revert coverage
|
|
When I invoke revert with format "json" for cancel-revert coverage
|
|
Then the cancel-revert command should succeed
|
|
And the cancel-revert output should contain "plan_id"
|
|
And the cancel-revert output should contain "reversion_reason"
|
|
|
|
Scenario: revert_plan rejects invalid phase
|
|
Given the service can revert a plan for cancel-revert coverage
|
|
When I invoke revert with invalid phase "bogus" for cancel-revert coverage
|
|
Then the cancel-revert command should abort
|
|
And the cancel-revert output should contain "Invalid phase"
|