doc/REVIEW_02.md: require reading SPEC.md before any finding

Hoist the "re-read SPEC.md" step out of position 2 into a bold
preamble + step 1, with rationale: the spec is the contract these
refactors must preserve, and the build-phase log in §9 explains why
a "complicated" pattern landed that way (R02-N02 itself was a
classic example — the JS mirror's three historical hotfixes were
all driven by edits that didn't first reload the partial's
contract).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

doc/REVIEW_02.md

@@ -34,12 +34,20 @@ REVIEW_01.
 
 ## How to use this with /loop
 
-1. Pick the lowest-numbered `open` finding whose severity ≥ MEDIUM.
-2. Re-read SPEC.md §5 (capacity math), §7 (audit), and §9 (phase log)
-   to confirm the invariant the simplification must preserve.
+> **Before starting on any finding, read `SPEC.md` end-to-end.** It is
+> the contract these refactors must preserve — vanilla JS, strict CSP,
+> Twig auto-escape, audit-row-per-mutation, the capacity math in §5, the
+> audit logging rules in §7, and the build-phase log in §9 (which often
+> records *why* the "complicated" pattern landed that way). A
+> simplification that silently breaks any of these is a regression, not
+> a fix. Most findings here are pure internals so SPEC.md will not need
+> editing — but you can only know that after reading it.
+
+1. Read `SPEC.md` in full (at minimum §5, §7, §9). Skip this step and
+   you will land R02-N02-style hotfixes a week later.
+2. Pick the lowest-numbered `open` finding whose severity ≥ MEDIUM.
 3. Apply the rewrite, add/adjust tests, update SPEC.md if a public
-   contract changes. Most findings here are pure internals — no spec
-   touch required.
+   contract changes.
 4. Commit; flip Status to `fixed-in-<sha>` and add a one-line note.
 5. Commit the doc update separately.