发现于 #5094 的实施(PR #5104)反向验证。Filed unassigned, not claiming。观察类:今天没有读者会撞到 —— 现存的每张键表实测都是对的;这条记的是「守它的东西不存在」。
两条实测事实
scripts/check-doc-component-types.mjs 的 scanDocs 只在 fenced code block 内取 type: 'VALUE' 形的字面量(函数自己的注释写明:"Fences are tracked so prose that merely mentions a type in backticks is not read as a snippet")。由此:
1. markdown 表格 / 散文里的组件键,门看不见。
在 content/docs/plugins/plugin-dashboard.mdx 的键表里插一行假键:
| plugin-dashboard:phantom-widget | phantom-widget | PhantomWidget — nothing registers this |
node scripts/check-doc-component-types.mjs → rc=0,Every documented component type is registered.
同一个假键放进本页某个 fenced code block("type": "phantom-widget")则立刻红:
content/docs/plugins/plugin-dashboard.mdx:179 [unregistered-doc-type] type 'phantom-widget' (json)
门本身有牙,牙只长在围栏里。
2. 门从不判 namespace 半边。
把 packages/plugin-dashboard/src/index.tsx 里 dashboard 那次注册的 namespace: 'view' 改成 'dash',deriveRegistryKeys 立刻翻成 dash:dashboard(推导是活读),但 check-doc-component-types 仍然全绿 —— 它判的是 bare 键存在与否。所以任何文档把 view:dashboard 写成 plugin-dashboard:dashboard,静态面零信号。
为什么现在值得记一笔
#5002 家族这一轮(PR #5071 / #5078 / #5079 / #5085 / #5089 / #5093 / #5100 / #5104)把「虚构的 *Components 手动注册循环」一律换成了同一种同族形:一张 | Namespaced key | Bare-name fallback | Renderer | 的 markdown 表。这个形是对的 —— 但它恰好整体落在门的扫描面之外,而它替换掉的那些代码块曾经在扫描面之内(尽管那批缺陷门也抓不到,原因另有其一:旧循环里 type 是解构出的标识符,不是 type: '字面量')。
净效果:这一族修复把「教什么键」的事实从代码块搬进了表格,守它的只剩人工比对。#4823(门的立卡)在正文里把扫描面定义成代码块,是有意的作用域,不是 bug —— 所以这条不是「门坏了」,是「同族形与门的作用域错开了」。
可能的方向(不预断,交分诊)
- A. 把
| \ns:key` | `key` |这种**结构化表格行**也纳入扫描(只认这一种形,避免把散文里的反引号全部拖进来),namespaced 半边对deriveRegistryKeys` 的 namespace 一起核; - B. 不动门,改让这族键表生成而不是手抄(键表由
deriveRegistryKeys 产出,文档只留一处 include); - C. 判定为可接受的作用域,只在门的头注释里写明「表格不在扫描面」,让下一个照抄同族形的 agent 知道自己没有网。
代价与长期取向差别很大(A 扩门面、可能引入误红;B 是契约先行但要新增生成步骤;C 零成本但把可防错性留给人),故不自裁。
复核方式
sed -n '685,730p' scripts/check-doc-component-types.mjs # scanDocs 的围栏跟踪
node scripts/check-doc-component-types.mjs # 基线绿
# 在 content/docs/plugins/plugin-dashboard.mdx 键表插一行假键 → 仍绿
# 把同一假键放进任一 json 代码块的 "type" → 红 unregistered-doc-type
发现于 #5094 的实施(PR #5104)反向验证。Filed unassigned, not claiming。观察类:今天没有读者会撞到 —— 现存的每张键表实测都是对的;这条记的是「守它的东西不存在」。
两条实测事实
scripts/check-doc-component-types.mjs的scanDocs只在 fenced code block 内取type: 'VALUE'形的字面量(函数自己的注释写明:"Fences are tracked so prose that merely mentions a type in backticks is not read as a snippet")。由此:1. markdown 表格 / 散文里的组件键,门看不见。
在
content/docs/plugins/plugin-dashboard.mdx的键表里插一行假键:node scripts/check-doc-component-types.mjs→ rc=0,Every documented component type is registered.同一个假键放进本页某个 fenced code block(
"type": "phantom-widget")则立刻红:门本身有牙,牙只长在围栏里。
2. 门从不判 namespace 半边。
把
packages/plugin-dashboard/src/index.tsx里dashboard那次注册的namespace: 'view'改成'dash',deriveRegistryKeys立刻翻成dash:dashboard(推导是活读),但check-doc-component-types仍然全绿 —— 它判的是 bare 键存在与否。所以任何文档把view:dashboard写成plugin-dashboard:dashboard,静态面零信号。为什么现在值得记一笔
#5002 家族这一轮(PR #5071 / #5078 / #5079 / #5085 / #5089 / #5093 / #5100 / #5104)把「虚构的
*Components手动注册循环」一律换成了同一种同族形:一张| Namespaced key | Bare-name fallback | Renderer |的 markdown 表。这个形是对的 —— 但它恰好整体落在门的扫描面之外,而它替换掉的那些代码块曾经在扫描面之内(尽管那批缺陷门也抓不到,原因另有其一:旧循环里type是解构出的标识符,不是type: '字面量')。净效果:这一族修复把「教什么键」的事实从代码块搬进了表格,守它的只剩人工比对。#4823(门的立卡)在正文里把扫描面定义成代码块,是有意的作用域,不是 bug —— 所以这条不是「门坏了」,是「同族形与门的作用域错开了」。
可能的方向(不预断,交分诊)
| \ns:key` | `key` |这种**结构化表格行**也纳入扫描(只认这一种形,避免把散文里的反引号全部拖进来),namespaced 半边对deriveRegistryKeys` 的 namespace 一起核;deriveRegistryKeys产出,文档只留一处 include);代价与长期取向差别很大(A 扩门面、可能引入误红;B 是契约先行但要新增生成步骤;C 零成本但把可防错性留给人),故不自裁。
复核方式