You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
pm-stack: one Needs-Drew queue of record — reconcile user/* labels with the aggregator Needs-you page #1226
Part of epic #1184 (PM stack coherence review, 2026-10-26).
'Needs Drew' is scattered across two unreconciled systems. Evidence: 26 open code items carry user/* labels (including blocked, user/review #1007), but the aggregator's Needs-you page derives its queue from session state, not from the user/* label system of record. There is no single GitHub-side queue enumerating what waits on Drew across repos.
Acceptance:
Opening one URL (Project view or /attention) lists every user/review and user/escalated open item across the four repos with its reason.
The reconciliation direction (labels as input to the page, or page state written back as labels by the orchestrator) is specified and implemented for at least user/review + user/escalated.
Acceptance criteria
Opening one URL (Project view or /attention) lists every open user/review and user/escalated item across the four repos, each with its reason.
The reconciliation direction (labels as input to the page, or page state written back as labels by the orchestrator) is specified and implemented for at least user/review + user/escalated.
Related: epic #1184; #1007 is the named spot-check item; #1220 (Project #4 coverage) and #1218 (Project auditability) are sibling pm-stack items from the same review.
Notes: counts in the body are from the 2026-10-26 review and will have drifted; the first implementation step is a fresh label census. No merged PR references this issue (checked this run).
Risks: two writers (orchestrator write-back vs label-first) can fight; the issue's own acceptance forces the direction to be specified before implementation, which is the right order.
Suggested approach: labels-as-input first (read-only aggregator change), spot-check, then decide whether write-back is needed at all.
🤖 Agent note · filed
Agent: fleet monitor
Session / ID: repo-fleet-monitor run 2026-10-28 02:19 CDT
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 8614 (triage, queued, priority 40) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
Implemented on main: pm-stack/aggregator/src/needs-drew.ts — a census of OPEN issues and PRs carrying user/review or user/escalated across all four repos (NEEDS_DREW_LABELS), rendered as the "Needs Drew — GitHub label census" section on the aggregator attention view with a machine form at /api/needs-drew.json (src/render.ts, src/server.ts), with tests in test/needs-drew.test.ts.
Landed as PR feat(aggregator): Needs-Drew label census on the attention view (#1226) #3970, feat(aggregator): Needs-Drew label census on the attention view (#1226) (commit c8e58a2), shepherded and merged per the 2026-11-03 note from task 7495 on this issue; follow-up fix 1eeaa8a (2026-11-03) shares the sweep, honours incomplete_results, and fetches the census only where rendered.
Reconciliation direction is specified and implemented, as acceptance required: the labels are the system of record; the view reads them and never writes them (render.ts census header, source.ts census contract).
Spot-check against live GitHub label state this shift (open items, gh search issues): code 26 user/review + 30 user/escalated, opencode 6 + 8, openchamber 1 + 5, nix 0 + 5 — 81 items, exactly the population the census queries enumerate.
Activity
developing-today commentedon Oct 27, 2026
CODE-360
dezren39 commentedon Oct 28, 2026
Intake review
Related: epic #1184; #1007 is the named spot-check item; #1220 (Project #4 coverage) and #1218 (Project auditability) are sibling pm-stack items from the same review.
Notes: counts in the body are from the 2026-10-26 review and will have drifted; the first implementation step is a fresh label census. No merged PR references this issue (checked this run).
Risks: two writers (orchestrator write-back vs label-first) can fight; the issue's own acceptance forces the direction to be specified before implementation, which is the right order.
Suggested approach: labels-as-input first (read-only aggregator change), spot-check, then decide whether write-back is needed at all.
🤖 Agent note · filed
30 remaining items
developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 8614 (triage, queued, priority 40) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
dezren39 commentedon Nov 3, 2026
🤖 Agent note · done
Evidence (fresh, 2026-11-03):
pm-stack/aggregator/src/needs-drew.ts— a census of OPEN issues and PRs carryinguser/revieworuser/escalatedacross all four repos (NEEDS_DREW_LABELS), rendered as the "Needs Drew — GitHub label census" section on the aggregator attention view with a machine form at/api/needs-drew.json(src/render.ts,src/server.ts), with tests intest/needs-drew.test.ts.feat(aggregator): Needs-Drew label census on the attention view (#1226)(commit c8e58a2), shepherded and merged per the 2026-11-03 note from task 7495 on this issue; follow-up fix 1eeaa8a (2026-11-03) shares the sweep, honoursincomplete_results, and fetches the census only where rendered.gh search issues): code 26user/review+ 30user/escalated, opencode 6 + 8, openchamber 1 + 5, nix 0 + 5 — 81 items, exactly the population the census queries enumerate.status:done), so its absence from an open-items queue is correct, not a miss.Closing issue #1226 on its merits: the queue of record exists, at one URL, from the label system of record.