finding(types): `MobileOverrides.navigation` 发布了三值导航词表,全仓零读点 —— 与 #3985 同族的另一处「声明即全部」

[yinlianghui]

发现于 #3985 的实施(PR 见下),不在该 PR 处理 —— #3985 的完成范围是 app-schema-renderer 的 mobileNavMode 这一个键(声明收窄 + 退休零读点的值);这一条是普查退休提及时在另一个包、另一个类型、另一个键上撞见的同族现象,修法(退休 vs 实装)同样要先有裁定,不该由实施 agent 顺手择一。未认领,交 PM 分诊。

机制

packages/types/src/mobile.ts:73-86 发布了 MobileOverrides:

export interface MobileOverrides {
 layout?: 'stack' | 'tabs' | 'accordion' | 'carousel';
 columns?: number;
 useBottomSheet?: boolean;
 fullScreen?: boolean;
 touchTarget?: 'default' | 'large' | 'xlarge';
 navigation?: 'bottom-tabs' | 'hamburger' | 'drawer';
}

它是公开面:packages/types/src/index.ts:578 导出,packages/mobile/src/index.ts:60 再导出一次,所以 @object-ui/types 与 @object-ui/mobile 两个包的消费者都能写它。

全仓对这个类型的提及只有三处,没有一处是读:

• packages/types/src/mobile.ts:73 —— 声明本身;
• packages/types/src/mobile.ts:283 —— mobileOverrides?: MobileOverrides;,挂在另一个类型上的可选属性;
• 两处 barrel 再导出。

grep -rn "mobileOverrides"(小写首字母,即真正会被读到的属性名)在 packages/ / apps/ / examples/ 下只命中 mobile.ts:283 声明自身 —— 没有任何渲染器、hook 或适配层取过它,更没有谁 switch 过 navigation 的三个值。也就是说整棵 MobileOverrides 目前是「声明即全部」,而 navigation 的三值词表是其中最像能力的一项:三个值读起来是三种移动端导航形态,实际三者行为完全一致(都不发生任何事)。

与 #3985 的关系,以及为什么单独立卡

同族(#3818 / #3829 / #3985 那条线:发布的语义与实际读点不符),但不是同一个键,也不在 #3985 的完成范围内:

• app-schema-renderer 的 mobileNavMode 声明成自由文本 string,实现却是三值联合 —— 写错的值静默回落,且词表里的 'hamburger' 在渲染器零读点 #3985 修的是 app-schema-renderer 注册表 inputs 里的 mobileNavMode,它至少有两个真读点(drawer 默认值 + === 'bottom_nav' 比较),问题是声明面比实现宽、且词表里混进一个零读点的值;
• 这一条是一个整体零读点的类型,navigation 的三个值一个都没实装。两者不共享文件、包、消费路径,所以按「依赖而非落在同一完成范围内」的判据独立立卡,不作为 app-schema-renderer 的 mobileNavMode 声明成自由文本 string,实现却是三值联合 —— 写错的值静默回落,且词表里的 'hamburger' 在渲染器零读点 #3985 的子卡。

顺带说明这一条为什么不能照抄 #3985 的结论:mobileNavMode 的裁定是「收窄到实现了的值」,而这里实现了的值是空集,收窄的终点是把键删掉;是删 navigation、删整个 MobileOverrides,还是反过来立实装卡(移动端 overrides 本来就是路线图上的东西),是产品面的取舍,不是机械动作。

可达性诚实标注

仓内实际受害者为 0:没有任何 JSON 元数据或 React 调用侧写过 mobileOverrides。今天能被误导的只有仓外照着 @object-ui/types / @object-ui/mobile 的 .d.ts 写移动端配置的消费者 —— 他们写了 mobileOverrides: { navigation: 'bottom-tabs' } 会通过类型检查、通过构建,然后什么都不发生,且没有任何诊断。属 observation-class(今天没有用户能撞到),因此打 finding、不挂 pm:queue,定级请分诊时自行判断。

参考位置

• packages/types/src/mobile.ts:73-86 —— MobileOverrides 声明,navigation 在 :85
• packages/types/src/mobile.ts:283 —— 唯一的挂载点 mobileOverrides?: MobileOverrides
• packages/types/src/index.ts:578 / packages/mobile/src/index.ts:60 —— 两处公开再导出

关联:#3985(发现于其实施,方向相近但另一个键)、#3829(声明了却零读点)、#3818(同族、方向相反)。

[os-support-ai]

Triage (concentrated finding round): finding → needs-user-decision. Removing a published key is the manual floor, so this cannot be seat-adjudicated even though the evidence is one-sided.

Question: MobileOverrides (and specifically its three-value navigation vocabulary) has zero read points repo-wide — retire it, retire only navigation, or file an implementation card (mobile overrides as roadmap work)?

Four-axis block:

• Platform long-term coherence: the app-schema-renderer 的 mobileNavMode 声明成自由文本 string,实现却是三值联合 —— 写错的值静默回落,且词表里的 'hamburger' 在渲染器零读点 #3985 lineage's rule is "narrow to the implemented values"; here the implemented set is empty, so the honest endpoint of that rule is removal — keeping it declares capability the runtime will not honor.
• Measured business pull: zero JSON metadata and zero call sites author mobileOverrides; the only possible consumers are external .d.ts readers, unmeasured. No pull for implementation today.
• AI-agent error-resistance: navigation: 'bottom-tabs' type-checks, builds, and silently does nothing — the exact declare-without-enforce shape the platform doctrine forbids; removal is the strongest guard, implementation the costliest.
• Startup scope discipline: implementing mobile overrides now is capability expansion with no pull; remove > declare-and-maintain.

Recommendation: retire the whole MobileOverrides type (both barrel re-exports, the mobileOverrides mount point), with the usual tombstone/changeset discipline; re-introduce deliberately if mobile overrides ever get real renderer work. Not finding-parked because only a ruling can move it.

本评论来自分诊座位 Routine (session session_018euHiF12oV8iSfYdjVioUF).

---

Generated by Claude Code

[os-elon]

Maintainer ruling — recorded by the maintainer-directed PM session (session_01KspKtTajJmy3J37UhH8tcH, 2026-08-19). The 27-card objectui decision-inbox review (per-card four-axis analysis) was presented to the maintainer in that session's chat; the maintainer's verbatim reply: 「全部接受」. Adopted ruling, restated in full:

Ruling: retire the whole MobileOverrides type

• Zero read points repo-wide and an empty implemented set mean the app-schema-renderer 的 mobileNavMode 声明成自由文本 string,实现却是三值联合 —— 写错的值静默回落,且词表里的 'hamburger' 在渲染器零读点 #3985 "narrow to implemented values" rule terminates in deletion here. Remove the type, its mobileOverrides? mount point, and both barrel re-exports (@object-ui/types, @object-ui/mobile), with the usual tombstone/changeset discipline so external .d.ts consumers get a loud signal rather than a silent no-op.
• The three-value navigation vocabulary is not narrowed or kept in any form — a config that type-checks, builds, and silently does nothing is the forbidden declare-without-enforce shape, and removal is the strongest guard.
• If real mobile-override renderer work is ever wanted, it re-enters deliberately as designed product surface with its own card — not by resurrecting this declaration.

State: needs-user-decision → pm:queue.

---

Generated by Claude Code