Receipts

An unverified "done" is a rumor. This skill turns rumors into records.

Breaking this rule in letter is breaking it in spirit.

The Iron Law

NO "DONE" CLAIM WITHOUT FRESH VERIFICATION EVIDENCE

The verification command must run in THIS message. A run from an earlier message proves nothing about the current state.

The INCONCLUSIVE verdict

A verification that ran but proved nothing is INCONCLUSIVE — never a pass: the command errored mid-run, the output was unreadable, the environment was wrong, or the evidence covered something other than the claim. INCONCLUSIVE is a first-class verdict alongside done and NOT done; it closes the unit honestly (report what was inconclusive and why) and forbids gating on it. Silence about an inconclusive run — reporting "done" because something ran — is the covered-up failure this rule exists to kill.

The Gate Function

BEFORE stating any result or feeling satisfied:

1. IDENTIFY: which command would prove this claim?
2. RUN: the full command, fresh and complete
3. READ: every line of output, the exit code, the failure count
4. VERIFY: does the output actually support the claim?
   - If NO: report the real status, evidence attached
   - If YES: make the claim, evidence attached
5. ONLY THEN: the claim exists

A skipped step is not a shortcut — it is a lie told in installments

Gate semantics

Every receipt proves exactly what its gate measured — nothing more. "Tests pass" attests that tests ran green; it is silent about requirements, about done-ness, about whether the UI looks right. Those each need a gate of their own, and a gate of their own receipt. And hitting a limit — round cap, token budget, clock — is a stop, not a success: report it as a stop. Every receipt should be readable as two lists: what this evidence proves, and what it leaves unproven.

Categorical gate (deterministic picker)

A verdict written as a sentence lets the model freelance. A verdict composed from categorical features cannot. Commit to the booleans, then let the verdict assemble itself:

1. Every constraint satisfied — yes / no (name the constraints: requirements checklist, acceptance criteria)
2. Evidence fresh — yes / no (the verifying command ran in THIS message, not a previous one)
3. Scope held — yes / no (no drive-by changes outside the request)
4. Subject verified — yes / no (the claim's object was checked: tests cover the changed code, the UI shows real data)
5. Fail-first proven — yes / no (for any claim about new production behavior: the failing test was observed BEFORE the implementation existed — the fail-first cycle was actually run, not assumed)

Compose: all five yes → "done with evidence". Any no → NOT done — report the failing feature(s) with the exact evidence that disproves each. A verdict without the five booleans is an opinion, not a receipt.

Fail-first proven — the mechanical gate

The fifth boolean exists because "dont trust anyone even themselves" means a condition that can be checked mechanically is checked mechanically, not left to the model's self-assessment. A claim that new production behavior works is only trustworthy if the fail-first cycle was actually run:

• yes requires the fail-first cycle was observed: the test FAILED against the pre-implementation code, then PASSED against the implementation. The failing run is the evidence — a test that passes immediately against user-supplied code is verification of a claim, not of a spec.
• no when the fail-first cycle was not run or not observed. This is a hard no for any new-behavior claim — it cannot be waived by confidence, by "the test is simple", or by a passing run alone.
• n/a when the claim is not about new production behavior (a refactor with no behavior change, a docs edit, a config change). n/a is a deliberate answer, never a silent skip — state why the claim is not new-behavior.

The fail-first proven boolean is the mechanical seam: it is what a pre-commit hook or CI gate can check for, so the discipline survives even when the model would rather skip it.

The enforced receipt shape

This repo enforces the receipt's shape, not just its presence (scripts/receipt-enforcement.mjs, pinned by eval check 45): the four blocks (Verdict / Evidence / Open / Next) with each of the five booleans carrying its own evidence line — a blanket "all five hold" is not a verdict and is rejected by name. The labels are fixed English tokens — never translated (Verdict / Evidence / Open / Next, plus the measured / inferred / guess markers); the body under each label follows the user's language. The template:

**Verdict** — <one-line summary>
constraints satisfied — <the constraint list / acceptance criteria checked>
evidence fresh — <literal repo-gate command + result, e.g. node scripts/doctor.mjs → OK, this turn>
scope held — <files in / out of scope>
subject verified — <the artifact checked, not a proxy>
fail-first proven — <RED evidence cited, or n/a with the reason>
**Evidence** — <the outputs cited above>
**Open** — <what remains>
**Next** — <one concrete forward arrow>

Rules the validator enforces:

• The repo-gate allowlist: a cited verification command must be a repo gate the PROJECT declares as its proof — a proof-commands fenced block in its AGENTS.md, else the run steps of its own .github/workflows/*.yml. The allowlist resolves from the project being graded, never from this framework's tree: a project that declares nothing gets an explicit "no proof commands declared" refusal, not a silent empty set. "tests pass" without a command is not evidence, and a non-allowlisted command is rejected.
• The fast one-line receipt: a fast unit still carries a receipt — one line: claim, one allowlisted command, its result. Nothing truly skips.
• The staleness window: a claim older than 14 days (RECEIPT_STALE_DAYS) is stale by computation and must be re-verified — its cited gates re-run through the hardened runner — before it may gate anything. Statuses: fresh / re-verified / stale / unverifiable; only fresh and re-verified may gate.
• The veto: the commit veto denies when the newest ledger entry lacks a valid receipt, or its claim is stale — bypassing the receipt cannot land.

Common Failures

Operational claims

Claims about systems, not code — where "the command ran" is not "the state changed". Each needs its own receipt shape (live exhibit: a data-fix script whose filter matched 0 rows was reported as "migration applied"):

Class rules:

• Name the target identity — which DB, branch, tenant, environment, commit. A fresh green receipt for the wrong target is a false receipt.
• Never claim "exactly once" because one send succeeded. Either name the idempotency invariant, or state at-least-once with the duplicate-safety explicitly declared. Delivery guarantees are declared, never inferred from a happy run.
• Receipt each part of a multi-part operation — a fix spanning several tables/regions/channels is only "done" when every part shows its own state; a silently half-applied operation becomes the next incident's root cause.
• Partial success gets a recovery decision on record — complete the remainder, roll back, or accept-and-log; the choice is stated with evidence, not defaulted to silence.

Labeled claims (prose discipline)

Every prose claim in a receipt or report carries its evidence or its label in the same sentence: measured (you ran it), inferred (you reasoned from evidence), or guess (you are speculating). An unlabeled assertion is an opinion wearing a receipt's clothes. Examples:

• ✅ "measured: node scripts/doctor.mjs → OK, installation healthy"
• ✅ "inferred: the drift came from the rebase, because both failing suites touch rebase-touched files"
• ❌ "the drift came from the rebase" (unlabeled — is it measured or a guess?)
• ❌ "this should work now" (a guess wearing a verdict's clothes)

Lesson capture

A repair that leaves no lesson behind will be repeated. The corrective tier (.trust/lessons.md) must be fed on every repair — regardless of which skill drove the fix:

• Before accepting a fixed/done/repair claim, check the lesson exists: the root cause and its imperative correction are in .trust/lessons.md (feature-named root cause, imperative correction — the make-it-so repair format). A missing lesson is a hole in the receipt: either the driving skill writes it (make-it-so repair loop does), or write the one-line lesson yourself in the same message — root-cause has already produced the material.
• The check is a read, not a ceremony: one appended line, not a new process. What is forbidden is silence — a "fixed" receipt whose incident left no trace in the corrective tier.

This rule lives in receipts, not only in make-it-so, because receipts is MANDATORY — forced into every delegation and loaded before any done claim — so the corrective tier cannot depend on the user remembering to invoke a user-invoked skill.

Proof Command Template

Each repo declares its own proof commands in its own AGENTS.md. The table shape:

If the repo declares none, derive the commands from package.json scripts and say so.

Red Flags — STOP

• Any sentence containing "should", "probably", or "seems to"
• Satisfaction expressed before verification ran ("Great!", "Perfect!", "Done!")
• A commit/push/PR about to happen on unverified work
• Verification treated as authorization — a fresh receipt proves the work; the commit/push/PR itself still rides Iron Law 4's human sign-off (make-it-so: commit is never a self-serve action)
• An agent's success report taken at face value
• Verification that covered only part of the claim
• The thought "just this once"
• Visual or subjective quality asserted from an automated receipt — a deterministic receipt proves the check ran; visual sign-off is a separate gate
• ANY wording implying success before verification has run

Rationalization Table

Key Patterns

Tests:

✅ [Run test command] [See: 42/42 pass] "All tests pass"
❌ "That should be green now" / "Looks right to me"

Regression tests (fail-first):

✅ Write → Run (pass) → Undo the fix → Run (MUST FAIL) → Re-apply → Run (pass)
❌ "I've written a regression test" (without fail-first verification)

Requirements:

✅ Re-read spec → Create checklist → Verify each → Report gaps or completion
❌ "Tests green, so this phase is wrapped"

Agent delegation:

✅ Subagent says success → Read the VCS diff → Verify the changes → Report the true state
❌ Trust agent report

Behavioral / UI evidence (per-assertion record):

✅ test_start → assertion: passed / failed / untested (with reason — never silently skipped)
   → state the exact commit + branch tested
❌ "Tested it, works" — no per-assertion record, no commit named