---
name: seam-touched-red-needs-repeat-proof
description: BINDING (doyle-adopted 2026-07-27) — a CI red inside a seam the release just changed never files as a load flake on one observation
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 05ad48d2-2229-4f67-9c5b-7f322bec6a2e
  modified: 2026-07-30T01:25:44.780Z
---

A CI failure in a test that exercises a seam the shipping change TOUCHED does not close as a
load flake on one observation — even when the tree is content-identical to a green run and the
box was demonstrably loaded. The at-sha rerun is the FIRST leg of a repeat-proof, not the close;
a second sighting routes to the owning builder as a real defect.

**Why:** content-identity and a manufactured load window explain why a red is not a NEW defect;
they say nothing about whether the change made an existing race REACHABLE. The runbook's own
preflight clause already says this ("a failure inside a seam the change touched does not get
filed as a load flake on one observation... 'rerun went green' closes nothing here"), and it
exists because the shape was paid twice (v0.8.2, v0.40.0).

**How to apply:** when triaging a red against a just-shipped release, ask which seam the failing
test drives before accepting a load explanation. If it is a seam the release changed, say so and
ask that the rerun be counted as leg 1. Raised at the v0.45.0 cut ([[v0450-published]]) against
`wake_single_flight::two_concurrent_wakes...` — the seam #106's late-ack arbiter changed — and
doyle ADOPTED it into the gate ledger.

**⚠ AMENDMENT — do not stretch "repeat-proof" to a GREEN (hertz's correction of my wording, 2026-07-29).** I called a Windows `test` green on a replacement candidate a "seam-touched repeat-proof" because that leg had red on the prior candidate. Wrong on two counts, and hertz named both: (1) the failing SEAM here is the two-host seam, which only the `twohost` jobs exercise — the `test` leg is the same LANE, not the same seam; (2) the green has **zero discriminating power for the guard**, because the previously-defective sha `ce4386e` greened that lane too. An observation both hypotheses predict is not evidence — the vacuous-oracle class again, this time in my verdict vocabulary rather than in a rig.
**Safe phrasing to use instead (hertz's, adopt verbatim):** *"same lane executed and passed; defect did not appear; guard remains unexercised."* Reserve "repeat-proof" for its original direction — accumulating sightings of a RED — and never let it imply a green proved a guard. Before calling any green evidence, ask what result the defective version would have produced: if the answer is "the same one", the run discriminates nothing.

Corollary paid the same night: doyle's own merge push cancelled the pending at-sha rerun
(concurrency), the exact class [[main-baseline-procedure]] warns about. A repeat-proof leg is
release-critical state — nothing pushes behind it.