[Decision] Route CPU-heavy check:* runs through os-verify-lock? The measurement is in and one-directional — no cell of 64 reaches today's exit-99 baseline #13615

[Decision] Route CPU-heavy check:* runs through os-verify-lock? — the number is in, and it is one-directional: no.

Provenance. Filed by the domain:devx seat (post #6023, session session_01Pk26oZ12t5N1hwGW1m1MgC), R33, carrying the measurement #12795 owed. Triage reserved this decision as a separate, probably-maintainer card and ⛔ this seat does not retire that reservation by having measured a clear answer. This is a confirmation, not a deliberation.

Measurement: #12795 → PR #13610, docs/audits/2026-08-verify-lock-gate-routing-measurement.md.

The number

Today 2.0% of locked runs return exit 99 (acquisition exceeded the 540s budget ⇒ the run is NOT MEASURED).

Across a 64-cell sweep — 4 routing policies × 4 demand levels × 4 levels of CPU credit granted to routing — the best cell is 4.0%, the worst 65.7%. ⛔ No cell reaches today's baseline.

⇒ every routing policy measured makes the NOT-MEASURED rate worse, and "a routing rule that converts measurements into non-measurements is a net loss whatever it does to CPU" is the card's own criterion.

And it does nothing good to CPU either: W=1 was never the throughput maximum in 3 of 3 concurrency sweeps — unsaturated box W=4 beat W=1 by 2.38×, saturated box flat.

⭐ The model was validated before it was trusted: replayed against the population --report prints, simulated exit-99 2 vs observed 2, wait p50 151s vs 151s, p90 536s vs 536s. The other 63 cells are evidence because the calibration cell reproduces reality on three independent statistics.

四维分析

1 — 实际业务需求。 今天没有人因为门禁不走锁而受损:基线 exit-99 是 2.0%,而任何一种路由都把它抬到 4.0% 起。⇒ 采纳路由是用一个真实的可用性退步,换一个纸面上的"名副其实"。⛔ 没有业务需求推动它。

2 — 平台长远合理性。 锁的名字与它的保证确实不一致(#12528 已把这条边界写进文本)。但一致性的正确修法是改名字或改文本,不是改行为 —— 尤其当改行为被实测证明会让它服务的那个量变差。⭐ 而且还有一条预算硬事实:最重的两个族合计 534.5s,而本文件的预算是 540s ⇒ 一次被路由的重族清扫,就能吃掉另一个调用者的全部获取预算。

3 — 避免 AI 写代码犯错。 ⭐ 本卡最该记的一条:本席在派发令里写了一条错的前提 —— 「#12538 / PR #12788 把等待预算抬高了」。实测 HARD_CAP_S=540、DEFAULT_WAIT_S=540 都没动,动的是 SLOT_MAX_AGE_S(→1620s)。⇒ 那条围栏朝宽松方向错,会让路由显得比实际更负担得起。⚠️ 一条错向宽松的围栏,正好招来它本该拦住的那个改动。

4 — 创业阶段不扩散需求。 采纳「什么都不路由」的成本是零:不改代码、不改预算、不改锁的行为。#13610 已经把这条结论写进锁的头注(退掉那句现在为假的「此权衡未经测量」),⇒ 裁定「维持现状」不需要任何后续工程动作。

三条候选

• A —— 维持现状,什么都不路由。(本席建议)零成本;实测支持;锁的头注已记录测量与结论。
• B —— 路由全部 CPU 重族。 ⛔ 被实测否决:64 格无一格达到基线。
• C —— 只路由最重的 5 个族(占门禁总秒数 64.3%,前 2 个占 46.3%)。 ⚠️ 分布确实够尖锐,能划出干净阈值 —— 但它仍然让 Q3 变差,因为最重的两族合计 534.5s 对 540s 预算。

⚠️ 唯一数字settle不了的子问题(来自 dev 的 option C,原样上呈)

路由那 5 个重族,是用测量的「可得性」去买测量的「卫生」。

即:让重族串行,能让它们彼此之间的读数更干净(不互相抢核),代价是抬高别人拿不到锁的概率。⭐ 这是一个价值判断,不是一个测量问题 —— 本席不裁,原样交上。

⛔ 本席的边界

⛔ 不代裁:路由决策触舰队形态/支出,按人工地板归维护者;triage 也明确把它留成独立卡。上面是建议与数字,不是裁决。

Refs: #12795(测量卡)· PR #13610(审计文档 + 锁头注更正)· #12528(披露半边)· #13611(顺带发现:轻量族 ~97% 的时间是 pnpm 启动开销)· #12783(ledger 位置,限制了 --report 能回答什么)

Generated by Claude Code