Dependency Tracking
Core functionality works; some edge cases warrant caution
Dependency Tracking is a task-blocking mechanism that prevents execution until prerequisite tasks complete.
How It Works
The system uses two complementary commands to establish task dependencies:
addBlocks(A, B): Task A blocks task B from executionaddBlockedBy(B, A): Task B is blocked by task A (inverse syntax for the same relationship)
Blocked tasks display [blocked by #X] in TaskList view until the blocker completes. The blocked_by field in TaskGet persists after completion for audit trails. Multiple blockers are supported with AND semantics—a task unblocks only when all blockers finish.
Direct blockers appear in the UI; transitive dependencies work but remain hidden (e.g., in chain A→B→C, TaskList shows C blocked by B but not by A).
What the Test Found
Runtime tests (2026-01-22, v2.1.16) confirmed core behavior: dependencies block as intended, blocked tasks unblock automatically when prerequisites complete, and historical metadata persists. Multi-level chains execute correctly—Task C waits for B, which waits for A.
The system exhibits permissive semantics: blocked tasks can be manually progressed to in_progress despite the block, and no cycle detection prevents deadlock patterns. Tested edge cases included blocker deletion (auto-unblocks dependents), multiple blockers, and dependency chains. The feature lacks a removal command; unblocking requires task deletion and recreation.
Why It Matters
Dependency Tracking enables linear task sequencing without explicit IPC. It provides lightweight DAG support for simple workflows without requiring separate orchestration systems. Automatic unblocking on completion eliminates manual state management, while historical tracking aids debugging and audit.
Caveats
No enforcement: The system is UI-only—blocked tasks can be started anyway, creating ambiguous state. Skills using this primitive should layer validation: reject progress calls on blocked tasks.
No removal: Dependencies are immutable once created; the only path to unblock is deletion. No cycle detection: Circular dependencies create permanent deadlocks. Calling code must validate before creating relationships.
One-level UI: Transitive chains are opaque to the UI despite being enforced logically. Complex DAGs may require manual tracking.
- file2.1.16/tests/02-dependency-tracking/TEST-RESULTS.md
primitive_ed915e3eff411cedceeee2c0ed255199b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd5b0167bdeb9622d3dd9164cc2e50597092f0e8d68a57ebee6d04c78e819aa5b7f8903d383e85c031852a76ab4eec33b7580ed6ec20416a56196c466d115e3504Signed with an ed25519 key held off the repo. Anyone can verify against the published public key; nobody without the secret key can forge it. Click verify: it recomputes the signature in your browser. The signature proves integrity and authorship of this exact content — not a third-party timestamp or that the underlying claim is objectively true. signedAt is when the @f3/attest pipeline ran, not when the work happened; the evidence refs carry the source dates.
- instance-of Scheduler / IPC Class
- introduces (in) 2.1.16 Battle Test (2.1.16) Release
- verifies (in) Dependency Tracking — runtime test Test