cleveragents/cleveragents-core

Fork 3

UAT: `plan.max-child-depth` config key is registered but never read by `DecompositionService` — hierarchical decomposition depth is not configurable #3331

New issue

Open

opened 2026-04-05 09:54:50 +00:00 by freemo · 1 comment

freemo commented

2026-04-05 09:54:50 +00:00

Owner

Metadata

Branch: fix/decomposition-max-child-depth-config
Commit Message: fix(decomposition): wire plan.max-child-depth config key into DecompositionService
Milestone: v3.5.0
Parent Epic: #360

Summary

The plan.max-child-depth configuration key is registered in ConfigService with a default of 5 and an env var CLEVERAGENTS_PLAN_MAX_CHILD_DEPTH, but DecompositionService never reads this config key. Instead, it always uses the hardcoded DecompositionConfig.max_depth = 4. This means:

The config key has no effect on actual decomposition depth
The spec-required depth limit enforcement is missing
Users cannot configure the maximum nesting depth via agents config set plan.max-child-depth

Expected Behavior (from spec)

Per docs/specification.md line 30576:

plan.max-child-depth | integer | 5 | CLEVERAGENTS_PLAN_MAX_CHILD_DEPTH | Maximum nesting depth for child plan spawning. Prevents runaway recursive plan decomposition. A value of 1 means no child plans; 5 means up to 5 levels of parent-child nesting. Project-scopable.

The DecompositionService should read plan.max-child-depth from the config service and use it as the max_depth in DecompositionConfig.

Actual Behavior

DecompositionService.decompose() creates a DecompositionConfig with the hardcoded default:

cfg = config or DecompositionConfig()  # max_depth=4 hardcoded

The plan.max-child-depth config key is registered in config_service.py (line ~376) but is never read by DecompositionService.

Code Location

src/cleveragents/application/services/decomposition_service.py — decompose() method
src/cleveragents/application/services/decomposition_models.py — DecompositionConfig.max_depth = 4 (hardcoded default)
src/cleveragents/application/services/config_service.py — plan.max-child-depth registered but unused

Steps to Reproduce

Run agents config set plan.max-child-depth 2
Create a plan with a large project that would normally decompose to 4+ levels
Observe: decomposition still goes to 4 levels (ignoring the config)
Expected: decomposition should stop at 2 levels

Impact

This is a critical gap for the v3.5.0 acceptance criterion "Full autonomy acceptance flow with hierarchical decomposition (4+ levels)". Without proper depth control:

The config key is misleading (registered but non-functional)
Runaway recursive decomposition cannot be prevented via configuration
Project-scoped depth limits cannot be applied

Subtasks

Inject ConfigService (or Settings) into DecompositionService
Read plan.max-child-depth from config in decompose() and pass to DecompositionConfig
Respect project-scoped config when a project context is available
Add Behave scenarios verifying that plan.max-child-depth limits decomposition depth
Ensure nox -e typecheck and nox -e unit_tests pass

Definition of Done

DecompositionService reads plan.max-child-depth from config
Setting plan.max-child-depth 2 limits decomposition to 2 levels
Project-scoped config is respected
Behave scenarios cover the config-driven depth limit
All nox stages pass
Coverage >= 97%

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: ca-new-issue-creator

## Metadata - **Branch**: `fix/decomposition-max-child-depth-config` - **Commit Message**: `fix(decomposition): wire plan.max-child-depth config key into DecompositionService` - **Milestone**: v3.5.0 - **Parent Epic**: #360 ## Summary The `plan.max-child-depth` configuration key is registered in `ConfigService` with a default of 5 and an env var `CLEVERAGENTS_PLAN_MAX_CHILD_DEPTH`, but `DecompositionService` never reads this config key. Instead, it always uses the hardcoded `DecompositionConfig.max_depth = 4`. This means: 1. The config key has no effect on actual decomposition depth 2. The spec-required depth limit enforcement is missing 3. Users cannot configure the maximum nesting depth via `agents config set plan.max-child-depth` ## Expected Behavior (from spec) Per `docs/specification.md` line 30576: > `plan.max-child-depth` | integer | `5` | `CLEVERAGENTS_PLAN_MAX_CHILD_DEPTH` | Maximum nesting depth for child plan spawning. Prevents runaway recursive plan decomposition. A value of 1 means no child plans; 5 means up to 5 levels of parent-child nesting. **Project-scopable.** The `DecompositionService` should read `plan.max-child-depth` from the config service and use it as the `max_depth` in `DecompositionConfig`. ## Actual Behavior `DecompositionService.decompose()` creates a `DecompositionConfig` with the hardcoded default: ```python cfg = config or DecompositionConfig() # max_depth=4 hardcoded ``` The `plan.max-child-depth` config key is registered in `config_service.py` (line ~376) but is never read by `DecompositionService`. ## Code Location - `src/cleveragents/application/services/decomposition_service.py` — `decompose()` method - `src/cleveragents/application/services/decomposition_models.py` — `DecompositionConfig.max_depth = 4` (hardcoded default) - `src/cleveragents/application/services/config_service.py` — `plan.max-child-depth` registered but unused ## Steps to Reproduce 1. Run `agents config set plan.max-child-depth 2` 2. Create a plan with a large project that would normally decompose to 4+ levels 3. Observe: decomposition still goes to 4 levels (ignoring the config) 4. Expected: decomposition should stop at 2 levels ## Impact This is a critical gap for the v3.5.0 acceptance criterion "Full autonomy acceptance flow with hierarchical decomposition (4+ levels)". Without proper depth control: - The config key is misleading (registered but non-functional) - Runaway recursive decomposition cannot be prevented via configuration - Project-scoped depth limits cannot be applied ## Subtasks - [ ] Inject `ConfigService` (or `Settings`) into `DecompositionService` - [ ] Read `plan.max-child-depth` from config in `decompose()` and pass to `DecompositionConfig` - [ ] Respect project-scoped config when a project context is available - [ ] Add Behave scenarios verifying that `plan.max-child-depth` limits decomposition depth - [ ] Ensure `nox -e typecheck` and `nox -e unit_tests` pass ## Definition of Done - [ ] `DecompositionService` reads `plan.max-child-depth` from config - [ ] Setting `plan.max-child-depth 2` limits decomposition to 2 levels - [ ] Project-scoped config is respected - [ ] Behave scenarios cover the config-driven depth limit - [ ] All nox stages pass - [ ] Coverage >= 97% --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: ca-new-issue-creator

freemo added this to the v3.5.0 milestone

2026-04-05 09:56:20 +00:00

freemo added a new dependency

2026-04-05 10:00:31 +00:00

#360 Epic: Autonomy Hardening + Server Stubs (M6)

freemo referenced this issue

2026-04-05 10:15:19 +00:00

[CA-AUTO] UAT Pool Supervisor — v3.2.0–v3.7.0 — Session Tracker #3124

freemo commented

2026-04-05 10:18:34 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified — config key registered but never read is a clear implementation gap
Priority: Critical (unchanged) — plan.max-child-depth is a safety guard for hierarchical decomposition. Without it, plans can recurse infinitely.
MoSCoW: Must Have — hierarchical decomposition depth limiting is a core safety feature for autonomous plan execution. Without this guard, the system cannot safely execute hierarchical plans.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: ca-project-owner

Issue triaged by project owner: - **State**: Verified — config key registered but never read is a clear implementation gap - **Priority**: Critical (unchanged) — `plan.max-child-depth` is a safety guard for hierarchical decomposition. Without it, plans can recurse infinitely. - **MoSCoW**: Must Have — hierarchical decomposition depth limiting is a core safety feature for autonomous plan execution. Without this guard, the system cannot safely execute hierarchical plans. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: ca-project-owner

freemo referenced this issue

2026-04-05 10:20:00 +00:00

[CA-AUTO] Architecture Supervisor — Session Tracker — 2026-04-05 #3180

freemo referenced this issue

2026-04-05 10:24:17 +00:00

Proposal: fix multiple agents — add mandatory label assignment when creating issues #3321

freemo referenced this issue

2026-04-05 18:43:15 +00:00

[Automated] CleverAgents Build Session - 2026-04-05 #3377

freemo removed this from the v3.5.0 milestone

2026-04-06 21:05:28 +00:00