Claude Code First, specification version 0.1.0. The plain-language guide

Version 0.1.0. Grade R3/S3.

F304 Gates went red for reasons outside the change, and a red nobody could act on was ignored

Claim

In three projects a gate reported red for a cause unrelated to the change under test (a concurrent run, a build that never started, a runner without the needed desktop, a non-deterministic fixture), and the projects answered by narrowing what the gate may conclude rather than by telling the agent to rerun, on the stated ground that a false red trains everyone to ignore the true one.

Mechanism

A gate's colour is only information if red means the tree is wrong. A gate that is red for another reason costs a diagnosis each time and, once it is red on every run, stops being read, so a real failure arrives unnoticed beside the false ones. The remedies separate "the gate could not judge" from "the gate judged red": an inconclusive state, a lock, a deterministic input, or a narrower place to run.

Observations

• Shio. Two concurrent runs of one gate corrupted each other: a "measured collision reported 3 errors over 1092 tests where the tree alone reports 1894" [shio@821f18d74:scripts/run-gate.mjs#L57]

green, answered by one run per gate. A failed clean "was stamped as the suite's colour, twice (SH828)" [shio@77f9042f0], answered by a run that is "recorded as INCONCLUSIVE rather than red (SH828)" [shio@821f18d74:scripts/run-gate.mjs#L94]. The task filed between them is titled "a false red is worse than an absent stamp" [shio@be14dab5e]. The CI workflow that made the suites visible notes that "One of those two alarms turned out to be wrong" [shio@821f18d74:.github/workflows/suites.yml#L9], and that "a false alarm nobody answers is how a" [shio@821f18d74:.github/workflows/suites.yml#L10] suite's colour "stops meaning anything, and the next true one is then also unread." [shio@821f18d74:.github/workflows/suites.yml#L11]

• winwright. CI ran desk-dependent cases on a hosted runner: "Red since 2026-09-17 and never about the tree." [winwright@7a37e95]

"Twenty-odd pushes each produced a red nobody could act on" [winwright@7a37e95]. The workflow now runs only the desk-free half, because "A permanently red badge is one nobody reads, so the run that catches a real break" [winwright@861b82e:.github/workflows/ci.yml#L51] "arrives beside two that mean nothing." [winwright@861b82e:.github/workflows/ci.yml#L52] Separately, the skill's name check failed on UI Automation words, "so a skill saying them went red for a true and irrelevant" [winwright@861b82e:tests/Winwright.Tests/SkillTests.cs#L85] reason, and was narrowed to the tree's vocabulary [winwright@5fe977c].

• freewilly. DD64 registered "the budget gate that can go red for the wrong reason" [freewilly@f514e11],

and a later run corrected the diagnosis: "a second red run refutes the first" [freewilly@ecaad33]. The fix made the figures deterministic and asserted exactly [freewilly@c1c2eaf:agent-budget.json#L103].

Independence

Three independent origins, each a gate of that project on its own stack: Shio's gate runner and CI, winwright's hosted runner and skill test, freewilly's token budget test. No remedy was copied between them.

Counter-evidence

None found at the pins. The two winwright sources disagree on how long CI was red: the commit says since 2026-09-17 [winwright@7a37e95], the workflow comment that "it answered wrongly for three weeks" [winwright@861b82e:.github/workflows/ci.yml#L49]. The pins cannot settle it, and "twenty-odd pushes" is not a count: git records commits, not pushes.

Grade

R3: independent incidents in three projects. S3: Shio's collision is counted (3 errors over 1092 tests against 1894) and its SH828 red occurred twice. winwright's and freewilly's are dated incidents (S2). Not S4: Shio's inconclusive state and lock encode the remedy, and no source records them firing on a real run.