# Case: `blocked-worker-timeout-without-reply-through-bundled-cli`

## Test Type

This is a `forward-test` and a timeout-path skill validation.

The goal is to verify that a blocked worker using the bundled inbox skill sees the correct `wait-reply` timeout behavior when no answer arrives.

## Purpose

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

- a worker can use the skill to fetch, claim, and block a real thread
- the worker can call `wait-reply` through the bundled CLI
- the leader intentionally does not answer
- the worker receives the expected timeout contract instead of silently succeeding
- the thread remains in a blocked state with the question preserved

## Preconditions

- skill path exists: `SKILL_PATH=skills/inbox`
- bundled CLI executable exists: `SKILL_PATH/assets/inbox`
- use an empty temporary directory `TMPDIR`
- test database path is `TMPDIR/coord.db`

## Agent Topology

- `leader`
- `worker-a`

## Inputs

### Leader Prompt

```text
Use $inbox at SKILL_PATH to act as leader on SQLite DB TMPDIR/coord.db. Only coordinate through the bundled inbox CLI from the skill. Workflow: 1) initialize the DB, 2) send exactly one task to worker-a, 3) monitor until worker-a asks one blocked question, 4) intentionally do not reply, 5) stop after confirming the thread is still blocked. Do not use ordinary chat to coordinate with the other agent.
```

### Worker Prompt

```text
Use $inbox at 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 pending work, 2) claim it, 3) send a blocked update with one precise question, 4) call wait-reply with a short timeout, 5) stop after reporting the timeout result exactly as observed. Do not use ordinary chat to coordinate with the other agent.
```

## Execution Parameters

- use the shared execution contract from [README.md](./README.md)
- override the worker-side wait timeout to a short interval such as `10s`
- keep the default cleanup policy

## Execution Steps

1. Inject the same `skills/inbox/` skill into both real agents
2. Point both agents at the same database path `TMPDIR/coord.db`
3. Launch `leader` and `worker-a` in parallel
4. Wait for both agents to finish
5. Resolve `THREAD_ID` from the agent outputs or inbox history
6. Independently run the validation commands from the main thread

## Validation Commands

```bash
SKILL_PATH/assets/inbox --db TMPDIR/coord.db --json show --thread THREAD_ID
SKILL_PATH/assets/inbox --db TMPDIR/coord.db --json list --status blocked
```

## Expected Outcomes

- `leader` successfully creates one thread for `worker-a`
- `worker-a` successfully fetches and claims it
- `worker-a` emits one blocked `question`
- the blocked question is preserved at least in `message.payload_json.question`
- `worker-a` runs `wait-reply` and receives the no-match timeout contract
- the leader emits no `answer` message
- the final thread status remains `blocked`

## Assertions

- the worker reports exit code `10` and JSON error code `no_matching_work` from `wait-reply`
- `show` includes the blocked `question` message
- `show.data.messages[*].payload_json.question` contains `Should logging go to stdout or stderr?`
- `show` does not include any `answer` message
- `list --status blocked` returns the thread

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