iterative-plan-review

## Project Context - CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f` - project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f` ## Review Approach - Read the full plan before challenging — an assumption that looks wrong in isolation may make sense in context. - Ground challenges in codebase evidence: "The API handler at `src/api/handler.go:47` returns XML, not JSON" is actionable; "This assumes the API returns JSON" is not. - Check overlap against existing code, not just the plan — the most valuable overlap findings are external utilities or patterns the codebase already has. - Ask practical ambiguity questions — "Should this handle concurrent access?" is only useful if there's evidence concurrent access actually happens. - **YAGNI is a first-class review pillar.** Apply the evidence-based YAGNI rule from [../../references/yagni-rule.md](../../references/yagni-rule.md) to every plan item the review touches — every behavior, plan step, abstraction, configuration knob, runbook, observability hook, infrastructure component, test category, ADR clause, or coding-standard line. Items that fail the evidence test or have a strictly simpler version available are first-class findings (`Category: YAGNI candidate`), not polish. Resolution paths: cite missing evidence and keep, replace with simpler version, or move to the plan's `## Deferred (YAGNI)` section with the reopening trigger named. YAGNI candidates are surfaced visibly to the user — never si...