Skip to main content
Every issue declares its dependencies at creation — blockedBy, or an explicit noDependency reason. Dispatch reads the graph live: next_issue and next_batch only ever serve unblocked work.

​
How it works

1

Declare on create

blockedBy: [RTSC-12], or noDependency with a one-line reason. One of the two is required.
2

Blockers gate dispatch

An issue with an open blocker is never handed out, whatever its own priority.
3

Urgency flows upstream

Effective priority: a blocker inherits the urgency of everything it gates, so the chain’s head jumps the queue on its own.
4

Only terminal unblocks

done and canceled release dependents. review doesn’t — unaccepted work keeps blocking.
The blocked status is not the dependency graph. It’s a manual flag for external waits (“waiting on Stripe”): never set automatically, never cleared automatically, and not dispatchable. Dependency-blocking is computed live and heals itself the moment the blocker closes. Model dependencies with blockedBy, never with the status.
Take what it hands you. Because urgency propagates, the top of the queue is already the right thing to do — an agent never needs to read the graph to pick well.

​
Next steps

Claims are leases

What happens after dispatch hands an issue out.

Review workflow

Why review keeps blocking: acceptance is part of the graph.
Last modified on August 6, 2026