@phase1 @domain @plan @subplan
Feature: Plan Hierarchy and Subplan Failure Handling
  As a system operator
  I want plans to correctly identify their position in a hierarchy
  And I want the failure handler to make sound decisions about stopping and retrying
  So that subplan orchestration behaves reliably under all conditions

  @subplan_hierarchy
  Scenario: A standalone plan is not considered a subplan
    Given an uncovered-lines plan that was created independently
    Then the uncovered-lines plan should not be recognized as a subplan

  @subplan_hierarchy
  Scenario: A plan spawned by another plan is a subplan
    Given an uncovered-lines plan that was spawned by another plan
    Then the uncovered-lines plan should be recognized as a subplan

  @subplan_hierarchy
  Scenario: A plan with no designated root is considered the root
    Given an uncovered-lines plan with no designated root
    Then the uncovered-lines plan should be recognized as a root plan

  @subplan_hierarchy
  Scenario: A plan whose root is itself is considered the root
    Given an uncovered-lines plan whose designated root is itself
    Then the uncovered-lines plan should be recognized as a root plan

  @subplan_hierarchy
  Scenario: A plan whose root is a different plan is not the root
    Given an uncovered-lines plan whose designated root is a different plan
    Then the uncovered-lines plan should not be recognized as a root plan

  @subplan_hierarchy
  Scenario: A root plan reports a depth of zero
    Given an uncovered-lines plan with no designated root
    Then the uncovered-lines plan hierarchy depth should be 0

  @subplan_hierarchy
  Scenario: A non-root plan reports a placeholder depth
    Given an uncovered-lines plan whose designated root is a different plan
    Then the uncovered-lines plan hierarchy depth should be -1

  @subplan_hierarchy
  Scenario: A plan with no child work has no subplans
    Given an uncovered-lines plan that has no child work tracked
    Then the uncovered-lines plan should report having no subplans

  @subplan_hierarchy
  Scenario: A plan with tracked child work has subplans
    Given an uncovered-lines plan that has tracked child work
    Then the uncovered-lines plan should report having subplans

  @failure_handler
  Scenario: The failure handler halts remaining work when fail-fast is enabled
    Given an uncovered-lines subplan configuration with fail-fast enabled and parallel work
    And an uncovered-lines subplan that has failed
    When the uncovered-lines failure handler evaluates whether to halt remaining work
    Then the uncovered-lines remaining work should be halted

  @failure_handler
  Scenario: The failure handler halts remaining work for sequential execution
    Given an uncovered-lines subplan configuration with fail-fast disabled and sequential work
    And an uncovered-lines subplan that has failed
    When the uncovered-lines failure handler evaluates whether to halt remaining work
    Then the uncovered-lines remaining work should be halted

  @failure_handler
  Scenario: The failure handler allows remaining work for parallel execution without fail-fast
    Given an uncovered-lines subplan configuration with fail-fast disabled and parallel work
    And an uncovered-lines subplan that has failed
    When the uncovered-lines failure handler evaluates whether to halt remaining work
    Then the uncovered-lines remaining work should continue

  @failure_handler
  Scenario: The failure handler allows remaining work for dependency-ordered execution without fail-fast
    Given an uncovered-lines subplan configuration with fail-fast disabled and dependency-ordered work
    And an uncovered-lines subplan that has failed
    When the uncovered-lines failure handler evaluates whether to halt remaining work
    Then the uncovered-lines remaining work should continue

  @failure_handler
  Scenario: The failure handler does not retry when retries are disabled
    Given an uncovered-lines subplan configuration with retries disabled
    And an uncovered-lines subplan that failed with error "ValidationError occurred"
    When the uncovered-lines failure handler evaluates whether to retry the failed work
    Then the uncovered-lines failed work should not be retried

  @failure_handler
  Scenario: The failure handler does not retry when all attempts are exhausted
    Given an uncovered-lines subplan configuration allowing up to 2 retries
    And an uncovered-lines subplan on attempt 3 that failed with error "TimeoutError"
    When the uncovered-lines failure handler evaluates whether to retry the failed work
    Then the uncovered-lines failed work should not be retried

  @failure_handler
  Scenario: A configuration error is not eligible for retry
    Given an uncovered-lines subplan configuration allowing up to 3 retries
    And an uncovered-lines subplan on attempt 1 that failed with error "ConfigurationError: bad config"
    When the uncovered-lines failure handler evaluates whether to retry the failed work
    Then the uncovered-lines failed work should not be retried

  @failure_handler
  Scenario: An authentication error is not eligible for retry
    Given an uncovered-lines subplan configuration allowing up to 3 retries
    And an uncovered-lines subplan on attempt 1 that failed with error "AuthenticationError: invalid token"
    When the uncovered-lines failure handler evaluates whether to retry the failed work
    Then the uncovered-lines failed work should not be retried

  @failure_handler
  Scenario: A missing resource error is not eligible for retry
    Given an uncovered-lines subplan configuration allowing up to 3 retries
    And an uncovered-lines subplan on attempt 1 that failed with error "MissingResourceError: file not found"
    When the uncovered-lines failure handler evaluates whether to retry the failed work
    Then the uncovered-lines failed work should not be retried

  @failure_handler
  Scenario: A circular dependency error is not eligible for retry
    Given an uncovered-lines subplan configuration allowing up to 3 retries
    And an uncovered-lines subplan on attempt 1 that failed with error "CircularDependencyError: cycle detected"
    When the uncovered-lines failure handler evaluates whether to retry the failed work
    Then the uncovered-lines failed work should not be retried

  @failure_handler
  Scenario: A validation error is eligible for retry
    Given an uncovered-lines subplan configuration allowing up to 3 retries
    And an uncovered-lines subplan on attempt 1 that failed with error "ValidationError: schema mismatch"
    When the uncovered-lines failure handler evaluates whether to retry the failed work
    Then the uncovered-lines failed work should be retried

  @failure_handler
  Scenario: A timeout error is eligible for retry
    Given an uncovered-lines subplan configuration allowing up to 3 retries
    And an uncovered-lines subplan on attempt 1 that failed with error "TimeoutError: deadline exceeded"
    When the uncovered-lines failure handler evaluates whether to retry the failed work
    Then the uncovered-lines failed work should be retried

  @failure_handler
  Scenario: A temporary resource error is eligible for retry
    Given an uncovered-lines subplan configuration allowing up to 3 retries
    And an uncovered-lines subplan on attempt 1 that failed with error "TemporaryResourceError: service unavailable"
    When the uncovered-lines failure handler evaluates whether to retry the failed work
    Then the uncovered-lines failed work should be retried

  @failure_handler
  Scenario: A merge conflict error is eligible for retry
    Given an uncovered-lines subplan configuration allowing up to 3 retries
    And an uncovered-lines subplan on attempt 1 that failed with error "MergeConflictError: conflicting changes"
    When the uncovered-lines failure handler evaluates whether to retry the failed work
    Then the uncovered-lines failed work should be retried

  @failure_handler
  Scenario: An unrecognized error type is not eligible for retry
    Given an uncovered-lines subplan configuration allowing up to 3 retries
    And an uncovered-lines subplan on attempt 1 that failed with error "SomeUnknownError: unexpected"
    When the uncovered-lines failure handler evaluates whether to retry the failed work
    Then the uncovered-lines failed work should not be retried

  @failure_handler
  Scenario: A failure with no error message is not eligible for retry
    Given an uncovered-lines subplan configuration allowing up to 3 retries
    And an uncovered-lines subplan on attempt 1 that failed with no error message
    When the uncovered-lines failure handler evaluates whether to retry the failed work
    Then the uncovered-lines failed work should not be retried