The Kill Test

What you'll be able to do: answer the one question every safety system owes you — how do I know it actually works, before I trust it with anything real? You'll take any repo with a CI gate and prove three things in one sitting: the alarm catches bad work, the lock blocks bad work from publishing, and a repair can flow back through the same gate. Begin with the end in mind: you will deliberately break your own project, watch the machine refuse it, and watch it heal.

Choose your door

Builder — before reading anything: open a branch called killtest, break one thing on purpose (flip a sign, invert a condition), open a PR, and watch what turns red.
Architect — this module chains all five primitives into one closed loop, then attacks the loop to test it: truth, judge, laws, and human judgment.
Translator — it's a fire drill: you don't discover whether the alarm works during a real fire. Start at the Bridge below.
Validator — work the Gates at the bottom; confirm first that CI has been green once, branch protection is on, and your invariant tests pass.

Translator Bridge

A commercial kitchen installs a health-inspection station at the pass: no plate reaches the dining room without the expeditor's check. The kill test is the day the head chef deliberately sends out a bad plate — undercooked, on purpose, labeled — to prove three things: the expeditor catches it (the alarm), the plate physically cannot reach the dining room (the lock), and a corrected plate flows back through the same pass without special treatment (the repair).

Where the analogy ends: the expeditor is human and can be sweet-talked, tired, or bribed. CI cannot. That's the whole point of the chassis: the judge is deterministic — it doesn't care who cooked the plate, who asks nicely, or whether you own the restaurant (enforce_admins means even the chef-owner gets refused). Also: a real bad plate is wasted; a kill-test branch costs nothing — its net change is zero and it merges or closes cleanly.

Builder Track (DO FIRST)

Break it, on a branch. On a fresh branch off the default branch, reintroduce a real historic bug — mine was flipping -math.pi/2 + deflect to - deflect in a small game of mine, in the ball physics, the exact bug that once shipped. Commit with an honest message: "kill test: deliberately broken." Push, open the PR. You should see: the PR opens normally — nothing stops a proposal.
Watch the alarm. Wait for CI. You should see: red, fast (mine: 11 seconds), and precise — 3 deflection invariants failed, the other 8 passed. Precision matters: it caught THE bug, not everything.
Try to publish the lie. Run the merge command on the red PR. You should see: REFUSAL — "base branch policy prohibits the merge." This is the lock, distinct from the alarm. A gate you never saw hold is not a proven gate.
Hire a blind repair. Hand a separate AI (or colleague) ONLY the raw failing CI log and the one broken file — no explanation, no history. Ask for the minimal fix as exact old-line → new-line. You should see: the correct fix from mechanical context alone. Mine came back byte-perfect in one round-trip (three allowed). Count your round-trips.
Heal through the same gate. Apply the fix on the same branch, push. You should see: CI reruns green. Merge with the standard one-liner — now it works, because the truth changed. Log the result where your project keeps state (STATE OF BUILD), dated, with all three criteria.

Architect Track (MODEL FIRST)

Three separable guarantees, often confused: the alarm (CI turns red on bad work), the lock (the platform refuses to merge red — server-side branch protection with the required check being the JOB name from the workflow, enforce_admins: true), and the repair channel (a fix flows through the same branch → PR → CI → merge path as any other change; no side door for emergencies). Why a deliberate break instead of waiting for a real one: you control the blast radius, you know the correct answer in advance so you can grade the repair, and the branch's net change is zero. Why the repair must be blind: the future automated mesh will hand its architect nothing but logs and files — if a human relay with only mechanical context works, the machine relay will too. The kill test is the PROVING primitive pointed at your own safety system.

Validator Gates

Pass each gate before moving on. These are permission to advance, not hazing. Confirm first: CI runs on your PRs and you've seen it green at least once; branch protection is ON for the default branch (check with gh api repos/OWNER/REPO/branches/BRANCH/protection — a JSON wall, not a 404); your invariant tests exist and pass; you know the one-line merge command and the one-line revert.

Gate 1: I saw CI fail on the broken PR, and the failures named the exact invariants that describe the bug.
Gate 2: I ran the merge command on the red PR and was refused by policy (not by my own restraint).
Gate 3: A repairer with only the CI log + the broken file produced the correct fix, in ≤3 round-trips.
Gate 4: The fix merged through the normal loop — no admin override, no direct push.
Gate 5 (active recall): Write it in your own words — what is the difference between the alarm and the lock? ______________

Lesson complete — you can now prove, not assume, that a truth machine catches, blocks, and survives bad work; every automation you build on top of it inherits that proof.

The graduation build

This module IS the graduation build for the Chassis tier. From scratch, in one session, no guidance: take any repo with tests, stand up the gate (Modules 1–5), then run this kill test on it. Completion criteria:

A deliberately broken PR went red, and you can name which test caught it and why.
The merge of the red PR was refused by branch protection, with enforce_admins on, and you watched it refuse YOU.
A blind repair (log + file only) fixed it in ≤3 round-trips and merged green through the normal loop.
The lap is logged, dated, in the project's state file.
You can explain what each step does to someone who has never seen it.