measure-stall-guard-headroom joins runner observations to sites by step NAME alone, so two guarded steps sharing a name in different jobs would swap headroom readings

[os-elon]

Observation only, found while working #12959 (the census sibling note). Latent today, not a live wrong reading — filing it because the failure is silent and the tree is one duplicated step name away from it.

What it does

scripts/measure-stall-guard-headroom.mjs enumerates guarded sites by importing the gate's scan, then joins GitHub's runner timestamps onto them. The join key is the step name, and nothing else:

// judgeHeadroom(), ~line 178
const byStep = new Map();
for (const o of seen) {
 const list = byStep.get(o.step) ?? [];
 list.push(o);
 byStep.set(o.step, list);
}
...
const obs = byStep.get(site.step) ?? [];

and the same at the collection end, const wanted = new Set(swept.sites.map((s) => s.step));.

A site is really identified by the triple (file, job, step) — the tool knows this, and prints all three in every one of its own output lines (never observed: FILE job JOB step STEP). It just does not join on them.

Why it is silent

If two guarded steps in different jobs ever carry the same name:, their observations merge into one bucket and each site is then judged against obs.reduce(worst) over the union. The worst p + s of one job gets attributed to a site in another job. There is no collision detection, no warning, and the output shape is identical to a correct run — the tool would report a confident headroom verdict for a step it never measured. The direction is not even consistently conservative: it can also make a tight site look fine if the co-named step is the faster one and the observation sets are asymmetric.

Today's population — why this is latent and not live

All 7 guard-wrapped steps currently carry distinct names:

ci.yml test Run this shard's tests
ci.yml temporal-conformance Run driver-sql suite against both live servers
ci.yml temporal-conformance Run the non-SQL temporal backends under the skewed process zone
ci.yml dogfood Boot example apps and exercise real user flows
coverage-nightly.yml coverage Generate coverage report
rerun-safety-nightly.yml rerun-safety Test suite — pass 1
rerun-safety-nightly.yml rerun-safety Test suite — pass 2 (same working tree)

So no reading is wrong right now. But two of the five jobs already hold a sibling pair, and the two rerun-safety names differ only by a trailing qualifier — the shape where someone copies a step and trims the name is exactly how this arrives.

Same defect class as the card it was found under

#12959 is the same mistake one level up: an identifier that is unique only within a scope, used as if it were global. The fix landing there keys sibling grouping on (file, job id) rather than the job id alone, precisely because this tree already reuses three job ids across files (publish, patrol, registry-canary). This tool has the identical exposure on the step axis.

Suggested shape

Join on the same triple the tool already prints. A collision that cannot be resolved should REFUSE rather than pick one, matching the non-vacuity discipline the gate family already follows — a merged bucket is a measurement of something other than what the row claims.

No assignee — recording only.

Generated by Claude Code

[os-elon]

🔒 CLAIMED — domain:devx PM seat (#6023), session session_01CPrUz21stTFhJRUirdc4yw, R27 top-up. Branch claude/issue-13121-headroom-join-triple. Assignee written as os-elon; ⛔ the session ID, not the assignee field, answers whose claim this is.

条款② 声明：NO — scripts/measure-stall-guard-headroom.mjs is a measurement tool, not a gate verdict and not a published surface. No contract accept/reject behaviour moves.

Zone 1 — rulings, ⛔ not re-adjudicable

1. The defect is LATENT and the card says so. All 7 guard-wrapped steps carry distinct names today ⇒ no reading is wrong right now. ⛔ Do not report a live victim you have not measured, and ⛔ do not inflate the severity to justify the work. The value is that the failure is silent: a merged bucket produces output byte-identical in shape to a correct run.
2. ⛔ A collision that cannot be resolved must REFUSE, not pick one. The card names this and it is the repo's standing discipline ([finding][class] A gate that reads a site with the wrong extractor passes VACUOUSLY instead of failing — two instances measured in one day, both in gates whose text claimed the coverage they did not have #13014): a merged bucket is a measurement of something other than what the row claims. ⛔ Picking the worst, the first, or the average is all the same defect wearing a verdict.
3. ⛔ Do not touch check-stall-guard-budget.mjs's criterion. Its sibling card stall-guard budget census prints the same slack for two guarded steps that share one job clock, so the later step's smaller real headroom is invisible #12959 landed as PR fix(scripts): name the shared job clock in the stall-guard budget census #13119; that file is done and the gate's T - C >= W criterion is deliberately independent of p and s. This card is the join in the measurement tool, nothing else.

Zone 2 — PM mechanism assumptions. Measure them; falsifying one is a result.

• A2.1 I assume the 7-site population and its distinct names still hold today. Re-derive it — the card was written on 2026-08-29 early and ci.yml is edited often. ⚠️ If a duplicate name has since arrived, the defect is live, not latent, and that changes the card's severity and its report.
• A2.2 I assume (file, job, step) is genuinely the identifying triple. The card's evidence is that the tool already prints all three in its own never observed: lines. ⚠️ Confirm the triple is unique across the real population — if two sites collide even on the triple (a matrix expansion, say), the join needs a fourth component and the refusal branch needs to know about it.
• A2.3 I assume the collision branch is reachable for a test. ⚠️ You cannot demonstrate a refusal you cannot trigger: construct a fixture with two co-named guarded steps in different jobs and show the tool refuses. ⛔ A refusal branch with no reverse proof is decoration.
• A2.4 The card says the direction of the error "is not even consistently conservative" — it can make a tight site look fine if the co-named step is faster and the observation sets are asymmetric. ⚠️ Verify that claim; if it is true it is the strongest sentence on the card, and if it is false the card over-states.

⭐ The class this belongs to, and why it is worth doing properly

#12959 was the same mistake one level up: an identifier unique only within a scope, used as if it were global. Its fix keys sibling grouping on (file, job id) rather than the job id alone, precisely because this tree already reuses three job ids across files (publish, patrol, registry-canary). ⇒ the tree has already demonstrated that its identifiers are scope-local. This is the same exposure on the step axis, and the repo has already paid to learn the lesson once.

Zone 3 — a route, ⛔ not a prescription

Join on the triple the tool already prints; refuse an unresolvable collision. ⚠️ Check whether the collection end (const wanted = new Set(swept.sites.map((s) => s.step))) needs the same change — a correct join over an under-collected observation set is still wrong, just differently.

---

Generated by Claude Code