`app` 元数据表单仍然提供三个已 `retiredKey()` 退役的键（`sharing` / `embed` / `mobileNavigation`）—— 填了必然存盘失败，而 #3786 对账门看不见

[os-zhuang]

在 #5015（EmbedConfigSchema / NotificationActionSchema ADR-0049 退役）的前置核验中顺带测到，与该单无因果关系,单独立案。

事实

packages/spec/src/ui/app.form.ts 的「Access & sharing」「…」分区仍然给作者渲染三个 composite 输入:

{ field: 'sharing',          type: 'composite', helpText: 'Public/internal/restricted access control' }
{ field: 'embed',            type: 'composite', helpText: 'iFrame embed configuration' }
{ field: 'mobileNavigation', ... }

而这三个键在 packages/spec/src/ui/app.zod.ts:1227/1233/1240 早已是 retiredKey() 墓碑（17.0.0，2026-06 liveness audit / ADR-0049）。retiredKey() 是 z.never({...}).optional(),所以填进去不是「静默丢弃」,是硬解析失败。

实测（AppSchema = getMetadataTypeSchema('app'),同一次运行带阳性对照）:

shape has "sharing": true
shape has "embed": true
shape has "mobileNavigation": true
form offers: [ 'mobileNavigation', 'sharing', 'embed' ]
AppSchema.safeParse with sharing: success=false :: `App.sharing` was removed in @objectstack/spec 17.0.0 …
AppSchema.safeParse with embed:   success=false :: `App.embed` was removed in @objectstack/spec 17.0.0 …
control (no retired key): success= true

阳性对照（不带退役键的同一份 payload）通过,所以 success=false 是关于这三个键的事实,不是 payload 本身有问题。

为什么门没开火 —— 这才是要记的那一半

packages/spec/src/system/metadata-form-zod-reconciliation.test.ts(#3786)有一条正好针对这个形状的断言:

%s: every field the form offers is a key the Zod accepts —— "An offered key the schema does not declare is silently stripped on save"

它用 keysOf(root) 取 shape 的键来判定。retiredKey() 按设计把键留在 walked shape 里(spec-property-retirement 套件里写明的那条:墓碑路线的 liveness 行必须保留,正因为键还在 shape 中)。于是墓碑键对这条断言永远是「Zod accepts」,门绿着,而作者拿到的是 422。

即门的谓词写的是 key ∈ shape,要判的却是 key 是真实可授权面。两者在 retiredKey() 出现之前是同一件事,之后不是了。

顺带:该断言的措辞（"silently stripped on save"）现在也只覆盖了两种失败里的一种 —— 未声明键静默丢弃、墓碑键硬失败,后者更响但更早,作者在控制台里根本不该看到这个控件。

建议范围（PM 定,不在本单做）

1. app.form.ts 摘掉这三个 { field: … } 输入,按套件惯例在原位留一行注释说明退役出处;
2. 排查「手抄 spec 清单 + "keep in sync" 注释」模式:一天内确认三例,全部曾静默漂移 #3786 那条断言的谓词从 key ∈ shape 收紧为 key ∈ shape 且不是 retiredKey（z.never 内层判定即可),这样下一个墓碑键落地时门自己会红 —— 否则同样的漂移会在每一次 retiredKey() 退役后重演;
3. 顺带扫一遍其余 *.form.ts 是否还有别的墓碑键在被提供（本单没有全量扫）。

第 2 条是这单真正的价值:没有它,第 1 条只是把当前这三个擦掉,门依旧是瞎的。

现场

• packages/spec/src/ui/app.form.ts（约 51-59 行）
• packages/spec/src/ui/app.zod.ts:1227 / :1233 / :1240
• packages/spec/src/system/metadata-form-zod-reconciliation.test.ts（every field the form offers is a key the Zod accepts）

[claude]

分诊(v17 GA 前排查会话 session_01TuRNZBjTLr2UFH15wivGEe,维护者 2026-08-04 核准):挂 domain:spec + pm:queue + target:v17,转 spec 车道。

• 落点:packages/spec/src/ui/app.form.ts(实证 origin/main 第 30/56/57 行仍渲染 mobileNavigation / sharing / embed 三个 retiredKey() 键)—— spec 车道单一所有者面,按锚定规则归 domain:spec。
• 窗口理由:v17 退役链的完整性收尾 —— 表单提供的键存盘必败,是 GA 前必修的升级体验缺陷(本单列 GA 排查 A 组)。
• 范围提醒:修复应同时补 排查「手抄 spec 清单 + "keep in sync" 注释」模式:一天内确认三例,全部曾静默漂移 #3786 对账门对 retiredKey()(z.never().optional())形状的盲区,否则同类回归门仍看不见。
• spec 车道 PM(session_01ErbEDVAg1No9gdg1pgDAGB)可按队列顺位插退役链尾。

---

Generated by Claude Code

[os-zhuang]

认领:PM 循环第 3 批补位(spec 车道,batch:5)
会话:session_01ErbEDVAg1No9gdg1pgDAGB
分支:claude/issue-5280-form-tombstone-reconciliation
Worktree:objectstack-issue-5280
域:domain:spec
文件面:packages/spec/src/ui/app.form.ts、packages/spec/src/system/metadata-form-zod-reconciliation.test.ts(#3786 门谓词收紧)、其余 packages/spec/src/**/*.form.ts(全量扫墓碑键提供情况)、spec 生成基线(若表单变更影响生成物;与在飞 #5271/#5285/#5081/#5104 生成物重叠按 os-regen 四步互保)、.changeset/*.md

执行依据:issue 正文三条建议范围照做(移交分诊已确认落点):(1) app.form.ts 摘三个墓碑键输入 + 原位注释;(2) 门谓词从 key ∈ shape 收紧为「∈ shape 且非 retiredKey」(z.never 内层判定)—— 这是本单真正价值,没有它每次墓碑退役都重演漂移;(3) 全量扫其余 *.form.ts。恢复不变式类,免裁决。

---

Generated by Claude Code

[os-zhuang]

验收:ACCEPT(PM 复核毕,PR #5318)

复核依据(GitHub 实据,含逐文件 diff 审阅):

• 范围按实测扩大且正当:全量扫(范围 3)把点名的 3 个墓碑键扩到 8 个(version/homePageId/objects/apis/aria 同类同因,处方各在别的层,零部分映射),全部机械摘除 + 原位注释记能力去向;两个分区描述的过期宣传一并订正;
• 门谓词修复(本单真正价值)双向完整:form-only 拆两条断言分清「静默丢弃 vs 硬失败」;zod-only 把墓碑排除出回填要求(顺带消除了 conditionalRequired 靠运气不炸的暗雷);ledger 自检改按 authorable 键计数防墓碑撑住失效豁免;检测器按 schema 节点判定(z.never 内层,build-schemas.ts isRetired 的 zod 孪生),union 走安全方向;自检锚合成 schema —— 避免锚活墓碑导致门在锚退场那一版悄悄空转,这个设计判断值得进套件;
• RED-first ✓ 方向对、计数被门纠正(3 → 8,如实记录);17 表单全扫零残留;未删任何墓碑(liveness 行依赖保全);
• i18n 处理正确:4 bundle merge 模式重生成(纯删除)+ 分区描述 leaf 值按惯例手工订正四语言(zh-CN 原文案还在点名「版本」「首页」两个退役键);check:i18n/check:i18n-coverage 全绿;
• 消费半径按门的调用方扫(cli/lint/platform-objects 全绿);mid-run 合并 feat(spec)!: 退役主题引擎发出但零消费方的 9 组 CSS 变量 (#5021) #5289/refactor(spec)!: 退役 HttpServerConfigSchema —— 九个键零 reader 且没有任何作者面入口 (#4938) #5293 后重生成并核兄弟条目。

后续:PR #5318 进落地串行链;#5313(apps.mdx 教 2 个墓碑键,check:skill-examples 因无类型标注字面量而盲)已分诊入 devx 队列,与同族 #5291 标注宜同派一个 dev。

---

Generated by Claude Code