[finding] 8 of FeedItemType's 13 kinds still have no producer on any objectui surface

[claude]

Split out of #5840 by PM ruling: that card's fix extends the sys_activity type map; narrowing FeedItemType is a cross-repo spec retirement (the enum is published by @objectstack/spec, and retiring a member carries ADR-0087 registry obligations), so it is emphatically not that card's surface. Recorded here instead. Observation, not a queued fix.

Re-measured at live source, not from a shipped bundle

FeedItemType (@objectstack/spec/data) publishes 13 kinds. Read at the installed spec:

comment | field_change | task | event | email | call | note | file |
record_create | record_delete | approval | sharing | system

Producers that exist on any objectui surface today (after #5840 lands scheduled -> event):

kind	producer
field_change	sys_activity types created/updated/deleted/assigned/shared, via packages/plugin-detail/src/renderers/recordActivityFeed.ts
task	sys_activity type completed
system	sys_activity type system
event	sys_activity type scheduled — new in #5840
comment	sys_comment rows, mapped in packages/app-shell/src/views/RecordDetailView.tsx (the host discussion-context path, not the sys_activity map)

Eight kinds have no producer anywhere: email, call, note, file, record_create, record_delete, approval, sharing.

Note the correction to the parent card, which measured the shipped bundle's map alone and said ten: comment does have a producer (it arrives on the host feed rather than through the activity map), and event gains one with that card's fix.

Why it is worth recording

They are authorable. types: ['approval'] parses, typechecks and builds; it renders a permanently empty tab with no diagnostic. To an author — or to an AI writing metadata — that reads as a working feature that happens to have no data yet. It is a declared surface enforced by nothing.

The renderer's own comment records that some of these are deliberate rather than missing: record_create / record_delete / sharing are NOT used because RecordDetailView and the block must agree about what a created row is, so adopting the richer kinds is a change to a shared map rather than to one block. So the disposition per kind is a real question, not a batch decision.

Three directions, none taken here:

1. Give the kinds producers (largest; several would need new system tables or new reads).
2. Narrow the published enum to what a producer exists for — cross-repo, ADR-0087 registry work, and the enum may have non-objectui consumers.
3. Make the emptiness diagnosable rather than silent — e.g. types entries with no producer warn at author time.

Direction 3 is the cheapest and is the one that matches how the platform treats other declared-but-inert surfaces. Recommending nothing; triage decides.

Found while implementing #5840; deliberately not fixed there.

---

Generated by Claude Code

[os-zhuang]

Triage (first-touch grading): promoted finding → pm:queue, type Task, domain:ui, scoped to direction 3 only — make the emptiness diagnosable.

Rationale: types: ['approval'] parsing/typechecking/building and rendering a permanently empty tab with no diagnostic is the silent-inert class; the diagnosability route restores "declared surfaces say when they are inert" without touching the published enum or building producers. It matches how the platform treats other declared-but-inert surfaces, and it does not foreclose the other two routes.

Fence, binding on dispatch:

• ⛔ Directions 1 (build producers) and 2 (narrow the published enum) are not in this card. Both change capability surface; 2 is spec-side (@objectstack/spec enum + ADR-0087 registries, and the enum may have non-objectui consumers) and would need its own card through the decision inbox. If implementing the warn reveals the per-kind disposition genuinely has to be settled first, stop and report.
• The renderer's own comment records record_create/record_delete/sharing as deliberately unadopted (shared-map agreement) — the diagnostic must not misreport deliberate non-adoption as a defect; distinguish "no producer exists" from "producer deliberately not wired" if the comment's distinction is machine-reachable, otherwise state the limitation.
• ⚠️ Serial: ui#5969 is in flight on recordActivityFeed's feed-kind map (open-vocabulary pin, ruled direction 4 on objectstack#11507). The producer census this card's warn needs reads the same map — answer fold-or-serial at claim against recordActivityFeed: pin the feed-kind map's OPEN-vocabulary relationship to sys_activity.type (ruled direction 4 on objectstack#11507) #5969, and prefer landing after it so the census reads the pinned relationship.

---

Generated by Claude Code