self-reviewlisted

# Self-Review Run an explicit second-pair-of-eyes pass on non-trivial work before declaring done. Quality of review depends on quality of question. ## When to RUN self-review - More than ~30 lines OR multi-file change - Hot path (many requests flow through this code) - Subtle interactions with code you might have missed - Prompt or output affecting user-visible content - Code not worked in recently (mental model might be stale) - Any genuine uncertainty after writing the change ## When to SKIP self-review - One-line edit, mechanical fix, obvious diff - Pure rename or move with no logic change - Code just written with full context, low blast radius - Cost-benefit doesn't justify (review takes longer than the fix did) If skipping, say so explicitly: "Skipping self-review — N-line trivial fix." Don't silently bypass. ## How to execute ### Step 1 — Set context (3-5 lines max) State, in plain language: - The bug / feature / what was asked - The cause (what was actually wrong) - The fix (what was actually changed) ### Step 2 — List specific changes ``` - path/to/file_one.ts:L123-L145 — replaced regex with structured parser - path/to/file_two.ts:L56 — added null guard for empty corpus - path/to/config.json — bumped diversity_threshold 0.6 → 0.75 ``` ### Step 3 — Ask 4-6 specific verification questions **Bad asks (do not produce useful answers):** - "Is this good?" - "Does this look right?" - "Any issues?" - "Did I miss anything?" **Good asks (concrete, falsifiable, nam