Effective priority via dependency-chain inheritance — would you be interested in a PR?

[sahuagin]

What

Add an opt-in effective priority view to bd list that surfaces how urgent a task actually is given its place in the dependency graph.

A P3 leaf that blocks a P1 task is effectively P1 work — today's static-priority listing doesn't show that. With this feature:

○ bd-x4z [● P3] [feature] - some long-tail leaf
○ bd-agc [● P3] => P2 via blocks bd-7pq [task] - migrate proxy traffic
○ bd-7pq [● P2] [bug] - parser rejects redacted_thinking blocks

bd-agc is statically P3 but effectively P2 because it blocks the P2 bd-7pq. The effective rank shows the urgency the dependency graph implies.

Shape:

• bd list --effective-priority — adds the column
• bd list --sort=effective — sorts by effective priority
• Default bd list output unchanged. JSON/CSV schemas unchanged in v1 (opt-in only).

Why

Classic priority-inheritance pattern (Mars Pathfinder is the canonical war story from the OS-scheduling literature). Most ticketing systems don't surface this — but agent-driven workflows benefit from it more than human-driven ones, because dispatchers picking next-actionable work otherwise leave load-bearing leaves to languish in P3-land while statically-tagged-P0 work eats their attention. We've been using the feature in a prototype for ~12 hours and it's already caught a real priority inversion in our own backlog within hours of going live.

Related: #3544 has been pushing toward exposing dependency layers compactly so LLMs can reason about scheduling directly. This proposal is complementary, not competing — it computes a single derived field (effective priority) from the same graph, so a bd list reader can see the inversion without first asking the LLM to walk the deps. Both surfaces have a place: #3544 for full graph reasoning by an agent, this for a quick scan by a human or a CLI-piping caller.

Algorithm (small)

effective_priority(t) = min(t.priority, min(effective_priority(d) for d in tasks_that_t_blocks))

Note the min — bd's priority ordering puts P0 at most-urgent, so "most urgent" is the minimum numeric value, not the max. (Catches people on first read, hence flagging.)

Implementation: build reverse adjacency once from the existing dependency table, memoized DFS over in-memory issues. O(V+E). Cycle-defensive (visiting set). Closed/tombstoned dependents don't promote; external:* dependencies skip in v1. Pagination flushes through client-side computation before applying limit/offset so --sort=effective page 2 isn't silently wrong.

Why this is a clean PR

• Data model unchanged — view-time computation only
• Default output unchanged — opt-in via flag
• JSON/CSV schemas unchanged — opt-in field exposure is a follow-up
• No cognitive logic — pure graph walk + arithmetic min. Should pass the ZFC bar in CONTRIBUTING.md trivially (no heuristics, no ranking, no semantic analysis — just the dependency graph that's already there).
• Effort: ~150-200 LOC including table-driven tests. One PR, one issue, no scope creep.

Working prototype

We shipped this to a Rust fork of beads (Dicklesworthstone/beads_rust) yesterday — flagged the design, the priority-inversion math (it's min, not max), and the edge cases (cycle, closed, external, pagination). PR ran into that project's "no external PRs" policy, but the design held up and the implementation works in production for us. Happy to share a link to the closed PR's discussion thread if the prior art is useful.

Question

Would you be interested in a Go port for upstream bd? If yes, I'll file an issue per the one-PR-per-issue rule and put up the implementation. If no, no harm done — wanted to ask before doing the port work.

Thanks.