Skip to content
sdlc

The orchestrator needs the next N parallel-safe tasks

Status: open/validated

Statement

Section titled “Statement”

The SDLC orchestrator must repeatedly choose which tasks to start next: those in open/ready status whose depends_on prerequisites are all satisfied, capped at max_implementations, and held under per-category in-flight limits. Today this readiness-and-cap computation is hand-rolled inside the orchestrate skill; it wants a reusable engine that, given the task graph and current statuses, returns the next N parallel-safe tasks.

Who/what it affects

Section titled “Who/what it affects”
  • The /sdlc:orchestrate tick and anyone running it under /loop.
  • Every task carrying depends_on edges.
  • The per-project in-flight limits and max_implementations in sdlc.yaml.

Evidence

Section titled “Evidence”
  • solutions/ontological/skills/orchestrate/SKILL.md: a tick “categorizes in-flight tasks via sdlc task inflight against the per-project in-flight limits in sdlc.yaml, then dispatches up to max_implementations concurrent /sdlc:task-work runs against tasks in status open/ready.”
  • Bespoke verbs already solve slices of this by hand: sdlc task next, sdlc task inflight, and the pickup-order decision D-Q2WR-task-pickup-order.
  • The dependency edges the engine would consume already exist as tasks’ depends_on frontmatter.

Toward resolution

Section titled “Toward resolution”

PR-DZTZ-graph-scheduler and its D-BPD8-graph-scheduler-api: the push readiness engine with per-node trigger rules and registered eligibility filters. A per-category in-flight cap becomes a filter; max_implementations is the limit. The orchestrator dispatches what getReady returns instead of re-deriving readiness every tick.

← Back to Drivers