Feature: Plan Lifecycle Service coverage round 2
  As a developer
  I want to exercise remaining uncovered branches in PlanLifecycleService
  So that code coverage improves for the specific gaps identified in build/coverage.xml

  Background:
    Given I have a fresh plan lifecycle service for coverage r2

  # ---------------------------------------------------------------
  # Lines 226-231: _try_record_decision exception handling
  # The except block in _try_record_decision that catches failures
  # from decision_service.record_decision and logs a warning.
  # ---------------------------------------------------------------

  Scenario: Decision recording failure is silently caught during start_strategize
    Given a plan lifecycle service with a failing decision service
    And an action "local/decision-fail" exists for coverage r2
    And a plan created from "local/decision-fail" for coverage r2
    When I start strategize and the decision service raises an error
    Then the plan should be in processing state without raising an error

  # ---------------------------------------------------------------
  # Line 643: use_action description fallback to str(namespaced_name)
  # Triggered when both long_description and description are falsy.
  # ---------------------------------------------------------------

  Scenario: use_action falls back to namespaced name string when description fields are blank
    Given an action "local/blank-desc" with its description cleared after creation
    When I use the blank-description action to create a plan for coverage r2
    Then the plan description should equal the action namespaced name string

  # ---------------------------------------------------------------
  # Line 1437: try_auto_revert_from_apply early return when not Apply
  # ---------------------------------------------------------------

  Scenario: try_auto_revert_from_apply returns plan unchanged when not in Apply phase
    Given a plan in strategize phase for auto-revert test
    When I call try_auto_revert_from_apply on the non-apply plan
    Then the plan should remain in strategize phase unchanged

  # ---------------------------------------------------------------
  # Line 1440: try_auto_revert_from_apply early return when not CONSTRAINED
  # ---------------------------------------------------------------

  Scenario: try_auto_revert_from_apply returns plan unchanged when not constrained
    Given a plan in apply phase with queued state for auto-revert test
    When I call try_auto_revert_from_apply on the non-constrained plan
    Then the plan should remain in apply phase with queued state

  # ---------------------------------------------------------------
  # Lines 1452-1458: try_auto_revert_from_apply loop guard
  # When reversion_count >= MAX_REVERSIONS, auto-reversion is blocked.
  # ---------------------------------------------------------------

  Scenario: try_auto_revert_from_apply is blocked by reversion loop guard
    Given a plan in apply constrained state that has reached max reversions
    And the plan uses a profile that permits auto-reversion from apply
    When I call try_auto_revert_from_apply on the max-reverted plan
    Then the plan should remain in apply constrained state due to loop guard

  # ---------------------------------------------------------------
  # Line 1488: try_auto_revert_from_execute early return not Execute
  # ---------------------------------------------------------------

  Scenario: try_auto_revert_from_execute returns plan unchanged when not in Execute phase
    Given a plan in strategize phase for execute-revert test
    When I call try_auto_revert_from_execute on the non-execute plan
    Then the plan should remain in strategize phase for execute-revert test

  # ---------------------------------------------------------------
  # Lines 1500-1506: try_auto_revert_from_execute loop guard
  # When reversion_count >= MAX_REVERSIONS, reversion is blocked.
  # ---------------------------------------------------------------

  Scenario: try_auto_revert_from_execute is blocked by reversion loop guard
    Given a plan in execute phase that has reached max reversions
    And the plan uses a profile that permits auto-reversion from execute
    When I call try_auto_revert_from_execute on the max-reverted execute plan
    Then the plan should remain in execute phase due to loop guard

  Scenario: start_strategize resolves estimation actor names to config payloads
    Given a persisted plan lifecycle service with actor repository for coverage r2
    And a persisted estimation actor config named "local/estimator"
    And an action "local/preflight-resolve" with estimation actor "local/estimator" for coverage r2
    And a plan created from "local/preflight-resolve" for coverage r2
    When I start strategize with preflight capture enabled
    Then preflight actor registry should include a resolved estimation actor config payload