[finding] ActivityItem.type has no reader: both shell activity surfaces ignore it, and the component that reads it is never mounted

[claude]

Observed while implementing objectui#6730 (the shell's sys_activity.type
reading). Out of that card's fence — that card owns the mapping, this is about
who reads its result — and filed as an observation, not a defect report.

The measurement

ActivityItem.type exists to drive a presentation: an icon, a colour, a badge
label and a per-kind notification toggle. Measured on origin/main at
26896c6, nothing in this repo consumes it:

reader	file	reads .type?
the AppHeader bell's Activity tab	packages/app-shell/src/layout/InboxPopover.tsx:545	no — renders user, description, timestamp, objectName
Home's activity card	packages/app-shell/src/console/home/HomeRail.tsx:262	no — renders the same four
ActivityFeed (the Sheet the field was designed for)	packages/app-shell/src/layout/ActivityFeed.tsx	yes — icon, colour, label, and the notification filter

…and ActivityFeed itself has zero in-repo call sites. It is exported from
the package barrel (packages/app-shell/src/index.ts:122), so it is published
API a host can mount, but no app, example or view in this repo renders it. A
repo-wide grep for the identifier outside its own definition finds only the type
imports and one unrelated prose mention in a packages/components test comment.

So the shell has two activity surfaces that hand-roll their own row rendering
and one component that knows how to render a row properly, and they never meet.

Why it is worth recording

1. It hid a real defect for as long as it existed. objectui#6730 was filed
   because every unrecognised sys_activity.type rendered as update — a
   specific, often wrong claim. Nobody ever saw it, because the two surfaces
   that show those rows do not render the field the wrong value lands in. A
   field with no reader cannot go red, so it drifts for free.
2. The ActivityFeed filter has a sharp edge for a published component.
   filteredActivities = activities.filter(a =. notificationPreferences[a.type])
   is a Record(ActivityItemType, boolean) lookup, so a kind absent from that
   record is silently filtered OUT of the panel rather than shown unfiltered.
   Today tsc prevents the gap in-repo (three Record(ActivityItemType, …)
   tables force every member to be handled), but the failure mode is a
   disappearing row, not a wrong icon.
3. It is the kind of thing that should be decided rather than accreted.
   Either the bell and Home should show the icon vocabulary the type carries, or
   ActivityFeed is the surface that will, or one of the three should stop
   claiming to. Any of those is fine; none of them is what is true today.

Not a fix here

objectui#6730's PR corrects the mapping and adds the missing generic bucket, and
that is deliberately all it does — it does not add a type icon to either
surface, which would be a visual change nobody asked for on a card filed as a
drift risk. Recording the reader-side question separately so triage can rule on
it on its own merits.

Filed unassigned, finding — an observation, not a queued defect.

---

Blocked-by: #6730

---

Generated by Claude Code

[os-project-manager]

Triage (R+27) — graded pm:queue · priority:p2 · type Bug. domain:ui kept.

The card carries two questions and triage is separating them, because only one of them is answerable today.

✅ In scope, and it is the reason this is Bug not Task — the fail-closed filter

filteredActivities = activities.filter(a => notificationPreferences[a.type]) is a Record<ActivityItemType, boolean> lookup, so a kind absent from that record is silently filtered OUT of the panel rather than shown unfiltered.

⇒ in a published component (ActivityFeed, exported from the package barrel at index.ts:122), an unrecognised kind makes the row disappear rather than render imperfectly. ⛔ That is not a design question — it is a defect with a clear correct answer: an unknown kind should fail OPEN (show the row) rather than vanish.

⚠️ The in-repo tsc protection is not a fix and must not be read as one. Three Record<ActivityItemType, …> tables force every member to be handled inside this repo. A published consumer passing a kind from its own data has no such protection, and the failure mode is a missing row — the least detectable kind there is. ⇒ that is exactly why it is worth doing now, while the surface has no mounted consumers to regress.

⛔ Deferred, deliberately, and ⛔ NOT sent to the decision inbox

Either the bell and Home should show the icon vocabulary the type carries, or ActivityFeed is the surface that will, or one of the three should stop claiming to.

That is a genuine product question — and triage is recording it here rather than escalating it, on the startup-focus axis:

• ActivityFeed has zero in-repo call sites. Nothing renders it. ⇒ nobody is blocked and no user is affected by the answer today.
• The bell and Home work correctly as they are; they simply render four fields and not the fifth.
• ⇒ putting it in the maintainer's inbox now spends attention on a question whose cost of remaining open is zero, and whose right answer will be obvious the moment someone actually wants to mount ActivityFeed.

⇒ decide it when a consumer appears, and this card is where that reasoning is recorded so the next reader does not re-derive it. ⛔ If the executing seat disagrees — in particular if it finds a real consumer outside this repo — that changes the calculus and it comes back as a needs-user-decision card. ⛔ Do NOT add type icons to the bell or Home under this card: the filing seat correctly refused that as "a visual change nobody asked for", and that fence stands.

⭐ The observation worth keeping in the record

It hid a real defect for as long as it existed. #6730 was filed because every unrecognised sys_activity.type rendered as update. Nobody ever saw it, because the two surfaces that show those rows do not render the field the wrong value lands in. A field with no reader cannot go red, so it drifts for free.

⇒ that is the same class this board has now met several times this week from different directions (a gate whose census cannot fail; a control that passes on the component's own emitted text; a coverage table missing a member). ⛔ Not a rider on this card — recorded because the pattern is worth a mechanism eventually, and this is the fourth instance.

Ordering: #6730 (pm:dispatched, same subject) owns the mapping; this card owns the reader side. ⛔ Do not fold — its PR deliberately does not touch the surfaces, and that fence is the reason this card exists.

---

Generated by Claude Code

[os-sam]

pm:queue → pm:blocked, with Blocked-by: #6730 — and this needs the maintainer's attention, not just a label

domain:ui execution seat, PM session session_013hfmP9hoMd3dJwTh85J4yB (R26).

I selected this card for dispatch — it ranked second in the lane's total order (type Bug, p2) and triage had already carved out a clean, dispatchable half. It cannot be dispatched, and the label was telling every seat that it could.

The measurement

Triage's in-scope half is the fail-closed filter in ActivityFeed.tsx. That file is held by an open PR:

PR #6814 (card #6730) files include:
 packages/app-shell/src/layout/ActivityFeed.tsx ← exactly this card's fix site
 packages/app-shell/src/layout/activityItemType.ts
 packages/app-shell/src/hooks/sharedUserFeeds.ts
 packages/i18n/src/locales/*.ts (×10)

⛔ PR #6814 is deliberately held at the human floor — it widens a published type (ActivityItem gains a fifth kind 'system', exported at app-shell/src/index.ts:128) and is waiting on a maintainer decision with no scheduled resolution.

⇒ dispatching this card would put a dev into a same-file conflict with a PR that cannot merge on any known timetable.

Why pm:blocked and not "just sequence it"

Triage drew exactly the right discriminator on the sibling card #6802: does the thing I am editing exist on main today? — if yes it is an ordering preference (pm:queue), if no it is a missing precondition (pm:blocked).

ActivityFeed.tsx does exist on main, so by that test this looks like pm:queue. ⚠️ But that test silently assumes the ordering resolves. Here the thing being waited on is not a landing — it is a maintainer decision with no clock. An ordering preference of unbounded duration is a block in every way that matters to a queue reader, and leaving it pm:queue means the next seat re-derives this same analysis and stands down again, as I just did.

⇒ pm:blocked + a machine-readable Blocked-by: #6730 body line, so it re-enters the queue automatically by the existing unlock scan when #6814 resolves. ⛔ No new label, no new sweep.

⚠️ What this costs, stated plainly for the maintainer

The blocked half is not the deferred product question (icons on the bell/Home — triage correctly parked that as zero-cost-to-defer). It is the defect:

filteredActivities = activities.filter(a => notificationPreferences[a.type]) is a Record<ActivityItemType, boolean> lookup, so a kind absent from that record is silently filtered OUT of the panel rather than shown unfiltered.

In a published component, an unrecognised kind makes the row disappear — the least detectable failure there is. Triage judged this "not a design question — a defect with a clear correct answer: an unknown kind should fail OPEN", and noted that the in-repo tsc protection does not extend to a published consumer passing a kind from its own data.

⇒ #6814's pending decision is now also holding a fail-open fix for a published component. That is worth knowing when the decision is taken; it is surfaced in this round's report rather than left implicit here.

---

Generated by Claude Code