# Case: `wait-wakes-on-matching-run-event`

## 用例意义

验证 `wait` 能在后续匹配事件出现时被唤醒，并返回稳定的事件载荷。

## 前置条件

- 空数据库已初始化
- 已创建运行 `run_blog_wait_001`
- 已添加任务 `T1` 并完成一次 `dispatch`
- 已知当前尝试线程为 `THREAD_ID`
- `wait` 在工作线程写入阻塞状态前启动

## 输入

```bash
orch --db TMPDIR/coord.db --json wait --run run_blog_wait_001 --for task_blocked --after-event 0 --timeout-seconds 2
inbox --db TMPDIR/coord.db --json claim --agent worker-a --thread THREAD_ID
inbox --db TMPDIR/coord.db --json update --agent worker-a --thread THREAD_ID --status blocked --summary "Need logging decision" --payload-json '{"question":"stdout or stderr?"}'
```

## 预期输出

- `wait` 退出码为 `0`
- `wait.data.woke == true`
- `wait.data.events` 长度为 `1`
- 唯一事件的 `type == "task_blocked"`
- 事件 `summary == "Need logging decision"`
- 事件 `payload.question == "stdout or stderr?"`

## 断言结论

- `wait` 不是简单睡眠，而是面向 run 事件流的阻塞读取接口
- `task_blocked` 事件会把 worker 提问摘要和结构化 payload 暴露给 leader

## 补充约束

- `--for` 支持逗号分隔的事件类型列表；该用例验证的是单事件过滤
- `wait` 返回成功时也会给出 `next_event_id`，便于后续增量等待