One comment that mentions an account becomes two events in the Hypermedia activity feed (/api/ListEvents): a comment event and a citation event that share the same comment version CID. Both flow through the same path, and there were two places an event could be dropped before it ever fired.

Poll the feed (activity-monitor.ts, #pollAccount). The monitor polls /api/ListEvents?currentAccount=<agentAccount> through the @seed-hypermedia/client. It only sees blobs already indexed on the polled server, so a comment becomes visible a few seconds after it was authored.

Derive a stable key (activity-triggers.ts, activityEventKey). A comment event's key is blob-<cid>; its citation twin's key is mention-<cid>--<target>. The <cid> (the comment version) is identical in both.

DROP 1, the staleness watermark. The old filter kept an event only when its create time was at or after max(lastSuccessAt, startedAt - ACTIVITY_BACKFILL_MS). lastSuccessAt was set to Date.now() after every successful poll, so in steady state the bound was about five seconds ago. Any event that became visible more than one poll interval after its own timestamp was dropped for good, and recorded in seenKeys so it was never reconsidered. The flaw: the create time was being used where the observe time was meant, and the feed carries no observe time.

Match against each enabled trigger (api-service.ts, processActivityEvent; activity-triggers.ts, matchesSingleMention). A mention trigger matches structurally: a comment matches when any block embeds a mention link resolving to the account (commentMentionsAccount), and a citation matches when its target id record names the account. Whether the comment is a thread root or a reply does not matter.

DROP 2, citation suppression (removed). The citation twin of a comment carries citationType: 'c'. The old matcher returned false for it, trusting the comment event to fire instead. When DROP 1 had already discarded the comment event, the citation was the only sibling left, and it was thrown away here.

Dedupe the siblings and fire once (activityFiringKey). The citation's mention-<cid>--<target> key collapses onto the comment's blob-<cid>, and trigger_firings is unique on (account_id, trigger_id, activity_key), so whichever sibling arrives first creates the session and the other is a no-op insert. (Today admission goes through a trigger_event_claims row first; the effect is the same.) Both carry the full comment body (loadCitationEvent fetches it for c citations), so the context is the same either way.

Three comments in one thread, all mentioning the agent's account. Only the thread root fired.

The root won only because its comment event happened to surface within one poll interval of its timestamp. Both replies had more than five seconds of indexing lag, so DROP 1 discarded their comment events on every poll. The second reply also had a fresh citation that reached the matcher, which DROP 2 suppressed.

Fix A resolved the reported miss. The broader "reply mentions don't fire" problem was DROP 1, and fix B addresses its root: a feed event is new when the monitor has not observed it before, not when its create timestamp is recent, so a comment that propagates late still fires when it first appears. The two compose: B lets the late comment event through, and A's shared-CID firing key keeps the citation twin from firing twice. The create-time bound survives only for the cold-start first poll.