从 #4658(双源清账 C6)的路线定价实验里掉出来的范围外发现,不在 #4658 的 PR 里修,单独立案。与 #4650 同族(都是 authorable-surface 门禁的自我校验漏洞)。
事实
packages/spec/scripts/build-schemas.ts 检查 (b)(「live → retired 必须有登记的迁移」)这样匹配:
const surfaces = registeredRetirementSurfaces().flatMap((s) => s.split(' / '));
const unregistered = newlyRetired.filter(
(k) => !surfaces.some((s) => s.endsWith('.' + k.split(':')[1])),
);k 形如 automation/Event:type,k.split(':')[1] 只取叶名 type,再拿它跟全部 major 的所有 conversion surface 做 endsWith。匹配完全不看 key 属于哪个 def —— 任何一条无关的 conversion 只要 surface 以同名叶子结尾,就把这个 tombstone 判为「已登记」。
实测证据
在 #4658 的定价实验里,我把 src/automation/state-machine.zod.ts 的 EventSchema 两个 key 同时改成 retiredKey(...),没有新增任何 conversion。pnpm check:authorable-surface 的输出:
❌ 1 key(s) were tombstoned with no registered migration:
- automation/Event:schema
只报了 schema。automation/Event:type 静默通过 —— 因为 CONVERSIONS_BY_MAJOR[11] 里 flowNodeHttpRename 的 surface: 'flow.node.type' 以 .type 结尾。两者毫无关系:一个是 flow 节点的 type,一个是 automation 状态机事件的 type。
为什么要紧
检查 (b) 的整个目的是保证退休进入 spec-changes.json / upgrade guide / os migrate meta(ADR-0087 D4)。叶名匹配让这个保证对常见叶名整体失效:type、name、config、filter、schema 之外的 objectName、flowName 等 surface 已在册,任何以它们结尾的 key 都能零迁移文档退休,门禁全绿,消费者只能靠失败才知道。
这与 #4650 是同一类问题:门禁的证据链自己不设防。#4650 是「删基线行没人校验」,本单是「登记检查可被无关条目满足」。
建议处置(需维护者裁决,故不自行动手)
把匹配从叶名收紧到定位到 def 的路径。两个方向:
- surface 里带上 def。让 conversion 的
surface 与 ${defKey}:${name} 可判定地对应(或加一个显式的 retires: ['automation/Event:type'] 字段),检查 (b) 改成精确集合匹配。最严格,但要回填现有 conversion。
- 保留 surface 的散文形态,另加一个显式登记表。新增
RETIRED_KEYS_BY_MAJOR: Record<number, string[]>,值就是 ${defKey}:${name},检查 (b) 只认这张表。改动小,且「declared = enforced」。
倾向 2:它让登记这件事从「碰巧字符串对上」变成作者必须写下确切的 key,正是 AI 生成的元数据最容易蒙混的那一环。
关联:#4650(基线手编漏洞)、#4658(发现现场)、#4535、ADR-0087、ADR-0104
从 #4658(双源清账 C6)的路线定价实验里掉出来的范围外发现,不在 #4658 的 PR 里修,单独立案。与 #4650 同族(都是 authorable-surface 门禁的自我校验漏洞)。
事实
packages/spec/scripts/build-schemas.ts检查 (b)(「live → retired 必须有登记的迁移」)这样匹配:k形如automation/Event:type,k.split(':')[1]只取叶名type,再拿它跟全部 major 的所有 conversion surface 做endsWith。匹配完全不看 key 属于哪个 def —— 任何一条无关的 conversion 只要 surface 以同名叶子结尾,就把这个 tombstone 判为「已登记」。实测证据
在 #4658 的定价实验里,我把
src/automation/state-machine.zod.ts的EventSchema两个 key 同时改成retiredKey(...),没有新增任何 conversion。pnpm check:authorable-surface的输出:只报了
schema。automation/Event:type静默通过 —— 因为CONVERSIONS_BY_MAJOR[11]里flowNodeHttpRename的surface: 'flow.node.type'以.type结尾。两者毫无关系:一个是 flow 节点的type,一个是 automation 状态机事件的type。为什么要紧
检查 (b) 的整个目的是保证退休进入
spec-changes.json/ upgrade guide /os migrate meta(ADR-0087 D4)。叶名匹配让这个保证对常见叶名整体失效:type、name、config、filter、schema之外的objectName、flowName等 surface 已在册,任何以它们结尾的 key 都能零迁移文档退休,门禁全绿,消费者只能靠失败才知道。这与 #4650 是同一类问题:门禁的证据链自己不设防。#4650 是「删基线行没人校验」,本单是「登记检查可被无关条目满足」。
建议处置(需维护者裁决,故不自行动手)
把匹配从叶名收紧到定位到 def 的路径。两个方向:
surface与${defKey}:${name}可判定地对应(或加一个显式的retires: ['automation/Event:type']字段),检查 (b) 改成精确集合匹配。最严格,但要回填现有 conversion。RETIRED_KEYS_BY_MAJOR: Record<number, string[]>,值就是${defKey}:${name},检查 (b) 只认这张表。改动小,且「declared = enforced」。倾向 2:它让登记这件事从「碰巧字符串对上」变成作者必须写下确切的 key,正是 AI 生成的元数据最容易蒙混的那一环。
关联:#4650(基线手编漏洞)、#4658(发现现场)、#4535、ADR-0087、ADR-0104