Repository navigation
design(pm-stack): spend rollups — token and dollar attribution per project and per epic, rendered on Projects/Roadmap #1259
Description
Part of epic #1184 (PM stack coherence — ideal-system design series, 2026-10-26).
Why
Usage & billing shows pools and services, but not what any project or epic costs: Drew can't answer 'what did the id epic cost this week?' in tokens or dollars across plan pools and PAYG. The ideal stack attributes spend per project and per epic (consuming quota-plane data, not rebuilding collectors) and renders it next to progress on Projects and Roadmap, so cost sits beside the value it bought.
Design questions to answer
- Attribution model: how are sessions/issues mapped to project and epic (labels, Project Area, sub-issue parent), and how is unattributed spend shown rather than hidden?
- Units: tokens per pool, dollars for PAYG, and plan-pool 'share of window' — how are unlike units presented without fake dollar conversions?
- Windows and history: per-week/per-month rollups from snapshot history; how far back, and what happens when attribution rules change retroactively?
- Placement of spend vs progress: epic card shows % complete beside spend-to-date and forecast-to-complete (with the forecasting design) — what exactly renders where?
- Cost anomaly surfacing: which spend patterns (burning with no closures, one session dominating an epic) bubble into Needs-you or Today?
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).
- Unlike units are never merged into a fake single figure: tokens per pool, PAYG dollars, and plan-pool share-of-window are presented as distinct measures, and unattributed spend is shown, not hidden.
Activity
developing-today commentedon Oct 27, 2026
CODE-383
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 (spend rollups), 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
23 remaining items
docs(pm-stack): spend rollups design note (#1259) (#4828)
dezren39 commentedon Nov 3, 2026
agent-note:v1
Transition: done
Worker: repo-worker-code (lane code-f, direct execution lane)
Task: task 6899
Outcome — issue #1259 acceptance met, closed on merge
doc/spend-rollups-design-1259.mdvia PR docs(pm-stack): spend rollups design note (#1259) #4828, merged 2026-11-03T09:47Z (merge commit 0885d60). The note answers all five design questions against current code (attribution projection over opencode-usage-export records; three unit families never merged; snapshot-store windows + versioned restatement; Projects/Roadmap placement consuming design(pm-stack): forecasting — epic ETAs from measured velocity, quota-wall prediction, and stall-risk scoring #1256 forecasts; anomalies via the feat(aggregator): alert throat — sentinel incident intake, Supabase ledger, Web Push delivery + ack #3676 alert throat) and names five Drew-owned questions explicitly with recommendations.dezren39 commentedon Nov 3, 2026
agent-note:v1 — CORRECTION (repo-worker-code, lane code-f, task 6899)
The slice numbers in PR #4828, in the merged design note as first landed, and in my done note on this issue were wrong for slices 1–3. Cause: a background tool result in my shift reported fabricated issue numbers (4820/4821/4822) for the three
gh issue createcalls; the real creations were #4822/#4823/#4824, which only surfaced when the genuine command output arrived later. Verified fresh against GitHub after the discrepancy appeared:Everything else in the done note stands: PR #4828 merged (0885d60), this issue's acceptance is met, and the five slices carry the implementation work.
docs(pm-stack): correct slice issue numbers in spend-rollups design n…