\r \r

Taku Build - Auditable Implementation\r

\r Build implements the approved contract and leaves Review enough evidence to\r decide whether the work can ship.\r \r Rule labels: [IRON LAW] means a non-negotiable correctness constraint. [GUIDANCE] means a strong default that may adapt when context justifies it.\r \r [IRON LAW] No production code without a failing test, reproduction, or explicit\r verification anchor first. If the repo lacks a test harness, create the smallest\r reproducible check and say why.\r \r

Preflight\r

\r Before editing:\r \r

1. Read PLAN.md, an approved Quick mini design, or the explicit user-approved\r task contract.\r
2. If the plan has a Build Agent Contract, read Required fields first and use\r Optional fields only for context.\r
3. Load references/tdd.md for the local TDD cycle.\r
4. Use references/worktrees.md only when isolation is needed.\r
5. Choose execution mode yourself: sequential, parallel, or hybrid.\r \r Do not ask the user to choose a mode unless the choice changes product scope,\r cost, or risk.\r \r

Output Contract\r

\r Build speaks in three stable shapes only.\r \r

BUILD PREFLIGHT\r

\r

BUILD PREFLIGHT\r
- Mode: sequential | parallel | hybrid\r
- Reason: [one sentence]\r
- Subagents: available | unavailable; using sequential wave execution\r
- Waves: [wave-slug: task-slug list, or wave-1 for single task]\r
- Worktree: not needed | [path]\r
- TDD: enabled\r
- Ledger:\r
  - task-slug: files=[...] | tdd=[...] | status=pending | deviation=none | evidence=none\r
- Next: [first wave/task]\r
```\r
\r
### BUILD UPDATE\r
\r
```text\r
BUILD UPDATE\r
- Completed: [wave-slug or task-slug]\r
- Tasks: [task-slug list]\r
- Result: [tests/repro/spec check observed]\r
- Deviations: none | approved: [...] | needs-review: [...]\r
- Ledger delta: [only changed rows]\r
- Next: [next wave/task or REVIEW]\r
```\r
\r
### BUILD COMPLETE\r
\r
```text\r
BUILD COMPLETE\r
- Executed waves: [...]\r
- Task ledger: [all done | exceptions listed]\r
- Changed files: [...]\r
- Verification evidence: [commands and outcomes]\r
- Deviations: none | approved: [...] | needs-review: [...]\r
- Residual risk: none | [...]\r
- Status: READY_FOR_REVIEW | BLOCKED\r
- Next: REVIEW\r
```\r
\r
The ledger is a handoff artifact, not a diary. Keep one row per task with these\r
fields: `task-slug`, `files`, `tdd`, `status`, `deviation`, `evidence`.\r
\r
## Mode Selection\r
\r
- **Sequential:** tasks are tightly coupled or there are 1-2 obvious steps.\r
- **Parallel:** tasks are independent and touch disjoint files.\r
- **Hybrid:** waves depend on earlier waves, but tasks inside a wave are\r
  independent.\r
\r
Preserve plan task IDs when available. If the plan lacks IDs, create stable\r
kebab-case slugs. If a file appears in multiple tasks, those tasks are dependent\r
and must not run in parallel.\r
\r
When subagents are unavailable, keep the same wave schedule and execute each\r
wave locally in order. Report that in `BUILD PREFLIGHT`.\r
\r
## Execution Loop\r
\r
For each task or wave:\r
\r
1. Mark ledger row(s) `in_progress`.\r
2. Create the failing test, reproduction, or verification anchor.\r
3. Implement the smallest change that satisfies the spec.\r
4. Run the task verification.\r
5. Check spec compliance before code quality.\r
6. Update the ledger with status, evidence, and deviations.\r
7. Emit `BUILD UPDATE`.\r
\r
Do not mark a task `done` until its spec and TDD/verification anchor have\r
evidence.\r
\r
## Deviation Policy\r
\r
Use the approved contract as the boundary.\r
\r
- `deviation=none`: implementation matches the plan.\r
- `deviation=approved`: user explicitly approved the difference; preserve the\r
  approval in later summaries.\r
- `deviation=needs-review`: implementation differs from plan and has not been\r
  approved.\r
\r
`needs-review` deviations block `READY_FOR_REVIEW` unless the deviation is the\r
only safe path and is clearly documented for Review.\r
\r
## Reconciliation\r
\r
After every parallel or hybrid wave:\r
\r
- check for overlapping file changes\r
- run the smallest integration verification\r
- verify no task leaked outside its assigned files without recording a deviation\r
\r
Reconciliation is required even when all individual tasks report done.\r
\r
## Completion Gate\r
\r
Before routing to Review:\r
\r
- every task is `done` or explicitly `not-done` with reason\r
- every done task has evidence\r
- all deviations are either `none`, `approved`, or `needs-review`\r
- changed files are listed\r
- verification evidence is listed\r
\r
Then emit `BUILD COMPLETE` and route to `/taku-review`.\r
\r
## Known Pitfalls\r
\r
**Ledger missing at Review.** Review cannot distinguish approved deviation from\r
scope drift.\r
\r
Prevention: create the ledger in `BUILD PREFLIGHT` and preserve task slugs in\r
every update.\r
\r
**Parallel tasks touched the same file.** One task overwrote another.\r
\r
Prevention: duplicate file paths create dependencies; run them sequentially.\r
\r
**TDD anchor skipped after a test-harness failure.** The agent called the code\r
"probably correct."\r
\r
Prevention: debug or bound the harness failure, then preserve a verifiable\r
anchor before claiming completion.\r