Repository navigation
ADR-0049 定去留:NotificationActionSchema / EmbedConfigSchema 实测没有授权门(#4001 批 14 改判的两个站点) #5015
Description
Activity
分诊(PM,2026-08-04):按既定规范直接定退役,T2 档(空位填充,错过 v17 零悔)。同形状本周已三裁全 A(#4988/#4938/#4834——无门死面按 implementation-first 退役),切线规则 T2 明含此类;不再升级,维护者否决窗口有效。执行按 spec-property-retirement 套件,批 14 的 BFS/阳性对照证据(6860 节点、合成承载键翻转验证)即立案依据,dev 复核后照走。
Generated by Claude Code
- added a commit that references this issue
on Aug 4, 2026 - added a commit that references this issue
on Aug 4, 2026 认领:PM 循环第 1 轮(spec 车道,维护者已提速至 batch:3,v17 优先)
会话:session_01ErbEDVAg1No9gdg1pgDAGB
分支:claude/issue-5015-notification-embed-retirement
Worktree:objectstack-issue-5015
域:domain:spec
文件面:packages/spec/src/ui/notification.zod.ts(候补整文件退役)、packages/spec/src/ui/sharing.zod.ts(⚠️ 仅EmbedConfigSchema,同文件SharingConfigSchema是活门不动)、packages/spec/src/ui/index.ts(barrel)、ADR-0087 conversion registry、spec 生成基线(与同批 #5021/#4938 在生成物上重叠,落地时按 os-regen 四步互保兄弟条目)、strictness 台账、.changeset/*.md执行依据:上方分诊裁决(2026-08-04,T2 退役,否决窗口已过)。注意:objectui
animation-notification-spec-parity.test.tsx把NotificationActionSchema.shape当词汇表消费,spec 侧摘除后 objectui 刷新依赖时会红 —— objectui 侧适配由 PM 在验收时单独立案挂 objectui 队列,本单 dev 不碰 objectui。
Generated by Claude Code
验收:ACCEPT(PM 复核毕,PR #5300)
复核依据(GitHub 实据):
- PR 形态 ✓ draft、目标 main、
Fixes #5015开头;18 个文件对账吻合(D3 语义迁移落migrations/registry.ts),无 releases/、无越界; - 裁决贴合 ✓ 双 schema 整 def 删除;按 SCHEMA 不按文件 ——
SharingConfigSchema活门原样保留(strictObject 未动,strict 列 120 不变即为证),notification.zod三个活枚举保留。dev 否决了派发词里「整文件退役 on the table」的预期,证据充分(三个活导出),予以确认; - 路线偏离予以确认:免墓碑免 D2、注册 D3
SemanticMigration—— 两个形状从未有承载键,无键可墓碑、无源可转写,ADR-0049:plugin-runtime.zod.ts剩余家族(DynamicLoadRequest / DynamicUnloadRequest / DynamicPluginResult / PluginSource / DynamicPluginOperation)四仓零 runtime consumer —— enforce-or-remove 悬置待裁 #4834 同档先例成立; - 测量质量突出:BFS 仪器两个缺陷(derived-clone 桥接、
.mts双模块实例)被阳性对照抓住并修复后才采信零命中 —— 「第一版结论恰好也对但理由是假的」这条记录进了 PR 正文,是本车道读数纪律的活教材; - 测试证据 ✓ 12 张门 + i18n PASS、spec 309/7938、双向 pin(缺席 + 存活)反向验证两次均按预判红 —— 第二次正好抓住派发词点名的范围性错误形状;台账 484→482、no door 38→36 全机器重算;
- 顺带发现
app元数据表单仍然提供三个已retiredKey()退役的键（sharing/embed/mobileNavigation）—— 填了必然存盘失败，而 #3786 对账门看不见 #5280 已立、已转入本车道队列(前置核验的直接产物,App.embed墓碑线索同时解释了EmbedConfig孤儿成因 —— 闭环)。
后续:CI 全绿后转 ready 入合并队列;objectui 侧适配单已立(3 个文件受影响,见下),Blocked-by 本 PR。
Generated by Claude Code
- PR 形态 ✓ draft、目标 main、
- added a commit that references this issue
on Aug 4, 2026 - added a commit that references this issue
on Aug 4, 2026 - added a commit that references this issue
on Aug 6, 2026 - added a commit that references this issue
on Sep 28, 2026 - added a commit that references this issue
on Oct 6, 2026 - added 3 commits that reference this issue
on Oct 7, 2026
与 #4988 同类。#4001 批 14 对
ui/六个文件逐个做门测量,11 个 strip 站点里 9 个是真门(已收紧)、2 个实测没有门。这两个不收紧 —— 「一个被精确校验的死槽位是更有说服力的谎言」(#4583)—— 但它们需要的判定是 ADR-0049 enforce-or-remove,不是棘轮。两个站点
NotificationActionSchemapackages/spec/src/ui/notification.zod.tsEmbedConfigSchemapackages/spec/src/ui/sharing.zod.ts注意
sharing.zod.ts是同文件内劈开的 —— 它的兄弟SharingConfigSchema是活门(FormViewSchema.sharing承载,rest-server.ts真的读sharing.allowAnonymous/sharing.publicLink来挂匿名表单路由,两个示例应用都在写),批 14 已收紧。这是账本第一次遇到一行两判,也是「per SCHEMA, not per file」这句话第一次真正生效。三条独立测量(2026-08-03,均带阳性对照,同一次运行)
packages/spec/src里除ui/index.tsbarrel 外无任何模块 import 这两个模块……ui/notification.zod的 importer 精确等于['ui/index.ts'];ui/sharing.zod的 importer 是['ui/index.ts', 'ui/view.zod.ts'],而view.zod.ts点名的是SharingConfigSchema;全仓没有任何模块提到EmbedConfigSchema。sharing.zod,子串法会把stack.zod.ts/security/index.ts误记为 UI 那个的 importer。这一条是先证红发现的。)defineStack的ObjectStackSchema做 BFS(build-schemas.ts给 authorable-surface 的 tombstone 门禁可被手编基线绕过 —— 删掉基线行就删掉了证据(#4638 / #4643 已两次这样过绿) #4650 删除检查用的同一套闭包),6860 个节点,两个都走不到。同一次运行里四个阳性对照PageSchema/ActionSchema/DashboardWidgetSchema/WebhookSchema全部root-graph;注入一个合成承载键后两个都翻成root-graph。对照通过,所以「不可达」是关于图的事实。.parse()。一个值得单独记的细节:objectui 消费的是 shape,不是 parse
NotificationActionSchema并非无人问津 —— objectui 的animation-notification-spec-parity.test.tsx读NotificationActionSchema.shape.variant,双向 pin 它自己手写的NotificationActionButton接口。但那是把 schema 当词汇表用,和 posture 完全无关:收紧它不会让那条 pin 更强一分。这恰好说明「有消费者」不等于「有授权门」,也是这两个站点该走 ADR-0049 而不是走棘轮的原因。
需要的判定
EmbedConfigSchema:iframe 嵌入从来没有承载键。是补一个(哪个 metadata type 该带embed?),还是按 enforce-or-remove 退役?NotificationActionSchema:spec 双源清账 C3:通知语汇 Notification(Schema)(./api ≠ ./ui)+ NotificationConfig(Schema)(./system ≠ ./ui)—— 4 条,单 PR #4610 已经因为零消费者删掉了它的两个 wrapper(NotificationSchema/NotificationConfigSchema),这个 action 形状是那次留下的孤儿。留作纯词汇表(那就该在文件里说清它不是可授权面),还是一并退役?批 14 已在两处 schema 的 JSDoc + 测试 pin + 账本行三处留痕,pin 是会红的:任何人给这两个形状接上承载键,那条断言立刻红并把人指回这里。
未指派。