Skip to content

pm stack: one cross-stack event log (actions, orchestration, sessions, comments in a single chronological stream) #1739

Closed

Description

@dezren39

Gap

The PM stack has no first-class event log. The audit/activity pieces exist but are scattered across separate stores in the aggregator state dir (~/.local/state/pm-aggregator/):

  • the actions store (dashboard triage actions + their applied outcomes)
  • the orchestrator's published actions[] in orchestration.json
  • the session registry (agent/session identity + outcomes)
  • the dashboard comments store (note / message / github kinds)
  • per-item derived activity (derive.ts merges linked refs' comments — but comment resolution depends on the projector, which is not deployed; see code#1199)

There is no single chronological "what happened across the stack" stream a human (or the /today page) can read.

What to build

  • An append-only event record in the aggregator: {at, actor (drew / orchestrator / keeper / job id / session), kind (action-applied, tier-change, comment, session-outcome, status-write, wall, ...), ref (item/session/goal), summary}.
  • Writers: the aggregator's own action-result route, the orchestration publish step, and the session registry merge — events are emitted where the facts already occur, not scraped afterward.
  • A page + machine-first /api twin (e.g. /events and /api/events.json) with filters by kind/ref/actor, newest first, bounded retention (e.g. 30 days or N=5000, whichever first).
  • /today links its "progressed since last run" entries to the underlying events.

Acceptance

  • Dashboard actions, orchestration tier changes, and session outcomes all appear in one stream with timestamps and refs.
  • The /api twin carries the same records; filters work.
  • Writing an event never blocks the underlying action (fire-and-forget append with the same durability as the existing stores).

Raised by Drew 2026-10-28 in the PM-stack non-Git data review; companion to the roadmap-files integration issue filed the same day.

Acceptance criteria

  • Dashboard actions, orchestration tier changes, and session outcomes all appear in one chronological stream with timestamps and refs.
  • The /events page and its /api/events.json twin carry the same records; filters by kind/ref/actor work.
  • Writing an event never blocks the underlying action (fire-and-forget append with the same durability as the existing stores); retention is bounded (e.g. 30 days or N=5000, whichever first).

Activity

  1. added
    enhancementNew feature or request
    nextOrg Project gate: queued next — orchestrator adds to the board
    on Oct 28, 2026
  2. developing-today commented on Oct 28, 2026

    @developing-today
    Contributor
  3. dezren39 commented on Oct 28, 2026

    @dezren39
    MemberAuthor

    Acceptance clarification (Drew, 2026-10-28): the event stream needs a front-end endpoint too, not only the API — a user-facing /events page in the dashboard (chronological stream, filterable by kind/ref/actor in the UI, linked from /today's progress entries) in addition to the machine-first /api/events.json twin. Both are required; an API-only delivery does not close this issue.

  4. added
    source/humanFiled directly by a human
    priority/normalOrdinary priority (the default)
    effort/mMedium: expected under 1 day of work
    app/pm-stackpm-stack (Pad/Grist) in developing-today/code
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Oct 28, 2026
  5. dezren39 commented on Oct 28, 2026

    @dezren39
    MemberAuthor

    Intake review

    Related: #1744 (shared PM-stack schema — this log should be designed against it), #1738 (roadmap files, companion filed the same day), #1199 (projector not deployed; per-item derived activity depends on it).

    Notes: Verified still live at intake (2026-10-28T17:45Z): no cross-stack event log exists; the scattered stores named in the body (actions store, orchestration.json actions[], session registry, comments store) are the current state. Acceptance criteria section appended formalizing the body's ## Acceptance list; original body preserved above it.

    Risks: Writing events at three separate emission points can double-count if the orchestration publish and the session-registry merge both fire for one fact — pick a single emitter per fact. Retention bound must be enforced from day one or the append-only file becomes the next unbounded store.

    Suggested approach: Define the event record + append helper in the aggregator first, wire the action-result route as the first writer, ship /api/events.json with the page, then add orchestration and registry writers.

    🤖 Fleet monitor intake enrichment · 2026-10-28

  6. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

  7. 247 remaining items

  8. added
    status/parkedDeliberately paused with a recorded resume condition
    on Nov 3, 2026
  9. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked

  10. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked

  11. added
    queue/claimedQueue worker lifecycle state
    and removed
    status/parkedDeliberately paused with a recorded resume condition
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    on Nov 3, 2026
  12. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

  13. added 2 commits that reference this issue on Nov 3, 2026
  14. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

app/pm-stackpm-stack (Pad/Grist) in developing-today/codeeffort/mMedium: expected under 1 day of workenhancementNew feature or requestkind/enhancementmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addednextOrg Project gate: queued next — orchestrator adds to the boardpriority/normalOrdinary priority (the default)source/humanFiled directly by a human

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions