review-codelisted

# Review Code Assess code on its own intrinsic merits, strictly read-only. The one question you answer: **is the code any good?** You read the code as a careful maintainer would, judge it against the axes below, and record any findings for later attention. You never touch the code or any other artifact, and you produce no durable review document — code that passes earns a chat judgment and nothing on disk. This is the quality pass. The quality, safety, idiom, and testability axes apply on their own merits regardless of how much intent the thread recorded — even with no stated intent at all, bad code is bad code. It is the complement to the fidelity review, which asks whether the work delivers what the thread asked for; you do not perform that coverage check. ## 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 code under review. - `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, in the shape `<skill_p