freemo
c4f71e930d
CI / benchmark-publish (pull_request) Has been skipped
CI / lint (pull_request) Successful in 21s
CI / quality (pull_request) Successful in 21s
CI / build (pull_request) Successful in 23s
CI / typecheck (pull_request) Successful in 39s
CI / security (pull_request) Successful in 50s
CI / integration_tests (pull_request) Successful in 4m4s
CI / unit_tests (pull_request) Successful in 9m15s
CI / docker (pull_request) Successful in 1m0s
CI / benchmark-regression (pull_request) Successful in 23m41s
CI / coverage (pull_request) Successful in 43m24s
CI / lint (push) Successful in 22s
CI / build (push) Successful in 24s
CI / quality (push) Successful in 27s
CI / typecheck (push) Successful in 44s
CI / benchmark-regression (push) Has been skipped
CI / security (push) Successful in 55s
CI / integration_tests (push) Successful in 4m16s
CI / benchmark-publish (push) Successful in 14m39s
CI / unit_tests (push) Successful in 24m24s
CI / docker (push) Successful in 1m1s
CI / coverage (push) Successful in 45m36s
Implement step-level progress persistence and plan resume with graceful shutdown handling. - Add ResumeCheckpoint, ResumeMetadata, ResumeEligibility, ResumeSummary domain models (resume.py) - Add PlanResumeService with validate_eligibility(), build_resume_summary(), resume_plan(dry_run), record_step_checkpoint(), record_shutdown() - Add last_completed_step and last_checkpoint_id fields to Plan model - Add 'plan resume' CLI command with --dry-run flag - Update plan lifecycle docs (ADR-006) with resume behavior section - Add Behave tests (24 scenarios in plan_resume.feature) - Add Robot Framework integration tests (10 tests) - Add ASV benchmarks for resume overhead Closes #328
73 lines
3.7 KiB
Gherkin
73 lines
3.7 KiB
Gherkin
Feature: Plan Lifecycle Service coverage boost
|
|
As a developer
|
|
I want to exercise uncovered branches in PlanLifecycleService
|
|
So that code coverage improves for the specific gaps identified
|
|
|
|
Background:
|
|
Given I have a fresh plan lifecycle service for coverage boost
|
|
|
|
# ---------------------------------------------------------------
|
|
# Line 284: get_action_by_name linear scan fallback
|
|
# Branch 283:284 — the dict key doesn't match but the action's
|
|
# namespaced_name string representation does.
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: get_action_by_name normalises case so mixed-case input finds lowercase-stored action
|
|
Given an action stored under its normalised lowercase key
|
|
When I look up the action with mixed-case input via get_action_by_name
|
|
Then the action should be found via case-insensitive lookup
|
|
|
|
# ---------------------------------------------------------------
|
|
# Line 420: use_action appends PlanInvariant from action.invariants
|
|
# Branch 419:420 — the loop body over action.invariants
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: use_action copies action invariants as PlanInvariants onto the new plan
|
|
Given an action with invariants "no-breaking-changes" and "preserve-api-compat"
|
|
When I use that action to create a plan
|
|
Then the plan should contain 2 action-sourced invariants
|
|
And the invariant texts should include "no-breaking-changes"
|
|
And the invariant texts should include "preserve-api-compat"
|
|
|
|
# ---------------------------------------------------------------
|
|
# Line 643: execute_plan raises InvalidPhaseTransitionError
|
|
# Branch 642:643 — can_transition returns False
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: execute_plan raises InvalidPhaseTransitionError when plan is in Execute phase
|
|
Given a plan that is already in execute phase
|
|
When I try to execute the plan from execute phase
|
|
Then an InvalidPhaseTransitionError should be raised for the coverage boost
|
|
|
|
Scenario: execute_plan raises InvalidPhaseTransitionError when plan is in Apply phase
|
|
Given a plan that is already in apply phase
|
|
When I try to execute the plan from apply phase
|
|
Then an InvalidPhaseTransitionError should be raised for the coverage boost
|
|
|
|
# ---------------------------------------------------------------
|
|
# Lines 829-846: constrain_apply method — happy path and wrong phase
|
|
# Branches 831:832,836
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: constrain_apply marks an Apply-phase plan as constrained
|
|
Given a plan in apply phase with processing state for coverage boost
|
|
When I constrain the apply with reason "invariant violated" for coverage boost
|
|
Then the plan processing state should be "constrained" for coverage boost
|
|
And the plan error message should be "invariant violated" for coverage boost
|
|
|
|
Scenario: constrain_apply raises PlanError when plan is not in Apply phase
|
|
Given a plan in strategize phase for coverage boost
|
|
When I try to constrain the apply with reason "should fail"
|
|
Then a PlanError should be raised for coverage boost
|
|
|
|
# ---------------------------------------------------------------
|
|
# Line 959: auto_progress final return — plan doesn't match either
|
|
# auto-progress condition.
|
|
# Branch 948:959 — the else/fallback in auto_progress
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: auto_progress returns plan unchanged when neither auto-progress condition matches
|
|
Given a plan in strategize queued state with full automation for coverage boost
|
|
When I call auto_progress on the plan for coverage boost
|
|
Then the plan should be returned unchanged in strategize queued state
|