old-coder

# 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