Arising from int-0002 — Zero-ceremony operation — one binary, no server, no daemon

The cold-start budget is a median, not a maximum; the single-run ceiling is dropped

`coldMaxBudget` is removed. The cold-start gate asserts the **median** of N>=20 spawns against `int-0002`'s 100ms and nothing else.

The evidence

The perf gate's first run on real CI hardware — the measurement three earlier tasks deferred to rather than fake on a developer machine — reported this on `ubuntu-latest`:

- cold median: **passes** the 100ms ceiling - cold single-run maximum: **191ms**, over the 150ms ceiling

`macos-latest` passed both, and an earlier run passed both on both runners. So the clause that fails is the one that depends on the single unluckiest spawn out of twenty.

Why the maximum was the wrong instrument

**At n=20 the maximum IS the worst single observation.** It has no averaging behind it at all, which makes it the noisiest statistic in the set — the opposite of what a gate wants. `internal/index/latency_test.go` already carries the sibling lesson in a comment: contention only ever ADDS time, so the extreme of a distribution measures the machine and the centre measures the code.

This is the same shape as the three gates fixed the same day, and it is worth naming because it keeps recurring in a new costume: **a check that reports a verdict it did not have the evidence to reach.** A single 191ms sample is not evidence that a hook invocation is perceptible; it is evidence that one spawn in twenty was descheduled.

The cost, stated rather than buried

**A genuine tail regression can now hide behind a healthy median.** If dira grows a path that is fast most of the time and occasionally slow — a lock, a retry, a lazy build — the median will not move and this gate will not catch it. That is a real hole and it is accepted deliberately, not overlooked.

What partly covers it: `E1-L6-T5`'s phase attribution, which is unblocked by this and should report the distribution rather than a single number; and the fact that the perf job publishes the full sorted sample list to the CI step summary on every run, so a widening tail is visible to anyone who looks even though nothing fails on it.

`int-0002`'s number is unchanged. What changed is the statistic it is read from.

Correction, 2026-08-08 — a number in this entry was never measured

The argument above originally read "the median on CI passes at roughly **95ms** against a 100ms ceiling". **No CI log supports 95ms.** Harvested from the actual runs, the cold medians pass comfortably on both platforms.

**Corrected again 2026-08-09.** The list first written here — "39.0, 45.2, 39.8, 62.9 and 39.8 ms" — was itself wrong, and wrong in an instructive way: it was harvested with a grep that took the FIRST match per run, so it mixed ubuntu and macOS samples into one list presented as though it were coherent. The platforms run differently enough that this matters — in a single run, ubuntu measured 38.967 ms and macOS 55.294 ms. Per platform:

| | cold medians, 5 runs | |---|---| | ubuntu-latest | 33.0, 38.8, 39.7, 39.8, 45.2 ms | | macOS-latest | 49.2, 50.4, 55.1, 61.0, **111.1** ms |

The macOS outlier is the run this entry already names. Its figure is **111.073 ms**, verified from the CI log — an earlier note here said 109.7 ms, which came from a report that contradicted itself between its own table and its prose.

So a correction written to fix an unmeasured number introduced two more. Both are recorded rather than quietly overwritten, because the pattern is the point: every one of these came from carrying a figure forward without opening the log it supposedly came from.

Where 95ms came from: E1-L6-T4's report carried a *projection* for CI hardware — "cold ≈100–110 ms, marginal" — explicitly labelled an estimate. I carried it into this entry as though it were measured, and softened it in the carrying. That is the failure this repo keeps naming, committed inside a decision entry: a claim reported with more confidence than its evidence supports.

**The conclusion is unchanged and in fact stronger.** The reason for dropping the single-run ceiling was that at n=20 the maximum is one observation and grades the scheduler; real medians of ~40ms against a 100ms budget make that argument more comfortable, not less.

**Two things the harvest found that were recorded nowhere.**

One macOS run in five broke the *median* at **109.7ms** — run 30669750621, seven minutes before this entry was written. Its minimum was 49.7ms, so it was a degraded runner rather than slow code, and it is exactly the case the "can this machine judge?" discriminator is for. It went unnoticed at the time.

And the measured distribution this entry's `revisit_if` asked for **now exists**: 200 cold samples, 5 CI runs across 2 platforms. It says a percentile ceiling still cannot be derived — macOS pooled p90 is **111.1ms**, above the 100ms budget it would enforce, and the variance is *between* runs rather than within them. So the trigger has fired, been examined, and the answer is that the discriminator the data supports is the minimum against the ceiling, not a percentile. The revisit stays open only in the sense that more runs may change it.