Recent activity feed misses peer-promoted assertions on non-authoring nodes — lifecycle metadata is local-only

[Jurij89]

Summary

dkg:AssertionCreated / dkg:AssertionPromoted events are written to the local _meta graph by the promoting node only (packages/publisher/src/dkg-publisher.ts:3170,3465). Unlike dkg:WorkspaceOperation rows in _shared_memory_meta, replicas don't materialise these lifecycle events when they receive the SWM gossip.

Result: after PR #694 switched the Overview "Recent activity" feed to source from useAssertionLifecycleEvents, a non-authoring node that received SWM-shared assertions from peers shows an empty feed for those assertions, even though the entities themselves are visible in the SWM tab.

Where

• Writer (local only): packages/publisher/src/dkg-publisher.ts:3170 (assertionCreate) and :3465 (assertionPromote) call generateAssertionCreatedMetadata / generateAssertionPromotedMetadata which write into did:dkg:context-graph:<cgId>/_meta.
• SWM gossip path: WorkspaceOperation records in _shared_memory_meta ARE replicated as part of SWM sync, but lifecycle events in _meta are NOT.
• Consumer (no peer source): packages/node-ui/src/ui/hooks/useAssertionLifecycleEvents.ts queries only the local _meta graph.

Symptom

1. Peer agent A promotes 10 entities on their node → AssertionPromoted event written to A's local _meta + SWM gossip carries the entities themselves.
2. Non-author node B receives the SWM gossip, sees the 10 entities in the SWM tab.
3. Node B's Overview "Recent activity" feed: empty. The lifecycle SPARQL against B's _meta returns no rows for A's promotion (because A's _meta was never replicated to B).

PR #694's joiner treats lifecycleEvents = [] as authoritative (suppresses legacy 'added' rows) — so B doesn't fall back to entity-derived rows either. The feed reads "no activity" even though there is plenty of peer-shared activity to surface.

Reviewer threads on PR #694 that surfaced this

• useAssertionLifecycleEvents.ts:114 — "this query only reads the local _meta graph, but AssertionCreated/AssertionPromoted are only written by the promoting node ... after the Overview switches to this source other agents' promotions disappear on every non-author node"
• ProjectView.tsx:517 and :255 — same finding from the consumer side.

Resolved as wontfix on PR #694 with a pointer to this issue, because the fix is architectural and out of scope for a polish PR.

Proposed directions

Pick one. My ordering reflects effort + cleanliness.

Option 1 — Replicate lifecycle events to _shared_memory_meta (backend, recommended long-term)

Have the lifecycle metadata writers ALSO emit a replication-safe copy of the events into _shared_memory_meta (or a sibling graph that's part of the SWM gossip set). The hook then queries that replicated graph instead of (or in addition to) _meta.

• Pros: Single source of truth for the activity feed. Peer activity surfaces naturally on every node. No UI rework.
• Cons: Backend change. Increases SWM payload. Need to be careful that the event subjects are deterministic so multiple peers don't write conflicting copies of the same event.
• Effort: Medium — touches generateAssertion{Created,Promoted}Metadata, the SWM-share write path, and the hook's SPARQL.

Option 2 — Bring back swmEvents as a peer-activity fallback in the joiner

When lifecycleEvents is supplied but doesn't account for some WorkspaceOperation rows (i.e. there exist promotion ops in _shared_memory_meta whose ?root doesn't appear in any lifecycle event), surface those peer ops via the legacy swmEvents path as "peer activity" rows.

• Pros: UI-only; no backend change.
• Cons: Partially undoes the B-collapse design (peer rows are per-entity, not per-bundle; agent appears as peer-id, not DID). Two row shapes in the same feed. Reintroduces the visual issues we just fixed.
• Effort: Low.

Option 3 — Explicit "peer activity" surface (new UX)

Keep the lifecycle source as local-only-by-design; build a separate "Peer activity" panel sourced from WorkspaceOperation that lists what other agents have shared into this CG.

• Pros: Cleanest separation; local vs peer become two distinct stories.
• Cons: New UX surface; design work; lands in a separate plan section.

Definition of done

• Decision recorded (link to a decision note or the team-lead's preferred Slack thread) on which option to pursue.
• For Option 1: lifecycle events are queryable on a non-authoring node post-sync; PR feat(node-ui): N6 polish bundle — lifecycle events, quieter empty state, agent attribution #694's joiner gives the right shape without modification; the wontfix replies on the 3 PR feat(node-ui): N6 polish bundle — lifecycle events, quieter empty state, agent attribution #694 review threads are amended with a "closed by #NNN" pointer.
• For Option 2/3: matching design notes added to agent-docs/context-graph-implementation-plan.md N6 section as a fold-in.

Related

• Surfaced during PR feat(node-ui): N6 polish bundle — lifecycle events, quieter empty state, agent attribution #694 (N6 polish bundle) review by the Codex bot.
• PR feat(node-ui): N6 polish bundle — lifecycle events, quieter empty state, agent attribution #694 ships the local-only source as-is; this issue covers the peer-replication gap as a follow-up.
• Plan section N6 in agent-docs/context-graph-implementation-plan.md already tracks N6 polish work; the peer-activity question can be folded into either N6 or its own new section depending on which option above is picked.

[Bojan131]

Automated liveness test added in PR #1129 (docs/testing/ISSUE_LIVENESS_TESTS.md). The test asserts the correct behaviour and currently fails-as-expected (bug confirmed live on main as of 2026-06-11). When this is fixed the test flips RED — remove its it.fails wrapper and close this issue.