mini-SDLC stage 2: frontier-tier complexity-dispatcher — depth-scaled lanes + upward-summarization contract (child of #513)

[kyle-sexton]

This was generated by AI during triage (decomposition intake, rule 8f).

Part of #513.

Scope (from the control-tower plan comment on #513)

The management-chain tier: the orchestrator spawns an Opus dispatcher that evaluates a ticket's complexity, reads the sizing declared in the T2 plan (plan-driven, orchestrator override), and spawns the right-sized worker chain. Sizing scales depth per lane — a lane collapses from a dispatched fresh-context subagent to an inline lightweight check, and from N rounds to 1 — every lane in the shape always runs; no lane is ever omitted. The dispatcher also owns the upward-summarization contract: chatty coordination stays low in the chain, the dispatcher returns only identifiers + verdict + parked payload to the orchestrator.

Files: the Stage 1 SSOT's depth-tier semantics; work/SKILL.md (dispatcher-tier step); brief templates for the dispatcher.

Acceptance criteria

• Depth tiers name depth levels, not lane subsets.
• A trivial ticket still traverses every lane (at minimum depth); a complex ticket deepens each lane — no lane is ever skipped.
• Dispatcher return payload matches the existing return-payload contract (context-economy pattern already established elsewhere in this pipeline).
• The per-ticket nested chain-depth cap and its interaction with the existing across-ticket concurrency cap are wired to configuration, not hardcoded.
• This is the throughput lever for the whole mini-SDLC — treat depth-tier correctness as the core acceptance bar.

OPERATOR DECISION (unresolved — this stage is gated on it, not resolved here)

• Depth-tier taxonomy: names of the depth levels, and whether depth is carried as a T2-plan field (RECOMMENDED — matches the settled plan-driven heuristic) or a label.
• Concurrency knob names + the nested per-ticket chain-depth cap default (new; the across-ticket cap already exists elsewhere).
• Sizing source-of-truth field name in the T2 plan (couples to the depth-tier taxonomy decision above).

Prerequisite

Depends on Stage 1 (mini-SDLC stage 1: durable pipeline-shape SSOT + work-skill wire-in, child of #513, tracked as #613) — do not start until that lands.

STOPGAP NOTE: plain child issue pending the #552 native sub-issues convention — convert when #552 lands.

[kyle-sexton]

Decision brief — depth tiers, concurrency knobs, T2-plan sizing field

Human-operator decision brief. This comment decides nothing; it only frames the three coupled OPERATOR DECISION items so you can approve or redirect. Parent epic #513, prerequisite Stage 1 #613.

Problem (2 sentences)

The Stage 2 Opus dispatcher can't be built until it has concrete strings to read and write: the names of the depth levels, the field in the T2 plan that carries a ticket's size, and the name + default of the new per-ticket chain-depth cap (alongside the already-existing across-ticket cap). All three are naming/default choices, they are interdependent (the field's allowed values are the depth-tier names), and #613 deliberately left them as placeholders — so this is one coherent decision, not three.

What's verified today (from the repo, not memory)

• The existing across-ticket cap already has a name and default. plugins/work-items/skills/work/SKILL.md (Step 1, execute): "the intended maximum concurrent dispatch waves is ${user_config.work_dispatch_concurrency_cap}" and "the concurrency default mirrors /implementation:implement-dispatch's 3–5 wave cap." The mirrored source is plugins/implementation/skills/implement-dispatch/SKILL.md: "Cap concurrent dispatch waves at 3–5 workers." A sibling knob work_cycle_batch_cap (per-cycle item budget) exists in the same paragraph. Enforcement of both is not yet wired — tracked in work-items:work — work_dispatch_concurrency_cap / work_cycle_batch_cap are documented but not wired to any enforcement mechanism #573 (implement-dispatch still applies its own internal 3–5 cap and reads no userConfig).
• Config-key convention is settled and consistent. userConfig keys are work_…-prefixed snake_case, dereferenced as ${user_config.KEY}. Adjacent numeric limits follow the same style: the tracker CONTRACT.md limits block uses sub_item_depth: 8, sub_items_per_parent, list_items_max — note sub_item_depth is the issue-tree depth cap, a different concept from agent-chain depth, but it establishes the _depth noun for a nesting-limit key.
• No formal "T2 plan" schema exists. "T2 plan" is work-items(work): per-issue execution should compose installed skills as a role-separated mini-SDLC (implementer ≠ reviewer ≠ verifier, ephemeral fresh-context agents) #513's term for the Tier-2 plan the triage lane writes (work-items(work): per-issue execution should compose installed skills as a role-separated mini-SDLC (implementer ≠ reviewer ≠ verifier, ephemeral fresh-context agents) #513 triage question: "per-issue in the T2 plan — triage lane already writes plans"). That plan/brief is prose per plugins/work-items/reference/agent-brief.md (behavioral contracts, no file paths). So there is no field registry to match — the only naming precedent is the snake_case config/limits style above.
• Nesting budget is a stated convention, not a verified platform limit. work-items(work): per-issue execution should compose installed skills as a role-separated mini-SDLC (implementer ≠ reviewer ≠ verifier, ephemeral fresh-context agents) #513 / CLAUDE.md state "nesting is available up to 5 levels." This is the tightest number anchoring the new cap; I did not verify a platform-enforced ceiling.

RECOMMENDED — one coherent proposal

1 + 3 (collapsed deliberately into a single field). Decision 1 already asks "field vs label" for the depth tier, and decision 3 asks for the field that carries sizing — these are the same field. Carry it as a T2-plan field, not a label (matches the settled plan-driven heuristic; labels are for coordination/routing state, not per-execution guidance, and this avoids label-taxonomy churn):

• Field name: depth_tier
• Allowed values (the depth-tier taxonomy): shallow | standard | deep

These name depth levels, not lane subsets, satisfying the issue's core AC directly. Numbered tiers (T1/T2/T3) were considered and rejected: T-numbering already collides with priority tiers, source-evidence tiers, and triage's own T1=trivial usage — named levels are self-documenting and collision-free. The dispatcher reads depth_tier from the plan; the orchestrator may override at dispatch (plan-driven, orchestrator override, per #513). "Variation in depth, never in shape" holds: shallow collapses each lane toward inline / 1 round, deep deepens each — no lane is ever skipped at any tier.

2 — concurrency knobs. Keep the existing cap as-is and add the new one following the same work_…_cap shape and the _depth noun from sub_item_depth:

Knob	Scope	Default	Status
work_dispatch_concurrency_cap (exists)	across-ticket: max concurrent dispatch waves	3–5 (mirrors implement-dispatch)	unwired, #573
work_chain_depth_cap (new, this stage)	per-ticket: max nested agent-chain depth	5, counted from the orchestrator root	to be wired with #573

Default 5 = the stated 5-level nesting convention (#513/CLAUDE.md), counted as total depth from the orchestrator root (orchestrator L1 → Opus dispatcher L2 → lane worker L3 → sub-worker L4 → L5). Stating the counting basis is load-bearing: from-root 5 is coherent and encodes the invariant; if instead counted beneath the dispatcher it would permit L6 and should be ~3. The cap is what makes depth-collapse graceful — when a deep ticket's chain would exceed it, a lane flattens to inline rather than nesting past the budget. Both knobs are userConfig snake_case with a manifest default; a surviving literal ${user_config.…} placeholder means unset → apply the manifest default.

Reversibility: HIGH. Nothing consumes these strings yet — enforcement is unwired (#573) and #613 shipped the tier names as explicit placeholders. Renaming the field, the tier values, or the cap key later is a cheap find-replace, not a migration.

Alternatives (if you veto)

• A — separate size input, derived tier. T2 plan carries size (e.g. S/M/L or trivial/typical/complex); the dispatcher derives depth_tier from it. Keeps the human-facing sizing vocabulary independent of the internal depth mechanic (useful if sizing later drives things beyond depth). Cost: two names to keep in sync, and a derivation rule to specify now. Reversible.
• B — chain-depth cap default 3, conservative. If you'd rather reserve nesting headroom than spend the full stated budget by default, set work_chain_depth_cap: 3 (from root) and let deep tickets ratchet up via config. Trades some designed depth for a wider safety margin. Reversible.
• C — depth as a label, not a field. Rejected in the recommendation but available: a depth:* label instead of a plan field. Makes tier queryable/filterable at the tracker but couples execution guidance to the label taxonomy and contradicts the plan-driven heuristic; not recommended.

Cross-links

Parent epic #513 · Stage 1 prerequisite / placeholder-owner #613 · cap-enforcement wiring #573 · return-payload contract #496.

One approval unblocks all three: reply "yes" to take depth_tier: shallow|standard|deep + work_chain_depth_cap: 5 (from root), or name your substitutions.

[kyle-sexton]

Design input from a Codex review on #861 (pipeline-shape SSOT, #613): the dispatcher this stage builds must reconcile the mandatory Plan lane with autonomous execution.

The Plan lane in the pipeline shape is realized by /planning:plan, whose Step 5 "Present for Approval" is a non-negotiable human gate ("the user is the terminal gate"). But /work-items:work claims a lease and dispatches autonomously with no approval handoff — so once this stage makes the lanes actually dispatch, an unattended run would park at the Plan lane's approval gate before reaching implementation.

This is not a Stage-1 doc concern (the SSOT makes no runtime claim; nothing dispatches lanes yet), which is why it's deferred here rather than patched into the shape doc. It becomes a live bug the moment this dispatcher lands. Three materially-different remedies to choose among when designing the dispatcher (an author/operator decision, not a default):

1. An approval-free / autonomous planning variant for the Plan lane (the dispatcher invokes a non-gated planning path in autonomous mode).
2. A stop-before-claim condition (an item requiring human plan-approval isn't claimed autonomously).
3. An explicit approval handoff mechanism (the dispatcher parks the plan for async human approval, then resumes).

Source: #861 thread https://github.com/melodic-software/claude-code-plugins/pull/861#discussion_r… (Codex P1, 2026-07-21).

[kyle-sexton]

Operator design constraint (attended session 2026-07-23): the dispatcher must express routing as ordered capability tiers (frontier / strong / fast) resolved through live model aliases at runtime — never a hard-coded family or dated model name, including in this issue's own title/framing ("Opus complexity-dispatcher" should become tier-worded). Authority: loop-lane convention §3 (order-defined tiers, alias-only resolution). Complements the reviewer-≥-implementer and security-surface→frontier rules already fixed there.