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 the implementation's report 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. ## Inputs Gather all of these before judging; the procedure below works from what you gather here. - `docs/adr/`, read via `/consult-adrs` — the project decisions bearing on the reviewed work. - `docs/glossary.md`, read via `/consult-glossary` — the project's fixed terms, to be used in everything you write. - **The implementation folder under review** — the primary input, in one of two accepted forms. When the invocation **names a folder** under `implementations/`, that folder is the form; otherwise the form is the **newest folder under `implementations/` by stamp**. It is the boundary of what this review covers. - That folder's `report.md` — the implementer's account of the delivered work and the cla