forked from cleveragents/cleveragents-core
freemo
738c3b5eda
Add domain models, application service, CLI integration, and full test coverage for multi-project subplan orchestration. New components: - MultiProjectMetadata, ProjectScope, ProjectDependency domain models - MultiProjectService for creating/managing multi-project plans - CLI display of multi-project metadata in plan commands - Behave BDD tests (20 scenarios), Robot Framework integration tests, ASV benchmarks, and reference documentation Also fixes pre-existing test flakiness in cli_core, core_cli_commands, cli_plan_context_commands, and helper_server_stubs caused by environment leakage and path-with-spaces issues. ISSUES CLOSED: #199
139 lines
6.4 KiB
Gherkin
139 lines
6.4 KiB
Gherkin
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
|