Feature: Plan persistence via LifecyclePlanRepository
  As a developer
  I want plans to persist correctly through the LifecyclePlanRepository
  So that plan lifecycle state is durable across operations

  Background:
    Given a fresh in-memory plan persistence database
    And a prerequisite action "local/persist-action" exists in the database

  # Create scenarios
  Scenario: Create a plan and retrieve it by ID
    Given a new lifecycle plan with ID "01HV000000000000000000PP01"
    When I persist the plan via the plan repository
    Then I can retrieve the plan by ID "01HV000000000000000000PP01"
    And the persisted plan description should be "Persistence test plan"

  Scenario: Create a plan preserves all identity fields
    Given a new lifecycle plan with parent tree ID "01HV000000000000000000PP02" parent "01HV000000000000000000PP01" root "01HV000000000000000000PP01"
    When I persist the plan via the plan repository
    Then I can retrieve the plan by ID "01HV000000000000000000PP02"
    And the plan parent_plan_id should be "01HV000000000000000000PP01"
    And the plan root_plan_id should be "01HV000000000000000000PP01"

  # Phase and state transition scenarios
  Scenario: Plan persists phase transition from action to strategize
    Given a persisted plan in phase "action" with state "queued"
    When I update the plan phase to "strategize" with state "queued"
    Then the plan persistence phase should be "strategize"
    And the persisted plan processing_state should be "queued"

  Scenario: Plan persists phase transition from strategize to execute
    Given a persisted plan in phase "strategize" with state "complete"
    When I update the plan phase to "execute" with state "queued"
    Then the plan persistence phase should be "execute"
    And the persisted plan processing_state should be "queued"

  Scenario: Plan persists phase transition from execute to apply
    Given a persisted plan in phase "execute" with state "complete"
    When I update the plan phase to "apply" with state "queued"
    Then the plan persistence phase should be "apply"
    And the persisted plan processing_state should be "queued"

  Scenario: Plan persists processing state transition to processing
    Given a persisted plan in phase "strategize" with state "queued"
    When I update the plan phase to "strategize" with state "processing"
    Then the persisted plan processing_state should be "processing"

  Scenario: Plan persists terminal applied state
    Given a persisted plan in phase "apply" with state "queued"
    When I update the plan phase to "apply" with state "applied"
    Then the persisted plan processing_state should be "applied"

  Scenario: Plan persists terminal constrained state
    Given a persisted plan in phase "apply" with state "queued"
    When I update the plan phase to "apply" with state "constrained"
    Then the persisted plan processing_state should be "constrained"

  Scenario: Plan persists terminal errored state
    Given a persisted plan in phase "apply" with state "queued"
    When I update the plan phase to "apply" with state "errored"
    Then the persisted plan processing_state should be "errored"

  Scenario: Plan persists terminal cancelled state
    Given a persisted plan in phase "strategize" with state "queued"
    When I update the plan phase to "strategize" with state "cancelled"
    Then the persisted plan processing_state should be "cancelled"

  # List filter scenarios
  Scenario: List plans filtered by phase
    Given 3 persisted plans in phase "strategize"
    And 2 persisted plans in phase "execute"
    When I list persisted plans filtered by phase "strategize"
    Then I should get 3 plans in the list

  Scenario: List plans filtered by processing state
    Given 2 persisted plans with processing state "queued"
    And 1 persisted plan with processing state "processing"
    When I list plans filtered by processing_state "queued"
    Then I should get 2 plans in the list

  Scenario: List plans filtered by action name
    Given 2 persisted plans linked to action "local/persist-action"
    When I list plans filtered by action_name "local/persist-action"
    Then I should get 2 plans in the list

  # Plan tree link scenarios
  Scenario: Plan tree preserves parent-child relationships
    Given a parent plan with ID "01HV0000000000000000TREE01"
    And a child plan with ID "01HV0000000000000000TREE02" under parent "01HV0000000000000000TREE01"
    When I retrieve the child plan "01HV0000000000000000TREE02"
    Then the child plan should reference parent "01HV0000000000000000TREE01"
    And the child plan should reference root "01HV0000000000000000TREE01"

  Scenario: Plan tree preserves three-level hierarchy
    Given a root plan with ID "01HV0000000000000000R00T01"
    And a mid plan with ID "01HV0000000000000000M0D001" under root "01HV0000000000000000R00T01"
    And a leaf plan with ID "01HV0000000000000000KEAF01" under parent "01HV0000000000000000M0D001" and root "01HV0000000000000000R00T01"
    When I retrieve the leaf plan "01HV0000000000000000KEAF01"
    Then the leaf plan parent should be "01HV0000000000000000M0D001"
    And the leaf plan root should be "01HV0000000000000000R00T01"

  # Cross-restart scenarios (require file-based SQLite to survive reconnection)
  Scenario: Plan status persists across database reconnection
    Given the plan persistence database is file-based
    And a prerequisite action "local/persist-action" exists in the database
    And a persisted plan in phase "execute" with state "processing"
    When I close and reopen the persistence database
    Then the plan should still be in phase "execute" with state "processing"

  Scenario: Plan with project links persists across reconnection
    Given the plan persistence database is file-based
    And a prerequisite action "local/persist-action" exists in the database
    And a persisted plan with project links "proj-alpha" and "proj-beta"
    When I close and reopen the persistence database
    Then the plan should still have 2 project links

  Scenario: Plan with arguments persists across reconnection
    Given the plan persistence database is file-based
    And a prerequisite action "local/persist-action" exists in the database
    And a persisted plan with arguments "target" and "coverage"
    When I close and reopen the persistence database
    Then the plan should still have 2 arguments in order

  Scenario: Plan with invariants persists across reconnection
    Given the plan persistence database is file-based
    And a prerequisite action "local/persist-action" exists in the database
    And a persisted plan with invariant "No breaking changes"
    When I close and reopen the persistence database
    Then the plan should still have invariant "No breaking changes"