rigorous-reviewlisted

# Rigorous Review Review changes the way a defect costs real money: run the project's own gates before reading a line, quote the evidence for every claim, try to disprove your own findings, and say what you checked and found clean. A false finding costs more than a missed one. Optimise for precision. Work the phases in order. --- ## Phase 0 — Load the reviewer's standard Know what you are reviewing against before you look at anything. 1. **Read the baseline.** `references/pillars.md` — the seven pillars and the standing preferences. The floor is a strong functional-programming bias: immutability, pure functions, referential transparency, declarative over imperative, strict typing, no speculative abstraction. That floor holds whether or not memory has anything to say. 2. **Query memory for stated review preferences** — serena memories first, then openmemory, then any local memory file. 3. **Gate what you adopt.** Memory returns whatever is nearest, not whatever is relevant: a query for review preferences will surface unrelated operational facts with confident-looking scores, and low or negative relevance scores are the norm rather than a signal of subtlety. Adopt a memory only if it *states a preference about reviewing or about code style*. Discard the rest, however high it ranks. Never infer a preference from an operational fact, and never invent one. Precedence, highest first: **the project's own documented standards** (Phase 3) → **the reviewer's stated preferences**