Push readiness frontier

Status: open/planned · Kind: component · Audience: user

Summary

• The core query: given a graph and caller-supplied state, get_ready(graph, state, opts) returns up to limit nodes runnable now — the parallel-safe frontier.
• Push model: the caller updates state, the engine recomputes the frontier; a pure function of (graph, state).
• Sub-capability of C-D2GO-readiness-scheduling.

Statement

The push readiness frontier is the load-bearing feature. A node is in the frontier iff its status is Pending and its parents’ statuses satisfy its trigger rule (C-PPXU-status-model-and-trigger-rules) — dependency satisfaction is just the default trigger rule. get_ready computes that set, applies registered filters (C-GUGX-eligibility-filters), orders it via sorters (C-V44L-priority-ordering-sorters), and returns the top limit. It executes nothing and holds no state of its own: the caller owns state and re-queries after each change.

This is the surface the work-runner engine calls in-process on its dispatcher tick, which is why the crate is Rust — the tick carries no child-process boundary.

What it provides

• get_ready(&Graph, &impl StatusSource, &ReadyOptions) -> Vec<ReadyNode>.
• Query-time options on ReadyOptions: where_fn (per-node predicate), order (a sorter), limit (the parallel cap), toward (goal rank).
• Capacity via “ask for N” — no separate capacity primitive.

use graph_scheduler::{Done, ReadyOptions, get_ready};

let opts = ReadyOptions { limit: Some(4), ..Default::default() };
get_ready(&g, &Done(vec!["T-1".into()]), &opts);
// up to 4 nodes unlocked by T-1 whose trigger rules are satisfied

ReadyOptions is #[non_exhaustive] with a Default, so later layers fill in fields rather than widening the struct and breaking callers.

Inputs

• A graph (C-409J-dag-core) and any StatusSource — a status map, the Done id-list sugar, or a closure (C-PPXU-status-model-and-trigger-rules).
• Options: limit, where_fn, order, toward.

Outputs

• An ordered list of up to N runnable nodes (id + attributes).

Hook points

• Registered filters (C-GUGX-eligibility-filters) and sorters (C-V44L-priority-ordering-sorters) compose into the query.

Underlying implementation

• No code realizes this yet — the capability is planned. It lands with the crate at packages/rust/graph-scheduler/, the frontier in src/ready.rs. Until the crate exists there is no anchor to record here.

Notes

• Pure: get_ready is a function of graph and state — no hidden state, safe under concurrency. Computing the frontier is O(V + E); the cap is a bounded top-N selection.
• An unknown dependency target reads Pending and so never satisfies the default rule, keeping its dependent out of the frontier. That is deliberate fail-safe behaviour, matching what sdlc task next does with an unresolved depends_on.

---

← Back to Capabilities