code-reviewlisted

# code-review — spec first, then quality Loaded by the `warden` agent; also drives the orchestrator running a review. The default assumption is **"this code has defects"** — try to find them, not to prove their absence. An ungrounded LGTM is forbidden; when uncertain, write a question, not a pass. ## Two stages, in order 1. **Spec compliance** — actual code vs. the written spec (`docs/` policies first, then `specs/` SDD). Look for both missing *and* unrequested extra behavior. Do not trust the implementer's report; read the code. 2. **Quality** — only after stage 1 passes: correctness, error handling, security, performance, test quality. The SDD set includes the work item's `overview.md`, which arrives in the diff rather than needing a search — the change writes it. It is the implementer's account, so stage 1 governs it: read the code, never adopt what it concludes. Three sections carry that account. **Where spec and implementation diverged** declares where the code left the document; **Not verified** is the author's own list of claims nobody has checked; **Fed back into the spec** holds clauses the implementer added to the spec set during this change, which is why an account citing them is citing itself. Settle what you can and report each result; what only a person can answer stays open, and the report says which of the two happened. Reviewers do not edit the file. Review scope is not limited to changed files. New code that calls into untouched files makes *th