cleveragents/cleveragents-core
4
0
Fork 3
Code Issues 6.0k Pull Requests 115 Actions Packages Projects Releases Wiki Activity

docs(spec): document DEPENDENCY_ORDERED subplan execution mode
ci.yml / docs(spec): document DEPENDENCY_ORDERED subplan execution mode (push) Failing after 0s
Details

Browse Source 
Add the DEPENDENCY_ORDERED execution mode to the Child Plan Execution
Modes section. This mode performs topological sorting of subplan
dependencies and executes independent subplans concurrently in waves.
Also adds the dependency-ordered row to the failure handling table.

Closes #4034
This commit is contained in:
Jeffrey Phillips Freeman
2026-04-06 09:20:16 +00:00
parent 0c9a537948
commit 658b86c976
1 changed files with 9 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/specification.md
+9
View File
@@ -18508,6 +18508,14 @@ The `local/plan-tools` skill references this tool (and others) by name:
Parallel execution is bounded by `SubplanConfig.max_parallel` (default: `5`, range: 1–50). This cap prevents runaway resource consumption when a large number of child plans are spawned simultaneously. The runtime uses a `ThreadPoolExecutor` with `min(max_parallel, len(subplans))` workers. The `SubplanConfig` model also controls `merge_strategy` (default: `git_three_way`), `fail_fast` (default: `false`), `timeout_per_subplan_seconds` (default: `null`), `retry_failed` (default: `true`), and `max_retries` (default: `2`).
=== "Dependency-Ordered"
When child plans have explicit dependencies on each other, the `DEPENDENCY_ORDERED` execution mode respects those dependencies while maximizing concurrency. The dependency graph is provided as a `dependency_graph: dict[str, list[str]]` mapping each `subplan_id` to the list of `subplan_ids` it depends on.
The runtime performs a topological sort to determine execution order, then executes independent subplans (those whose dependencies are all satisfied) concurrently in "waves". Subsequent waves wait for the previous wave to complete. Circular dependencies are detected and raise a `ValueError`.
This mode is useful when child plans produce artifacts that other child plans consume — for example, a code generation plan that must complete before a test plan can run.
##### Child Plan Failure Handling
!!! note "Failure Semantics"
@@ -18515,6 +18523,7 @@ The `local/plan-tools` skill references this tool (and others) by name:
| :------------- | :--------- | :------- |
| **Parallel** | One child fails | Other child plans ==continue== |
| **Sequential** | One child fails | Subsequent child plans ==not started== |
| **Dependency-Ordered** | One child fails | Dependent child plans ==not started==; independent plans ==continue== |
!!! tip
An "error" only occurs if an exception is thrown by the application (a bug). Plan failures (e.g., tests don't pass) are handled within the plan's logic, not as application errors.