@tdd_issue @tdd_issue_1076
Feature: TDD Bug #1076 — use_action() does not propagate automation_profile to Plan
  As a developer
  I want to verify that use_action() resolves the automation profile
  from the precedence chain and sets it on the created Plan
  So that the bug is captured and will be caught by a regression test

  Per the specification (docs/specification.md):

  - Line 18919: "The resolved automation profile name for this plan [...]
    Determined at `plan use` time using the profile precedence rules
    (plan > action > project > global). Once set, it is locked to the plan."

  - Line 18967: "2. The plan's automation profile is resolved
    (plan > action > project > global precedence)"

  Currently, PlanLifecycleService.use_action() constructs the Plan without
  passing automation_profile to the Plan() constructor. The Plan's
  automation_profile field is always None regardless of the action's
  automation_profile value or any other configuration source.

  These tests assert the expected behavior and will FAIL until the bug is
  fixed.  The @tdd_expected_fail tag inverts the result so CI passes.

  # Bug #1076 — captures the test for automation_profile propagation from
  # the Action to the Plan via use_action(). Uses @tdd_expected_fail until
  # the fix in #1076 is merged.

  Scenario: Plan inherits automation_profile from action when action has a profile set
    Given a plan lifecycle service for automation profile testing
    And an available action "local/profiled-action" with automation_profile "full-auto"
    When I use the profiled action on project "test-project"
    Then the created plan automation_profile should not be None
    And the created plan automation_profile name should be "full-auto"
    And the created plan automation_profile provenance should be "action"

  Scenario: Plan gets project-scoped automation_profile when action has no profile
    Given a plan lifecycle service for automation profile testing
    And an available action "local/project-config-action" without automation_profile
    And a project-scoped automation_profile "trusted" for project "configured-project"
    When I use the unprofiled action on configured project "configured-project"
    Then the created plan automation_profile should not be None
    And the created plan automation_profile name should be "trusted"
    And the created plan automation_profile provenance should be "project"

  Scenario: Plan gets global default automation_profile when action has no profile
    Given a plan lifecycle service for automation profile testing
    And an available action "local/unprofiled-action" without automation_profile
    When I use the unprofiled action on project "test-project"
    Then the created plan automation_profile should not be None
    And the created plan automation_profile name should be "supervised"
    And the created plan automation_profile provenance should be "global"

  Scenario: Plan falls back to settings default when config service raises an error
    Given a plan lifecycle service with a broken config service
    And an available action "local/fallback-action" without automation_profile
    When I use the unprofiled action on project "test-project"
    Then the created plan automation_profile should not be None
    And the created plan automation_profile name should be "manual"
    And the created plan automation_profile provenance should be "global"

  Scenario: Plan-level profile overrides action-level profile
    Given a plan lifecycle service for automation profile testing
    And an available action "local/override-action" with automation_profile "full-auto"
    When I use the action with plan-level profile "ci" on project "test-project"
    Then the created plan automation_profile should not be None
    And the created plan automation_profile name should be "ci"
    And the created plan automation_profile provenance should be "plan"
