Skip to content

Goal-directed frontier

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

  • A goal-directed variant: get_ready with toward: [G] ranks nodes that advance goal G (its unfinished ancestors) ahead of the rest of the frontier, plus a what_blocks(G) query.
  • Same push engine; toward is a soft priority (a sort key), not a filter — spare capacity spills to non-goal work.
  • Sub-capability of C-D2GO-readiness-scheduling.

“What is runnable anywhere” scatters effort; “what is runnable toward G” focuses it. toward takes an ordered list of goals and ranks each ready node by the earliest listed goal whose ancestors() include it (non-goal nodes last), composed ahead of the normal sorter. limit then fills goal-advancing work first and spills any spare capacity to the rest of the frontier — so “one goal with leftover slots” and “a priority-ordered list of goals” are the same mechanism. When nothing toward a goal is ready, what_blocks(G) returns the ancestors that are pending but not runnable — the blocking chain to attack. The strict “only goal work, exclude the rest” case is a filter (only_toward), not toward.

  • ReadyOptions::toward — an ordered goal list producing a goal-rank sort key applied ahead of the normal sorter; spare capacity spills to non-goal nodes.
  • only_toward(goal) — a predicate for where_fn, for the strict case (drop everything not advancing the goal).
  • what_blocks(schedule, state, goal) — the unfinished ancestors that are not yet runnable.
// goal work first, then spillover
ReadyOptions { toward: vec!["M-0011".into()], limit: Some(4), ..Default::default() };
// M-0011 tier, then M-0012, then the rest
ReadyOptions { toward: vec!["M-0011".into(), "M-0012".into()], limit: Some(8), ..Default::default() };
// strictly M-0011 ancestors
ReadyOptions { where_fn: Some(Box::new(only_toward("M-0011"))), limit: Some(4), ..Default::default() };
what_blocks(&schedule, &state, &"M-0011".into()); // why it is stuck
  • An ordered list of goal node ids (one or many); the graph and state.
  • The frontier ordered by goal rank (goal-advancing nodes first, then spillover); the blocking set.
  • No code realizes this yet — the capability is planned. It lands with the crate at packages/rust/graph-scheduler/, goal-direction in src/goal.rs. Until the crate exists there is no anchor to record here.
  • Deferred past cutover, not part of v0.1. The dispatcher’s first real work order needs a frontier, filters and an ordering, not goal-direction. The toward field is declared on ReadyOptions from the start and left unread until this layer lands, so adding it costs no struct change.

← Back to Capabilities