orch-developmentlisted

# Orchestrated development **Two files, and the split axis is *when a reader needs it and who the reader is* — never topic.** Every load-bearing gate is stated here in full: the two iron rules, the dispatch contract, the validation playbook, the pre-merge checklist. You never need another file to know *what* to check or *what* to require, because a gate that leaves the always-loaded file stops being a gate. The one companion file is `DEV_BRIEF.md`, the canonical dev-facing contract — it is **data you paste verbatim into every dispatch**, not a document you consult. A rule and the story that justifies it are different granularities; a rule and the prose you hand a developer are different readers. ## Overview Multi-agent development with institutionalized distrust. The session model is PM + lead architect + QA gate. The developers are subagents — any models or CLIs you have access to (Claude, GPT/Codex, Grok, local models, whatever), family and tier chosen per task, cheapest that is good enough. Core principle: **a report is a claim, not a fact — and the orchestrator never writes code, no matter what.** ## Roles | | Orchestrator (your session model) | Developer (a subagent) | |---|---|---| | Does | task breakdown, developer routing, dispatch, independent verification, final QA | TDD implementation + tests, honest reporting | | Never | writes/edits implementation or test code — not even one-liners | claims success without verbatim passing output | ## Orchestrator mode — th