Feature: Multi-project subplan support As a plan orchestrator I want to manage plans that target multiple projects So that cross-project refactoring and migration plans are supported Background: Given a multi-project service And a plan with projects "api-service" and "shared-lib" # --- scope initialization ------------------------------------------------ Scenario: Initialize project scopes from project links Given available resources for "api-service" are "res-api-1,res-api-2" And available resources for "shared-lib" are "res-lib-1" When I initialize multi-project scopes Then the plan should have 2 project scopes And scope "api-service" should have 2 resource IDs And scope "shared-lib" should have 1 resource IDs Scenario: Initialize scopes with no available resources Given no available resources When I initialize multi-project scopes Then the plan should have 2 project scopes And scope "api-service" should have 0 resource IDs Scenario: Plan is_multi_project returns true for multiple projects Then the plan should be multi-project Scenario: Single-project plan is not multi-project Given a plan with only project "api-service" Then the plan should not be multi-project # --- alias resolution --------------------------------------------------- Scenario: Resolve project by alias Given a plan with project "api-service" aliased as "api" And available resources for "api-service" are "res-api-1" When I initialize multi-project scopes Then resolving alias "api" should return project "api-service" Scenario: Resolve project by name when no alias matches Then resolving alias "shared-lib" should return project "shared-lib" Scenario: Resolve unknown alias returns None Then resolving alias "nonexistent" should return nothing # --- context views ------------------------------------------------------- Scenario: Resolve context view for a known project Given available resources for "api-service" are "res-api-1" And available resources for "shared-lib" are "res-lib-1" When I initialize multi-project scopes Then resolving context view for "api-service" should succeed And the context view should have project name "api-service" Scenario: Resolve context view for unknown project raises error Given available resources for "api-service" are "res-api-1" And available resources for "shared-lib" are "res-lib-1" When I initialize multi-project scopes Then resolving context view for "nonexistent" should raise KeyError Scenario: Resolve context view without initialization raises error Then resolving context view without metadata should raise ValueError # --- mixed read-only/write enforcement ----------------------------------- Scenario: Mixed access modes detected without opt-in Given a plan with "api-service" writable and "shared-lib" read-only When I validate access modes without allow_mixed Then there should be 1 validation error about mixed access Scenario: Mixed access modes allowed with opt-in Given a plan with "api-service" writable and "shared-lib" read-only When I validate access modes with allow_mixed Then there should be 0 validation errors Scenario: Uniform access modes pass validation When I validate access modes without allow_mixed Then there should be 0 validation errors # --- cross-project dependency tracking ----------------------------------- Scenario: Cross-project dependencies stored on metadata Given available resources for "api-service" are "res-api-1" And available resources for "shared-lib" are "res-lib-1" When I initialize multi-project scopes And I add a cross-project dependency from "api-service" to "shared-lib" type "imports" Then the metadata should have 1 cross-project dependency And the dependency should be from "api-service" to "shared-lib" Scenario: Validate unknown project in cross-project dependency Given available resources for "api-service" are "res-api-1" And available resources for "shared-lib" are "res-lib-1" When I initialize multi-project scopes And I add a cross-project dependency from "api-service" to "unknown-project" type "imports" Then cross-project validation should report an error about unknown project # --- per-project changeset summaries ------------------------------------ Scenario: Record changeset summary for a project Given available resources for "api-service" are "res-api-1" And available resources for "shared-lib" are "res-lib-1" When I initialize multi-project scopes And I record a changeset for "api-service" with 3 files changed and 10 lines Then scope "api-service" should have a changeset summary And the changeset should show 3 files changed Scenario: Record changeset for unknown project raises error Given available resources for "api-service" are "res-api-1" And available resources for "shared-lib" are "res-lib-1" When I initialize multi-project scopes Then recording a changeset for "nonexistent" should raise KeyError # --- sandbox isolation --------------------------------------------------- Scenario: Read-only project with modifications fails validation Given a plan with "api-service" writable and "shared-lib" read-only And available resources for "api-service" are "res-api-1" And available resources for "shared-lib" are "res-lib-1" When I initialize multi-project scopes with allow_mixed And I record a changeset for "shared-lib" with 2 files changed and 5 lines Then cross-project validation should report sandbox isolation violation Scenario: Read-only project with no modifications passes validation Given a plan with "api-service" writable and "shared-lib" read-only And available resources for "api-service" are "res-api-1" And available resources for "shared-lib" are "res-lib-1" When I initialize multi-project scopes with allow_mixed Then cross-project validation should pass # --- CLI dict integration ------------------------------------------------ Scenario: Plan as_cli_dict includes multi-project section Given available resources for "api-service" are "res-api-1" And available resources for "shared-lib" are "res-lib-1" When I initialize multi-project scopes Then the plan cli dict should contain a "multi_project" key And the multi_project section should have 2 project scopes