---
description: "Planner rules for parallel units, dependency evidence, context telemetry and autonomous recovery."
agents: [planner]
task_types: [orchestrated-execution, execution-sequence]
triggers: [orchestrated lanes, execution:compile, Execution Sequence]
---

# Planning orchestrated execution

Single DEV is always the recommended default, at every plan size. Orchestration requires an explicit user choice. When chosen, complete `aioson execution:configure . --feature={slug} --json` in the main monitoring chat before launch: explicit host, model AND effort per implementation role, QA and integration supervisor, then the reviewed summary and confirmation. Follow `.aioson/docs/dev/execution-lanes.md` § Role configuration wizard; a saved profile or Autopilot never answers the wizard.

- The execution choice is a quality/coordination trade-off, not a speed promise. Single DEV usually minimizes wall-clock and handoff overhead for coherent work. Orchestration buys fresh bounded contexts, per-lane host/model routing and independent DEV → QA review, but each unit may add review, recovery and final-integration time; it can therefore take substantially longer even with parallel waves. Explain this compactly when asking, cite measured unit/critical-path shape, and never invent hours without comparable historical evidence. When offering orchestration, name `aioson execution:dashboard . --feature={slug}` as the local live view of waves, active units, elapsed time, models, findings, recovery and integration status; closing the panel does not stop the executor.
- One row per UNIT (one process, one context), never per phase: cut a phase per lane inside its wave (`1-backend`, `1-frontend`) with an `## Interface Contract` row (`IF-*`) per boundary; a row over the unit ceiling (`plan.scale.units[].over_budget`: 10 files or 6 ACs) is cut again on disjoint files; small serial rows of one lane may merge. Exact Delta/Delivery paths, no globs.
- `Wave`: positive integer, ascending; rows sharing a wave run in parallel on disjoint `Files` — up to 10 unit pipelines, including several units from the same logical lane — and `spec:analyze` blocks `wave_file_overlap`.
- Optional `Depends on`: earlier rows this one needs (`1-backend (dev)`: when implemented; a bare phase number = every row of that phase, written `2` or `Phase 2`) — it starts when they pass, not with its whole wave. A parenthesis that is not `(dev)`/`(qa)` is a note (`1-backend (mod.rs and lib.rs)`), never part of the name; an unknown label is refused, never read as "every row of the phase whose number it contains".
- ACs per unit: a row that lists AC ids owns exactly those, and the ceiling counts them; the other ACs of its capabilities travel as context. A row that cites only a CAP owns every AC of that CAP.
- Verification cells may mix commands and human checks (`` `npm test` + smoke: open the app ``). Backticked commands are what the final integration supervisor runs; parts that read as a person's check (smoke, walkthrough, inspection, real AI session, desktop app) are handed to the owner as deferred manual verification and never block the run.
- Shared integration files go to a later solo row, never to two rows of one wave; one lane with one row per wave is serial by construction (`orchestration_serial`).
- Build waves from real prerequisites, not phase numbers: independent units from different phases share the earliest safe wave. Add `Depends on` for consumed artifacts and shared-file ordering; justify each edge with its file or interface. `(dev)` lets the implementation start on the dependency's implementation while the engine still makes this unit's review wait for the dependency's review, so it is the default for consumed code; use a plain edge (after QA) only when the consumer must read reviewed output before it can even start. Never invent an edge merely because a row was written first.
- Infer those edges with Jev when it is ready: after drafting the table run `aioson execution:dependencies . --feature={slug}`. It judges every same-lane pair from metadata only (paths, the Implementation Delta change per path, CAP and AC behaviour) and prints, per row, the minimal confirmed `Depends on` cell and the earliest safe wave, the pairs left to decide, and the projected makespan as written versus suggested. Write the confirmed cells and waves; settle each "to decide" pair from the plan's evidence, keeping it as a dependency when the plan cannot prove otherwise; then compile. When it answers `jev_unready`, tell the user once, in their language, what Jev would add to this plan (real dependencies, more units in parallel, the projection) and the steps it printed — the key in the git-ignored project `.env`, `"jev": { "enabled": true }` in the git-ignored `aioson-models.json`, then `aioson jev:judge . --check` — and continue from the plan's evidence alone. Never ask for the key in the chat.
- Keep each `Done when` executable inside that unit's ownership. A frontend unit may verify an approved interface contract before backend integration exists. Assign capability-wide and end-to-end checks to an explicit integration row after all producers, retaining every CAP/AC; never copy an integration test into both workers as a local blocker.
- Trace each generated artifact to its real runtime consumer before assigning ownership: a render graph, request payload or generated file is not delivered merely because its builder test passes. Include transport, process invocation and temporary-resource cleanup in the same unit when its local acceptance needs them, or name a later integration owner and defer those acceptance checks explicitly. Check target-platform limits with the complete production payload and supported input sizes; a reduced fragment is insufficient evidence. Never reduce requested output to make a local test pass.
- Context is telemetry, never an execution ceiling: the engine lets the host run to completion and reports the model window plus observed peak use when the harness exposes them. Legacy `max_fraction`, `max_tokens`, `max_continuations` and per-model `max_tokens` policy fields are accepted but ignored. Missing window/usage data is unknown, never an inferred value.
- There is no AIOSON token or wall-clock cutoff. Keep each unit focused by behavior and ownership anyway: the engine stops four identical structured actions or 24 consecutive read-only actions so an authorized fallback can take over, permits only one automatic retry of an equivalent failure with no measured source change, and stops after five QA → DEV returns for one unit. A genuinely larger unit must be split; elapsed time and context use remain telemetry.
- For large existing files, `Read ranges` may declare bounded initial reads as `src/editor.ts:1-60; src/editor.ts:400-480` (owned files, inclusive valid lines). Inspect the relevant functions first; the compiler measures selected bytes and keeps full file size, while workers resolve moved symbols with focused searches and expand as required to finish and verify the unit.
- For authorized Autopilot, make technical repair ownership explicit with separate DEV and QA roles. The engine defaults to continuous DEV → QA recovery; use `--bounded-recovery` only when finite retries are requested. Both backend and frontend inherit the DEV lane profile and their configured models. When `integration_dev` is configured, the engine automatically runs one final correcting integration supervisor over the combined result and then the shared independent QA; without that role, unowned integration rows remain with the supervising session. Do not force product decisions or unavailable capacity into technical retries.

## Execution Sequence shape

```markdown
## Execution Sequence
| Phase | Wave | Files | Scope | Done when |
|---|---|---|---|---|
| 1-backend | 1 | src/api/real.ext, tests/api/real.test.ext | CAP-{slug}-main | api command passes |
| 1-frontend | 1 | src/ui/Real.ext, tests/ui/Real.test.ext | CAP-{slug}-ui | ui command passes against IF-001 |
```