[17.0-rc2验收] sales_home_page / app_launcher_page / utility_bar_page 多个组件渲染为「Component Placeholder」,首页欢迎语用户名插值为空

[yinlianghui]

Blocked-by: objectstack-ai/objectstack#12183

现象

三个随 app 元数据发布的页面(均无导航入口,仅可通过 URL 访问)在 console 中大面积渲染占位符:

页面	URL(/_console/apps/app.objectstack.hotcrm/page/…)	占位组件
Sales Home(sales_home_page)	page/sales_home_page	nav:menu(Quick Create 卡片内)→ 显示「nav:menu / Component Placeholder」
App Launcher(app_launcher_page)	page/app_launcher_page	global:search、app:launcher → 整页两个 Component Placeholder
Utility Bar(utility_bar_page)	page/utility_bar_page	global:notifications、global:search → Component Placeholder

另:Sales Home 页头副标题声明为 Welcome back, {current_user.first_name}(src/pages/home.page.ts:44),实际渲染为「Welcome back, 」—— {current_user.first_name} 插值为空(admin 用户 name 为 "Dev Admin",非空)。

Sales Home 的 KPI 卡片(Revenue (Won) 1,290,000.00 / Deals Won 8 / Pipeline Value / Open Leads 21)数据渲染正常,说明页面框架本身工作,是这几类组件类型没有渲染器。

复现

admin 登录后逐个打开上表 URL,截图见验收记录 51-page-*.png。页面主体文本可直接看到字面量「Component Placeholder」以及组件类型名(nav:menu 等)。

期望 vs 实际

• 期望:发布的页面元数据只引用 console 能渲染的组件;或这些 demo 页面不随 app 发布
• 实际:终端用户可通过 URL 到达三个满是脚手架占位符的页面;欢迎语人名为空

落点分析

• HotCRM 侧:src/pages/home.page.ts / app_launcher.page.ts / utility_bar.page.ts 引用的 nav:menu、global:search、global:notifications、app:launcher 组件类型在当前 console(@objectstack 17.0.0-rc.2)没有实现,渲染为占位符。修复方向:替换为已实现组件、或将这三个 demo 页面从发布元数据中移除/标注。
• 平台侧(参考):console 对未实现组件类型的兜底就是「Component Placeholder」;{current_user.first_name} 模板插值为空可能与平台 page:header 的变量解析有关,如平台确认支持该 token 则需另查。

环境

hotcrm@0899b4f + @objectstack 17.0.0-rc.2

---

⚠️ 状态更新（2026-08-25）：halves 2 和 3 已由 PR #1219 落地（75cc335d）。剩下的 half 1 已在浏览器实测：四个组件类型仍全部渲染为 Component Placeholder，已按裁定立上游卡 objectstack#12183，本卡转为下游跟踪卡。⛔ 上面「落点分析」里 HotCRM 侧那条修复方向（替换组件 / 移除页面）已被裁定推翻：这四个类型是 spec 闭合枚举的一等成员，这三个页面是该上游缺口的唯一复现，删改即销毁证据。

[yinlianghui]

同页补测：Sales Home 上还有两张只有标题、没有 body 的空卡片

发现于 #771 的浏览器验证（dev server + Chromium，@objectstack 17.0.0-rc.2，基线 7667c9b）。不另开 issue —— 同一个页面、同一个"用户看到脚手架"症候族，落在本单的完成范围里，所以把实测证据补在这里。

本单已记的 nav:menu → Component Placeholder、Welcome back, 人名为空,两条都复现了。除此之外，sales_home_page 上还有两张卡片渲染成只有标题的空盒子——机理和本单表格里那几个不同：不是"组件类型没有渲染器"，而是容器组件没有 body，所以渲染器正常工作、只是没东西可画。

组件	源码	实际渲染
my_recent_items（左栏）	home.page.ts 的 page:card，只有 title: 'Recent Items' + bordered: true，无 body	一张带边框的空卡片，卡面只有 "Recent Items"
upcoming_events（右栏）	同上，title: "Today's Schedule"	一张带边框的空卡片，卡面只有 "Today's Schedule"

页面正文的 innerText 里，这两处就是两个孤零零的标题串，后面什么都没有：

… Key Performance Indicators Revenue (Won) 1,290,000.00 Deals Won 8 Pipeline Value 3,775,000.00 Open Leads 21
  My Leads My Opportunities My Tasks
  Quick Create nav:menu Component Placeholder
  Recent Items
  Ask the Sales Copilot
  Today's Schedule

（同一批测量里，ai_briefing 卡片是好的——它带 description，所以有内容可渲染；四个 object-metric 也都取到了真实数据。）

参考修法：这两张卡片要么绑上数据源（Recent Items 有平台侧的近期记录来源可用则用之；Today's Schedule 指向 crm_event 的 my_events 视图是最自然的落点），要么按本单"或这些 demo 页面不随 app 发布"的第二条路一并处理。#771 没有顺手改这两张卡：那一单的不变量是"标签页名字承诺内容却渲染空白"，范围严格限定在 home_tabs 的三个标签页（已改为内嵌 list-view，实测 21 / 10 / 6 行真实数据）；把侧栏卡片一起改会越界，而把守卫扩到侧栏会让规则在本单尚未修的东西上变红——那种规则最后会被抑制，不会被修。所以新增的 no page tab renders an empty container 守卫只覆盖 tab 子节点，侧栏卡片留给本单。

---

Generated by Claude Code

[huangyiirene]

PM note — deliberately deferred one round, with the known trap recorded (so this card is not picked up on stale premises):

• Why deferred: chore(deps): upgrade @objectstack/* 17.0.0-rc.5 → 17.0.0-rc.6 (maintainer order), and re-measure tracked upstream-mirror behavior #1059 (in flight this round) bumps @objectstack/* rc.5 → rc.6. This card's fix direction depends on which component types the console implements: if rc.6's console ships renderers for nav:menu / global:search / global:notifications / app:launcher, the right fix shrinks to (possibly) nothing plus the two empty side-bar cards; if not, the fix is replace-or-unpublish as the body proposes. Dispatching before the bump risks building the wrong fix against a dying baseline.
• Trap for the eventual dev: the scope now includes the 2026-08-05 addendum — two page:card containers with no body (my_recent_items, upcoming_events) render as empty titled boxes; that half is a metadata fix regardless of what rc.6's console implements. The no page tab renders an empty container guard added by 同 #758 缺陷类：activities.mdx 的「标准列表视图」清单与「主页活动小部件」都对不上 src/views/task.view.ts，且 Sales Home 的三个标签页是空壳 #771 deliberately excludes side-bar cards; extending it is part of this card, not a rider elsewhere.
• Re-measure first: all reproductions in this card were taken on rc.2. Re-verify on rc.6 (post-chore(deps): upgrade @objectstack/* 17.0.0-rc.5 → 17.0.0-rc.6 (maintainer order), and re-measure tracked upstream-mirror behavior #1059 main) before implementing; chore(deps): upgrade @objectstack/* 17.0.0-rc.5 → 17.0.0-rc.6 (maintainer order), and re-measure tracked upstream-mirror behavior #1059's report will carry a one-line probe verdict for the sibling upstream cards but NOT for this one.

---

Generated by Claude Code

[os-zhuang]

PM premise re-check on 17.0.0 GA — the body's 落点分析 is wrong on both halves, in opposite directions

Still pm:queue, still not dispatched. The 2026-08-11 deferral note asked for a re-measure on rc.6 before implementing; the repo has since gone past that to @objectstack/* 17.0.0 GA (package.json on main), so every reproduction here is now two baselines stale, not one. Before spending a live rig on the re-measure, I checked the two static questions that decide where the fix lands — and both answers contradict the body.

Half 1 — the four placeholder component types are spec-blessed, so this is not an app-side authoring error

The body proposes fixing HotCRM: 「替换为已实现组件、或将这三个 demo 页面从发布元数据中移除/标注」. That presumes the app is naming component types it had no business naming. It isn't. On framework main, all four are first-class members of the closed PageComponentType enum:

packages/spec/src/ui/page.zod.ts:65
  // Navigation
  'app:launcher', 'nav:menu', 'nav:breadcrumb',
  // Utility
  'global:search', 'global:notifications', 'user:profile',

and each has a deliberate no-props row in ComponentPropsMap:

packages/spec/src/ui/component.zod.ts:2197
  'app:launcher': emptyProps('app:launcher'),
  'nav:menu': emptyProps('nav:menu'),
  'global:notifications': emptyProps('global:notifications'),

The doc block above emptyProps names these exact components and states the point of the class: "these components take no configuration." So HotCRM authoring nav:menu in a card is the spec's sanctioned spelling, not scaffolding left in by accident.

If the GA console still renders them as Component Placeholder, the gap is a renderer missing for a type the protocol declares — an upstream card, not a HotCRM one. Deleting these pages or swapping in different components would be suppressing the only reproduction of an upstream hole, which is the failure mode the platform's own rules-that-get-suppressed argument warns about.

⚠️ What I could not verify statically: whether the 17.0.0 GA console renders them. Component Placeholder appears nowhere in the framework repo — the fallback lives in the console UI package, which is not installed in this checkout and is not in this session's repo scope. So the re-measure the deferral note asked for is still required. What changes is what its two outcomes mean:

• Still placeholders on GA → file upstream against the console. HotCRM's page metadata is correct and should not be touched for this half.
• Renders on GA → this half is already fixed by the version bump; close it as such, do not "fix" anything.

Half 2 — the empty welcome name is an app-side authoring error, and the body's platform theory is the wrong suspect

The body speculates: 「{current_user.first_name} 模板插值为空可能与平台 page:header 的变量解析有关,如平台确认支持该 token 则需另查」. There is nothing to 另查. The field has no interpolation contract to be broken:

packages/spec/src/ui/component.zod.ts:432
  subtitle: I18nLabelSchema.optional().describe('Page subtitle'),

and I18nLabelSchema (packages/spec/src/ui/i18n.zod.ts:173) is exactly two things:

z.union([ z.string(), InlineLocaleMapSchema ])
  .describe('Display label — the default-language string, or an inline locale map ({ en, "zh-CN" }) resolved at render time')

A display string or a locale map, run through resolveI18nLabel. No token pass, no expression pass. The schema's own doc block is emphatic that nothing is generated or expanded for a label beyond the bundle lookup: "A plain-string label is translatable exactly where the resolver and ObjectTranslationDataSchema define a slot for it, and nowhere else."

Two further signals that {current_user.first_name} is not a spelling this platform has anywhere:

• Filter tokens use braces, but the resolvable context token is {current_user_id} alone — and packages/core/src/utils/filter-tokens.ts:49 records {current_user} specifically as a near-miss that hard-errors with a suggestion. Dotted paths are not part of that vocabulary.
• CEL does have a current_user root (packages/formula/src/cel-engine.ts:98, added in #6290), so current_user.first_name is a valid CEL expression — but CEL is written bare, and where the platform embeds an expression in a metadata string it spells it ${…} (e.g. the auth settings manifest's visible: "${data.email_password_enabled !== false}"), never {…}.

So src/pages/home.page.ts:44 mixes the CEL path expression with the filter-token brace syntax and puts the result in a field typed as translatable copy. Three vocabularies, one string, no consumer.

This half is a HotCRM fix and needs no re-measure to justify. It is also not a find-and-replace: subtitle is an I18nLabel, so whatever replaces it has to be translatable, which a name-interpolated greeting fundamentally is not under this contract. The honest options are a static greeting, or moving the personalised greeting into a component that actually takes data — and that choice wants a moment's thought rather than the first thing that compiles.

Half 3 — the two empty page:card containers are unaffected by any of this

my_recent_items / upcoming_events from the addendum are page:cards with no body. Renderer works; there is nothing to draw. App-side, true on every baseline, independent of both findings above. Still in this card's scope, still includes extending #771's no page tab renders an empty container guard to side-bar cards.

What this changes for dispatch

This card now has three halves with three different owners, and one of them may belong upstream. Dispatching it as one unit invites a dev to "fix" half 1 in HotCRM — the one action that would destroy the evidence. Leaving pm:queue with the split recorded; the re-measure is the gate for half 1 only, and halves 2 and 3 are dispatchable without it.

Nothing above was measured on a live console. Everything above was read off framework main and is falsifiable by opening those files.

---

Generated by Claude Code

[os-sam]

PM note (seat repo:hotcrm, round 2) — half 1's live-console measurement now has a second passenger, and they should ride together.

#760 was graded to pm:queue this round and is blocked on the same one thing this card's half 1 is: opening the 17.1.0 console and reading what actually renders. Its question is "does the view switcher show tabs[].label (Closing Soon) or the view's own label (Closing This Quarter)?" — one glance at the Opportunities list switcher. Neither card can be answered statically: the console ships as a minified bundle and is not installed in this checkout or in objectstack.

⇒ When half 1 is dispatched as a dogfood / mode:cloud measurement, fold #760's reading into the same pass. Two windows in the same running app, two recorded answers, one rig. Folding the measurement is not folding the fix: the two cards branch into different work and keep separate PRs.

Nothing about this card's scope or state changes here. Half 1 remains open, remains a measurement rather than a metadata edit, and the ⛔ standing on it is unchanged: nav:menu / global:search / global:notifications / app:launcher are the spec's sanctioned spelling, so these three pages are the only reproduction of what looks like an upstream renderer gap — deleting or rewriting them would destroy the evidence.

---

Generated by Claude Code