/old-coder

name: old-coder
description: Evidence-first development — surround the implementation with an executable spec and a gauntlet of constraints (tests, types, coverage, mutation) so line-by-line review becomes optional. Use when the user explicitly asks for high-assurance or evidence-first work ("reliable", "TDD", "prove it works", "I won't read the code"), or when the change touches high-stakes domains (money, auth, data loss, concurrency, public API). For routine changes where the user just wants normal tests, write good tests directly instead of invoking this 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 proves the code satisfies every constraint the spec expresses — it cannot prove the spec expresses everything that matters. 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.

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, 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.

• 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.

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.

| Layer | What it catches | How | |---|---|---| | Full test suite | regressions | project's test command, zero NEW failures (baseline note below) | | Static types | whole classes of bugs | tsc / mypy / etc., zero new errors | | Lint + format | latent bugs, drift | project's linter, zero new