verify-before-donelisted

# Verify before done A green build is not evidence. A passing test proves that the function under test does what it should; it does not prove that the system calls it. The gap between those two sentences is where the bugs that reach users live. Before you write "done", "fixed", "working" or "deployed", produce one artefact from the list below. If you cannot, say what you could not verify instead of softening the claim. ## The rule > Every statement about system state needs a receipt: command output, an HTTP > response, a database row, a screenshot, a received message, or a real > scheduled execution. "Should work now" is not a result. Neither is "the tests pass". ## Pick the check that matches the change | What changed | What counts as evidence | | --- | --- | | HTTP route, API | `curl -s -o /dev/null -w '%{http_code}'` against the deployed URL, plus one response body assertion | | Anything visual | A screenshot from a real browser at a real viewport, looked at | | Database write | A `SELECT` that returns the row, run after the write | | Scheduled job | The next real execution, read from the scheduler's own log | | Outgoing mail | The received message, opened. Not the send log | | Mobile widget, background task, OS integration | A real device, app closed, across one full cycle | | Package published | Install it fresh into an empty directory and import it | | Config or secret change | The consuming process, restarted, doing the thing that needs it | ## Failure modes th