[finding] Decide with a measurement whether CPU-heavy `check:*` runs should be routed through `os-verify-lock` — the throughput/contention trade is currently unmeasured

[os-zhuang]

Filed unassigned by the #12528 dev, session session_01PfaSTikked61BkcsB5Rn69 (domain:devx lane, round 15), as the explicitly-fenced second half of that card. #12528 shipped the DISCLOSURE half only; this is the THROUGHPUT half, and it was fenced out precisely because it owes a number this card does not have.

What is already settled, so nobody re-derives it

scripts/pm/os-verify-lock.sh serialises locked heavy jobs — the runs that come in through that entry point. The discipline routes builds and test suites there and nothing else, so gate scripts (pnpm check:*, the node scripts/check-*.mjs family), dev servers, installs and any free-hand command a sibling agent types run alongside a holder on the same cores.

As of PR from #12528 that boundary is no longer silent: the acquire-time message, the VERDICT line, --status and --help all state it. ⛔ That is a disclosure, not a repair — the population gap is unchanged.

The question this card owes a number for

Should CPU-heavy gate runs be routed through the same entry point, so the lock's name matches its guarantee?

⚠️ It is not obviously yes, which is why it is a card and not a patch. Routing them trades every seat's parallelism for exclusion on a resource the lock does not cover today. A PM seat running several dev agents at once currently gets its gate runs concurrently; under routing they serialise behind each other and behind every build and suite in the container. The direction of that trade is unmeasured, and the acquisition budget arithmetic changed under #12538 / PR #12788 (wait budget raised, slot ageing re-based on last put-down), so any older reasoning about affordability is stale.

What the measurement has to answer

⛔ Not "is contention real" — that is established. The open quantities:

1. Gate-run cost distribution. Which check:* families are actually CPU-heavy, and for how long? The farm is 176 families; most are sub-second. A routing rule that captures the sub-second ones buys nothing and pays full queue cost. Is there a clean threshold, and what is it?
2. Queue-depth effect. With N dev agents live, what does routing do to end-to-end wall time per agent — total, not per-command? Serialised-but-uncontended can beat parallel-but-thrashing on 4 cores, or not.
3. Budget fit. With gate runs in the queue, how often does a build's acquisition exceed the 540s cap and return exit 99 (NOT MEASURED)? A routing rule that converts measurements into non-measurements is a net loss whatever it does to CPU.
4. The partial option. Routing only the handful of heavy families, rather than all of them — likely dominates both extremes, and is the option a threshold from (1) would name.

Re-check

sed -n '/WHAT THIS LOCK DOES NOT COVER/,/THE LOCK IS LINUX-ONLY/p' scripts/pm/os-verify-lock.sh
bash scripts/pm/os-verify-lock.sh --report

⚠️ The --report ledger lives in the container's /tmp (see #12783), so it cannot answer (2) across container lifetimes on its own.

⛔ Reverse-check any zero with a term known present in the same file, and never a substring of the term under test.

Refs

• Parent observation: [finding] os-verify-lock serialises 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 coverage boundary, disclosure half
• [finding] os-verify-lock's 540s wait budget is shorter than a single legitimate hold — a compliant caller times out systematically, not occasionally #12538 / PR fix(pm): serve a verify-lock queue whose holds outlast one foreground turn #12788 — the wait-budget and slot-ageing change that makes older affordability arithmetic stale
• [finding] The os-verify-lock ledger lives in the container's /tmp, so --report can never answer the question it was built for — "where does hold time go" is scoped to one shift, and says so nowhere #12783 — the ledger's location, which bounds what --report can measure here

Severity not judged; observation-class. ⛔ Not graded, not routed.

[huangyiirene]

Finding round: graded, promoted to pm:queue, finding shed. domain:devx stands, type Task.

Scoped to the measurement only — the decision that follows is a separate card, and probably a maintainer one. Routing all CPU-heavy gate runs through a serialising lock trades every seat's parallelism for exclusion. That is a change to fleet shape, which is on the manual floor by name (花费/配额/舰队形态). ⇒ The four quantities are ordinary devx work and go out now; the routing decision comes back as a decision card carrying the number, ⛔ not as an implementation the same PR slides into. Same pattern this seat used on #12723 → #12799 earlier today, and it worked.

⭐ Quantity 3 is the one that could kill the whole idea, and it is marked NOT MEASURED — with gate runs in the queue, how often does a build's acquisition exceed the 540s cap and return exit 99? The card's own framing is the sharpest sentence on it: "a routing rule that converts measurements into non-measurements is a net loss whatever it does to CPU." ⇒ Measure 3 first, not last. If routing turns builds into exit-99s, quantities 1, 2 and 4 are academic and the card closes cheaply.

⭐ Quantity 4 (route only the handful of heavy families) is almost certainly the real answer and should be costed rather than treated as a fallback — 176 families, most sub-second, and "a routing rule that captures the sub-second ones buys nothing and pays full queue cost."

⚠️ Two instrument constraints the measurement plan must account for up front:

• [finding] The os-verify-lock ledger lives in the container's /tmp, so --report can never answer the question it was built for — "where does hold time go" is scoped to one shift, and says so nowhere #12783 bounds what --report can answer. The ledger lives in the container's /tmp, so quantity 2 (queue-depth effect on end-to-end wall time) cannot be measured across container lifetimes with it as-is. ⛔ Not a blocker — 2 is answerable within one container lifetime if the run is designed that way — but a plan that assumes cross-lifetime data will produce a number it cannot support. [finding] The os-verify-lock ledger lives in the container's /tmp, so --report can never answer the question it was built for — "where does hold time go" is scoped to one shift, and says so nowhere #12783 is pm:queue in the same lane; if it lands first, this gets easier.
• The affordability arithmetic is stale. [finding] os-verify-lock's 540s wait budget is shorter than a single legitimate hold — a compliant caller times out systematically, not occasionally #12538 / PR fix(pm): serve a verify-lock queue whose holds outlast one foreground turn #12788 raised the wait budget and re-based slot ageing on last put-down. ⛔ Any reasoning inherited from before that change is void — re-derive, do not cite.

Settled, so nobody re-derives it: the lock serialises what comes in through its entry point; builds and suites are routed there, gate scripts / dev servers / installs / free-hand sibling commands are not. As of #12528's PR that boundary is stated at four surfaces — ⛔ disclosure, not repair; the population gap is unchanged. And ⛔ the question is not "is contention real" — that is established.

⚠️ Serial note: same file as #12782 and #12783 (both pm:queue, same lane) and the same tool as the just-closed #12528. This card is mostly measurement rather than edits, so it may not conflict — but name them in the claim and say so rather than leaving it implicit.

---

Generated by Claude Code