The human will NOT read your implementation. Their confidence comes entirely from two artifacts you produce: (1) an executable specification they approve before you write code, and (2) an evidence report proving the code ran the gauntlet. Your job is to make those two artifacts trustworthy enough that line-by-line review becomes optional within the spec's boundaries.

This inverts the normal review model: trust moves from inspection to constraints. Be honest about what that buys: the gauntlet turns the constraints the spec expresses into executable evidence — it cannot show the spec expresses everything that matters, and it is not self-authenticating, because a checker can be unsound and a mapping can claim more than it demonstrates. That is exactly why the human approves the SPEC (the one artifact that breaks the everything-authored-by-the-same-agent correlation), and why EVIDENCE reports layered, auditable confidence, never absolute proof. Every shortcut you take against the gauntlet destroys the only basis of trust.

Turn the request into executable acceptance criteria before touching implementation files:

Write the test for one behavior. Run it and watch it fail before writing the implementation. A test you never saw fail proves nothing — it may be testing nothing. Details that matter in practice:

Write the least code that makes the failing test pass. Run the full suite, not just the new test.

Minimal code is often ugly code. While the suite is green, improve names, extract duplication, and simplify structure. What is frozen is behavioral assertions, not test files wholesale:

Run the suite after each refactor. Repeat RED→GREEN→REFACTOR per behavior.

After all spec behaviors are green, run every applicable layer. Scale to the task (see "Calibration"), but never skip a layer silently — if a layer doesn't apply or a tool is unavailable, record that in the evidence report with the reason.

--cov-fail-under

diff-cover --fail-under

references/gauntlet.md

Baseline note — on a repo with pre-existing failures, record the baseline first (which tests already fail, verbatim) and hold the line at zero NEW failures. Fixing unrelated pre-existing failures is scope creep: surface them, don't silently "improve" them.

Mutation caveat — kills are attributed to whichever test fails first, so a 7/7 kill score validates the suite as a whole, not every layer in it. In Tier 3, rerun the mutants against the property suite alone before claiming the properties verify anything; survivors there mean the invariants have blind spots (a common one: a one-sided invariant like "never exceeds limit" cannot catch fail-closed bugs — pair it with the opposite bound).

Checker note — the gauntlet is only as trustworthy as its checkers, and the dangerous checker failure is fail-open: nothing crashes, the layer prints pass. Off-the-shelf tools (pytest, mypy, tsc…) have earned their failure behavior; home-grown checks — grep gates, custom scripts, the manual mutation runner — have not, so two rules apply to them: (1) fail closed — a crash, an unreadable input, an unexpected exit code, or an item silently skipped inside gate code is a hard failure of the layer, never a pass; no , no , no bare fallthrough. (2) Prove it can fail before trusting its pass: run it once against a known-bad input (a negative control) and watch it fail — the RED principle applied to checkers, exactly like the throwaway mutant for an immediately-passing test. Record the control in EVIDENCE. Be precise about what that buys: a negative control proves one known-bad case reaches the checker's failure path. It does not prove the checker recognizes every violation of the constraint it claims to enforce. A grep gate can fail closed perfectly and still guard a spelling rather than a behavior. When the gate's coverage is narrower than the rule it serves, say so where the rule is written, rather than letting the rule imply more.

Prove a negative control is itself non-vacuous the same way you prove a test: temporarily remove or break the defence it validates, and watch the control go red. A control that passes with the defence removed is measuring nothing — this is a one-time proof, not a permanent extra layer.

Equivalent-mutant note — with a mutation tool, a survivor is not automatically a failure: some mutants are semantically equivalent to the original and cannot be killed. Classify such survivors as "equivalent, because <reason>" in EVIDENCE rather than adding a meaningless test to kill them — that would violate anti-gaming rule 4. Hand-written mutants (the manual procedure) get no such excuse: you chose them, so choose real bugs.

End with a report the human can trust without opening a single source file (template in ):

The gauntlet only creates trust if it cannot be gamed. These are hard rules:

Scale effort to blast radius, and say which tier you chose:

The gauntlet is evidence, not self-authentication: its checkers can be unsound, its mappings can overclaim, and the spec can be incomplete. Human spec approval mitigates only the last, by breaking author correlation, and only before code exists — it does not make a spec complete.

Independent verification answers the rest where the stakes justify it: a fresh-context agent that attacks the finished work before EVIDENCE is signed. It reduces task-context correlation, not model correlation. It is not a gauntlet layer — a layer is an executable check with a machine-evaluable result; this is an agent returning prose a human must judge, spending the one resource this skill otherwise guards. Experimental: the evidence is one case study ( — for deciding whether to run this, not for the verifier to read), not a benchmark.

The protocol is

references/verifier.md

. Verification has not been performed until that file has been read in full and executed; missing or unreadable →

blocked

, never

passed

. What cannot be traded away:

If the project has no test runner, no linter, or no type checking, set up the minimal standard toolchain for the language first (see ). A gauntlet can't run on bare ground. Setup changes the user's environment — packages, config files, lockfiles — so it belongs in the SPEC's setup plan, where spec approval authorizes it in one step; record every environment change actually made in the evidence report. If the user forbids adding tooling, fall back to manual layers (manual mutation, manual execution) and record the reduced confidence honestly.

If the directory is not a git repository, propose in the SPEC's setup plan. Version control is itself a gauntlet layer: commit at SPEC and at each GREEN/REFACTOR checkpoint, so mutant restores are verifiable with (not by eyeball), a bad refactor is rolled back instead of debugged, and the final diff shows exactly what changed. Checkpoint commits happen only under that spec-approved authorization (or an explicit user request) — never impose a commit cadence on a repo whose owner hasn't agreed to it. If the user declines or git is unavailable, record that in EVIDENCE — mutant restores then rest on rerunning the suite, a weaker guarantee — and identify the source state with a tree hash instead of a SHA.