finding(app-shell): 租户环境的活动动态/系统概览查询 sys_activity 对象，环境里不存在 → 每次打开都 404

[hotlong]

观察（2026-09-03 重新验证 rig，objectui 0246d11 / framework 655b106c / cloud 9b6abe0f）

全新免费租户环境（os-*.localhost），打开环境首页与「系统设置 → 系统概览」时，console 发出：

GET /api/v1/data/sys_activity?top=20&sort=-timestamp → 404 Not Found

该环境的元数据里没有 sys_activity 对象；发起点在 packages/app-shell/src/layout/AppHeader.tsx / InboxPopover.tsx 的活动动态读取（activityItemType.ts）。首页「活动动态」面板显示「暂无最近动态」，用户看不出问题，但每次打开都是一次 404（与已修的 dev/metadata-events 404 同类噪音；rubric #5：出错应是人话或不出错）。

待定级

• 生产者在哪？sys_activity 应由哪个 framework 插件在租户 kernel 声明（cloud 控制面有，租户环境没有），还是 console 应按 features.* / 元数据存在性门控这条读取？

Re-check：grep -rn "sys_activity" packages/app-shell/src/layout | head；在任意租户环境首页看 Network。

Generated by Claude Code

[os-zhuang]

分诊 — domain:ui / priority:p3 / pm:queue / finding

锚定 (anchoring)：⚠️ 卡片指错了发起点。 它写的是 packages/app-shell/src/layout/AppHeader.tsx / InboxPopover.tsx，实测发起点在共享 feed：

packages/app-shell/src/hooks/sharedUserFeeds.ts:628   dataSource.find('sys_activity', { $orderby: { timestamp: 'desc' }, $top: 20 }) as Promise<{

AppHeader.tsx:205 只是消费这批行（"activity card reads the very same sys_activity rows"）。⇒ 落点 packages/app-shell/src/hooks/sharedUserFeeds.ts ⇒ domain:ui。⛔ 接手者不要按卡片给的两个文件去改。

⭐ 关键复核：缺席已经被刻意处理过了 —— 这改变了卡片的性质

packages/app-shell/src/hooks/sharedUserFeeds.ts:616    * never polled it either. Degrades to empty when `sys_activity` is absent
packages/app-shell/src/hooks/sharedUserFeeds.ts:632          // No `sys_activity` object ⇒ this deployment has no audit plugin, which
packages/app-shell/src/hooks/sharedUserFeeds.ts:92     * without the approvals plugin / `sys_activity` / the messaging pipeline will
packages/app-shell/src/hooks/sharedUserFeeds.ts:159    *    deployment does not have the approvals plugin / the `sys_activity`

也就是说："这个部署没有 sys_activity"是一个已知并已容纳的状态，代码在四处写明了它，且降级为空是刻意的。

⇒ 本卡不是"功能坏了"，而是卡片自己准确定位的那件事：每次打开都产生一次 404 噪音（"与已修的 dev/metadata-events 404 同类噪音；rubric #5：出错应是人话或不出错"）。用户看到的是「暂无最近动态」，行为正确。

⚠️ 这条对定级和修法都有影响，也是本卡最容易被误处理的地方：⛔ 不要把它当成"缺少降级处理"去修 —— 降级已经有了。要修的是"在明知可能不存在时仍然无条件发一次请求"。

定级理由

priority:p3：

• 无功能缺陷：面板正确显示空态，用户看不出问题（卡片自己也这么说）。
• 无数据面、无安全面。
• 代价是每次打开一次 404：控制台噪音 + 一次无谓往返。对全新免费租户这是必然发生（该环境元数据里就没有这个对象），不是偶发。
• 不上 p2：无用户可见故障；且 404 本身是服务端诚实的回答，不是错误数据。

⚠️ 卡片提的问题是对的，而且必须先答再动手

生产者在哪？sys_activity 应由哪个 framework 插件在租户 kernel 声明（cloud 控制面有，租户环境没有），还是 console 应按 features.* / 元数据存在性门控这条读取？

两条路落在不同的仓：

路线	落点	型
A — 让租户 kernel 也声明 sys_activity	上游 framework/cloud，跨仓	平台能力变更
B — console 按元数据存在性/features.* 门控这次读取	本仓 sharedUserFeeds.ts	收窄一次请求 ⇒ Bug/tidy，不踩底线

⛔ 分诊席不裁决。但记两条判断输入：

1. B 完全在本仓、不踩人工底线、且与既有降级逻辑同向 —— 现在的代码已经承认"这个部署可能没有它"，B 只是把这个承认提前到发请求之前。
2. A 是产品决策（每个租户是否都该有审计对象），成本远大于噪音本身。⭐ 而且即使走 A，B 仍然值得做：任何一个禁用了审计插件的部署都会回到同一个 404。

⛔ 给执行席的边界

1. 先定位真正的发起点（sharedUserFeeds.ts:628，不是卡片写的两个文件）。
2. 若走 B：⚠️ 门控判据要选对。按 features.* 还是按"元数据里有没有这个对象"？后者需要一次元数据查询，可能把一次 404 换成另一次请求 —— ⛔ 别把噪音搬个家。共享 feed 已经有 objectDef 就绪的概念（见同文件对 objectDefReady 一类的处理），优先复用。
3. ⛔ 不要删掉 :616 / :632 的降级路径 —— 门控是第一道，降级仍是第二道（元数据可能延迟到达）。两者并存才对。
4. 卡片的 Re-check 命令（grep -rn "sys_activity" packages/app-shell/src/layout | head）⚠️ 会漏掉真正的发起点（它在 hooks/ 不在 layout/）。⛔ 用 git grep -n "sys_activity" origin/main -- packages/app-shell/src 代替。

⛔ 分诊席不认领、不派单、不写码、不裁决 A/B。

---

Generated by Claude Code

[hotlong]

Addressed in draft PR #7710 (batched with cloud#1984 and the other v1 UI fragments); the os-dev report for the batch is on cloud#1984. Note: cloud needs a .objectui-sha bump before this reaches the cloud product.