Dependency-graph readiness scheduling
Status: open/planned · Kind: module · Audience: user
Summary
Section titled “Summary”- The whole ability graph-scheduler provides: given a dependency DAG and each node’s status, compute which nodes are runnable now and return the next N to run in parallel.
- Decomposes into a pure DAG core, a push readiness frontier, a status / trigger-rule model, eligibility filters, priority sorters, and goal-directed / pull / stateful wrappers.
- Feature-level root of the graph-scheduler capability tree; realized
at
packages/rust/graph-scheduler/(PR-DZTZ-graph-scheduler).
Statement
Section titled “Statement”Graph-scheduler lets a caller model work as a dependency graph of opaque node
ids and ask, repeatedly, “what can run now?” — receiving the next N nodes
whose dependencies are satisfied and whose eligibility rules pass, ordered by
priority. The ability is observable without knowing the implementation:
register nodes and edges, supply statuses, call get_ready with a limit, act
on the result, update statuses, repeat.
It is a Rust crate because the work-runner engine calls the frontier in-process on its dispatcher tick (P-0012-rust-core-adapters-as-needed). No TypeScript peer is built.
What it provides
Section titled “What it provides”- A dependency-graph model with opaque ids and light attributes.
- The readiness query
get_ready(graph, state, opts)— the parallel-safe frontier, capped and ordered. - Extension points to gate (filters), order (sorters), and condition (trigger rules) which nodes are returned.
- Goal-directed and pull variants for milestone-focused scheduling and blocker introspection.
D-BPD8 layered the library as subpath exports. Rust has no export map, so the
layering is expressed two ways: always-on layers are plain modules, and the
opt-in layers — the tracker and pull — sit behind default-off Cargo features, the
same idiom packages/rust/intersect uses for its fs entry point.
Contained sub-features
Section titled “Contained sub-features”| Capability | Module | v0.1 | Role |
|---|---|---|---|
| C-409J-dag-core | graph | yes | Immutable DAG: nodes, edges, topology, cycle detection |
| C-PPXU-status-model-and-trigger-rules | status | yes | The status enum, Airflow-style trigger rules, the StatusSource seam |
| C-PC3N-push-readiness-frontier | ready | yes | get_ready — the parallel-safe frontier |
| C-GUGX-eligibility-filters | schedule | yes | Reasoned filters with explain |
| C-V44L-priority-ordering-sorters | sorters | yes | by_key, priority_weight, registered sorters |
| C-551W-goal-directed-frontier | goal | no | Frontier ranked toward a goal, plus what_blocks |
| C-0UBY-stateful-wrapper | tracker | no | A stateful wrapper over the pure engine |
| C-FD3Q-pull-resolution | pull | no | Demand-driven resolution toward a goal |
The five v0.1 layers are what the engine needs to dispatch its first real work order. The other three are deferred past cutover.
Lifecycle map
Section titled “Lifecycle map”The DAG core (C-409J-dag-core) is the substrate. The push frontier (C-PC3N-push-readiness-frontier) reads it against caller-supplied state (C-PPXU-status-model-and-trigger-rules) to produce the ready set; filters (C-GUGX-eligibility-filters) and sorters (C-V44L-priority-ordering-sorters) shape that set. Goal-direction (C-551W-goal-directed-frontier), pull (C-FD3Q-pull-resolution), and the stateful wrapper (C-0UBY-stateful-wrapper) are optional layers above.
Underlying implementation
Section titled “Underlying implementation”- No code realizes this yet — the capability is planned. It lands as the crate at
packages/rust/graph-scheduler/, which takes the bare moon idgraph-schedulerper S-0009-moon-project-ids. Until the crate exists there is no anchor to record here.