# 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

```text
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 with --execution-mode analysis, 6) wait until T1 completes, 7) reconcile and inspect ready work again, 8) dispatch T2 only after it becomes ready with --execution-mode analysis, 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

```text
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

```text
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](./README.md)
- use the shared timeout defaults from [README.md](./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

```bash
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](./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