cleveragents/cleveragents-core

Fork 3

UAT: `SubplanConfig.max_parallel` default of 5 prevents spec-required scaling to 10+ concurrent subplans without explicit configuration #3139

New issue

Open

opened 2026-04-05 06:44:40 +00:00 by freemo · 3 comments

freemo commented

2026-04-05 06:44:40 +00:00

Owner

Metadata

Branch: test/subplan-parallel-10-plus-concurrent
Commit Message: test(subplan): add BDD scenario for 10+ concurrent subplan parallel execution
Milestone: (none — backlog)
Parent Epic: (to be linked — see orphan note below)

Backlog note: This issue was discovered during autonomous operation
on milestone M6 (Autonomy Hardening). It does not block milestone completion and has been
placed in the backlog for human review and future milestone assignment.

Bug Report

Feature Area: Parallel Execution Scaling (M6: Autonomy Hardening)

What was tested

The SubplanConfig.max_parallel field and SubplanExecutionService parallel execution mode.

Expected behavior (from spec)

Per docs/specification.md §Parallel Execution (line 18417): "Parallel execution is bounded by SubplanConfig.max_parallel (default: 5, range: 1–50)." The M6 acceptance criterion requires "Parallel execution scaling to 10+ concurrent subplans."

The spec explicitly states the range is 1–50, meaning the system MUST support 10+ concurrent subplans. The M6 acceptance criterion requires this to be demonstrated/tested.

Actual behavior (from code analysis)

In src/cleveragents/domain/models/core/plan.py, SubplanConfig.max_parallel defaults to 5:

# Lines 524-529
max_parallel: int = Field(
    default=5,
    ge=1,
    le=50,
    description="Max concurrent subplans (for PARALLEL mode)",
)

While the field supports values up to 50, the default of 5 means that without explicit configuration, the system will never scale to 10+ concurrent subplans. There are no integration tests or BDD scenarios that verify the system can actually execute 10+ subplans concurrently.

Additionally, in SubplanExecutionService._execute_parallel() (line 272 of subplan_execution_service.py):

max_workers = min(self._config.max_parallel, len(statuses))

This correctly caps workers, but there is no test that exercises 10+ concurrent subplans to verify the ThreadPoolExecutor handles the load correctly.

Missing test coverage

No BDD scenario tests parallel execution with 10+ subplans
No integration test verifies the system scales to 10+ concurrent subplans
The large_project_decomposition.feature tests decomposition but not parallel execution at scale

Code location

src/cleveragents/domain/models/core/plan.py, lines 524-529 (SubplanConfig.max_parallel)
src/cleveragents/application/services/subplan_execution_service.py, line 272 (_execute_parallel)
features/large_project_decomposition.feature (missing 10+ parallel scenario)

Impact

The M6 acceptance criterion "Parallel execution scaling to 10+ concurrent subplans" cannot be verified without explicit configuration override
No test coverage ensures the system actually works at 10+ concurrent subplans
The default of 5 may be insufficient for large hierarchical plans

Subtasks

Add BDD scenario that executes 10+ subplans in PARALLEL mode
Verify ThreadPoolExecutor handles 10+ workers correctly
Consider whether the default should be raised to 10 per M6 requirements
Add integration test for parallel scaling

Definition of Done

A BDD scenario exists that verifies 10+ concurrent subplans execute successfully
The scenario passes in CI
The max_parallel default is documented with the M6 scaling requirement
All nox stages pass
Coverage >= 97%

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

## Metadata - **Branch**: `test/subplan-parallel-10-plus-concurrent` - **Commit Message**: `test(subplan): add BDD scenario for 10+ concurrent subplan parallel execution` - **Milestone**: *(none — backlog)* - **Parent Epic**: *(to be linked — see orphan note below)* > **Backlog note:** This issue was discovered during autonomous operation > on milestone M6 (Autonomy Hardening). It does not block milestone completion and has been > placed in the backlog for human review and future milestone assignment. --- ## Bug Report **Feature Area**: Parallel Execution Scaling (M6: Autonomy Hardening) ### What was tested The `SubplanConfig.max_parallel` field and `SubplanExecutionService` parallel execution mode. ### Expected behavior (from spec) Per `docs/specification.md` §Parallel Execution (line 18417): "Parallel execution is bounded by `SubplanConfig.max_parallel` (default: `5`, range: 1–50)." The M6 acceptance criterion requires "Parallel execution scaling to 10+ concurrent subplans." The spec explicitly states the range is 1–50, meaning the system MUST support 10+ concurrent subplans. The M6 acceptance criterion requires this to be demonstrated/tested. ### Actual behavior (from code analysis) In `src/cleveragents/domain/models/core/plan.py`, `SubplanConfig.max_parallel` defaults to 5: ```python # Lines 524-529 max_parallel: int = Field( default=5, ge=1, le=50, description="Max concurrent subplans (for PARALLEL mode)", ) ``` While the field supports values up to 50, the default of 5 means that without explicit configuration, the system will never scale to 10+ concurrent subplans. There are no integration tests or BDD scenarios that verify the system can actually execute 10+ subplans concurrently. Additionally, in `SubplanExecutionService._execute_parallel()` (line 272 of `subplan_execution_service.py`): ```python max_workers = min(self._config.max_parallel, len(statuses)) ``` This correctly caps workers, but there is no test that exercises 10+ concurrent subplans to verify the `ThreadPoolExecutor` handles the load correctly. ### Missing test coverage - No BDD scenario tests parallel execution with 10+ subplans - No integration test verifies the system scales to 10+ concurrent subplans - The `large_project_decomposition.feature` tests decomposition but not parallel execution at scale ### Code location - `src/cleveragents/domain/models/core/plan.py`, lines 524-529 (`SubplanConfig.max_parallel`) - `src/cleveragents/application/services/subplan_execution_service.py`, line 272 (`_execute_parallel`) - `features/large_project_decomposition.feature` (missing 10+ parallel scenario) ### Impact - The M6 acceptance criterion "Parallel execution scaling to 10+ concurrent subplans" cannot be verified without explicit configuration override - No test coverage ensures the system actually works at 10+ concurrent subplans - The default of 5 may be insufficient for large hierarchical plans ## Subtasks - [ ] Add BDD scenario that executes 10+ subplans in PARALLEL mode - [ ] Verify `ThreadPoolExecutor` handles 10+ workers correctly - [ ] Consider whether the default should be raised to 10 per M6 requirements - [ ] Add integration test for parallel scaling ## Definition of Done - [ ] A BDD scenario exists that verifies 10+ concurrent subplans execute successfully - [ ] The scenario passes in CI - [ ] The `max_parallel` default is documented with the M6 scaling requirement - [ ] All nox stages pass - [ ] Coverage >= 97% --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: ca-new-issue-creator

freemo commented

2026-04-05 06:45:44 +00:00

Author

Owner

⚠️ Orphan Issue — Manual Linking Required

This issue was created without a known parent Epic. Per CONTRIBUTING.md, every issue must be linked to a parent Epic using Forgejo's dependency system (child blocks parent).

A project maintainer must:

Identify the appropriate parent Epic for parallel execution / subplan scaling work (likely under the M6 Autonomy Hardening epic)
Create the dependency link so that this issue blocks the parent Epic

Until this is done, this issue is considered an orphan and should not be moved to State/Verified.

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

⚠️ **Orphan Issue — Manual Linking Required** This issue was created without a known parent Epic. Per CONTRIBUTING.md, every issue must be linked to a parent Epic using Forgejo's dependency system (child **blocks** parent). A project maintainer must: 1. Identify the appropriate parent Epic for parallel execution / subplan scaling work (likely under the M6 Autonomy Hardening epic) 2. Create the dependency link so that this issue **blocks** the parent Epic Until this is done, this issue is considered an orphan and should not be moved to `State/Verified`. --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: ca-new-issue-creator

freemo added this to the v3.5.0 milestone

2026-04-05 06:53:09 +00:00

freemo referenced this issue

2026-04-05 06:53:25 +00:00

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

freemo referenced this issue

2026-04-05 07:06:25 +00:00

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

freemo referenced this issue

2026-04-05 09:01:27 +00:00

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

freemo referenced this issue

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

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

freemo commented

2026-04-06 18:46:44 +00:00

Author

Owner

Milestone Triage Decision: Moved to Backlog

This configuration issue has been moved out of v3.5.0 during aggressive milestone triage. While important for large-scale performance, it does not block basic autonomy hardening functionality.

Reasoning:

v3.5.0 focus: Essential autonomy hardening (guard enforcement, A2A facade, plan lifecycle)
This issue: Parallel subplan configuration limit - scalability optimization
Impact: Large-scale performance, not basic functional capability

Will be addressed in a future milestone focused on performance optimization and scaling.

**Milestone Triage Decision: Moved to Backlog** This configuration issue has been moved out of v3.5.0 during aggressive milestone triage. While important for large-scale performance, it does not block basic autonomy hardening functionality. **Reasoning:** - v3.5.0 focus: Essential autonomy hardening (guard enforcement, A2A facade, plan lifecycle) - This issue: Parallel subplan configuration limit - scalability optimization - Impact: Large-scale performance, not basic functional capability Will be addressed in a future milestone focused on performance optimization and scaling.

freemo removed this from the v3.5.0 milestone

2026-04-06 22:40:01 +00:00

freemo commented

2026-04-06 22:40:15 +00:00

Author

Owner

This issue has been moved to the backlog as part of an aggressive grooming of the v3.5.0 milestone. It has been deemed non-critical for the minimal viability of the milestone and will be addressed in a future release.