spec: `editMode` is read off the object document by objectui's runtime but the strict parse rejects it — declare or rule out

[os-sam]

Out-of-scope finding from objectui#5362 (the consumer half of the #10144 split). Filed unassigned, not claiming.

Fact (measured on published @objectstack/spec 17.2.0)

editMode?: 'modal' | 'page' is an authored key on the object document that objectui's shipped runtime reads:

• packages/app-shell/src/utils/recordFormNavigation.ts branches on objectDef.editMode !== 'page'; AppContent's central handleEdit dispatcher routes on it (modal form vs dedicated /record/:id/edit route).
• objectui's CHANGELOG announces it as a feature ("ObjectSchemaMetadata.editMode — optional 'modal' | 'page' flag"), i.e. it is documented for authors, not host-composition surface.

The spec's object document neither declares it nor merely strips it — the strict parse rejects it loudly:

ObjectSchema.safeParse({ name: 't', fields: {...}, editMode: 'page' })
→ success: false
→ issues[0] = { code: 'unrecognized_keys', keys: ['editMode'], path: [] }

(Measured against the published artifact, node_modules/@objectstack/spec 17.2.0; the rejection message cites the #4001 strictness change. Positive control: the same document without editMode parses success: true.)

So an author who follows objectui's documentation and publishes editMode through any spec-validating path is rejected; the key only works through data sources that skip spec validation.

Why this is the #10144 family

#10144 (closed completed) ran declare-or-rule-out for titleFormat / listViews / icon — the three object-document keys objectui read but the spec did not declare. editMode is the measured residue of the same census: the one remaining member of objectui's retired hand-written ObjectSchemaMetadata mirror with a live runtime read. Under objectui#5362 it now lives in an explicitly-labeled client extension (ObjectSchemaClientExtensions), with a pinned test asserting the spec parse rejects it — so the client type stays honest either way, but the contract question is open:

• Declare: the spec's object document adopts editMode (objectui then retires the extension member and lets the derivation carry it — the pinned tests flip and say so), or
• Rule out: the key is judged UI-host configuration that does not belong on the object document, and objectui moves the affordance to wherever the ruling points (and retires its documentation of the key as authored surface).

No recommendation beyond the family precedent; both routes need the maintainer's contract-review tier per the #10144 pattern.

Back-links: objectui#5362 (ruling + consumer half), objectui PR (derivation + object-schema-metadata-spec-derivation.test.ts, which pins the current rejection).

---

Generated by Claude Code

[claude]

分诊落箱(session session_01Kktexqp6uVuFMztvvTMf3V,2026-08-24)。一句话问题:objectui 已发布并写进文档的「编辑记录用弹窗还是整页」开关(editMode),作者照文档写上去,平台校验当场响亮拒绝整份对象 —— 两边只能留一边。

选项 × 真实代价:

• A. spec 收编:对象文档声明可选 editMode: 'modal' | 'page'。代价:契约面 +1 键(永久义务);业务上 = objectui 文档写的功能真的能用了。
• B. objectui 缩面:判定 objectui 越权发布,删它的读点与文档(走 deprecate-first)。代价:回收一个已宣布的功能,已用它的应用行为变化;业务上 = 作者少一个开关,契约保持最小。
• C. defer:维持互相矛盾。业务上 = 每个照 objectui 文档写的作者都撞 422,撞完还查不到为什么。

四棱:

• ① 长远合理性:唯一契约原则下 C 不可持续 —— 一键两个权威答案正是要消灭的形态;A 与 B 都收敛,方向相反。
• ② 实际业务拉动:读者是 objectui shipped runtime(记录编辑路由真实分叉),CHANGELOG 已公告为作者功能 —— 拉动真实存在,不是投机声明。
• ③ 防 AI 犯错:现状是最坏解:AI 照 objectui 文档写 editMode → 整对象被拒;A 后声明即兑现;B 后文档与运行时同删,AI 无从写错。
• ④ 创业阶段不扩散:一个 UI 行为开关是小面;但「先上车后补票」若成惯例,契约会被消费端牵着走 —— 若采 A,建议裁决附一句「下不为例:UI 侧新增作者键先过 spec」。

推荐 A(功能已发布、有真实读者、语义清楚;回收的伤害大于收编的义务);回退 B。置信缺口:未测树外应用实际写了多少 editMode(npm 消费者不可测);未核 objectui 侧是否还有同类「读而未声明」的兄弟键(#5903 在查 gantt 的同类)。回「A」/「B」即可。裁后执行:A ⇒ 转 pm:queue spec 席,Clause-② yes 契约复审档,objectui 文档半随卡;B ⇒ 转 objectui 立 deprecate-first 卡,本卡关 moved。

---

Generated by Claude Code

[os-zhuang]

分诊席四维分析(维护者 2026-08-24 点名要求;裁决仍归维护者)。

os-decision-facets

一句话问题:editMode: 'modal'|'page' —— objectui 以 CHANGELOG 向作者发布、运行时有活读点,而 spec strict parse 响亮拒绝。收编进对象文档(declare),还是判为 UI-host 配置逐出(rule out)?

① 实际业务需求:作者照 objectui 文档写 editMode,走任何 spec 校验路径就被拒;只有绕过校验的数据源才"能用"——同一个键在两条路径上两种命运,今天就撞。这是 #10144 census 的最后一个残余成员,其余同族已处理完。→ declare。
② 项目长远合理性:担忧是对象文档积累"渲染器行为旋钮"。但 editMode 是跨渲染器的编辑意图(以弹窗还是整页编辑该记录),不是像素样式;且今天不存在任何"UI 配置"专属面可以逐去——rule out 意味着先发明一个新家。声明收编与既有 titleFormat/listViews/icon 的处理同族自洽。→ declare。
③ 防 AI 犯错:现状最坏——文档邀请、契约拒绝、旁路放行,AI 作者拿到的是分裂答案。declare 后一处声明处处生效;rule out 则在新家落成前作者持续撞墙。→ declare。
④ 创业阶段不扩散需求:declare = 对象文档加一个可选枚举键 + objectui 退役 ObjectSchemaClientExtensions 成员(它的 pin 测试已预告会翻);rule out = 设计新配置面 + objectui 撤文档改流——更贵且服务于一个纯洁性偏好。→ declare。

推荐:declare(四轴同向)。 实施:spec 对象文档收编 editMode 可选枚举,Clause-② yes(扩接受集),契约复审档位;objectui 侧退役扩展成员由既有 pin 驱动。本分析看不见什么:您对「对象文档能不能承载 UI 意图键」的边界观本身——若您认为这个口子一开后患大于此键,rule out 就是对的,且需同笔指定新家。

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded — declare

Provenance: maintainer, 2026-08-24, live PM chat, verbatim: 「接受你的建议。」 on the aligned four-facet analysis above.

Ruled: the spec's object document adopts editMode?: 'modal' | 'page' as an optional authored key. objectui then retires the ObjectSchemaClientExtensions.editMode member and lets the derivation carry it — its pinned rejection tests flip by design and say so. Clause-②: yes (widens the accept set) — contract-review tier at dispatch. Consumer-side retirement is a follow-up the accepting seat files in objectui per the cross-repo rule (with Blocked-by: on the spec release covering it — release-gated per the #11498 discipline, not merely merged).

State: needs-user-decision → pm:queue (spec lane).

---

Generated by Claude Code