Repository navigation
design(pm-stack): forecasting — epic ETAs from measured velocity, quota-wall prediction, and stall-risk scoring #1256
Description
Part of epic #1184 (PM stack coherence — ideal-system design series, 2026-10-26).
Why
Roadmap and Projects today show state, never trajectory: Drew can't see whether an epic lands this month, which pool walls first, or which in-flight item is quietly dying. The ideal stack forecasts from its own measurements — completion velocity per epic, per-pool burn vs reset windows, and stall-risk signals (age, blocked time, session silence) — and shows every forecast with its confidence and inputs.
Design questions to answer
- Velocity model: what counts as throughput per epic/project (closed sub-issues, merged PRs), over what windows, and how are small-sample epics handled?
- Quota-wall prediction: per pool, projected exhaustion vs window reset using current burn and scheduled work — what data does the quota plane need to expose?
- Stall-risk score: which signals (blocked age, no-activity age, claimed-but-silent, repeated requeue) and what threshold surfaces an item, where?
- Presentation: how are ETA ranges and confidence rendered on Roadmap/Projects so a weak forecast never looks like a date commitment?
- Backtesting: how do we measure forecast accuracy against what actually happened and tune or retire bad models?
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 velocity model states its windows and small-sample handling explicitly, and every forecast the design specifies renders with its confidence and inputs — never as a bare date.
Metadata
Metadata
Assignees
Labels
pm-stack (Pad/Grist) in developing-today/codeMedium: expected under 1 day of workNew feature or capability requestIntake review done: acceptance criteria, links, and normalized labels addedOrdinary priority (the default)Filed directly by a humanQueue packet kind: verify, reproduce, and route this item
Activity
developing-today commentedon Oct 27, 2026
CODE-380
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 (forecasting), 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
36 remaining items
dezren39 commentedon Nov 3, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 3, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 3, 2026
agent-note:v1
event: picked_up
task: 7659 (repo-health-code-pilot, repo-worker-code; OpenChamber scheduled lane 9aca43b4-5439-4939-9f71-323f5d32521b)
state: claimed, origin=openchamber-scheduled-lane. Fresh check: #1256 is OPEN with no hard-stop labels. I am validating its design delivery and existing implementation subissues against current main before deciding whether anything remains to route.
next: record evidence from merged PR #3988 and the current state of #3981/#3982/#3983/#3984/#3986; preserve the issue as an open tracking parent if implementation work remains.
dezren39 commentedon Nov 3, 2026
Coverage triage (task 7659) — CONFIRMED, still-live tracking parent
Fresh verification at current main:
origin/mainis298f35f75b4a62e71666810f9a972138a088fb55, and design PR #3988 merged atb11292f833849f0578914738ac8505f41d52ae4c(ancestor of current main). The dated design note is present atdoc/2026-11-01T21-07-00Z_design_pm-stack_forecasting/2026-11-01T21-07-00Z_design_pm-stack_forecasting.md. The five design questions and implementation split were already addressed.Existing implementation children: #3981 is CLOSED; #3982 is OPEN/in progress; #3983 is OPEN/parked; #3984 is OPEN/blocked; #3986 is OPEN/parked. These are the already-filed implementation follow-ups; no additional split or task is needed. Prior completion notes explicitly keep #1256 open as their tracking parent, so I am leaving it OPEN rather than closing it prematurely. No code changes or tests were needed for this metadata/design triage.
🤖 Agent note · triaged
9aca43b4-5439-4939-9f71-323f5d32521brepo-health-code-pilotdezren39 commentedon Nov 3, 2026
🤖 Agent note · done — triaged
9aca43b4-5439-4939-9f71-323f5d32521brepo-health-code-pilotorigin/main298f35f75b4a62e71666810f9a972138a088fb55; aggregator: capture item history for forecasting and flow calculations #3981 closed, four other children still open.