inspect-change

変更の検査

差分を、各サブエージェントが個別に実行する2つの独立した軸でレビューします。

• 標準 — コードはこのリポジトリで文書化されている規約に従い、基本的な問題点を避けていますか？
• 仕様 — コードは要件を ID ごとに実装していますか？

この2つの軸は意図的に分離されています。一方を満たし、もう一方を満たさない変更もあるためです。たとえば、完璧なコードでも間違ったものをビルドしていたり、仕様に忠実な実装でもリポジトリの規約を踏みにじっていたりすることがあります。レポートを統合すると、一方の軸がもう一方を覆い隠すおそれがあります。

1. 範囲を確定する — 失敗は早めに

呼び出し元から指定されたベース参照（SHA、ブランチ、タグ、またはマージベース）を取得します。git rev-parse <base> で解決できることと、git diff <base>...HEAD が空でないことを確認します。不正な参照や空の差分が見つかった場合は、2つの並列サブエージェント内ではなく、ここで失敗させます。また、git log <base>..HEAD --oneline も取得します。ベースが指定されていない場合は、ユーザーに尋ねます。完了条件：参照が解決でき、差分が空でないこと。

1b. 確定した範囲を逆方向に追跡する（スクリプト、読み取り専用）

確定した base..HEAD に対して、map-features の逆方向ランナーを実行します。助言用の範囲のみで、INDEX／シャードへの破棄的な書き込みは行いません。

python3 skills/track/map-features/scripts/reconcile.py \
  --repo <root> --base <base> --head HEAD --mode full

.skills/ が書き込み可能で、Git の対象外になっている場合に限り、--write-overlay を追加します（/map-features の dispose ステップ 0 と同じ契約です）。出力された範囲を保持します。ステップ 2 で使用します。ここでは Feature CODE を新たに発行しないでください。保留中の OBS は、処理のために /map-features を案内してください。自動で呼び出してはいけません。 完了条件：逆方向の範囲を保持していること（または、ランナーが明示的にステートレスな結果を返していること）。

2. 仕様を特定する

ステップ 1b の範囲を使用して、次の順に該当する要件を探します。

1. 範囲内の known-impact CODE → 該当フィーチャーの requirements.md。
2. それ以外の場合、差分内のパスについて、ブランチ名、フィーチャー名、または INDEX コードと一致する docs/specs/<date>-<feature>/requirements.md（catalog-query.md に従い、CODE を正確に検索してください。INDEX を貼り付けないでください）。
3. 呼び出し元が指定したパス。
4. 未所有のパスに対する範囲内の pending OBS／known-impact／uncertain → 「仕様なし」ではありません。これらの参照を保持し、仕様軸を対象外にしてはいけません。
5. それ以外の場合は、ユーザーに尋ねます。仕様がないことをユーザーが確認し、かつ 1b に該当パスの pending OBS がない場合は、仕様軸を対象外にし、最終レポートでその旨を伝えます。

（コミットのトレーラーは、要件 ID の必須の記載場所ではありません。ドキュメントのみを背骨としてください。）

完了条件：requirements.md のパス、または未所有のパスに対する pending OBS／uncertain の参照、または (5) で明示的に確認された「仕様なし」を保持していること。

3. 標準の情報源を集める

ここでのコードの書き方を示す情報源を集めます。CLAUDE.md、リンター／フォーマッターの設定、CONTEXT.md を確認し、docs/standards/ を優先してください。docs/agents/project.md が存在しない場合は、その旨を記録し、configure-repo を提案します。標準軸には、常に standards-baseline.md（12の問題点 + セキュリティ + 本番運用の準備状況）を含めます。リポジトリで文書化された標準は、ベースラインより優先されます。ツールで既に強制されている項目は対象外にします。完了条件：情報源のリストとベースラインのパスを用意していること。

3a. 既存フィーチャーとの重複を確認する

差分で変更されたソースファイル（ステップ 1 で確定した範囲のもの）について、必須サブスキルとして load-subgraph を使用します。P0 と P1 の両方に反映されるよう、差分／PR の概要から任意のキーワードも指定できます。スキーマ 1.1 のフィールド（path_evidence、term_evidence、via_traces）から、近隣のカードを保持します。owns_coverage を明示します。根拠に基づく主張（帰属先は1つ）は、パッケージから導くすべての結論（Spec の再利用ミスを含む）について、skills/execution/load-subgraph/references/grounded-claims.md に従ってください。 完了条件：重複するフィーチャーのカード、または grounded-claims.md に従い、空であること／カバレッジを明記した「重複なし」を保持していること。

3b. 不変条件への準拠（参考情報）

docs/architecture/ が存在する場合、必須サブスキルとして inspect-invariants を差分に対して使用します。結果として、Respects: ARCH-N ごとの判定（準拠／違反／不明）が返されます。違反／不明の判定はステップ 5 まで保留してください。このレーンは仕様上、参考情報であり、2 つのハードな判定軸には含まれません。マージをブロックする要因にはなりません。docs/architecture/ が存在しない場合は、このステップをスキップし、何も追加しません。完了条件：不変条件の判定を保留するか、明示的に「no spine」とすること。

3c. コードベースのナビゲーションドキュメント（任意のコンテキスト）

適用条件： 差分のパスが、既存のナビゲーションドキュメントに記載されたモジュール、所有権、依存関係の範囲と重なる場合。読み込み： skills/project/define-system-doc/consult-recipe.md。

パス： docs/codebase/modules.md、ownership.md、dependencies.md。

承認済みの場合： Spec／Standards の参考コンテキストとしてのみ使用します。文書化された境界／所有権／依存関係との競合は、参考情報として指摘してください（それだけでマージをブロックするものではありません）。所有権ドキュメントはアクセス制御を強制するものではありません。

存在しない場合／権威ある情報源でない場合： 続行します（何もしません）。レビューの明確化に不足しているナビゲーションドキュメントが役立つ場合に限り、/define-system-doc codebase/modules|ownership|dependencies を 1 回提案します。自動的に呼び出してはいけません。

完了条件：ナビゲーションのコンテキストを保留するか、存在しない場合は明示的に何もしないこと。

3d. UI レビュー — 表示条件に応じて実施

ステップ 1 の範囲に対する --name-only の一覧に、ブラウザーでレンダリングされるファイル（HTML、CSS／スタイリング、JSX／TSX／Vue／Svelte コンポーネント、テンプレート）が含まれる場合 → 必須サブスキルとして、同じ範囲に対して inspect-ui を使用します。スクリーンショットに基づく調査結果と needs-human-eyes の行をステップ 5 まで保留してください。差分にレンダリング対象のファイルがない場合はスキップし、何も追加しません。完了条件：UI の調査結果を保留するか、明示的に「no rendered surface」とすること。

3e. 仕様のステージング

Spec のディスパッチ前（およびインラインの Spec 確認前）に、必須サブスキルとして hold-stage を使用します。この固定された差分が実装または違反する ID を採用します。適用される仕様に含まれるその他すべての ID はこの範囲外です。仕様がそれらを約束している場合は、その一覧を 1 回だけ報告します。範囲外の項目ごとに完全な指摘を書いてはいけません。完了条件：Spec の概要に採用した ID の集合と、範囲外の ID を 1 行で記載すること（または「all IDs are in range」とすること）。

3f. 影響範囲の検証 — 表示条件に応じて実施

固定された範囲がランタイムの動作、ストレージ、ワイヤー／コントラクトの形式、または構成を変更する場合は、マージの判定前にこのファイルと同じ場所にある blast-prove.md を読み、内容に厳密に従います。## Blast prove ブロックをステップ 5 まで保留してください。ドキュメント／テストのみの差分はスキップします。完了条件：検証済みまたは明示的に未検証とするか、「no runtime surface」とすること。

4. 両方のサブエージェントを並列でディスパッチする

両方のディスパッチを含むメッセージを1つ送信し、同時に実行して、それぞれのコンテキストに互いの情報が混入しないようにします。どちらも読み取り専用です。作業ツリー、インデックス、HEAD、ブランチの状態を変更してはいけません。別のリビジョンを調べる場合は、一時的なワークツリー（git worktree add <tmpdir> <sha>）を使い、HEAD を移動してはいけません。各ブリーフは400語未満にします。ディスパッチで調査結果を先回りして決めつけてはいけません。「指摘しない」や、評価済みの重大度を示す表現は禁止です。

Standards サブエージェントには、差分コマンドとコミット一覧、規約の参照元となるパス、そして standards-baseline.md のパスを渡します。最初に standards-baseline.md を必ず読むよう指示してください。

レポートは、次の5部構成に固定し、順番どおりに、各部を完了してから次へ進みます。

• (a) 文書化された規約 — 差分がリポジトリに文書化されたルールに違反する箇所をすべて挙げ、該当する文書とルールを示します。CONTEXT.md の用語とのずれも含めます（用語集の概念を変更する、または別の用語で表す差分は指摘対象です）。
• (b) 12のコードスメル — 各スメルについて、1～12の番号を付けた判定を1行ずつ記載します。該当しないものも含めます。スメル名に続けて HIT（該当箇所を命名し、該当するハンクを引用）または no hit と記します。12行未満の (b) セクションは未完了とみなされ、再実行されます。
• (c) セキュリティ — 信頼境界（信頼されない入力、シークレットの取り扱い、特権操作）をまたぐハンクに対してのみ、項目13～18を確認します。信頼境界をまたがない場合は、その旨を一度だけ述べて先へ進み、指摘を捏造してはいけません。
• (d) 本番運用への準備状況 — 差分が実行時の動作、ストレージ、契約、設定を変更する場合に限り、項目19～24を確認します。問題が発生したときに運用担当者が何を目にするかを、項目名とともに記載します。項目24は、差分以外のリポジトリを検索して必ず回答します。確認対象の読み取り側は差分が触れていないファイルにあるため、差分だけを読んで判断すると、問題を見落としてしまいます。
• (e) テスト — 差分がテストファイルを追加または変更する場合に限り、追加・変更されたテストファイルごとに、またはファイルに含まれるテスト数が少ない場合はテストごとに、項目番号とテスト名を記した判定を1行ずつ記載し、アサーションを引用します。リテラルをそのまま言い換えるだけのテスト、別のテストと同じ失敗を繰り返すテスト、失敗し得ないテストは指摘対象です。これらに該当するテストを根拠に「カバー済み」と報告してはいけません。差分にテストファイルがない場合は、その旨を一度だけ述べます。

(c)、(d)、(e) はそれぞれ独自の適用条件に従います。適用されない部は省略せず、適用外と報告します。後続の部を追加しても、先行する部を短縮してはいけません。(c)、(d)、(e) が適用されるかどうかにかかわらず、(b) は最後まで確認します。文書化された規約への違反は重大な指摘となる場合があります。ベースラインのスメル、セキュリティ、本番運用への準備状況は、いずれも常に判断を伴う項目です。リポジトリの文書はベースラインより優先されます。ツールで強制される項目は対象外にします。

Spec サブエージェントには、差分コマンドとコミット一覧、requirements.md のパス、step 3e で認められた ID の一覧と範囲外の一覧、ブリーフを渡します。認められた ID を確認し、(a) 欠落している、または一部しか実装されていない ID、(b) 要件で求められていない差分内の動作（スコープクリープ）、(c) 実装済みに見えるものの誤っている ID を報告するよう指示します。すべての指摘で要件 ID を引用します。範囲外の ID は一度だけ列挙します（約束されている場合は未実装のままですが、ID ごとの説明は不要です）。また、カバーされている各認定 ID の動作がテストまたは受け入れ証跡によって確認されているかも調べます（ドメイン用語を使ったテストを確認し、テストソース内の ID タグは要求しません）。step 3a で機能が重複していることが判明した場合、Spec サブエージェントには隣接機能のカード（所有するパスと Out-of-Scope）もコンテキストとして渡します。ブリーフでは、差分が共有領域を持つ隣接機能の担当する動作を再実装している箇所を、隣接機能の feature code を引用した reuse-miss の指摘として報告するよう指示します。

完了条件：両方のレポートが返ってきたら完了です。

4b. 2 回目の Standards パス — ハーネスが可能な場合

レビューで検出される事項の大半を担うのは Standards 軸であり、1 回のパスだけでは指摘を取りこぼします。ハーネスで別の読み取り専用サブエージェントを実行できる場合は、独立した新しいコンテキストで、同じ依頼内容を使って 2 人目の Standards レビュアーを実行します。ハーネスで選択できるなら別のモデルを優先し、選べない場合は同じモデルでもう 1 回パスを実行します。価値をもたらすのは 2 回目のパスであり、モデルの違いは誰も測定していないおまけだからです。各 Standards パスで使ったモデル名をレポートに記載するか、unknown としてください。ハーネス名から推測してはいけません。

2 つの結果は投票ではなく、和集合として統合します。 片方のレビュアーだけが指摘し、もう片方が見落としたからといって、その指摘の重要性が下がるわけではありません。シード済みの差分で測定したところ、4 人のレビュアーは最初の 5 件では一致し、残りでは意見が分かれました。そして、ちょうど 1 人のレビュアーだけが挙げた 2 件は、セット内で最も深刻なものでした。コード自体が引き起こすインシデントを再構成できない監査ログと、初回アクセス時のプロビジョニングにおける暗黙の信頼境界です。一致度に基づいて重み付けしていれば、どちらも軽視されていたでしょう。2 つのレポートが同じ欠陥を説明している場合は重複を除き、同じ行に対する異なる問題を指摘している場合は両方の表現を残し、他のレビュアーの同意がないことを理由に削除してはいけません。

5. 集約

レポートは ## Standards と ## Spec の見出しの下に提示します。手を加える場合も、軽微な整形にとどめてください。2 つの軸の間で統合、重複排除、再順位付けをしてはいけません。軸を分けているのは、まさにそうした再順位付けを防ぐためです。ステップ 3b で不変条件の判定が作成された場合は、独立した第 3 のレーンとして ## Invariants (advisory) の見出しの下に提示します。Standards／Spec と統合したり、これらに対して再順位付けしたりしてはいけません。ステップ 3d を実行した場合は、inspect-ui の指摘を ## UI の見出しの下に提示します。これらの指摘には重大度があり、アドバイザリーではなくスクリーンショットに基づくものなので、2 つの軸と同様に判定に数えます。また、needs-human-eyes の行はそのまま再掲します。ステップ 3f を実行した場合は、そのブロックを ## Blast prove の下に提示します。安全性に関する事実が証明されていなければ、Ready to merge? Yes とは判定できません。

各指摘には、重大度（Critical／Important／Minor）、ファイルと行番号、問題となる理由、そして明白な場合を除き、推奨される修正方法を記載します。

最後に、次の判定を記載します。

Ready to merge? Yes | No | With fixes
[1–2 sentences of technical reasoning]

続いて、繰り越しの欄を記載します。判定に Minor の指摘が含まれ、このブランチでは誰も対応しない場合、それらの指摘が存在するのはこのレポートだけです。そのような Minor ごとに、次のブロックを出力します。欄の名前は record-debt の The entry と同じにします。ただし、見出しには DEBT-N を含めません（ID を付与するのは /record-debt です）。ユーザーが実行するコマンドとして /record-debt を記載します。Critical と Important は、繰り越してはいけません。

### `<path>` — <one-line finding>

- **Found:** `<YYYY-MM-DD>` · inspect-change on `<branch or range>`
- **Cost:** <what this makes harder or riskier, concretely>
- **Deferred because:** unactioned Minor on this branch
- **Fix shape:** <one line | Unknown>
- **Ticket:** none
- **Status:** open

答えがない欄には Unknown を記載し、その行を省略してはいけません。「残りだけ列挙する」／「台帳の形式を勝手に作らない」は、これらの欄を省略する理由にはなりません。ここで **DEBT-N** を付けると ID が衝突するため、付けてはいけません。

完了条件：両方の軸のセクション、判定、繰り越し欄が提示されていること。対応されずに残る Minor がない場合は、繰り越し欄に「繰り越しなし」と記載します。

インラインでの代替手順（サブエージェント機能がない場合）

このハーネスにサブエージェント機能がありませんか？ 2 つの軸を同じコンテキスト内で順に自分で実行します。まず Standards — standards-baseline.md を読み、差分を 12 個の問題パターン、Security セクション、Production-readiness セクションそれぞれに照らして確認します。次に Spec — hold-stage を最初に確認し、その後、対象範囲に含まれる ID を確認します（範囲外は一度だけ確認します）。続いて、ステップ 3d が実行された場合は、inspect-ui に従って UI レーンを確認します。次の軸に着手する前に、1 つの軸を最後まで確認して記録し、軸どうしを再順位付けせずに、それぞれ ## Standards、## Spec（および ## UI）の見出しの下に提示します。この方法では、2 つのサブエージェントが提供するコンテキストの分離が失われます。そのため、軸を 1 つずつ完了してから次の軸を始めるという規律が、互いの内容が混ざるのを防ぎます。