Current state
A developer reading any ADR in the 005 → 006 → 009 → 012 → 013 → 014 chain concludes a different (and wrong) mental model of how task dispatch works. ADR 005 concludes "TUI keypress → tmux split"; ADR 012 supersedes it with the task dispatch loop; ADR 013 partially supersedes 012; ADR 014 partially supersedes 013. Each ADR's addendum points to the next ADR in the chain — not to a current authoritative document — so the chain never terminates. A developer researching dispatch or session launch reads the chain, draws a plausible model, and implements against integration points that don't match the current code. This affects dispatch, session launch, completion detection, and prompt injection — exactly the high-risk areas most likely to be touched.
Ideal state
docs/architecture/task-dispatch.md is the single authoritative description of dispatch as currently built.
- Each ADR in the chain (005, 006, 009, 012, 013, 014) has its addendum updated to point to
docs/architecture/task-dispatch.md rather than to the next ADR, so the chain terminates at a readable, current document.
- A developer reading any ADR in the chain immediately sees "for the current implementation, read
docs/architecture/task-dispatch.md."
Out of scope
- Rewriting or deleting ADRs — they document rationale history and should be preserved.
- Restructuring the docs/ directory.
Starting points
docs/decisions/005-agents-and-prompts.md — first ADR in the chain
docs/architecture/task-dispatch.md — the architecture document that should be the terminal reference
QA plan
- Open
docs/decisions/005-agents-and-prompts.md — expect its supersede note to link to docs/architecture/task-dispatch.md.
- Open
docs/decisions/012-task-dispatch-loop.md — expect the same.
- Open
docs/decisions/013-session-file-signals.md — expect the same.
- Open
docs/architecture/task-dispatch.md — expect it to describe the dispatch system as currently built, not a planned state.
Done when
Any ADR in the 005–014 supersede chain redirects the reader directly to docs/architecture/task-dispatch.md, which describes the system as currently implemented.
Current state
A developer reading any ADR in the 005 → 006 → 009 → 012 → 013 → 014 chain concludes a different (and wrong) mental model of how task dispatch works. ADR 005 concludes "TUI keypress → tmux split"; ADR 012 supersedes it with the task dispatch loop; ADR 013 partially supersedes 012; ADR 014 partially supersedes 013. Each ADR's addendum points to the next ADR in the chain — not to a current authoritative document — so the chain never terminates. A developer researching dispatch or session launch reads the chain, draws a plausible model, and implements against integration points that don't match the current code. This affects dispatch, session launch, completion detection, and prompt injection — exactly the high-risk areas most likely to be touched.
Ideal state
docs/architecture/task-dispatch.mdis the single authoritative description of dispatch as currently built.docs/architecture/task-dispatch.mdrather than to the next ADR, so the chain terminates at a readable, current document.docs/architecture/task-dispatch.md."Out of scope
Starting points
docs/decisions/005-agents-and-prompts.md— first ADR in the chaindocs/architecture/task-dispatch.md— the architecture document that should be the terminal referenceQA plan
docs/decisions/005-agents-and-prompts.md— expect its supersede note to link todocs/architecture/task-dispatch.md.docs/decisions/012-task-dispatch-loop.md— expect the same.docs/decisions/013-session-file-signals.md— expect the same.docs/architecture/task-dispatch.md— expect it to describe the dispatch system as currently built, not a planned state.Done when
Any ADR in the 005–014 supersede chain redirects the reader directly to
docs/architecture/task-dispatch.md, which describes the system as currently implemented.