Filed unassigned and ungraded by the #12538 dev (session session_01PfaSTikked61BkcsB5Rn69). #12538 asked for the p95 of legitimate holds so a number could be priced against it; the answer was that the data does not exist, and this is why.
Measured
LEDGER_FILE="${OS_VERIFY_LOCK_LEDGER:-${LOCK_FILE}.ledger}" with LOCK_FILE defaulting to /tmp/os-heavy-verify.lock. That path is per-container and empty after every reset.
Read 2026-08-27: 25 records, spanning 25m30s, held max 344s, waited max 3s, arrival depth 1 on every row, zeroqueue-timeout records. The four observations #12538 is priced on — a 1164s hold, three 540s timeouts, ~37 minutes queued — are from 2026-08-26 and appear in no ledger at all.
So the ledger's population is not "the fleet"; it is "whatever ran in this container since it last came up". The records: N, spanning T header states the span but not the reason it is short, and --report's own framing ("the standing answer to where hold time goes", "which command dominates hold time") reads as a fleet-scale claim.
Why it matters
The ledger was added precisely because contention could only be characterised anecdotally — it took a dispatch seat correlating three devs' reports by hand across one shift. As it stands it reproduces that limit: an agent asking "is a 19-minute hold normal here?" gets a confident, well-formed answer computed over a population that structurally excludes every long hold from before the last container reset. That is the same family as the defects this file has already repaired twice — an instrument answering in the green direction about something it did not measure.
Candidate shapes (⛔ suggestions, not a ruling)
- Say the scope out loud — cheapest, and it is the half that cannot be wrong:
--report states that its population begins at container start and names the first record's timestamp against the container's uptime. - Persist it somewhere that survives a reset. Note the constraint that shaped the original design: this file must create nothing that outlives a process and needs reaping, and the ledger must never be able to redden a gate.
⚠️ 1 and 2 are not alternatives — 2 without 1 still ships a report whose scope is implicit.
Refs
Generated by Claude Code
Filed unassigned and ungraded by the #12538 dev (session
session_01PfaSTikked61BkcsB5Rn69). #12538 asked for the p95 of legitimate holds so a number could be priced against it; the answer was that the data does not exist, and this is why.Measured
LEDGER_FILE="${OS_VERIFY_LOCK_LEDGER:-${LOCK_FILE}.ledger}"withLOCK_FILEdefaulting to/tmp/os-heavy-verify.lock. That path is per-container and empty after every reset.Read 2026-08-27: 25 records, spanning 25m30s,
heldmax 344s,waitedmax 3s, arrival depth 1 on every row, zeroqueue-timeoutrecords. The four observations #12538 is priced on — a 1164s hold, three 540s timeouts, ~37 minutes queued — are from 2026-08-26 and appear in no ledger at all.So the ledger's population is not "the fleet"; it is "whatever ran in this container since it last came up". The
records: N, spanning Theader states the span but not the reason it is short, and--report's own framing ("the standing answer to where hold time goes", "which command dominates hold time") reads as a fleet-scale claim.Why it matters
The ledger was added precisely because contention could only be characterised anecdotally — it took a dispatch seat correlating three devs' reports by hand across one shift. As it stands it reproduces that limit: an agent asking "is a 19-minute hold normal here?" gets a confident, well-formed answer computed over a population that structurally excludes every long hold from before the last container reset. That is the same family as the defects this file has already repaired twice — an instrument answering in the green direction about something it did not measure.
Candidate shapes (⛔ suggestions, not a ruling)
--reportstates that its population begins at container start and names the first record's timestamp against the container's uptime.Refs
os-verify-lock's 540s wait budget is shorter than a single legitimate hold — a compliant caller times out systematically, not occasionally #12538 — the card whose p95 could not be priced from thisos-verify-lockserialises locked heavy jobs but NOT gate scripts — so every timing card measures a contended box while believing the lock gave it an idle one #12528 — the lock's coverage boundaryGenerated by Claude Code