Repository navigation
Open
Labels
app/pm-stackpm-stack (Pad/Grist) in developing-today/codepm-stack (Pad/Grist) in developing-today/codeeffort/lLarge: multi-day or open-ended; expect staged check-insLarge: multi-day or open-ended; expect staged check-inskind/featureNew feature or capability requestNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedIntake review done: acceptance criteria, links, and normalized labels addedpriority/lowNice to have; do when convenientNice to have; do when convenientsource/humanFiled directly by a humanFiled directly by a human
Description
Part of epic #1184 (PM stack coherence — ideal-system design series, 2026-10-26).
Why
The dashboard answers fixed questions on fixed pages; anything else means Drew opens GitHub, Kaneo, and a chat and stitches the answer himself. An ideal aggregator has a conversational layer: 'what's blocked on me across all projects?', 'dispatch the next nix item', 'why is this epic stalled?' — answered from the canonical PM data, with actions executed through exactly the same mediated, confirmed, audited path as dashboard clicks (no side door).
Design questions to answer
- Where does the conversation live (a dashboard surface, the existing Muse, or both) and what data/actions does it reach through the aggregator's API — never around it?
- Action safety: which actions may run from language directly, which need an explicit confirm step, and how is the confirmation rendered?
- Grounding: how are answers cited to items/pages so Drew can verify, and what does the layer say when data is stale or fixture-backed?
- Audit: every conversational action writes the same attributed record as a UI action (identity from the SSO design), visible in the activity river.
- Scope honesty: what question classes are out of scope v1 (free-form reporting, bulk edits) and how are they refused usefully?
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 is landed in the repo
doc/answering the design questions above: where the conversation lives, the action-safety/confirm model, grounding/citation of answers (including what it says when data is stale or fixture-backed), and the audit record shape. - Implementation issues are filed and linked as sub-issues of epic(dashboard): PM stack coherence - single-URL, fresh data, triage-able, hierarchical #1184.
- Open questions needing Drew are named explicitly in the design note.
- No conversational action path bypasses the aggregator's mediated, confirmed, audited action path.
Metadata
Metadata
Assignees
Labels
app/pm-stackpm-stack (Pad/Grist) in developing-today/codepm-stack (Pad/Grist) in developing-today/codeeffort/lLarge: multi-day or open-ended; expect staged check-insLarge: multi-day or open-ended; expect staged check-inskind/featureNew feature or capability requestNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedIntake review done: acceptance criteria, links, and normalized labels addedpriority/lowNice to have; do when convenientNice to have; do when convenientsource/humanFiled directly by a humanFiled directly by a human
Activity
developing-today commentedon Oct 27, 2026
CODE-379
dezren39 commentedon Oct 28, 2026
Intake review
Related: epic #1184 (parent; this is a design-series child) · #1253 (the SSO/identity design — conversational actions inherit its identity and role model) · #941 (caller-asserted authorship on the comment API, the audit weakness this design must not repeat).
Notes: Still live — verified this run: no merged PR or design note covers a conversational layer; merged-PR searches return only unrelated number coincidences. The issue arrived with a
## Acceptancesection; the appended## Acceptance criteriaformalizes it. Priority classedpriority/low,effort/l: it is the most speculative item in the #1184 series and depends on the identity (#1253) and freshness (#1252) designs landing first.Risks / suggested approach: Design-only deliverable in this issue: the acceptance bar is the landed design note plus filed, linked implementation issues — per the standing rule, a design with no implementation link is not finished work. Sequence it after #1252/#1253 so the design answers rest on settled transport and identity rather than assumptions.
— repo-fleet-monitor intake pass, 2026-10-28T03:55Z
dezren39 commentedon Oct 28, 2026
🤖 Agent note · picked up
dezren39 commentedon Oct 28, 2026
🤖 Agent note · done
Triage verdict: CONFIRMED — gap is real at current HEAD, design is gated on #1252 + #1253
Verified at
origin/maine91098f (laptop clone, read-onlygit grep/git showagainst the ref; no merged PR and nodoc/design note covers a conversational layer — merged-PR searches for "conversational" and "1255" both return empty):pm-stack/aggregator/src/server.ts— the aggregator serves only fixed pages (/board,/today,/roadmap,/quota,/attention,/sessions,/projects,/program,/item/<ref>) and fixed/api/*.jsonfeeds. Its only POST routes are/api/comments,/api/comments/triage,/api/comments/github-result,/api/actions,/api/actions/result. There is no ask/chat/query endpoint and no natural-language handling anywhere inpm-stack/aggregator/src(grep for conversational / natural-language returns only a README aside about comments).pm-stack/aggregator/src/actions.ts(dashboard actions store; consumers pollGET /api/actions.json?state=newand report viaPOST /api/actions/result; records are never deleted — the file is the audit log). So the design questions are well-grounded, not speculative about the substrate.actions.tsnotes authorship is self-asserted (DashAuthor) on the loopback+tailnet surface, with aggregator(dashboard): comment API accepts self-asserted author identities — anyone can post as Drew into the orchestrator/GitHub flow (PR #920) #941 tracking hardening — which is why this design inherits design(pm-stack): one identity across the stack — SSO propagation from the public entry into every layer, roles replace asserted authorship #1253's identity model rather than inventing its own.Routing: No follow-up packet enqueued, deliberately. (1) This issue is the scoped design deliverable — its acceptance is the landed design note plus implementation sub-issues of #1184, so a separate small_fix packet would misroute it (the packet kinds have no design kind; effort/l does not fit a 45-minute fix). (2) It is sequenced behind #1252 (event-driven freshness) and #1253 (SSO/identity), both still OPEN — the grounding/stale-data and audit-identity answers depend on those designs landing first, as the intake review already noted.
Named next action: when #1252 and #1253 close, this issue is claimable directly for the design note (
doc/), with the open-questions-for-Drew section its acceptance requires. Until then it stays open under epic #1184 as the tracked design item — not blocked on a Drew decision today.dezren39 commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 30 (priority/low). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 3, 2026
🤖 Agent note · triaged (live design task, not blocked, nothing started)
repo-worker-code), OpenChamber scheduled laneec118cadorigin/main: design(aggregator): conversational layer — ask and act over PM data in plain language through the same audited action path #1255 OPEN; epic parent epic(dashboard): PM stack coherence - single-URL, fresh data, triage-able, hierarchical #1184 OPEN; no design doc underdoc/matching this issue and no PR referencing it — the design has not been started.What the issue actually asks for: a design note, not code — conversation surface (dashboard, Muse, or both), action safety tiers and how confirmation renders, grounding/citation from canonical PM data, audit parity with UI actions, and an explicit out-of-scope/refusal list for v1. Acceptance is that note plus implementation issues filed as sub-issues.
Verdict: live and unblocked, but it is an L design deliverable for the PM-stack series, so a
small_fixpacket would be the wrong shape. When scheduled: one design pass first (answers the five design questions against the aggregator's existing action path, cites the SSO/audit design), then split the resulting build into child issues. No implementation should land under this issue, and no shortcut around the aggregator's API is acceptable per its own "no side door" constraint.Disposition: no fix packet enqueued; no code, branch, or worktree. Labels reset so nothing reads as in-flight while no task is live.