Observation found while implementing #5840. Not fixed there: that card's fence is the record:activity renderer, and this file is a different package with its own suite. Filed so the divergence is visible rather than discovered later.
The duplicate
record:activity maps sys_activity.type onto feed kinds in
packages/plugin-detail/src/renderers/recordActivityFeed.ts (ACTIVITY_TYPE_TO_FEED_TYPE, exported).
packages/app-shell/src/views/RecordDetailView.tsx hand-copies the same table as a local activityTypeToFeed literal (near the sys_activity merge), rather than importing the exported one. The renderer's docblock states the two are meant to be the same reading — "Two renderers that disagree about what a created row IS would put the same record's history under two different icons depending on which block an author reached for."
They now disagree
#5840 adds scheduled -> event to the renderer's map, because a shipped producer (HotCRM's schedule_meeting) writes that value and the row was being dropped before any filter ran. The RecordDetailView copy was left untouched, deliberately and under the PM's fence.
Consequence today: a scheduled meeting appears on a hand-authored record page that uses the record:activity block, and is still dropped on the console record page, which uses the RecordDetailView merge. Same record, same row, two answers — exactly what the shared-map comment warns about.
The part that outlives this instance
Nothing fails when the two disagree. There is no test that compares them, and neither file imports the other, so any future edit to one silently reopens the gap. The fix is not "copy the line across"; it is that the second copy should read the exported map (or a test should pin them equal).
Upstream has recorded the same class of unguarded mirror from the other side: plugin-audit/src/objects/sys-activity-type-vocabulary.test.ts in objectstack notes that objectui pins its key set against a hardcoded literal rather than against the declaration, so an addition upstream does not reach it. It cites an issue number for that which returns 404 in objectstack today, so treat the reference as dangling rather than as prior work.
Generated by Claude Code
Observation found while implementing #5840. Not fixed there: that card's fence is the
record:activityrenderer, and this file is a different package with its own suite. Filed so the divergence is visible rather than discovered later.The duplicate
record:activitymapssys_activity.typeonto feed kinds inpackages/plugin-detail/src/renderers/recordActivityFeed.ts(ACTIVITY_TYPE_TO_FEED_TYPE, exported).packages/app-shell/src/views/RecordDetailView.tsxhand-copies the same table as a localactivityTypeToFeedliteral (near thesys_activitymerge), rather than importing the exported one. The renderer's docblock states the two are meant to be the same reading — "Two renderers that disagree about what acreatedrow IS would put the same record's history under two different icons depending on which block an author reached for."They now disagree
#5840 adds
scheduled->eventto the renderer's map, because a shipped producer (HotCRM'sschedule_meeting) writes that value and the row was being dropped before any filter ran. TheRecordDetailViewcopy was left untouched, deliberately and under the PM's fence.Consequence today: a scheduled meeting appears on a hand-authored record page that uses the
record:activityblock, and is still dropped on the console record page, which uses theRecordDetailViewmerge. Same record, same row, two answers — exactly what the shared-map comment warns about.The part that outlives this instance
Nothing fails when the two disagree. There is no test that compares them, and neither file imports the other, so any future edit to one silently reopens the gap. The fix is not "copy the line across"; it is that the second copy should read the exported map (or a test should pin them equal).
Upstream has recorded the same class of unguarded mirror from the other side:
plugin-audit/src/objects/sys-activity-type-vocabulary.test.tsin objectstack notes that objectui pins its key set against a hardcoded literal rather than against the declaration, so an addition upstream does not reach it. It cites an issue number for that which returns 404 in objectstack today, so treat the reference as dangling rather than as prior work.Generated by Claude Code