Lesson 28 — Dependency readiness

Outcome

Compute which Tasks are eligible to run from dependencies and Task state without adding a new orchestration language.

Why this comes now

Planning can now create dependency edges. The scheduler needs one trustworthy answer: “is this Ready Task eligible?”

Understand

A dependency is simple: Task C cannot be assigned until every required predecessor satisfies the chosen completion/integration condition. Early Forge uses Done (or a clearly documented integrated state if introduced later). Eligibility is derived; do not store a second mutable “is_unblocked” flag that can drift.

Build the real project

1. Add repository/query for dependency satisfaction.
2. Validate cycles on every edge insertion path, not only decomposition.
3. Define EligibleTask query: status Ready + dependencies satisfied + no incompatible active Run/Operation + environment/provider available as needed.
4. Surface blocked-by information in Task UI.
5. Add tests for diamond graph, no dependencies, unfinished predecessor, and cycle rejection.

Completion gate

Eligibility changes automatically when predecessor state changes; no manual unblocking update is required.

Pitfalls to avoid

Do not use dependency graph as branch stacking yet. Do not persist derived eligibility unless profiling proves a need and invalidation is explicit.

References

DOMAIN_MODEL.md, topological sorting.

Checkpoint

Only proceed to scheduler when eligibility logic is readable and heavily tested.