Repository navigation
feat(pm-stack): WIP limits + flow analytics — per-lane WIP caps with violation flags; time-in-status and throughput charts per project/epic #1281
Description
Part of epic #1184 (PM stack coherence — wave 2, 2026-10-26).
Nothing in the stack limits or even visualises work-in-progress: the board's in-flight lane mixes queued, in-progress, and blocked work, and there is no sense of whether a project is flowing or piling up. WIP limits give each lane (per project and per epic) a cap with a violation flag when exceeded — not to block work mechanically, but to make overcommitment visible the moment it happens. Flow analytics use the usage/queue snapshot history the stack already accumulates: time-in-status per item and throughput (items completed per week) per project and epic, rendered as charts on the Projects/Roadmap pages and exposed in the JSON twins. Caps are configuration (per lane, editable in one documented place), violations render on the board lane headers themselves, and analytics never present derived numbers without the window they were computed over.
Acceptance:
- Each board lane shows its WIP count against a configured cap, and an over-cap lane is flagged in the lane header and on /today.
- Time-in-status and weekly throughput charts render per project and per epic from snapshot history, with the computation window stated on the chart.
- Caps live in one documented configuration location; changing a cap changes the flags without a code change.
- Analytics endpoints are machine-first (same numbers in the JSON twin) and covered by tests over fixture snapshots.
Acceptance criteria
- Per-lane WIP caps exist per project and per epic; exceeding a cap raises a visible violation flag (informational, not a mechanical block).
- Time-in-status and throughput charts render per project/epic from snapshot history, with the computation window stated on the chart.
- Caps live in one documented configuration location (changing a cap changes flags without a code change); analytics endpoints are machine-first (same numbers in the JSON twin) and covered by tests over fixture snapshots.
Activity
developing-today commentedon Oct 27, 2026
CODE-405
dezren39 commentedon Oct 27, 2026
Intake review
Related: epic #1184 (wave 2 parent).
Notes: depends on reliable snapshot history from the canonical projection — the freshness work in merged PR #1318 (per-source chips, no silent zeros) is a helpful prerequisite and is already landed. Verified live: no WIP or flow-analytics surface exists yet.
Risks: charts computed from gappy snapshots will mislead; state the window and degrade visibly on gaps (per the stack's honesty conventions).
Suggested approach: caps + violation flags first (small, immediate value), analytics second once snapshot coverage is confirmed.
dezren39 commentedon Nov 1, 2026
agent-note:v1 — queue task 2539 (lane E) — triage verdict: CONFIRMED on current main
Verified 2026-11-01 against origin/main 0ea0a0f:
pm-stack/aggregator/src/board-policy.tsis only the fix(aggregator): board is again a completion log - 95 of 107 cards are Done; age out / collapse done by default #1146 done-window filter (DONE_BOARD_WINDOW_MS); no cap configuration, count-vs-cap display, or violation flag exists anywhere in aggregator src. The board is named the WIP board, but nothing limits or measures WIP.throughputin the aggregator is the quota view (model.ts:220, design(aggregator): quota + throughput view — pooled quotas, resets, burn rates, model-choice support #851); there is no time-in-status computation and no per-project/epic throughput chart on Projects/Roadmap or in any JSON twin.Route: scoped implementation packet enqueued as queue task 4998 (small_fix): caps as configuration in one documented place with lane-header + /today violation flags (informational only), time-in-status + weekly throughput per project/epic from snapshot history with stated windows, identical JSON twins, fixture-snapshot tests.
dezren39 commentedon Nov 1, 2026
Claimed queue task 4998 as repo-worker-code. No prior queue progress was provided; checking current issue/PR state and ownership before creating a task worktree.
99 remaining items
dezren39 commentedon Nov 4, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 4, 2026
🤖 Agent note · parked
dezren39 commentedon Nov 4, 2026
agent-note:v1
state: handed off
task: 4998
session_id: ses_e5e5af119e4ffeJvj0iCk7vOhJ
lane: opencode
launched_by: opencode-claimant