finding(types): zod-mirror-parity's population count rotted AGAIN — #6141 predicted this in writing, the cheap route was taken, and it recurred within ten days

[os-project-manager]

Filed by the domain:ui execution seat (session session_01EMrWaQw3XS5DxTHxp4yRyC), unassigned and unlabelled beyond finding — ⛔ domain:* and grading are triage's. Handed back by the #4895 implementer, which measured it but could not file: search_issues is the only channel matching issue-body text and its repo-scoped REST probe does not cover /search/*, so it correctly declined to file blind rather than skip the duplicate check. This seat ran the check and it changed what the card is.

This is a recurrence, not a new defect — and that is the point

#6141 (closed 2026-08-24, same day it was filed, via PR #6149) recorded the identical defect in the identical file, and set out two routes:

1. Correct the prose — cheapest, and it rots again the next time an entry lands.
2. Derive the count — the runtime census at the bottom of the file already reads MIRRORS; a case asserting the registry size against a single written-down constant would make the number self-correcting the way the key census already is.

⭐ Route 1 was taken. Ten days later the number is stale again. The card predicted its own recurrence in writing, named the mechanism, and was right. That is the finding — not the digits.

Measured on origin/main (6411def25), independent of any open PR

packages/types/src/__tests__/zod-mirror-parity.test.ts:

	#6141, 2026-08-24	today
what the prose claims	163 pairs	160 pairs (:56, Object.keys(MIRRORS).length)
what the registry holds	158	163

The two readings have crossed over: the number the file used to claim is now the number it actually holds, and vice versa. Repeated at :31, :100, :267, :886, :1305, :1353, :1408 — eight sites quoting a figure nothing checks.

The header says so itself: "this line is prose and can rot". Nothing fails when it does — assertionRegistryHalvesAgree compares the two registry halves to each other, never to a written-down count, exactly as #6141 already explained.

⚠️ One half of the handback is NOT reproduced, and is withdrawn here

The implementer also reported the header internally inconsistent, on the grounds that it says both 142 and 123 for "pairs with no entry". This seat did not reproduce that. Read in place, they are two different populations with their denominators written out:

• :1305 — 123 pairs with no entry (160 − 37), against the 37 type-drift pairs;
• :1353 — never for the 142 pairs with no entry in either (160 − 18), against the 18 recorded in either ledger.

Different subtrahends, both labelled. ⛔ Not an inconsistency, and it should not be repeated into the fix as though it were. Only the population count is stale.

Why route 2 is now the only honest option

⛔ A third prose correction is not a fix — it is the same move that has already been measured to fail once in this exact file, and the failure mode is not slow: ten days. The numbers are load-bearing rather than decorative — #6141 recorded that #5927 / PR #6032 was framed as "17 → 13" and that #6058's dispatch asked "how many of the 163 pairs turn red", so a card inheriting the denominator reports a wrong fraction.

⭐ What makes this tractable: the file already contains the instrument. Its runtime census reads MIRRORS directly. A single assertion comparing Object.keys(MIRRORS).length to one written-down constant would make every quoted figure derive from a number that cannot drift silently — which is the "no hand-maintained artefact the drift keeps producing" principle the file's own header argues for.

Not claimed

⛔ Nothing here says any drift measurement is wrong. The ledger entries are pinned to exact key sets and the ratchet works. Only the written population size is stale, and only the absence of a pin on it is new.

Interaction with an open PR — read before measuring

PR #7432 (retire the block schema family, #4895) removes nine paired entries, taking the true count 163 → 154. It deliberately does not touch this header, on the grounds that correcting it properly is its own measurement pass over KnownDrift / UnmirroredDeclared / RuntimeOnlyDeclared and that inventing numbers there would be worse than leaving stale ones. ⚠️ Whoever takes this card should therefore re-derive against the tree as of when they start, not against 163 or 154.

Duplicate check run with a control that fires: the semantic search returned 13 on-topic results including #6141 (the prior instance, closed) and the adjacent live family #6058 / #6152 / #5927 / #7069 — a non-empty on-topic hit set, so the absence of a live card for the recurrence is a reading rather than a broken query.

Refs: #6141 (the prior instance and its written prediction) · PR #6149 (which closed it) · #6058 · #6152 · #5927 · #7069.

[os-project-manager]

两条新读数，都指向同一个结论：路线 1 连「重写的那一刻」都撑不住

本席（session_01EMrWaQw3XS5DxTHxp4yRyC）在别的事上重新量这个表头时撞到的，补记在此。⛔ 不改本卡的诉求，只是把论据从「十天后又烂了」推进到更硬的两条。

① 160 不是「后来烂掉的」——它写下当天就是假的

本卡记录的是状态（宣称 160 / 实际 163，与 #6141 的数字对调）。我把表头写的值与同一提交上的实测值沿该文件最近 25 次提交逐个比对，得到的是历史：

提交	日期	表头写	同一提交实测
7797e3b74	08-24	158	✅ 158
2c1c96735	08-30	158	✅ 158
a04d7c65c	08-30	158	159
2c45966ff	08-31	158	161
a8d5c717e	09-02	158	161
4ca30d044	09-02	160 ← 在此把数字改上去	163
d88e20f55	09-03	160	154（#7432，−9）
045d20ba8	09-03	160	154

4ca30d044 是把这个数往上更新的那次提交，而当天真值是 163。⇒ 这次「重写一遍」不是先对、后来才漂——它在落笔的瞬间就差 3。

这比本卡目前的表述更强：路线 1 失败的机制不是「十天的自然衰减」，而是手写数字这个动作本身不可靠，因为动手的人没有仪器可用。路线 2（把数派生出来）因此不只是「更耐久」，而是唯一在写入时刻就能是对的那条。

三种互不相同的数法各数一次（2 空格缩进带引号键、'*.zod.ts#Name': 行匹配、去重键集合），在 045d20ba8 与 4ca30d044 上三法一致（154 / 163），所以差值不是数法造成的。

② 正在飞的 PR #7543 把它演了一遍——而且作者其余每一项都做对了

#7543（#7455 hidden 加宽，已 PASS 合约复核、已 ready）必须编辑这个表头，因为它的加宽在 app.zod.ts#AppComponentSchema 上种下了一条新的 KnownDrift。在它的 head f7b8948b1 上实测：

表头行	#7543 head 上写的	同一 head 实测
:60 — **40 entries** / **56 keys** ← 本 PR 改的	40 / 56	✅ 40 / 56
:93 — 160 − 40 = **120** ← 本 PR 新写的一行	120	❌ 114（154 − 40）
:56 / :31 / :1459 — 160 pairs / all 160 entries	160	❌ 154
:91 — “stands at 143”	143	❌ 137

它动到的那个数是对的——KnownDrift 39/55 → 40/56，我独立数过，完全吻合。作者在这个 PR 里做了逆向验证、方向预测、对照组、ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL 的重跑，样样到位。它唯一做不到的事，是察觉自己引用的基数是错的——于是把 160 代进了一条全新的算式，生产出一个此前不存在的假数字 120。

⇒ 这是本卡生命期内新增的一个路线-1 失效实例，而且失效方式是最不容易防的那种：一个正在认真测量的作者，正确地更新了自己动过的数，同时无意中扩散了没动过的那个。

⛔ 我没有在 #7543 里手改 120 → 114：手改正是本卡断言撑不住的那个补救法，改完下一次落地照旧。已在该 PR 上留了记录（评论 5531337768），并让它照常放行——它是注释文本，不动任何合约面。

现状读数（045d20ba8，即今日 main）

• MIRRORS = 154
• KnownDrift = 39 条 / 55 键 ✅、UnmirroredDeclared = 16 条 / 97 键 ✅、RuntimeOnlyDeclared = 7 条 / 24 键 ✅ —— 三个台账计数全部正确
• 派生数：154 − 39 = 115（表头写 121）；「no entry in either」= 137（表头写 143）

⚠️ 值得单独指出：烂掉的只有 pairs 及其派生数，三个台账计数一直是对的。台账计数有 ReconcileAgainstLedger 这类不变式在背后顶着，pairs 没有——正是本卡说的那个区别，现在有了对照读数支撑。

⚠️ 承本卡的告诫：154 是 045d20ba8 上的读数；#7543 落地后 KnownDrift 变 40/56、派生数变 114。接卡的人仍应以自己开工时的树为准重数，⛔ 不要继承这里的任何数字。

---

Generated by Claude Code

[os-project-manager]

Re-measured on origin/main — and the header has drifted AGAIN since this card was filed, in a way that strengthens it

domain:ui execution seat, session session_01EMrWaQw3XS5DxTHxp4yRyC. ⛔ Not claimed, no label change, ⛔ nothing edited — this card is awaiting a maintainer and re-measuring does not release it. Recording so the ruling is made against today's numbers.

I hit this while dispatching an unrelated card that edits the same file (#5928 → PR #7577). I had warned that PR's implementer off these counts; it measured the registry independently and got the same figure I did, which is the useful part below.

The falsifiable one

Header :56 names its own expression, so it cannot be argued about:

- **160 pairs** — Object.keys(MIRRORS).length, which assertionRegistryHalvesAgree …

Measured: 154. Twice, independently — my own count of top-level members of the MIRRORS object literal at :360, and #7577's implementer's AST read of the same const, which also reports Declared agreeing at 154. Two instruments, same answer.

⭐ The part that is new since this card was filed

The header has been partially updated. It now reads:

line	text	status
:60	**40 entries** in KnownDrift, **56 keys** across them — 39 / 55 until …	updated (was 39 / 55, which is what I measured earlier)
:93	160 − 40 = **120**	half updated — the 40 is current, the 160 is not
:56	**160 pairs**	not updated
:91, :279	"stands at 143" / "143 of the 160"	not updated

So someone came through, correctly updated the KnownDrift figures, correctly propagated 39 → 40 into the subtraction on :93 — and left the 160 that subtraction is computed from. 160 − 40 = 120 is now wrong in both terms: the minuend was already stale, and the difference was recomputed from it anyway.

⚠️ That is a stronger argument for this card than anything in its original body. The failure is not that someone once wrote a number and walked away. It is that a careful person maintaining these counts updated the ones they were looking at and could not see that the number underneath had moved — because nothing tells them. A hand-maintained derived figure does not become safe by being maintained.

⛔ I am not claiming :91/:279's 143 is wrong-by-N: I did not reproduce what that figure counts, and ⛔ a number I have not measured gets no verdict from me. :93's 120 and :56's 160 are the two I measured.

Third false count in this lane tonight, all in the same class

Recording the pattern, because one instance reads as carelessness and three read as a mechanism:

1. this file's header — 160 where Object.keys(MIRRORS).length is 154.
2. triage ruling R+129 on finding(plugin-calendar/i18n): calendar.allDay renders "all-day" without a provider and "All Day" with one — the factory defaults table is the one inline default check:i18n-keys never value-compares #7454 — "six of the seven other entries"; the table holds seven entries, so six siblings, and 6 of 6 match. (I relayed that count into a dispatch without measuring it; corrected on finding(plugin-calendar/i18n): calendar.allDay renders "all-day" without a provider and "All Day" with one — the factory defaults table is the one inline default check:i18n-keys never value-compares #7454.)
3. this card's neighbour finding(types): StylePropsSchema and StyleProps share a name and zero keys — the naming asserts a mirror relationship that does not exist #5928, in both the card body and its triage ruling — "five keys of phantom drift". PR refactor(types)!: rename the class-name/style zod object outright, no deprecated alias #7577's implementer could not reproduce it, measuring 8 unmirrored + 0 narrower instead, and reported rather than repaired it.

Every one lived in prose no gate reads. Every one was found only because somebody re-measured instead of quoting. ⚠️ The common factor is not the file — it is that a count inside a ruling gets no more credit than a count inside a header, and this lane has been extending it credit.

Suggested shape when this is ruled (⛔ not a decision, and not taken)

Whatever the maintainer decides about repairing the text, the repair that does not recur is to stop writing these as literals — derive them at test time from Object.keys(MIRRORS).length and friends and let the assertion print them, the way #7577's new docstring deliberately names its population as Object.keys(MIRRORS) rather than writing a number that can rot.

---

Generated by Claude Code