reviewlisted

# Review Two questions, answered independently and reported side by side: is the code *well made* (Standards), and is it *the right thing* (Spec)? One review that mixes them lets charm on one axis hide failure on the other. ## 1. Fix the review point Resolve what "the changes" means: an explicit commit/branch/tag from the user, else the merge-base with the default branch (`git merge-base HEAD origin/main`). The diff since that point — plus untracked files — is the entire review surface. State the resolved range before reviewing. ## 2. Run both axes — as parallel sub-agents Dispatch two sub-agents, each with the diff and its own brief; neither sees the other's findings (independence is the point). **Standards axis.** Reviews against what the repo *documents*: CLAUDE.md / AGENTS.md rules, CONTRIBUTING, lint/format configs, glossary terms for naming (a fresh needs.json supplies them, ADR_0006). Personal taste that no document backs is out of bounds — at most a closing note suggesting the rule be recorded (`/decide` or a term) if it keeps coming up. **Spec axis.** Walks the traceability chain: the originating issue (cited `ISSUE_xxxx` via needs.json, or GitHub `#n` via `gh issue view` + its `Implements:` line) → the linked requirements' shall-statements → any accepted decisions touching this area. Then three checks against the diff: - **Delivered?** Each shall-statement demonstrably satisfied (or explicitly deferred). - **In scope?** Changes beyond what the issue asked