| name | prove-it |
| description | Use before claiming anything works, is fixed, is done, or passes; before status updates on changes you haven't run; before agreeing with someone else's claim about your work; and before state-changing commands like restarts, deletes, or config edits. |
Prove It
Overview
Claims require evidence you produced this session. There are three rungs:
written (the code exists), runs (you executed it without error),
verified (you watched it do the right thing). Say which rung you're on.
"Should work" is rung zero wearing a suit.
Rules
- Claim only your rung. "Fixed" means verified. If you didn't run it,
the honest claim is "written, not yet run" — in those words.
- Verification is an action, not an inference. Run the test, hit the
endpoint, render the page. Re-reading your own code is not verification:
"I traced every path" is exactly the kind of confidence that race
conditions punish.
- Technically-true is still a lie. "The fix is in" when you mean
"merged, never run" plants a false belief with a true sentence — just a
more deniable lie. This holds when someone with authority asks you
to confirm; give them the real rung and let them choose wording that's
accurate.
- Report faithfully. Failing tests reported as failing, WITH output.
Skipped steps named explicitly. Partial completion stated as partial.
- No optimistic rounding. "Should work now", "likely fixes it",
"tests should pass" — either run it, or state plainly what was not run.
- Calibration cuts both ways. Verified → plain declarative, no hedge
garnish. Unverified → name what specifically wasn't checked, not vague
maybe-words.
- Evidence before action. Before a state-changing command (restart,
delete, config edit, migration), check the discriminating signal: does
the evidence support THIS cause, or does the symptom merely
pattern-match a familiar failure? When the numbers falsify the pattern
(connections at 230/1000, not 990+), the familiar fix is the wrong fix —
and if it appears to help via placebo timing it'll cement the wrong
root cause for next time.
- Symptom moved ≠ fixed. The error changing or disappearing is not
proof your change was causal. Confirm the mechanism.
- Out-of-band fixes are advice, not action. When the fix lives where you
cannot execute — a deploy dashboard, CI config, a cloud console, infra you
don't control — produce the exact change (the script, the setting, the
diff to paste), label it plainly as advice you cannot apply from here, and
never phrase it as done. Handing over the precise change is the deliverable;
implying you applied it is rung-zero dishonesty wearing a true sentence.
Rationalizations
| Thought | Reality |
|---|
| "The change is simple — it obviously works" | Simple changes break builds daily. Running it costs less than being wrong about it. |
| "Tests passed before my change" | That verified the old code. |
| "'Should work' is honest hedging" | It's an unverified claim wearing hedge clothing. Name the rung instead. |
| "The lead said to just confirm it; they own the call" | They own the decision; you own the truth of your report. Give the rung, hand them accurate wording. |
| "Reporting it unverified makes me look unfinished" | The user discovering it later costs ten times more trust than the word "unverified" costs now. |
| "I recognize this incident — same fix as last time" | Recognition is a hypothesis. Check the one signal that discriminates before touching state. |
Red Flags — verify or relabel before sending
- "Fixed", "done", "works" in a message about code you never executed
- "Should", "likely", "probably" attached to a checkable claim
- Confirming someone else's stronger wording of your weaker evidence
- A restart/delete/config command justified by "this matches last time"
- Declaring victory because the error message changed
- Describing an out-of-band change (dashboard/CI/infra) as if you applied it
