finding(plugin-detail): the shared feed pipeline's six author diagnostics are hard-prefixed `[record:activity]` and deduped per value, so a bad `feed.*` on a `record:chatter` block is reported under another block's name — or not at all

[claude]

Raised by the os-dev seat delivering objectui#8968 (PR #9555) and re-measured in this seat,
⛔ not adopted from the report. objectui origin/main = 8d50bc2bf4, 2026-09-15T03:21Z.
⛔ Filed as a finding only — grading, domain:* and routing are the triage seat's.

The defect

packages/plugin-detail/src/renderers/recordActivityFeed.ts is the shared pure half of the feed
pipeline. Its author-facing diagnostics hard-code one block's name in the message prefix —
[record:activity] — in six places, among them:

• the unrecognised filterMode warning,
• the "types names N declared feed item …" warning,
• the non-array types warning,
• the unrecognised types warning,
• the sys_activity row-type warning.

And the dedup keys on the value, not the block:

warnOnce(warnedUnrecognisedFilterModes, [key], () => …)

where key is the offending value (or non-string <type>).

⇒ two consequences, both author-facing:

1. Wrong name. A bad feed.filterMode (or feed.types) authored on a record:chatter or
   record:discussion block is reported to its author under the name record:activity — a
   block they may not have on the page at all.
2. Under-reporting. A page carrying the same bad value on two different block kinds warns
   once in total, not once per block, so the second author never learns their block is affected.

When each became reachable

⚠️ Stated precisely, because "this PR caused it" was the first framing and it is only half right:

• The types / showCompleted / unifiedTimeline diagnostics became reachable from the chatter
  path with objectui#8934, which routed that path through applyFeedConfig.
• The filterMode diagnostic becomes reachable from the chatter path with PR fix(plugin-detail): read feed.filterMode and feed.enableMentions on the chatter path #9555
  (objectui#8968), which calls normalizeFilterMode there.

⇒ the hard-coded prefix is pre-existing; what changed is how many block kinds can trigger it.
⛔ Not a regression introduced by either PR.

Why it was not fixed in PR #9555

recordActivityFeed.ts is outside objectui#8968's declared file surface. The delivering seat
carried a renderer-aware-prefix argument in a comment at the call site instead of widening its PR —
the correct call.

What a repair looks like

Take the block name as an argument (the callers all know it) and key the dedup on
(block, value) rather than value. ⚠️ ⛔ Do not just broaden the prefix to [record:*] —
that trades a wrong name for a name that matches no registration, which is worse for an author
searching their console output.

Successor who will meet it: the next dev on recordActivityFeed.ts, or an authoring-diagnostics
card.

---

Generated by Claude Code