An answer to a question is not an approval

[drmikecrowe]

Step 1 tells the agent to get the spec approved, but never says what approval is. So any adjacent agreement gets read as it.

Observed failure. The agent asked the human three decision questions, got three answers, and wrote: "All three approved — that matches the spec as written. Committing the approved spec now." It then implemented. The human had answered questions. They had never approved a spec.

Two additions close it.

Approval is defined by what it is not — an answer to a question you asked, a "go ahead" about some other step, silence, or the request that started the task. If you cannot quote the words that approved this spec, you do not have approval.

A question you asked is a hole in the spec. The answer fills it, which changes the spec — so an approval given before the question was answered 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.

The recommended-option shape makes this especially easy to get wrong. When the human picks the options you recommended, the spec appears unchanged and consent appears implied. Neither is true.

Also in here, one line: name the spec file 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.

+14 lines, all in SKILL.md step 1. No behavioural change to the gauntlet.

---

Part of a series from a fork that has been running this skill daily (drmikecrowe/old-coder). Each PR stands alone; opening as drafts so you can take them in any order, or none.

🤖 Generated with Claude Code

[AmazingAng]

Merged, and this one went in fastest of the five because of what it protects.

Spec approval is the only step in the whole skill that breaks the everything-authored-by-one-agent correlation. Everything else — spec, tests, implementation, checkers, and the report that grades them — has a single author. If an adjacent answer can be read as approval, then spec approval: obtained appears at the top of an EVIDENCE report describing work no human ever approved, and the skill's central claim is false while every layer stays green.

Your framing is sharper than the rule I would have written: the question you asked is a hole in the spec, the answer fills it, so any approval you held beforehand is approval of a document that no longer exists. That is the part I want to keep verbatim.

What the series made visible

Taken together with #8 and the isolation half of #9, these are not three separate improvements. They are three instances of one failure mode, and this project has now hit five:

• a coverage layer that printed a percentage and exited 0 (found here in Independent verification: what six fresh-context rounds found in a gauntlet that was already green #4)
• a must_not_match gate that failed closed perfectly while guarding a spelling rather than a behaviour (Independent verification: what six fresh-context rounds found in a gauntlet that was already green #4)
• a mutation runner scoring a mutant it never executed (Independent verification: what six fresh-context rounds found in a gauntlet that was already green #4, and your Prefer the real mutation tool, and make a hand-rolled runner prove it ran #8)
• an approval that was an answer to a different question (your An answer to a question is not an approval #6)
• a green suite reported from a worktree that could not have run it (your Config and isolation: where settings live, and staying out of the user's tree #9)

A mechanism that reports success while doing nothing. Each fails in the direction that looks good, so no red gauntlet ever surfaces it, and the human — who by construction is not reading the code — has no second route to find out.

Notice that only one of those five is a home-grown checker. The existing checker note covers exactly that one case, which turns out to be the narrow end of the problem: the others are an off-the-shelf tool, a human interaction, and an environment.

So rather than patch each site, I am going to state it once near the top of SKILL.md as the failure this skill is most exposed to, with the test attached: when you add a check, a gate, or any step that produces a claim, ask what it does when it is broken; if the answer is "reports success", it is not yet a check. The specific rules then hang off it and get shorter, including a light trim of the paragraph this PR added — the "why it matters" half will be stated above it rather than inside it. Nothing of the substance goes.

Credit where it is due: it took an outside fork running this daily to make the pattern visible. Thank you for that.