Observation only, found while re-measuring the stall guard's headroom. Not a wrong verdict — a census line that reads as more independent than it is.
What the census prints
check-stall-guard-budget.mjs --list reports, per guard-wrapped step, window / cap / budget / slack, where slack = T - C. On this tree five ci.yml-family sites all print slack 10m:
ci.yml:573 job `test` step `Run this shard's tests` slack 10m
ci.yml:969 job `temporal-conformance` step `Run driver-sql suite ...` slack 10m
ci.yml:1009 job `temporal-conformance` step `Run the non-SQL temporal backends ...` slack 10m
ci.yml:1152 job `dogfood` step `Boot example apps ...` slack 10m
coverage-nightly.yml:59 job `coverage` step `Generate coverage report` slack 10m
Two of those are the same job. timeout-minutes runs one clock for the whole job, so those two steps do not each get 10 minutes of room — they share it, and the second one starts with the first one's runtime already spent.
Measured
Runner timestamps, three consecutive merge_group runs of 2026-08-28 (33160601033, 33162164422, 33163163494). p measured from job start, which is the clock timeout-minutes actually runs on:
| step | worst p | worst s | worst p + s |
|---|
Run driver-sql suite against both live servers | 1m42s | 1m08s | 2m50s |
Run the non-SQL temporal backends under the skewed process zone | 4m08s | 1m28s | 5m36s |
The second step's p is 2m26s larger than the first's, and essentially all of that difference is the first guarded step's own runtime. Both rows print slack 10m.
Why this is only a legibility defect, not a wrong gate
The gate's criterion is T - C >= W, and its header is explicit that it does not model p or s at all — it deliberately refuses to encode the run length, because no static sweep can read it. Against that criterion slack 10m is correct for both rows.
The problem is that the census is also the thing a human reads to judge whether a family is comfortable, and there the two rows are not equivalent: a reader comparing them has no way to see that one of them is a first step and the other is a second step on the same clock. Today the numbers are small enough that it does not bite (worst p + s on that job is 5m36s against a 30m budget). It would bite on a job whose earlier guarded step grew.
Suggested remedy
Have the census name the sibling count when a job holds more than one guard-wrapped step — e.g. slack 10m (1 of 2 guarded steps in this job; they share one timeout clock). That keeps the criterion exactly as it is and only stops the line from reading as an independent per-step budget.
No behaviour change is proposed to the gate's verdict.
Observation only, found while re-measuring the stall guard's headroom. Not a wrong verdict — a census line that reads as more independent than it is.
What the census prints
check-stall-guard-budget.mjs --listreports, per guard-wrapped step,window / cap / budget / slack, whereslack = T - C. On this tree five ci.yml-family sites all printslack 10m:Two of those are the same job.
timeout-minutesruns one clock for the whole job, so those two steps do not each get 10 minutes of room — they share it, and the second one starts with the first one's runtime already spent.Measured
Runner timestamps, three consecutive merge_group runs of 2026-08-28 (33160601033, 33162164422, 33163163494).
pmeasured from job start, which is the clocktimeout-minutesactually runs on:psp + sRun driver-sql suite against both live serversRun the non-SQL temporal backends under the skewed process zoneThe second step's
pis 2m26s larger than the first's, and essentially all of that difference is the first guarded step's own runtime. Both rows printslack 10m.Why this is only a legibility defect, not a wrong gate
The gate's criterion is
T - C >= W, and its header is explicit that it does not modelporsat all — it deliberately refuses to encode the run length, because no static sweep can read it. Against that criterionslack 10mis correct for both rows.The problem is that the census is also the thing a human reads to judge whether a family is comfortable, and there the two rows are not equivalent: a reader comparing them has no way to see that one of them is a first step and the other is a second step on the same clock. Today the numbers are small enough that it does not bite (worst
p + son that job is 5m36s against a 30m budget). It would bite on a job whose earlier guarded step grew.Suggested remedy
Have the census name the sibling count when a job holds more than one guard-wrapped step — e.g.
slack 10m (1 of 2 guarded steps in this job; they share one timeout clock). That keeps the criterion exactly as it is and only stops the line from reading as an independent per-step budget.No behaviour change is proposed to the gate's verdict.