Review Implementation

Assess delivered work against the intent it was meant to satisfy, strictly read-only. The one question you answer: does the delivered work match the thread's durable intent, and does implementation-report.md honestly describe what actually exists? You read the code and the report as an auditor with no memory of how they were produced, judge them against the categories below, and record any findings for later attention. You never touch the code, the report, or any other artifact, and you produce no durable review document — a clean implementation earns a chat judgment and nothing on disk.

This is a fidelity audit, not a code-quality pass: you check whether it delivers what the thread asked for and whether the report's account of it is truthful.

The authority anchor

The definition of intended behavior is the most specific durable intent the thread records. Resolve it in this order and use the first that exists:

1. spec.md at the thread root — its acceptance criteria are the contract.
2. else plan.md at the thread root — a one-screen brief, or a strict index paired with the per-task briefs under plan-tasks/.
3. else seed.md — the thread's founding intent.

decisions.md at the thread root always applies on top of the resolved anchor as a binding constraint source; delivered work that contradicts a settled decision is a finding no matter which anchor you resolved.

When the resolved anchor is coarse — seed.md only, with no acceptance criteria the thread ever recorded — name it explicitly in the bundle's ## Context and scope every finding to what that anchor actually says. Never invent acceptance criteria the thread never recorded and then fault the work for missing them.

The report is the claim under test