Repository navigation
design(aggregator): cross-project dependency graph — critical path per epic and what unblocks the most work #1257
Description
Part of epic #1184 (PM stack coherence — ideal-system design series, 2026-10-26).
Why
Blocked-by today is prose strings on cards; the orchestration dependencies view is rendered by no page, so Drew cannot see the shape of what's stuck or which single unblock frees the most work. The ideal aggregator renders one dependency graph over native GitHub blocked-by relations and Project items: per-epic critical path, blocker age, and a ranked 'unblock this next' list.
Design questions to answer
- Graph source of truth: native blocked-by relations + sub-issue hierarchy + Project fields — how are prose blockedBy strings migrated or mapped?
- Layout at phone and desktop width: per-epic graph vs global graph, and how large graphs stay readable (collapse by epic/project)?
- Critical-path semantics: longest chain, oldest blocker, or most-descendants-freed — which rankings are computed and how are ties explained?
- Cycles and dangling refs: how are dependency cycles and links to closed/missing items detected and displayed?
- Actions from the graph: dispatch, poke, or escalate a blocker in place, through the same triage action path as the board.
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 design picks and justifies one critical-path ranking semantics (longest chain vs oldest blocker vs most-descendants-freed) and specifies how cycles and dangling references render.
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 humanNeeds a user-look: Muse reviews first and handles what it can
Activity
developing-today commentedon Oct 27, 2026
CODE-381
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 (cross-project dependency graph), 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
11 remaining items
dezren39 commentedon Nov 1, 2026
🤖 Agent note · handed off
doc/2026-11-01T21-05-00Z_design_aggregator_dependency_graph_1257.md; children feat(aggregator): add a responsive per-epic dependency graph #3973, feat(aggregator): rank blockers by downstream open work #3974, feat(aggregator): explain dependency cycles, external refs, and graph actions #3975 under epic epic(dashboard): PM stack coherence - single-URL, fresh data, triage-able, hierarchical #1184.Merge pull request #3980 from developing-today/queue/4962-1257-depend…
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 40 (priority/normal). 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 · done — triage verdict: ALREADY DONE (acceptance met; closing with evidence)
Evidence (verified fresh 2026-11-03)
main:doc/2026-11-01T21-05-00Z_design_aggregator_dependency_graph_1257.md(10,751 bytes, 185 lines) — produced by queue task 4962.## Needs Drewsection (line 150) rather than burying them in prose.Verdict
Every acceptance criterion of this design issue is met; the remaining work lives in #3973/#3974/#3975 under epic #1184. Closing as completed. The
## Needs Drewitems in the design note are tracked inside those implementation issues' scope and do not block this design issue.