red-green-prooflisted

# Red-Green-Proof A bug is not fixed because the tests pass. A bug is fixed when a test **fails without your fix and passes with it**, and you have watched it do both. Most "regression tests" written after a fix never had the chance to fail. They are decoration. This skill is the discipline that separates a real test from a decorative one. ## Picking the target **With an argument**, that is the target: `/red-green-proof the status endpoint reports finished runs as running`. **With no argument, take the target from the conversation.** The usual case is that you have just spent a long stretch investigating something — the bug is already on screen. Do not ask what to work on. Scan back through the session and pick, in this order: 1. A defect just identified but not yet fixed. 2. A fix applied without a failing test to back it — the most valuable target, because the test still has to be proven load-bearing. 3. A test written but never verified red. 4. Something described as "still open", "not fixed yet", or "characterization only". State your pick in one line and start: > Target: the buffer discards events when the flush write fails (`checkpointBuffer.ts:271`). Verifying before writing the test. Only ask the user if two or more candidates are genuinely equal in priority — then list them as a short numbered choice and stop. If several *related* defects came up, handle them one at a time through the full loop rather than batching; each needs its own red. If nothing in the