CoreRasurae
3a95701d9a
CI / lint (pull_request) Successful in 1m19s
CI / quality (pull_request) Successful in 1m39s
CI / typecheck (pull_request) Successful in 1m43s
CI / security (pull_request) Successful in 1m56s
CI / build (pull_request) Successful in 33s
CI / helm (pull_request) Successful in 40s
CI / unit_tests (pull_request) Successful in 6m36s
CI / integration_tests (pull_request) Successful in 3m57s
CI / push-validation (pull_request) Successful in 19s
CI / docker (pull_request) Successful in 1m28s
CI / coverage (pull_request) Successful in 12m46s
CI / status-check (pull_request) Successful in 4s
CI / lint (push) Failing after 12s
CI / typecheck (push) Failing after 11s
CI / integration_tests (push) Failing after 7s
CI / unit_tests (push) Failing after 12s
CI / quality (push) Failing after 12s
CI / security (push) Failing after 13s
CI / coverage (push) Has been skipped
CI / docker (push) Has been skipped
CI / push-validation (push) Failing after 13s
CI / helm (push) Failing after 14s
CI / build (push) Failing after 15s
CI / status-check (push) Failing after 2s
CI / benchmark-regression (push) Failing after 34s
CI / e2e_tests (push) Successful in 1m1s
CI / benchmark-publish (push) Failing after 35m10s
Add max_child_depth field to DecompositionConfig (default: 5, matching plan.max-child-depth config) with validation in __post_init__. Update _build_hierarchy() in DecompositionService to stop recursion and emit a warning when the depth limit is reached. BDD tests verify: max_child_depth guards trigger before max_depth when more restrictive, warnings are logged, default config value is correct, and invalid values are rejected. ISSUES CLOSED: #10269
39 lines
1.8 KiB
Gherkin
39 lines
1.8 KiB
Gherkin
Feature: Decomposition respects max_child_depth limit
|
|
As a plan orchestrator
|
|
I want the decomposition service to enforce plan.max-child-depth
|
|
So that child plans cannot nest deeper than the configured limit
|
|
|
|
Background:
|
|
Given a decomposition service
|
|
|
|
Scenario: Decomposition stops recursing when max_child_depth limit is reached
|
|
Given a project with 500 files across 8 directory levels
|
|
When I decompose with max_child_depth 2 and max_depth 10
|
|
Then the decomposition result should have max_depth_reached <= 2
|
|
And the decomposition warning log should contain "max-child-depth limit"
|
|
|
|
Scenario: Decomposition with default max_child_depth allows standard depth
|
|
Given a project with 2000 files across 5 directory levels
|
|
When I decompose with default max_child_depth
|
|
Then the decomposition result should have max_depth_reached >= 1
|
|
And the decomposition result should have max_depth_reached <= 5
|
|
|
|
Scenario: max_child_depth guard triggers before max_depth when more restrictive
|
|
Given a project with 500 files across 8 directory levels
|
|
When I decompose with max_child_depth 1 and max_depth 10
|
|
Then the decomposition result should have max_depth_reached <= 1
|
|
And the decomposition warning log should contain "max-child-depth limit"
|
|
|
|
Scenario: max_depth can be more restrictive than max_child_depth
|
|
Given a project with 500 files across 8 directory levels
|
|
When I decompose with max_child_depth 10 and max_depth 2
|
|
Then the decomposition result should have max_depth_reached <= 2
|
|
|
|
Scenario: Default config includes max_child_depth with expected value
|
|
Given default decomposition config
|
|
Then max_child_depth should be 5
|
|
|
|
Scenario: Invalid max_child_depth value is rejected
|
|
When I create a config with max_child_depth 0
|
|
Then a decomposition ValueError should be raised
|