[A検証 1回目] read-only 3 タスクを goose(kimi)に 3 並列 dispatch → ~29 秒で全 done(end_turn)。正解は私が grep / run_sql で独立採点。

- **T2(quacker MCP run_sql / count+直近3件)**: 完全正解。count=49 も直近3件の id・順序も一致。注入 MCP を使い BOTH-tag + 非削除 + order/limit の SQL を正しく組めた。
- **T3(定数名・値・file:line)**: 完全正解。`MAX_PARALLEL_JOBS = 8 @ acp_dispatch.rs:19`。
- **T1(run_prompt_capture 呼出箇所)**: file:line は 268/317/368 の3件とも正解、定義・import・worktree コピーを正しく除外(指示追従◎)。**ただし enclosing 関数名で line 268 を `run_goose_once`/`run_goose_batch` と誤答(実際は `run_goose_jobs`、`run_goose_batch` は存在しない捏造)+ list と VERDICT で自己矛盾**。

読み取れること: (1) crisp な lookup(count / 定数 / 行番号)は高信頼、(2) 注入 quacker MCP の SQL 利用も実働、(3) speed・cost とも良好(3並列 29 秒)。弱点 = **派生・構造的な詳細(関数名)で plausible な捏造が出る**。B への含意: kimi は「自信ありげに構造を間違える」ので、B-edit は goose の自己申告でなく **テスト通過を hard gate** にする設計が要る。VERDICT 契約は有用だが evidence 行を grep 裏付け必須にすると更に良い。

検証 job: n_01KT19M9ZWD417H6PKMW7RX3MR / n_01KT19MA2HHMCH8TR92J7GAKNA / n_01KT19MA57QNE1562FDPAJA7NM(done 済)。