Evidence-First Development Loop

Old Coder: Reliable Coding Under Constraint and Test

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.

Composition with old-coder-api: when both skills apply, this skill owns workflow order, SPEC approval, the gauntlet, and EVIDENCE; old-coder-api owns the HTTP/JSON contract. Run its scope check and API gates while drafting SPEC, turn the surviving constraints and risks into acceptance criteria and checks, then map those checks into EVIDENCE. Do not run two parallel workflows.

The Loop

SPEC → (human approves spec, not code) → RED → GREEN → REFACTOR → GAUNTLET → EVIDENCE
                                          ↑_____________________|
                                              repeat per behavior

1. SPEC — the only thing the human reads before code

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

• Write behaviors as Gherkin-style scenarios or a named test list — concrete inputs, concrete expected outputs, edge cases, and error cases. "Handles bad input" is not a spec; divide(1, 0) raises ZeroDivisionError with message X is.
• Include what the change must NOT do (invariants that must survive: existing tests, public API signatures, performance budgets if stated). These negative constraints are contract clauses like any scenario: each must end up mapped in EVIDENCE to a test, a gauntlet layer, or an explicit skipped-with-reason line — never silently absent from the mapping.
• The spec doubles as the authorization point: include the setup plan — tools to install, git usage (init? checkpoint commit cadence?), files the gauntlet will add by path, and every new dependency with a one-line justification (prefer the standard library and deps already present; an unjustified package is a spec defect) — so approving the spec authorizes the environment changes in one step instead of N interruptions, and the human can veto a risky package before it is ever installed.
• Show the spec to the human in plain language and get approval before writing implementation. In autonomous mode, state the spec in your response and proceed — but the correlation-breaking review never happened, so EVIDENCE must record spec approval: not obtained (autonomous run) and claim correspondingly lower confidence; the spec becomes the artifact the human reviews after the fact.
• An answer to a question is not an approval. If you asked the human to decide something, they answered that question and nothing else. Their answer is an INPUT to the spec, and it CHANGES the spec — so any approval you held before the question is approval of a document that no longer exists. Questions and approval are two exchanges, in that order: fold the answers in, say what changed, show the revised spec, ask again. If you cannot quote the words that approved THIS spec, you do not have approval — an answer to your question, a "go ahead" about some other step, silence, and the request that started the task are none of them approval. The recommended-option shape makes this easy to get wrong: when the human picks the options you recommended, the spec looks unchanged and consent looks implied, and neither is true.
• The spec is append-only during the task. If implementation reveals the spec was wrong, say so explicitly and revise it visibly — never silently drift.
• Write the spec to a file and name it by absolute path. A relative path is not clickable in a terminal, so the human cannot open the one artifact they are being asked to approve. Same for EVIDENCE when you get there. The SPEC and Gherkin templates are in references/templates.md.
• Commit the spec at approval where the repo's git conventions allow it — the setup plan is where that was authorized. Once the approved spec is a commit, later drift is literally a git diff. Without a durable spec, a compaction loses the approved contract while the code it authorized remains, and nobody can check whether a scenario was quietly dropped from the EVIDENCE mapping.

2. RED — prove each test can fail

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:

• If the module under test doesn't exist yet, create a stub that raises (e.g. NotImplementedError) so the test fails on behavior, not on import — a collection error is a weaker RED than an assertion failure.
• Related behaviors may share one RED run, as long as each new test is individually observed failing.
• If a new test passes immediately, it is either vacuous (fix it) or the behavior already exists. Don't just assert which — prove it: break the implementation with a one-off throwaway mutant, watch the test fail, restore. Then record it as pre-existing behavior kept as regression armor.

3. GREEN — minimal implementation

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

4. REFACTOR — clean up under green, assertions frozen

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:

• Implementation refactors touch no test files at all.
• Test-structure refactors (extracting helpers and fixtures, deduplicating setup) are allowed as a separate step: assertions unchanged, suite green before and after, then rerun mutation to confirm the restructured tests still kill — a refactor that blunts the tests is a silent hole in the gauntlet.
• Anything that requires editing an assertion isn't refactoring, it's a behavior change and belongs back in SPEC.

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

5. GAUNTLET — the constraint stack

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.

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 || true, no 2>/dev/null, 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.