review-implementation

実装のレビュー（内部スコープ／分類エンジン）

レビュー／監査スキルを構成する分類エンジンです。統合された指摘事項の表（該当する軸ごとのパスの出力を統合したもの）を受け取り、該当するすべての軸が網羅されていることを確認し、分類済みの判定表を返して終了します。コードのリファクタリングや編集は行いません。review-change、audit-pr、product-audit が内容を繰り返さずに参照する、スコープ／軸網羅の契約と分類基準（現行ユニットの契約とルーティング）を担います。

差分はスキャンしません。各指摘には、それぞれちょうど1つの担当パスがあります（軸の担当マップを参照）。軸ごとのパス（review-code、review-security、review-verify、review-perf、design/a11y/brand/SEO）が指摘を見つけ、このエンジンが分類します。ここでは広範な指摘事項のスキャンを行いません。

使用する場面

• ユーザー向けのレビュー入口であるreview-changeから、統合された指摘事項の表を対象とする分類エンジンとして呼び出されます。
• 監査スキルは、この分類基準と網羅性の契約を参照します。

スコープ

呼び出し元が示すスコープ（デフォルトブランチとの差分、または渡されたパス／glob）が正です。統合された表はそのスコープを対象に収集されています。分類済みレポートの冒頭にスコープを記載します。

ステップ 0 — プロジェクトを把握する（常に最初に実施）

エージェントガイドのワークフロー規約とドキュメントマップに従い、このスキルに必要な情報を読みます。アーキテクチャ／レイヤリングのルール、テストの方針、実行環境／プラットフォーム、セキュリティ、金額、i18n／SEO／a11y、バンドルに関するルールを確認します。ガードレールスキルがある場合は、プロジェクト固有のリスク軸を確認します。デフォルトの軸はFIND.mdのマップに従います。プロジェクトのドキュメントを踏まえ、該当する軸を決めます。

ステップ 1 — 軸の網羅性を確認する（統合された表）

宣言されたスコープについて、該当するすべての軸が統合された指摘事項の表に含まれていることを確認します。FIND.mdのマップに従い、軸ごとに指摘の担当者を1つ割り当てます。変更が関係する軸について、表に記載がない場合は、何も問題がないという意味ではなく、軸の不足に関する指摘（軸coverage）です。同じ不具合について異なるパスが示した重複する兆候は、統合時に1行にまとめます。表には重複も漏れもあってはなりません。該当する軸を示し、それぞれが表に含まれていることを確認します。

ステップ 2 — 分類する（現行ユニットの契約）

分類とルーティングを読み、統合された表の各行を、ソースファイルを再度開かずに分類します。まずignore（主張）を適用し、次に現行ユニットの契約（スコープ内の作業に対するfix-now／replan-in-unit／decision-required）を適用し、その後、真に独立した将来の機能にはproposalを適用します。分類は1回だけ行います。パスごと、レビュアーごとに分類してはいけません。

コンテキスト予算

入力は差分ではなく、統合された表です。周辺コンテキスト（呼び出し元、契約、SPEC）を把握するために全文を読める差分以外のファイルは、最大10個です。対象を絞った読み取り（名前を指定した範囲の50行以下）とgrep／globの結果は、この数に含まれません。分類はそれぞれ表の行としてただちに記録し、ファイルの生の内容は破棄します。

ガードレール

• 指摘事項と表のみ。このスキルでは、コードのリファクタリングも編集もしません。
• 分類担当は1つだけです。 分類は統合された表を対象に、ここで1回だけ行います。レビュアーごとに行ってはいけません。軸ごとのパスで再審議してはいけません。
• デッドコードの例外を守ります。ステージング済み／計画済みのコードはデッドコードではありません。
• 重要度を不当に上げてはいけません。「正しさ／セキュリティ」と「好み」は分けます。
• 重要度を不当に下げてもいけません。現行ユニットの作業がpostpone／tradeoff／wontfix／disputedになることや、新たな問題として扱われることはありません。規模に応じてreplan-in-unitに振り分けます。重要度を下げてはいけません（CLASSIFY.mdの現行ユニットの契約を参照）。
• それ以外は、プロジェクトのワークフロー規約（ドキュメントの言語、証拠）に従います。file:lineを引用し、不確実な点にはverifyと記します。

他のスキルとの関係

• review-change の分類エンジン — ユーザー向けのレビュー・スキルです。 適用可能な軸ごとのチェック（検出器）を実行し、それらの表を統合してから、 このエンジンを使って分類します。audit-pr と product-audit も この基準を再利用します。
• 機能ワークフローの ステージ 4（検証とレビュー）に位置します。
• fix-now は現在のユニットに組み込まれます。replan-in-unit は node scripts/unit-route.mjs <unit> を実行し、その route: replan 行で、 execute-phase の前にユーザーが確認したフェーズを追加するプランナーを指定します。 decision-required はユーザーの判断待ちとなります。独立した作業は、 ユーザーが triage-issue（D3）に振り分ける提案となります。

完了条件

• 統合された表が処理され、軸の網羅性が確認されていること（適用可能な軸の欠落がなく、 重複行もないこと）。すべての指摘が根拠とともに分類され、振り分けられていること。 そして、コードが変更されていないこと。