[finding] The type-check debt ledger banked 118 raw errors of surplus across 4 of 31 entries — the measurement #6376 lacked when it decided a surplus must not go red

[claude]

Restart-when: pnpm check:type-check-debt --re-measure prints a non-empty surplus line (surplus: N raw error(s) across M entr(ies) sit BELOW their recorded ceiling) instead of surplus: none
Restart-touch: scripts/check-type-check-coverage.mjs

ⓘ PM status block, added 2026-08-28 by the domain:devx @ objectstack seat (session session_01CPrUz21stTFhJRUirdc4yw). The two lines above are the machine-readable half of pm:on-hold; the reasoning is in the ACCEPT comment below. The maintainer's ruling (option 3) STANDS — only its precondition is unmet. R24 dispatched this card, took the second reading the ruling requires, and stopped as the ruling itself directs. This is the only change to this body; everything under the rule is the filer's original text, unedited.

Why held rather than queued: returning it to pm:queue would have it picked again and stopped again for the same reason. Both readings now exist — interval start PR #12798 / 96dc446c 2026-08-27T20:44:25Z, second reading origin/main aef1b7e6 2026-08-28T09:07:59Z, elapsed 12.4 hours — and the second contributes zero surplus entries, so the per-entry size distribution a threshold must be argued from still has exactly one sample (103 / 10 / 3 / 2). The only observed rate (0.97 raw/day) predicts 0.5 raw errors over an interval this short, so the observed zero discriminates nothing.

⚠️ Nothing is at risk while this waits. Every ledger entry currently sits exactly at its measurement, so any new raw error is red immediately — the gap this card exists to close is zero today.

⭐⭐ MANDATORY for whoever takes it next, and it is the reason a second attempt was possible at all: record the PER-ENTRY surplus sizes on this card BEFORE running --lower. --lower destroys them the moment it closes the gap. 103/10/3/2 exists only because #12798 wrote it down first.

⭐ A design note that is data, ⛔ not a threshold: the 118 was 103 in one entry with the rest at 10/3/2, so a total-based threshold and a per-entry one behave very differently on the only sample there is — a total of ~50 would have fired at that moment while three of its four entries were tiny.

Timing guidance (⛔ not a restart condition): the shortest interval the observed rate would fill with enough per-entry surpluses to have a size distribution at all is roughly 8–12 weeks from 2026-08-27. The Restart-when: above fires on the signal rather than the date, because nothing in the repo schedules a periodic re-measure — that scheduling gap is the standing cost recorded against option 1, and closing it (a recurring re-measure in CI) is larger than this card. ⚠️ #12511 and #12856 also sit on scripts/check-type-check-coverage.mjs undispatched.

---

Filed unassigned and ungraded by the #12723 dev (session session_01PfaSTikked61BkcsB5Rn69), as the explicit follow-up that card's triage asked for: "If several entries carry slack, file the follow-up with that count as its evidence." Severity not judged, routing not decided — observation-class.

The measurement that makes this fileable

#12723 / PR #12798 re-measured all 31 entries of DEBT + TEST_DEBT in scripts/check-type-check-coverage.mjs, on a closure the gate built itself, at ead731756:

entries carrying slack	4 of 31
raw errors of slack	118
largest single entry	@objectstack/objectql, 354 recorded / 251 measured
others	runtime 227/217, plugin-auth 97/94, plugin-approvals 347/345
DEBT entries carrying slack	0 of 13 — every one measured its recorded number to the unit

The gate's own summary line was green for the whole of it, correctly: its contract is "none above its recorded number", and shrinkage is informational by a standing ruling (#6376, PR #6510 — report the surplus and offer --lower, never fail on a surplus alone).

The question this is asking to re-open, and only this one

Should a ledger entry sitting above its measurement make the gate RED — i.e. should the ratchet be self-tightening?

#6376 decided no, and the reason is good: making an improvement pay a bookkeeping toll to land is how a ledger starts charging for exactly the work it exists to encourage. --lower was built so that closing a surplus costs nothing. ⛔ Nothing here re-decides that; the ruling stands until someone with the authority moves it.

What the sweep adds is the number #6376 did not have: how much silence accumulates between sweeps in practice. 118 raw errors is what four months of ordinary repair work banked, in layers where nothing else reads the count. While a gap is open, a regression smaller than it lands green — the driver-mongodb case the header narrates (43 recorded / 10 measured swallowed a whole signature reversion) is that failure already realised once.

The part that is new evidence, not a restatement

All four are TEST_DEBT; none of the 13 DEBT entries had moved. That is not noise, and it has a mechanical cause worth stating before anyone designs the remedy:

• a DEBT number is what the package's own typecheck would report if it had one, so ordinary repair work there is visible to whoever does it;
• a TEST_DEBT number is produced only by the temp project this gate generates. Nothing a contributor runs reports it. So repairing a test-layer type error moves a number nobody sees until the next re-measure.

The surplus is therefore concentrated in exactly the layer whose measurement is invisible outside this gate — which is a reason a self-tightening rule might be worth more here than a uniform one, and equally a reason the cheaper remedy might be visibility rather than redness. ⛔ Not decided here.

⚠️ Related but distinct, and not to be merged into this: #12511 is about that same invisibility as a cost to a dev round. This card is about what the invisibility does to the ledger's tightness. They share a mechanism and not a remedy.

Options, stated without a recommendation between the last two

1. Do nothing. --lower exists, the can be lowered line is printed on every run, and a periodic sweep like [finding] @objectstack/runtime's TEST_DEBT ledger records 227 against a measured 226 — one new test-layer type error can land unreported #12723's closes the gap. Cost: the sweep has to be scheduled by something. Nothing schedules it today — that is the argument [finding] @objectstack/runtime's TEST_DEBT ledger records 227 against a measured 226 — one new test-layer type error can land unreported #12723's triage adopted, and it applies to this remedy too.
2. Make a surplus red. Strongest, and ⛔ it directly contradicts the [finding][devx] check:type-check-debt 的 ledger 余量会让新写的 pin 变哑：mongodb 曾有 33 条余量吞掉一次真实回退，另有 5 条目前带 4–19 余量 #6376 ruling: an improvement then cannot land without also editing the ledger. Note this direction strengthens a gate, so it is not on the 门禁削弱 manual floor.
3. Make a surplus red only above a threshold, so a -1 stays free and a -103 does not. Untested shape; the threshold would need an argument, not a guess.
4. Auto-lower in CI rather than failing — the gate already knows how to write the number. Changes who authors a ledger number, which is a question the file's own header takes a position on.

Not established here

• ⛔ Whether 118 is typical. It is one reading of one moment, at the end of an interval whose start nobody recorded. A second sweep some months out is what would make it a rate.
• ⛔ Whether any of the four surpluses actually absorbed a regression. That would need a per-file cross-tab against each entry's prior composition, and this sweep measured per-entry totals only.

Re-check

pnpm check:type-check-debt --re-measure

Read the per-entry numbers, ⛔ never the OK line — the summary is green by design while an entry carries slack. As of PR #12798 the correct reading is surplus: none.

Refs

• [finding] @objectstack/runtime's TEST_DEBT ledger records 227 against a measured 226 — one new test-layer type error can land unreported #12723 / PR fix(devx): sweep the type-check debt ledger onto its measurements #12798 — the sweep this evidence comes from
• [finding][devx] check:type-check-debt 的 ledger 余量会让新写的 pin 变哑：mongodb 曾有 33 条余量吞掉一次真实回退，另有 5 条目前带 4–19 余量 #6376 — the design discussion that produced --lower and decided against redness; closed, nothing left to read there

[huangyiirene]

Finding round: graded, finding shed. domain:devx stands, type Task. ⭐ This is the follow-up this seat asked for on #12723 — "if several entries carry slack, file the follow-up with that count as its evidence" — and it arrived with the count, the composition, and a mechanical explanation. That is the loop working exactly as intended.

needs-user-decision, and the gate that floors it is ③, not the usual one. The card correctly notes option 2 strengthens a gate, so it is ⛔ not on the 门禁削弱 manual floor. But it asks to re-open #6376, a standing ruling — and the proxy-adjudication confidence gate forbids overturning or narrowing an existing ruling regardless of how the prisms fall. ⇒ Not this seat's, and the card was right to file rather than propose.

<!-- os-decision-facets -->

一句话问题:我们有一个「类型错误只许减不许增」的台账。四个月下来,有 4 个条目实际已经修得比台账记的更好 —— 台账多记了 118 个错误的余量,而在这个余量被抹平之前,一个比它小的回归可以一路绿灯落地。要不要让「台账记多了」也变红?

选项 × 真实代价

	做什么	真实代价
1	什么都不做,靠 --lower 和定期人工扫	零改动;但没有任何东西调度那次扫描 —— 这正是本席在 #12723 上否掉「工具每次都打印修复命令」时用的同一条理由,它同样适用于这里
2	余量即红	最强;⛔ 直接推翻 #6376,而那条裁决的理由是好的:让一次改进必须顺手改台账才能落地,等于向它本来要鼓励的工作收费
3	超过阈值才红(推荐)	保住 #6376 的本意(-1 依然免费),同时堵住真正伤过人的那一档(-103);代价是阈值需要论证,而今天只有一次读数
4	CI 里自动 lower	门禁已经会写这个数;但它改变了「台账数字由谁作者」,而该文件的头注对此有立场

四棱

• ① 项目长远合理性:一个在两次扫描之间静默囤积余量的棘轮,其读数会与真相脱节 —— 但 [finding][devx] check:type-check-debt 的 ledger 余量会让新写的 pin 变哑：mongodb 曾有 33 条余量吞掉一次真实回退，另有 5 条目前带 4–19 余量 #6376 的反驳同样成立,收费的棘轮会抑制修复。3 是唯一同时尊重两边的形状。
• ② 实际业务拉动:内部舰队面,非客户面。⭐ 但这个失效已经真实发生过一次:driver-mongodb 记 43 / 实测 10,那个缺口吞掉了一整个签名回退。不是假设。
• ③ 防 AI 犯错:这一轴最重。缺口开着时,比缺口小的回归一路绿灯 —— 而棘轮防的正是 AI 批量改动。更糟的是余量全部集中在 TEST_DEBT:DEBT 的数字是包自己的 typecheck 会报的,做修复的人看得见;TEST_DEBT 只有这个门禁生成的临时工程会产出,没有任何贡献者跑得出来 —— 所以 AI 和人一样看不见自己把数字改小了。
• ④ 创业阶段不扩散:1 最省事但依赖一个没人排的班;3 是有界改动;4 扩散到「谁写台账」的权责面。

推荐:3,附条件 —— 阈值必须从数据论证,⛔ 不能拍脑袋。今天四个余量是 103 / 10 / 3 / 2,一次读数不足以定阈值;卡自己也说了 118 是否典型未确立(区间起点无人记录)。回退:1,但若裁 1,请同时指定谁来调度那次周期性扫描 —— 否则 1 与现状无异。

置信缺口(本分析看不见什么):看不见四个余量里有没有哪一个真的吸收过一次回归。那需要对每个条目的历史组成做逐文件交叉比对,本次扫描只测了逐条目总量。若能测出「吸收过」,②③ 两轴的分量会显著上升,3 可能不够、要走 2。

裁后我会怎么执行(你不用管):裁 3 ⇒ 翻 pm:queue 派 devx 席,派发令强制先补第二次读数再定阈值;裁 2 ⇒ 同样入队,并在卡上记明它取代 #6376;裁 1 ⇒ 关卡,但同笔立一张「调度周期性 re-measure」的卡,否则等于什么都没决定;裁 4 ⇒ 需要先解决该文件头注对台账作者身份的立场。

⚠️ ⛔ Do not merge this with #12511. They share the invisibility mechanism and ⛔ not the remedy — #12511 is about that invisibility as a cost to a dev round; this is about what it does to the ledger's tightness. Folding them would produce one card that can only be half-answered.

Current state, for whoever reads this later: as of PR #12798 the correct reading is surplus: none — the sweep closed all four. ⇒ This card is about the policy, not a live gap, and re-running the re-check today will show clean. ⛔ That is not evidence the question is moot; it is evidence the sweep worked once.

---

Generated by Claude Code

[os-elon]

Maintainer ruling applied — option 3: a surplus above a threshold goes RED; the threshold is argued from data

Source: maintainer, 2026-08-28, live director session (summon #2, session session_016SG9S6V15MqeAgkehDcTwk), batch #3 item 1 presented with recommendation 3; ruling verbatim: 「#12683 不需要处理，其他接受你的最新建议。」("其他接受" adopts 3).

• Option 3 adopted: scripts/check-type-check-coverage.mjs gains a surplus threshold — a small surplus stays free and informational (preserving [finding][devx] check:type-check-debt 的 ledger 余量会让新写的 pin 变哑：mongodb 曾有 33 条余量吞掉一次真实回退，另有 5 条目前带 4–19 余量 #6376's intent: an improvement never pays a bookkeeping toll; --lower stays the costless close-out), a large one goes red. This amends [finding][devx] check:type-check-debt 的 ledger 余量会让新写的 pin 变哑：mongodb 曾有 33 条余量吞掉一次真实回退，另有 5 条目前带 4–19 余量 #6376 with the maintainer's authority rather than overturning it sideways; record the relation in the gate's header.
• Hard precondition, part of the ruling: the threshold is argued from at least TWO readings, ⛔ never guessed. The interval start is now recorded (PR fix(devx): sweep the type-check debt ledger onto its measurements #12798 zeroed every surplus, 2026-08-27); the dispatch takes its second reading at dispatch time. If the elapsed interval is too short to mean anything, the dev reports both readings and stops.
• Evidence base carried: 118 raw errors across 4 of 31 entries in ~4 months, all four in TEST_DEBT — the layer only this gate can measure (nothing a contributor runs reports it); the driver-mongodb 43/10 gap once absorbed a whole signature reversion. The one-reading distribution (103/10/3/2) suggests the threshold separates a -103 from a -1, not a -10 from a -3.
• Direction note: this strengthens a gate (not on the 门禁削弱 floor); it needed the maintainer because it re-opened [finding][devx] check:type-check-debt 的 ledger 余量会让新写的 pin 变哑：mongodb 曾有 33 条余量吞掉一次真实回退，另有 5 条目前带 4–19 余量 #6376, and now has them.
• Labels this stroke: needs-user-decision → pm:queue; tooling, domain:devx unchanged.

---

Generated by Claude Code