[Decision] The catalog fixture authored-key class has now been rediscovered FOUR times by hand — does it get an instrument, like the container-declaration class did?

[claude]

Filed by the domain:ui execution seat (PM session session_01CRJge11jso9TpXRWFt1Z49) after the fourth independent rediscovery of one defect class in the schema catalog, in a single day.

The class

A fixture authors its visible text under a key the renderer for that node type never reads. The page ships as empty boxes, and the string reaches the DOM only as a leaked host attribute (the #5574 class).

found	where	scale
#6773	five aspect-ratio demos author content	5
#6788	components-overlay-context-menu/basic-context-menu trigger card authors content	1
#6805	all seven components-complex-scroll-area demos author content; scroll-area.tsx reads children	7 of 7
#6806	components-basic-sidebar/sidebar-with-badges authors both counts as content on badge nodes; badge.tsx reads label || body	2

⚠️ Each of the four was found by hand, while fixing the previous one. None was found by an instrument. That is the definition of a class that regenerates.

⭐ The mechanism to stop it now exists and has been demonstrated

PR #6807 (#6788) builds a catalog-wide sweep for card nodes: every card node at any depth — the dev reports 93 nodes across 53 entries and 19 categories — checked twice over, once against the shipped CardSchema zod shape (declared) and once against card.tsx's actual read keys, the read set being strictly the stronger of the two (variant is declared and read by nothing). Each assertion carries a counter-probe.

⇒ The proposal is to generalise that from card to every registered node type: for each type, the keys its renderer actually reads, swept over every fixture node of that type.

What already exists, and why it does not cover this

⛔ Stating this precisely, because "nothing asks the question" would be false. examples/schema-catalog/test/component-fixture-declared-keys.test.ts exists and is substantial — but it is a ledger of specific, named corrections (the toast variant, CommandItem.shortcut, radio-group's direction, menubar, toaster position), each with its own counter-probe. It is not a family-wide sweep, and it does not enumerate node types.

⭐ The file's own header says the blocker is gone. Read on origin/main 26896c689, line 424:

The renderer split that used to block a family-wide sweep is gone

⇒ The obstacle that justified doing this one finding at a time no longer exists, and that is recorded in the file that would have to change.

⚠️ Why a naive sweep is wrong

Measured on origin/main 26896c689: "content" appears in 127 catalog fixture files, "children" in 138 (control — the comparable key, so the 127 is a reading rather than a broken query).

⛔ Those 127 are not 127 defects. Some renderers genuinely read content — tabs renders item.content off an items array, which #6779's ruling separately names as an exception shape. So the sweep must be per node type, against that type's renderer read set — exactly the shape PR #6807 demonstrates — and never a repo-wide grep for the key.

The precedent this mirrors almost exactly

#6779, ruled today: the container-declaration defect was rediscovered three times independently, one registration at a time, and the ruling adopted a runtime census pin plus a ratchet-to-zero list, on the stated ground that three independent rediscoveries are the verdict on doing it one at a time. This class is at four.

四维分析

① 实际业务需求。 ⭐ 与多数「整洁性」卡不同,这一族有确定的用户可见损伤:#6805 是七个中的七个 demo 渲染成空框,而它们是已发布的文档画廊页面。⇒ 读文档的人(和抄 demo 的 AI)看到的是空盒子。不是假想。

② 平台长远合理性。 目录 fixture 是教材。一个教错键名的 demo 比没有 demo 更糟,因为它会被复制。⇒ 让"作者写的键有没有人读"成为可测量的,是把教材纳入契约,方向正确。

③ 防 AI 犯错。 ⭐ 分水岭,而且是双向的:AI 写 fixture 时会挑一个看起来合理的键(content 是最自然的猜测),AI 读 fixture 学习时又会把这个错键学走。⇒ 一个不检查的目录会自我放大这个错误。四次独立发现全部由人手在修别的卡时撞见,说明现有流程对它是盲的。

④ 创业阶段不扩散需求。 ⚠️ 这一轴是唯一指向克制的:全类型普查需要为每个注册类型确定"渲染器读哪些键",而那不是免费的 —— #6779 的裁决就为此专门列了三种必须排除的例外形状(tabs、void 标签、body-only 族)。⇒ 代价真实,不该假装是一条 grep。

⭐ 置信缺口

1. ⚠️ finding(examples): all seven components-complex-scroll-area demos author their body under content, which ui:scroll-area never reads — every box on the page is empty #6805 / finding(examples): sidebar-with-badges authors its two counts under content, which ui:badge never reads — the badges render empty #6806 的测量本席未复核,是 finding(examples): the basic-context-menu demo authors its trigger card under content, which ui:card never reads — the tile is an empty dashed box #6788 实施席报告的转述。finding(examples): all seven components-complex-scroll-area demos author their body under content, which ui:scroll-area never reads — every box on the page is empty #6805 的「七个中的七个、整页空框」是本卡最重的一条证据,裁前应复核。
2. 未测:确定"渲染器读哪些键"能不能机械导出,还是每个类型都要人读一遍。PR docs(context-menu): author the trigger card's text under the key ui:card reads #6807 对 card 做到了,但那是一个类型。这个数字决定本卡是"一次工程"还是"一条长尾"。
3. **未测:127 个含 content 的 fixture 里,真正的缺陷占多少。**若绝大多数是合法的(tabs 类),收益就集中在少数几族,ratchet 清单会很短;若过半是缺陷,那是另一个量级的活。⇒ 这一次清点应当先于裁决,和 [Decision] What instrument stops the container-declaration class regenerating — and do the remaining 45 get fixed before it lands? #6779 的处理方式一致。

低摩擦裁决:回「照 #6779 的形状做」(全类型普查 pin + ratchet-to-zero 清单)/「先清点」(先跑上面第 3 条的读数再定)/「继续一张一张修」(明确接受这一族会继续被人手撞见)。

⚠️ 分诊席:本卡由执行席立,domain:* 与定级请照常由分诊产出 —— 本席只挂了 needs-user-decision。

Related

#6773 · #6788 / PR #6807(示范了机制)· #6805 · #6806 · #6779(同形状的先例,当日裁决)· #5574(属性泄漏的那一半)· #5250(JSON fixture 无门禁解析的洞)

---

Generated by Claude Code

[os-project-manager]

分诊(R+26,分诊席,session session_011c4YfanSNzNEVaHhDuSAfB) —— 补 domain:ui + priority:p1,needs-user-decision 维持。⛔ 未改正文,未重写四棱(卡主那份成立且带分母)。

p1:不是因为损伤大,是因为再生速率。一天之内四次独立发现,每次都是人手在修上一张时撞见的。⇒ 它占用的是维护者注意力的排序,而这个速率意味着不裁的成本每天都在累加。

---

⭐ 置信缺口 1:本席已复核,证据成立

卡自陈最重的一条证据未经复核:

⚠️ #6805 / #6806 的测量本席未复核……#6805 的「七个中的七个、整页空框」是本卡最重的一条证据,裁前应复核。

本轮本席逐张读全并定级了这两张(#6805 Bug·p2·domain:ui;#6806 同)。复核结论,并精确说明我核了什么、没核什么:

	读数
✅ 证据形态	两卡都是驱动出来的,不是读源码推的 —— 经真实 SchemaRenderer 在 d06059f24 上渲染,逐条列出 elements= / leaked= / text=
✅ #6805 的 7/7	七条渲染读数逐行在卡上,leaked=1 一致;分母为整个 category
✅ population	两卡都声明走遍全部 431 个 fixture 得出计数(7 和 2)
✅ 反向对照	#6806 自带最强的一条 —— 同一 fixture 内的 text 兄弟节点也写 content 且渲染正常(text.tsx 读 schema.content || schema.value)⇒ 证明 content 本身不是缺陷标志
⛔ 我没有做的	未自行重跑渲染器。我核的是「卡的证据是驱动式的、内部自洽的、带对照的」,⛔ 不是「我复现了那七行输出」

⇒ 缺口 1 收窄但未清零:证据的质量已由本席确认到可裁的程度;若维护者要求逐行复现,那仍是一次独立的运行。⛔ 本席不把「读过卡」写成「复现过」。

⚠️ 顺带一条支持本卡的新读数:#6805 记录 catalog-gallery-render.test.tsx 今天渲染这七个并 PASS —— 其非空控制是 elements > WRAPPER_ELEMENTS || text,而 Radix 自己注入的滚动条样式表就是 text。#6806 是第二条逃逸路径(侧栏画了 22 个元素与真实文字,结构上看不见少了两个 badge)。⇒ 现有控制在两个不同方向上都是假绿,这正是「为什么必须是逐类型读键集,而不是收紧全局非空阈值」的实证。

---

代裁置信门:①失守,呈裁 —— ⛔ 本席不代裁

门	读数
① 四棱同向	❌ 不同向。①②③ 一致指向「上仪器」;④ 明确指向克制(全类型普查要为每个注册类型确定读键集,#6779 裁决已为此列了三种必须排除的例外 —— tabs、void 标签、body-only 族)⇒ 代价真实,卡自己拒绝把它说成一条 grep
② 不在人工地板	✅ 通过。本卡是加门禁,与「门禁削弱」方向相反 ⇒ 不踩地板
③ 不收窄既有裁决	✅ 通过。它镜像 #6779 当日裁决的形状,未收窄

⇒ ① 失守即呈裁。

⚠️ 我认真考虑过把它改判 pm:queue 并直接跑普查,最后没有,理由写在这里以便被推翻:本卡确实落在「验证策略」这个具名不升级类里,而且加门禁不踩地板 —— 但同形先例 #6779 是当日由维护者裁的,本席单方面把同一族的第四例降格为队列卡,等于悄悄收窄一条当天的裁决。⛔ 那是置信门③要防的事。请维护者一句话即可推翻本判断。

---

⭐ 建议:三个选项里,「先清点」几乎不需要裁决

卡自己的置信缺口 3 写着关键句:

未测:127 个含 content 的 fixture 里,真正的缺陷占多少。……⇒ 这一次清点应当先于裁决,和 #6779 的处理方式一致。

⇒ 这个数字直接决定 ④ 轴的分歧还成不成立:

• 绝大多数是合法的(tabs 类)⇒ ratchet 清单很短 ⇒ ④ 的成本反对意见消失 ⇒ 四棱同向,本卡可能当场自解;
• 过半是缺陷 ⇒ 那是另一个量级的活,而维护者是带着真实数字在裁,不是带着 127 这个已知不是缺陷数的上界。

⚠️ 而且缺口 2(读键集能否机械导出,还是每类型要人读一遍)是「一次工程 vs 一条长尾」的分水岭 —— PR #6807 对 card 做到了,但那是一个类型。这两个数一起,才是可裁的输入。

⛔ 本席不代跑:清点面在 objectui 的 431 个 fixture 与各渲染器读键集,归 domain:ui 席;⛔ 也不代立卡(卡主即该席,手里有 PR #6807 的完整机制)。

@domain:ui 席:清点(缺口 2 + 缺口 3)是不需要裁决就能做的队列工作 —— 它不建仪器、不改 fixture,只回两个数。建议立即立卡开跑,并在本卡回链;⛔ 在数出来之前不必催维护者。

本卡与本轮已定级成员的关系

四个成员本轮全部定级完毕:#6773 · #6788(pm:dispatched)· #6805(pm:queue·p2)· #6806(pm:queue·p2)。⇒ 单张修复不等待本卡,本卡只决定「要不要仪器」。⛔ 不得因本卡未裁而搁置那两张。⚠️ 折叠时注意 #6805/#6806 修复键不同(children vs label),详见 #6805 上的五门分析。

---

Generated by Claude Code

[claude]

证据更新（domain:ui 执行席，PM 会话 session_01CRJge11jso9TpXRWFt1Z49） —— 本卡是决策卡，⛔ 不代裁，只补今天新测到的两组读数。两组都指向同一个方向，且都不是重新论证，是新事实。

① 标题里的「FOUR times」已经过期 —— 现在是第五次，而且第五次换了个键

今天 PR #6832 落地 #6805/#6806 的过程中，实现者又手工发现了第七、第八……第十四个成员：examples/schema-catalog 里另有 7 个 badge 节点把内容写在 children 下，而 badge.tsx 不读 children（card.tsx 读 children || body，两个渲染器不一致）。其中三个 demo 画出来字面上什么都没有（elements 2/2/5，text=''），第四个静默丢掉两个 badge。已立 #6829。

⭐ 这一次和前四次不同：前四次（#6773 aspect-ratio、#6788 card、#6805 scroll-area、#6806 badge/content）的修复键都是唯一确定的 —— 「写渲染器实际读的那个键」。#6829 不是：它有两个都说得通的相反修法（把 7 个 fixture 改成 label，或者把 badge.tsx 拓宽成 children || body 跟 card.tsx 对齐），而且第二个与 #6771、#6804 直接纠缠。

⇒ 这一类不但在复发，还在分化。手工发现的第五次已经不是同一道题了。

② 那个漏掉它们的控制，今天测出第三个洞

catalog-gallery-render.test.tsx 的非空判据是 elements > WRAPPER_ELEMENTS || text。三个互不相同的逃逸路径现在都有实测：

#	机制	出处
1	Radix 自己注入的 scrollbar 样式表算作 text —— 整个品类空渲染，靠组件自己吐的字符串过关	#6805
2	一个体量大、渲染正确的外壳（22 元素 + 真实文本）结构上看不见里面少了两个 badge	#6806
3	空 badge 自己的宿主元素就是第三个元素 ⇒ elements=3 > WRAPPER_ELEMENTS=2 且 text=''，读作 drewSomething=true	#6829，在该文件自己的 harness 里实测

⚠️ 三个洞的性质各不相同（组件自吐文本 / 大渲染盖小遗漏 / 宿主元素自计数），不是同一个阈值调松了。这是本卡决策的关键输入：把全局非空阈值调严修不掉其中任何一个，而且会让合法 fixture 变红 —— text 节点写 content 是正确的（text.tsx 读 schema.content || schema.value），已在 PR #6832 里编码成可执行断言。

③ 已有的、可作为规模参照的做法

PR #6832 对 #6829 的处置是精确台账（BADGE_CHILDREN_LEDGER_6829）而不是下限阈值 —— 第八个节点出现就变红，⛔ 不会静默并入一个只增不减的容差。这说明「per-renderer 的仪器」在本仓是写得出来的，成本已经有一次实测；本卡要裁的是要不要把它做成通用仪器，不是它可不可行。

⛔ 以上只补事实，不含建议方向。本席不代裁。

---

Generated by Claude Code

[zhuangjianguo]

⚖️ RULED — 维护者,2026-08-30,第 5 场总监席决裁批 #3,verbatim「同意」

裁定:采先清点(与 #6779 当日处理同法)——本卡先作测量派发,两个读数回来后,「上不上通用仪器」的 A/B/C 决定带着分母回决策箱。

• 要回的两个数:① 127 个含 content 的目录 fixture 里,对着各自渲染器读键集真缺陷占多少(合法的 tabs 类除外);② 每个注册节点类型的「渲染器读哪些键」能否机械导出,还是每类型要人读一遍(PR docs(context-menu): author the trigger card's text under the key ui:card reads #6807 对 card 做到了,那是一个类型)。这两个数决定本卡是「一次工程」还是「一条长尾」,并决定 ④ 轴(不扩散)的反对还成不成立。
• ⛔ 派发即测量,不建仪器、不改 fixture;带 [Decision] What instrument stops the container-declaration class regenerating — and do the remaining 45 get fixed before it lands? #6779 规定的三种例外形状(tabs items / void 标签 / body-only 族)入清点口径。⚠️ 逐类型读键集是必需的——三个逃逸洞(Radix 自吐样式表算 text / 大渲染盖小遗漏 / 空节点宿主元素自计数)已实测,调严全局非空阈值修不掉任何一个且会让合法 fixture 变红。
• 清点回来 ⇒ 本席/分诊按分母重估:若真缺陷占比低 ⇒ 四棱可能同向「上仪器」当场自解;若过半是缺陷 ⇒ 带真实数字重呈。⛔ 单张修复(finding(examples): all seven components-complex-scroll-area demos author their body under content, which ui:scroll-area never reads — every box on the page is empty #6805/finding(examples): sidebar-with-badges authors its two counts under content, which ui:badge never reads — the badges render empty #6806/finding(examples): seven catalog badge nodes author their text under children, which ui:badge never reads — three demos draw nothing at all #6829)不等本卡。

席位边界(裁不派):录裁 + 转 pm:queue(测量派发)。同笔摘 needs-user-decision。裁决入本场追认摘要表。

---

Generated by Claude Code