[finding] The sys_activity row -> FeedItem construction is still written twice, and the console surface drops unmapped types silently

[claude]

Observed while implementing #5878 (PR #5894). Not fixed there: that card's fence was the type TABLE, and closing this one changes behaviour rather than removing a duplicate, so it needs its own decision and its own tests.

The duplicate

#5878 converged the sys_activity.type -> FeedItem.type table onto record:activity's exported ACTIVITY_TYPE_TO_FEED_TYPE. The row -> FeedItem construction around it is still written twice:

• packages/plugin-detail/src/renderers/recordActivityFeed.ts -- activityRowToFeedItem(row, systemActorLabel), plus its helper activityTimestamp(row).
• packages/app-shell/src/views/RecordDetailView.tsx -- an inline for loop in the sys_activity merge that builds the same object from the same columns.

activityTimestamp's own docblock records the copy explicitly: "Copied from RecordDetailView's merge for the same reason the type map is: same rows, same quirk." That is the same unguarded-mirror shape #5878 was filed for, one level up, and nothing compares the two.

Three ways they already differ

1. Unknown types are silent here, loud there. The block distinguishes a type the table maps to undefined (a decision, returns quietly) from a type the table does not contain at all (an unmapped producer, warnUnknownActivityType fires once per value). The console merge tests only if (!feedType) continue;, so both collapse into a silent drop. The diagnostic record:activity drops every sys_activity.type: "scheduled" row, and 10 of FeedItemType's 13 kinds have no producer at all #5840 added -- for precisely the failure mode where a producer writes a value nothing maps, and the row vanishes with no signal anywhere -- does not reach the console record page.
2. Missing-timestamp fallback. activityTimestamp returns String(row.created_at ?? ''); the inline copy assigns when = row.created_at, which can be undefined. Different FeedItem.createdAt for a row with neither column.
3. The system-actor label. Two independently authored i18n lookups (detail.systemActor here, the block's systemActorLabel argument there) for the same fallback.

Why it was not folded into the #5878 fix

Converging the constructor is not a mechanical deletion. Adopting activityRowToFeedItem changes observable behaviour on the console record page -- it starts emitting a console.warn for unmapped types, and it changes the timestamp fallback -- so it needs its own regression tests and its own read on whether the warning is wanted on that surface. Doing it under #5878's fence would have widened the verification surface of a card whose thesis was "one table, one reading".

Suggested shape

Export activityRowToFeedItem from @object-ui/plugin-detail's entry point (the table is already exported there as of PR #5894, and app-shell already imports from that barrel -- no new dependency edge), have RecordDetailView call it, and pin the convergence with an identity spy rather than a value comparison, as #5878 did. Decide deliberately whether the unknown-type warning should fire on the console surface; it probably should, since that surface is where a shipped producer's rows are most likely to be seen going missing.

Filed unassigned for triage.

---

Generated by Claude Code

[yinlianghui]

PM annotation — the ruling that now governs the "drops unmapped types silently" half

Recording this from the domain:ui seat (session_01CSoz9uGhaaSgiq3hshtN7L) so whoever picks this card does not have to rediscover it. ⛔ No code change here, and this card is not claimed.

As of PR #6112 (Fixes #5969), the block-side surface no longer drops. packages/plugin-detail/src/renderers/recordActivityFeed.ts now renders an author-extended sys_activity.type through a defined fallback (UNMAPPED_ACTIVITY_FEED_TYPE), warned once per distinct type, instead of returning null for it.

That was a behaviour change, not just a pin, and the reason is this card's own finding turned out to understate it: what existed was a drop, not a fallback — a stored, queryable, author-extended activity row was simply invisible. That is #5840's failure reached by another route.

The ruling that applies

Maintainer, 2026-08-24, batch acceptance on objectstack#11507, verbatim 「四维分析一致的，接手你的建议。」 — adopting direction 4: sys_activity.type is author-extensible.

⇒ Under that ruling, silently dropping an unrecognised type is wrong on every surface, not only in the block. So this card's console half is now a ruled inconsistency rather than an unruled one.

What that means for whoever takes this

1. ⚠️ The console surface (RecordDetailView's own copy of the map) still drops. After fix(plugin-detail): pin recordActivityFeed's OPEN-vocabulary contract to sys_activity.type #6112 the two surfaces disagree about what an author-extended type does — the block renders it, the console discards it. ⛔ Do not close this card by pinning the current console behaviour; the fallback is what it should get.
2. ⚠️ [finding] RecordDetailView hand-copies record:activity's sys_activity map, and nothing fails when the two disagree #5878 is the same family — that copy is hand-written rather than importing the module. ✅ Fixing the drop and converging the copy are naturally one card; whoever takes either should read both.
3. ⛔ fix(plugin-detail): pin recordActivityFeed's OPEN-vocabulary contract to sys_activity.type #6112 deliberately did NOT touch app-shell — the boundary forbade it and ACTIVITY_TYPE_TO_FEED_TYPE itself is untouched, so nothing regressed. The divergence is new only in the sense that one side got better.
4. ⚠️ The four deliberate exclusions still return null silently (commented / mentioned / login / logout). ⛔ Those are not the drop this ruling is about — a converging fix must keep them excluded, and should say so.

One measured trap for the same work

⚠️ There is no live source for the built-in vocabulary that a UI package can read. sys_activity.type is declared only in @objectstack/plugin-audit, a server plugin; objectui depends on @objectstack/spec, client, formula and lint only, and the spec publishes FeedItemType (the map's values) and never its keys. So any census of the built-in set here is a hand copy — and #6112 measured that the previous copy had already drifted: scheduled was declared upstream (objectstack#11522) while the census still filed it as "undeclared but written".

✅ Filed as objectstack#11807 — publish the built-in set where a UI consumer can read it, without re-closing the vocabulary. Until that lands, the fallback is what keeps this drift costing an icon rather than a row.

---

Generated by Claude Code

[claude]

Concentrated triage round: finding → pm:queue, Task, domain:ui stands. Direction inherits #5878's convergence pattern one level out: converge the row→FeedItem construction onto plugin-detail's exported activityRowToFeedItem (+activityTimestamp), deleting the inline copy in RecordDetailView — the console surface then inherits the helper's unmapped-type behaviour instead of silently dropping. If converging surfaces a genuine product question the helper's behaviour does not answer (what an unmapped type should render as), stop and report the fork — do not invent a rendering. Read the full thread at claim (one measurement comment).

---

Generated by Claude Code