Repository navigation
design(aggregator): one activity river — a unified, filterable audit timeline across GitHub, Kaneo, sessions, and dashboard actions #1261
Description
Part of epic #1184 (PM stack coherence — ideal-system design series, 2026-10-26).
Why
History today is fragmented: GitHub timelines, Kaneo activity, session records, orchestration runs, and dashboard comments each tell part of a story, and reconstructing 'what happened to this item' means opening four systems. The ideal aggregator keeps one activity river — a unified, filterable audit timeline per item and globally — fed by every layer, including the dashboard's own actions.
Design questions to answer
- Event model: the common event shape (actor, action, object, timestamp, source link) and which sources emit v1 (GitHub, Kaneo, sessions, orchestrator, dashboard writes, watchdog).
- Identity and attribution: events carry the SSO/agent identity from the identity design; how are pre-SSO historical events labelled?
- Per-item vs global views: filters (project, epic, actor, kind), search, and how the river renders on an item page vs its own page.
- Retention and storage: where events live (with the durability design), growth expectations, and what's pruned or archived when.
- Integrity: which events are append-only, who can annotate vs edit, and how gaps (a source was down) are shown rather than papered over.
Acceptance
- Design note landed in repo
doc/+ implementation issues filed and linked as sub-issues of epic(dashboard): PM stack coherence - single-URL, fresh data, triage-able, hierarchical #1184; open questions needing Drew named explicitly in the design note.
Acceptance criteria
- A design note answering every question listed under "Design questions to answer" is landed in the repo
doc/tree and linked from this issue. - Implementation issues are filed and linked as sub-issues of epic epic(dashboard): PM stack coherence - single-URL, fresh data, triage-able, hierarchical #1184 (developing-today/code), each with its own acceptance criteria — this design issue does not itself carry implementation work.
- Every open question that needs Drew is named explicitly in the design note (not buried in prose).
- The common event shape (actor, action, object, timestamp, source link) is fixed in the note, with v1 emitting sources named and gap handling (a source was down) shown rather than papered over.
Activity
developing-today commentedon Oct 27, 2026
CODE-385
dezren39 commentedon Oct 28, 2026
Intake review
Fleet-monitor intake pass (2026-10-28T02:40:00Z): this issue was missing a
priority/*label and/or the standard## Acceptance criteriasection and was not yetmeta/enriched. The criteria section has been appended to the body (original text preserved verbatim above it) and labels normalized.Related: Epic: #1184 (PM stack coherence design series). Siblings in the same series were intake-enriched in prior monitor runs (#1264–#1277).
Notes: Design-series issue (one activity river), filed 2026-10-27 by Drew as part of the #1184 batch; body is well-formed (Why + design questions + its own Acceptance section). Still live: merged-PR search this run returns only unrelated PRs whose text coincidentally contains the number — none resolves or implements this design.
Risks: Design-only stall risk (see tail).
Suggested approach: This is one of the #1184 PM-stack coherence design series; its own "Acceptance" section already states the bar (design note in
doc/+ implementation sub-issues), and the appended criteria restate that in the fleet's standard heading so the monitor and queue can gate on it. Risks: design-only items can sit silently — per house rules a design with no implementation link is flagged by the next sweep, so the follow-through that matters is the sub-issue filing, not the note alone. Suggested approach: answer the design questions against the current aggregator/orchestrator code (cite file:line), land the note, file the implementation sub-issues in the same pass.🤖 Agent note · state: handed off
4 remaining items
dezren39 commentedon Nov 1, 2026
Design-only task 4965: proposed design note in PR #3324 (
doc/activity-river-design-1261.md). Native #1184 implementation sub-issues: #3321 source coverage/gaps, #3322 integrity/identity/durable recovery, #3323 item context/filters. #1739 is the existing stream overlap and is explicitly coordinated rather than duplicated; #2072, #1253 and #1258 are related interfaces. Drew decisions are called out in the note. PR is open; no implementation or merge.dezren39 commentedon Nov 1, 2026
🤖 Agent note · done
Merge pull request #3324 from developing-today/queue/4965-1261-activi…
dezren39 commentedon Nov 1, 2026
agent-note:v1 — re-triage (queue task 5531, lane C, 2026-11-01): acceptance met; closing.
The safety-net premise (no live follow-up) was stale: triage task 2520 routed the design to task 4965, which delivered it this morning. This re-triage verified each acceptance item fresh and landed the final step:
doc/: PR docs: design unified activity river (#1261) #3324 (docs-only,doc/activity-river-design-1261.md, +59) was MERGEABLE/CLEAN with no unresolved review threads and no undispositioned Codex findings; merged this run as4ae8da5e601f1548e858b62514e38abb572a8a35. Verified on main afterwards (blobb3f8536ae82f).legacy-unverified), per-item vs global views, retention/storage, and integrity/gap handling (gaps shown, never papered over).