# 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, 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

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