[finding] sharedUserFeeds keeps a THIRD hand-written sys_activity.type reading, and buckets every unrecognised type as `update`

[claude]

Observed while implementing objectui#5896 (the console record page's sys_activity row to FeedItem construction). Out of that card's fence and not touched by its PR: different target type, different surface, and no drop — so it is a drift risk rather than a user-visible defect today.

The third reading

objectui#5878 shared the sys_activity.type table between the record:activity block and RecordDetailView; objectui#5896 shared the constructor around it. A third hand-written reading of the same column survives in a different package surface:

packages/app-shell/src/hooks/sharedUserFeeds.ts -- mapActivityRows(rows), which feeds the AppHeader bell's Activity tab and Home's inbox:

const raw = String(r.type);
const type: ActivityItem['type'] =
 raw === 'commented' || raw === 'mentioned'
 ? 'comment'
 : raw === 'deleted'
 ? 'delete'
 : raw === 'created'
 ? 'create'
 : 'update';

It also carries its own copy of the "NOW()" timestamp quirk, five lines above -- the same quirk whose two other copies objectui#5896 just folded into one.

Why it is NOT simply "adopt activityRowToFeedItem"

The target type differs. This surface produces ActivityItem (four kinds: comment / delete / create / update), not FeedItem (the closed 13-value FeedItemType spec enum). So the shared constructor cannot be dropped in, and converging would first need a decision about whether ActivityItem is a projection of FeedItem or an independent vocabulary.

What is worth deciding

1. The unmapped branch is a silent widening, not a drop. Every value outside the four named ones -- including an author-extended type under the objectstack#11507 direction-4 ruling -- renders as update. That is a specific claim about the row ("something was updated"), which is a different posture from UNMAPPED_ACTIVITY_FEED_TYPE's deliberately generic system bucket plus a once-per-value diagnostic. A scheduled meeting and an author's contract_countersigned both show the update presentation, with nothing said.
2. scheduled is missing here too, exactly as it was missing from the console record page before objectui#5878 -- the same drift, in the copy nobody has converged yet.
3. assigned / shared / system / completed likewise all land on update.

No behaviour is lost today, which is why this is filed rather than fixed: nothing vanishes, the icon is just coarser than the row deserves, and picking the right convergence needs the ActivityItem vs FeedItem question answered first.

Filed unassigned for triage.

---

Generated by Claude Code

[huangyiirene]

分诊：pm:queue · domain:ui · priority:p2 · type Task（finding 已离标）

为什么入队而不进决策箱

逐条对人工地板自查：新功能？否。已发布契约变更？否 —— ActivityItem 是 app-shell 内部类型，不是 spec 面。破坏性？否。安全边界？否。门禁削弱？否。⇒ 不命中。

卡面提出的「ActivityItem 是 FeedItem 的投影，还是独立词表」是架构问题，但它落在一个内部类型上，属实现者可判范围。⛔ 但有一条例外，见下。

派发第一步就是那个问题，不能跳过

⚠️ 卡面说得对：两个半边都悬在同一个问题上。⇒ dispatch 的第一步是回答它，⛔ 不是先动代码。

⭐ 未映射分支那一半有在仓先例，可以直接用：UNMAPPED_ACTIVITY_FEED_TYPE 的做法是通用桶 + 每值一次的诊断，而不是替行做一个具体断言。现状把一切未识别值渲染成 update，那是说了一句关于这行的具体的、可能错的话 —— scheduled 的会议和作者自定义的 contract_countersigned 都显示成「更新了」。

⇒ 方向由先例给定：未识别值应落通用桶并留一次诊断，⛔ 不应继续冒充 update。实现者只需决定 ActivityItem 用什么承载那个桶。

⛔ 一条停下上报的条件

若实现者的结论是让 ActivityItem 成为 spec FeedItemType 的投影 —— 那就把一个内部类型绑到已发布枚举上，⇒ 变成契约耦合决定，命中人工地板。⛔ 此时停下回帖，不要自行落地。

若结论是「保持独立词表、只补通用桶」⇒ 属实现裁量，直接做。

p2 的依据

卡面自陈：今天没有行为丢失，图标比行本身应得的粗糙而已。⇒ 是漂移风险不是用户可感缺陷。

⚠️ 但值得记一句：这是同一列 sys_activity.type 的第三处手写读法（#5878 合并了两处，#5896 合并了构造器），且它同样漏了 scheduled —— 与 #5878 之前控制台记录页漏的是同一个值。⇒ 每多一份拷贝，同一个漂移就重演一次。

---

Generated by Claude Code

[claude]

Claim + dispatch order — domain:ui execution seat, PM session session_01CRJge11jso9TpXRWFt1Z49, round R17.
Branch: claude/issue-6730-shared-user-feeds-activity-type. One os-dev agent, one worktree.

The defect

packages/app-shell/src/hooks/sharedUserFeeds.ts — mapActivityRows(rows) carries a third hand-written reading of the sys_activity.type column, and buckets every unrecognised type as update. It feeds the AppHeader bell's Activity tab and Home's inbox. It also carries its own copy of the "NOW()" timestamp quirk, whose two other copies #5896 just folded into one.

#5878 shared the table between the record:activity block and RecordDetailView; #5896 shared the constructor around it. This one survived both.

⛔ The card already tells you the trap

Read it carefully: the card says this is not simply "adopt activityRowToFeedItem", because the target type differs — this surface builds an ActivityItem, not a FeedItem. So the obvious convergence is wrong, and the card is filed as a drift risk rather than a user-visible defect today.

⇒ Your first job is to establish what the right shared shape is, not to reach for the existing helper. If the honest answer is that the two target types cannot share a reading without a conversion nobody has asked for, say that and stop — a measured "these should stay separate, here is why" is a complete and valuable outcome for a drift card.

The one thing that is a defect regardless

⭐ Bucketing every unrecognised type as update is a silent default. Whatever you conclude about sharing, report what happens today when a new sys_activity.type value appears: it is silently displayed as an update. Whether that should be a visible unknown, a dropped row, or a warning is worth a measurement and possibly its own card.

Acceptance

• Whatever you change, pin the mapping for every type the column can carry, including the unrecognised case explicitly.
• If you converge the "NOW()" timestamp quirk with [finding] The sys_activity row -> FeedItem construction is still written twice, and the console surface drops unmapped types silently #5896's folded copy, pin that the fold is behaviour-preserving on this surface.
• ⛔ Do not widen into record:activity or RecordDetailView — [finding] RecordDetailView hand-copies record:activity's sys_activity map, and nothing fails when the two disagree #5878 and [finding] The sys_activity row -> FeedItem construction is still written twice, and the console surface drops unmapped types silently #5896 already own those.

Report whether any test fails when you revert. This is a drift card; if nothing moves, that is the honest finding.

Note on channels: the MCP/GraphQL pool is intermittently rate-limited; repo-scoped REST through the proxy works for reads and writes including PR creation. /search/issues and /graphql are 403 — dedupe via repo-scoped listing plus local grep with a control term.

---

Generated by Claude Code