\r \r

Taku Review - Delivery Gate\r

\r Review decides whether the change can ship. It is not a long critique and it is\r not a nit collector.\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] Hard stops come before concerns. Do not bury a blocking delivery\r failure under style comments.\r \r

Review Contract\r

\r Read the current diff against the base branch or, when there is no remote diff,\r the local dirty diff. Then output exactly three sections:\r \r

HARD STOPS\r
- [none | blocking finding list]\r
\r
CONCERNS\r
- [none | non-blocking risks worth fixing or noting]\r
\r
SUMMARY\r
- Changed files: [...]\r
- Verification evidence: [...]\r
- Scope/spec status: clean | drift | requirements missing | unknown\r
- Residual risk: none | [...]\r
- Status: DONE | BLOCKED | DONE_WITH_CONCERNS\r
```\r
\r
Use `BLOCKED` whenever a hard stop exists. Use `DONE_WITH_CONCERNS` only when\r
remaining issues are non-blocking and explicitly listed.\r
\r
## Step 1: Detect Base and Diff\r
\r
Run the repo-appropriate equivalent of:\r
\r
```bash\r
git remote get-url origin 2>/dev/null\r
git branch --show-current\r
git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||'\r
git status --short\r
git diff --stat\r
```\r
\r
If on the base branch with no local diff, stop cleanly:\r
\r
```text\r
HARD STOPS\r
- none\r
\r
CONCERNS\r
- none\r
\r
SUMMARY\r
- Changed files: []\r
- Verification evidence: not applicable; no diff\r
- Scope/spec status: clean\r
- Residual risk: none\r
- Status: DONE\r
```\r
\r
Do not invent findings when no code changed.\r
\r
## Step 2: Reconstruct Intent\r
\r
Read the strongest available intent source:\r
\r
- Build ledger from `/taku-build`\r
- `PLAN.md`\r
- approved Quick mini design\r
- `DESIGN.md`\r
- user request in the current session\r
- commit messages\r
\r
Then compare intent to delivered changes.\r
\r
Hard stops:\r
\r
- **Scope drift:** unrelated files, behavior, or refactors not approved.\r
- **Missing requirement:** approved behavior absent from the diff.\r
- **Unapproved deviation:** Build recorded a deviation that was not approved.\r
\r
Approved deviations are not hard stops, but must be listed in `SUMMARY`.\r
\r
## Step 3: Check Verification Evidence\r
\r
Review the observed evidence, not confidence statements.\r
\r
Hard stops:\r
\r
- The implementation claims completion but no test/build/lint/manual command\r
  evidence is visible.\r
- Verification output is stale or from before the relevant code changed.\r
- Required TDD anchor or reproduction check is missing.\r
\r
If evidence is unavailable because the repo has no harness, say what was used\r
instead. Do not claim tests passed unless output or explicit user evidence shows\r
that.\r
\r
## Step 4: Critical Pattern Pass\r
\r
Read the full diff before commenting. Search for production-risk patterns:\r
\r
- SQL/query injection from string-built user input\r
- Prompt injection or unvalidated LLM output crossing a trust boundary\r
- Missing auth checks or overly broad permissions\r
- Conditional side effects hidden in ternaries, short-circuits, or optional chaining\r
- Race conditions, shared mutable state, or non-atomic read/modify/write\r
- Resource leaks that can exhaust connections, files, streams, or listeners\r
\r
High-confidence critical/security bugs are hard stops. Apply a fix directly\r
only when the correct change is clear from local context. Otherwise provide the\r
smallest safe recommendation and keep status `BLOCKED`.\r
\r
## Step 5: Concern Pass\r
\r
Only after hard stops are handled, list non-blocking risks:\r
\r
- error paths that degrade behavior but do not block shipping\r
- weak type/null handling with bounded blast radius\r
- missing cleanup where impact is limited\r
- maintainability issues that make a follow-up risky\r
\r
Skip nit floods. If a style pattern matters, mention it once.\r
\r
## Auto-Fix Policy\r
\r
- Auto-fix Critical and Important findings when the fix is clear and locally\r
  verifiable.\r
- After an auto-fix, run the smallest relevant verification.\r
- Do not commit, push, or open a PR.\r
- Do not mix review with broad refactoring.\r
\r
## Output Rules\r
\r
- `HARD STOPS` must appear first.\r
- Every hard stop needs a file/line or artifact reference when available.\r
- `SUMMARY` must include changed files, verification evidence, residual risk,\r
  and status.\r
- If Review finds scope drift, missing requirements, or missing verification,\r
  status is `BLOCKED` until fixed or explicitly approved by the user.\r
\r
## Known Pitfalls\r
\r
**Nit flood hides the real issue.** A review produced 40 style comments and one\r
SQL injection finding. The developer fixed the easy comments and missed the\r
security bug.\r
\r
Prevention: hard stops first; concerns second; style notes only when they change\r
delivery risk.\r
\r
**Review accepts a build summary as evidence.** The summary said "tests pass",\r
but no command output was visible.\r
\r
Prevention: completion claims need observed command output, diff evidence, or\r
explicit user-provided evidence.\r
\r
**Scope drift looks like cleanup.** A task approved `--json` output, but the diff\r
also rewrote command discovery.\r
\r
Prevention: reconstruct intent before code-quality review. Good code outside\r
scope is still a delivery failure.\r