ai-workflow-skill/docs/tests/orch-skill/leader-dispatches-dependent-task-after-prerequisite-through-bundled-cli.md

Case: leader-dispatches-dependent-task-after-prerequisite-through-bundled-cli

Test Type

This is a forward-test and a dependency-gated ready-queue skill validation.

The goal is to verify that a leader using the packaged orch skill can create a dependency edge, observe the correct ready set before and after prerequisite completion, and dispatch the dependent task only after it becomes eligible.

Purpose

Validate that all of the following can be true at the same time:

• the leader can use dep add, ready, dispatch, wait, reconcile, and status through the bundled orch skill
• worker-a can complete the prerequisite task on the bundled inbox skill
• the dependent task stays out of the initial ready queue
• the dependent task appears in ready only after the prerequisite reaches done
• the leader can dispatch that newly ready dependent task to worker-b and close the run

Preconditions

• orch skill path exists: ORCH_SKILL_PATH=skills/orch
• inbox skill path exists: INBOX_SKILL_PATH=skills/inbox
• bundled CLI executables exist at ORCH_SKILL_PATH/assets/orch and INBOX_SKILL_PATH/assets/inbox
• use an empty temporary directory TMPDIR
• initialize TMPDIR/coord.db before launching role agents through INBOX_SKILL_PATH/assets/inbox --db TMPDIR/coord.db --json init

Agent Topology

• leader
• worker-a
• worker-b

Inputs

Leader Prompt

Use $orch at ORCH_SKILL_PATH to act as leader on the already initialized SQLite DB TMPDIR/coord.db. Only coordinate through the bundled orch CLI from the skill. Workflow: 1) create run run_blog_skill_deps_001, 2) add prerequisite task T1 for worker-a and dependent task T2 for worker-b, 3) make T2 depend on T1, 4) inspect ready work and confirm only T1 is dispatchable at first, 5) dispatch T1, 6) wait until T1 completes, 7) reconcile and inspect ready work again, 8) dispatch T2 only after it becomes ready, 9) wait until T2 completes, 10) reconcile and inspect final status, 11) stop after reporting THREAD_ID_1 and THREAD_ID_2. Do not use ordinary chat to coordinate with the workers.

Worker A Prompt

Use $inbox at INBOX_SKILL_PATH to act as worker-a on SQLite DB TMPDIR/coord.db. Only coordinate through the bundled inbox CLI from the skill. Workflow: 1) fetch and claim the prerequisite thread assigned to worker-a, 2) send one in_progress update, 3) finish it with done, 4) stop after reporting THREAD_ID_1. Do not use ordinary chat to coordinate with the leader or worker-b.

Worker B Prompt

Use $inbox at INBOX_SKILL_PATH to act as worker-b on SQLite DB TMPDIR/coord.db. Only coordinate through the bundled inbox CLI from the skill. Workflow: 1) wait until dependent work assigned to worker-b appears, 2) fetch and claim that thread, 3) finish it with done, 4) stop after reporting THREAD_ID_2. Do not use ordinary chat to coordinate with the leader or worker-a.

Execution Parameters

• use the shared execution contract from README.md
• use the shared timeout defaults from README.md
• do not override the default cleanup policy

Execution Steps

1. Initialize TMPDIR/coord.db once through the bundled inbox CLI before launching agents
2. Inject skills/orch/ into leader
3. Inject skills/inbox/ into worker-a and worker-b
4. Point all agents at the same database path TMPDIR/coord.db
5. Launch leader, worker-a, and worker-b in parallel
6. Wait for all agents to finish
7. Resolve THREAD_ID_1 and THREAD_ID_2 from the agent outputs
8. Independently run the validation commands from the main thread

Validation Commands

ORCH_SKILL_PATH/assets/orch --db TMPDIR/coord.db --json status --run run_blog_skill_deps_001
INBOX_SKILL_PATH/assets/inbox --db TMPDIR/coord.db --json show --thread THREAD_ID_1
INBOX_SKILL_PATH/assets/inbox --db TMPDIR/coord.db --json show --thread THREAD_ID_2

Expected Outcomes

• the leader initially sees only T1 in the ready output
• worker-a completes the prerequisite thread for T1
• after reconcile, the leader sees T2 become ready
• worker-b receives a distinct thread for T2 and completes it
• the final run reaches done

Assertions

• the initial ready output contains T1 and does not contain T2
• the post-reconcile ready output contains T2
• THREAD_ID_1 != THREAD_ID_2
• status.data.run.status == "done"
• status.data.tasks contains T1 and T2, both with status done
• show THREAD_ID_1 reports a terminal done thread state
• show THREAD_ID_2 reports a terminal done thread state

Cleanup

• use the default cleanup policy from README.md
• if the run fails, retain TMPDIR and coord.db for replay and manual inspection

Recorded Example Run

• recorded on: 2026-03-19
• execution mode: direct_cli_replay via scripts/run_orch_skill_forward_tests.sh
• result: pass
• observed run id: run_blog_skill_deps_001
• observed first thread id: thr_7f57b577e5ce4cc094341e7d2eae4570
• observed second thread id: thr_5dbc81f2fe234b6dbf0c57a176e13acf
• evidence summary:
• the initial ready output returned only T1, confirming that dependent task T2 stayed gated before prerequisite completion
• after worker-a completed T1 and the leader ran reconcile, the next ready output returned only T2
• final orch status --run run_blog_skill_deps_001 --json returned run.status == "done" with both tasks T1 and T2 in state done
• final inbox show on both thread ids returned terminal thread state done
• the replay also observed orch wait --for task_done wake on the prerequisite completion before the dependent dispatch
• note: this recorded run exercised the packaged binaries directly in a temporary DB and did not spawn separate Codex role agents