review-implementationlisted

# 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 acceptan