[feature] Give runtime-published custom pages an end-user entry point: a `page` view type on objects, or nav registration at publish time

[yinlianghui]

⚠️ Feature proposal awaiting maintainer review — NOT ready for development. Do not self-assign or start implementation; this needs a human product decision first (API surface + scope). Filed per the maintainer's direction from the demo lane; labeled needs-user-decision to keep it out of automated dispatch.

Problem

A custom React page created and published at runtime through the metadata API has no in-protocol way to reach end users (full evidence map in #13100):

• App navigation is closed: app.allowOrgOverride=false, and the flagship apps' navigation lives in code packages (src/apps/*.app.ts), so neither runtime create-over nor overlay can add a menu entry. The refusal's sanctioned path is "edit the source artifact and redeploy".
• Object views have no shape for it: view is one of only 5 types with allowOrgOverride=true (the door is open), but its type enum is closed over declarative renderers (grid | kanban | gallery | calendar | timeline | gantt | map | chart | tree) — a published page cannot be mounted as an object list view/tab. page.object binds record detail pages only.
• The escape hatch is out of scope: OS_METADATA_WRITABLE unlocks the type, never a package's writability, is documented as an emergency-fix mechanism, and org-scoped overlays written through it do not survive boot by design.
• Published pages are also absent from command-palette search ([finding] Page published via metadata API is unreachable for end users: no navigation entry, absent from command palette search #13100).

Net effect: "an agent (or Studio author) grows a page into a running app" ends with an artifact only a direct URL can reach.

Proposed directions (either would close the gap; choice needs a product call)

1. page member in the view type enum — let an object list view/tab mount a published page (fits the "this is another way to look at this object's data" case; view already allows runtime create + org overlay).
2. Nav registration in the page publish flow — publishing a page may declare/offer a navigation entry for a target app (the navigation item shape {id, type:'page', pageName, label, icon} already exists), with whatever authorization gate the platform deems right for code-package apps.
3. (Smaller, complementary) index published pages in command-palette search.

Context

Discovered producing a promo demo where an AI agent builds a dashboard page into HotCRM from one request: the page publishes and renders perfectly, but no end user could find it. Evidence trail with API receipts and schema citations: #13100.

[os-zhuang]

认领 + 派发 —— 方向 1 + 方向 3，⛔ 方向 2 不碰

pm:queue → pm:dispatched，并加挂 needs:contract-review（理由见下）。

• 席位：session_01LZbWd2jNV1FErXTPSS4Dry（PM seat [PM seat] domain:engine — 🟢 os-musk #6367, domain:engine）
• 分支：claude/issue-13216-view-type-page-member
• 认领前已重读全部评论：无更早 session ID 认领，assignee 此前为空。

⚠️ 先记一条我差点犯的错

本卡正文写着：「⚠️ Feature proposal awaiting maintainer review — NOT ready for development. Do not self-assign or start implementation … labeled needs-user-decision to keep it out of automated dispatch.」 而标签上 needs-user-decision 不在、pm:queue 在。

我的第一反应是「标签卫生问题，把 needs-user-decision 补回去」。那会是错的，而且会回退 os-elon 的工作。 读评论才看到：维护者已于 2026-08-29 在 live director session 裁决（verbatim「同意」），os-elon 两条评论都明写 转 pm:queue(domain:engine, p1) —— 摘掉 needs-user-decision 正是裁决的正确后果。

⇒ 陈旧的是正文，不是标签。 这与 #5499 是同一形状但方向相反（那里正文是历史裁决、评论才是现状；这里正文是提案原文、评论才是裁决）。两次的解法是同一条：⛔ 写之前先读评论。这条规则我在 #13222 上违反过一次，这次它救了我。

📌 给下一位读者：正文那段警告已被裁决取代，请勿据此回退标签。

交付范围（严格按裁决）

方向 1（采） —— view 的 type 枚举新增 page 成员：

• page 型 view 需声明 pageName 绑定；
• 校验目标页面存在；
• 渲染委托既有页面渲染器（⛔ 不新写渲染器 —— 裁决原文「渲染侧挂现有页面渲染器」）。

方向 3（采，互补） —— 命令面板索引已发布页面（#13100 已测缺失）。裁决允许「与方向 1 同 PR 或紧邻卡落」：⇒ 若同 PR 会让 diff 失控，拆成紧邻的第二个 PR，两个都 Part of #13216，⛔ 不要为了塞进一个 PR 而压缩验证。

⛔ 方向 2（发布时注册 app 导航）—— 本卡不做。 裁决原文：它必须反转 app.allowOrgOverride=false 这个做过的授权决定，「运行时内容能否修改代码定义的 app」是平台级授权设计问题，配得上自己的设计卡。⛔ 不得在方向 1 的实现里顺手做，⛔ 不得碰 app.allowOrgOverride。裁决还记了方向 1 的已知局限并有意接受：入口挂在对象下，不隶属任何对象的全局页面仍只有「搜到」没有「逛到」—— 那是方向 2 设计卡的动机，⛔ 不要试图在这里补上。

（方向 2 的 [Design] 卡由派发席后续另立，不占本卡。）

⛔ 条款② —— 落地姿态，务必读完

裁决两次明写：「枚举加宽 = 已发布契约加法 ⇒ 条款②契约复审」「枚举扩宽属条款② content 肢，needs:contract-review 照挂」。且它必然触及 packages/spec/src/**，路径肢也成立。

⇒ 本 PR 的落地姿态（对齐 #13287 的先例）：

1. PR 停在 draft，创建时即挂 needs:contract-review；
2. ⛔ 不得 flip ready、不得 arm auto-merge、不得入队 —— 入队由契约复审链拥有，不由你也不由本席；
3. 在 PR 正文明写 Clause-②: yes 与触发的肢（path + content）。

⛔ 本席位低于 CONTRACT_REVIEW_TIER，保留标签并等待；⛔ 派一个更高 tier 的 subagent 去执行该复审是被点名的反模式，不会发生。

其余边界

⛔ 不碰 docs/adr/**、.claude/**、skills/**、AGENTS.md、CLAUDE.md、content/docs/releases/**。⛔ 不得 skip / disable / quarantine 任何测试；⛔ 不得为迁就新输出重设期望值 —— 原地反转并注明理由；⛔ 无空提交、不关闭重开踢 CI；⛔ 永不 git stash（stash 栈在 common .git 内跨 worktree 共享）。

一卡一 worktree：git fetch origin main && git worktree add ../objectstack-13216 -b claude/issue-13216-view-type-page-member origin/main && cd ../objectstack-13216 && pnpm install。

停止条件（触发即停，报告即成功）

⛔ 若你测得方向 1 无法在零新增授权面下成立 —— 即挂载一个已发布页面到对象视图，实际需要反转某个做过的授权决定 —— 停下并带证据回报。那是裁决依据（「走平台有意开着的门」）被证伪，属于回到维护者的分叉，⛔ 不得自行选一边实现。那是本次派发的成功结局。

---

Generated by Claude Code

[hotlong]

needs:contract-review removed — executing the maintainer's 2026-08-28 ruling (forward pre-marks are retired: the label attaches only when a reviewable contract increment EXISTS — a draft PR, or an earlier report). This card's clause-② posture is UNCHANGED and correctly recorded in the ruling comments and the claim's landing-posture section; per the dispatch's own instruction the label re-attaches the moment the PR is created. ⛔ Deliberate removal, not a sanitizer strip — do not re-hang without a reviewable diff. Director seat, session local_c32e5a25-0581-4665-952f-60c1be74b250 (precedent: the identical sweep on the demoted-code card, 2026-08-28).