intent-validate

name	intent-validate
description	intent-tree・intent-compass・packets（+ export 下書き）を横断し、矛盾・カバレッジ漏れ・境界不整合・規範違反を深刻度付きで報告する読み取り専用の検証。修正は提案にとどめる。

intent-validate Skill

Core Mission

• Success Criteria:
  • intent-tree・intent-compass・packets（+ export 下書き）を横断し、検査カタログの全検査を適用している（検査の集合・区分・深刻度は rules/validate-checks.md の表が正）
  • 検出結果を深刻度別（要修正 / 推奨 / 情報）に分類し、各項目に検査 ID（rules/validate-checks.md の表の ID 列）・根拠（ファイルと該当記述）・修正の提案（再実行すべきスキル or 修正方針）を添えている
  • 未検証対象（未作成 / 未記入の成果物、およびスキップした検査の ID）とその理由を明示している
  • packet を PBR 四観点（利用者観点 / 運用観点 / テスト観点 / 保守観点）で静的に読み、各観点の破綻条件が記述されているかを read-only で確認している
  • ファイルの作成・変更・削除を一切行っていない（read-only・一方向報告）

Execution Steps

Step 1: 前提を確認する

• .intent/ が無ければ intent-planner のセットアップ手順（npx intent-planner の実行）を案内して終了する。
• intent-tree.md / intent-compass.md / .intent/packets/ の一部欠落は非ブロッキング: 停止せず、検証可能な範囲で検査を実施し、欠けた成果物は未検証対象として報告する（packets は .intent/packets/ 不在または active/ が空の場合を欠落とみなし、packet 系検査をスキップする）。

Step 2: 成果物を読む

• .intent/intent-tree.md、.intent/intent-compass.md、.intent/packets/index.md と .intent/packets/plan.md、検査対象の packet ファイル（packet 横断の検査では active/ 配下の全件を読む。archive/ は読まない）、.intent/cc-sdd/<スラッグ>/*.md（packet 毎の export 下書き。存在すれば）、引き継がれた発行ディレクトリの discovery/<スラッグ>-<rand>/mode.md（A34・discover が出力した発行名を引き継ぐ）→ 無ければ単一 .intent/mode.local.md（legacy）→ 無ければ旧 .intent/mode.md の順で mode 状態を読む（CONTRACT.md の read fallback 規約）。記号の実在照合では、分割収納 .intent/compass/（在れば）と旧本体のどちらかで到達できれば実在とみなす（新旧両対応・DR133）。intent-tree の案件記録（機能追記/機能撤去/履歴/再起案）は分割収納 .intent/tree/（在れば）と本体末尾の旧形式のどちらかで到達できれば実在とみなす（新旧両対応・骨格 L0–L4 は本体・tree-normalize / DR133）。
• mode.local.md / mode.md 両不在は standard 既定で続行し告知する（停止しない）。
• compass の読み込みは領域スコープで部分ロードしてよい（opt-in・federated-governance / INV101）: 引数の領域指定または案件文脈から対象領域が定まるときは、rules/domain-scope.md を読み、適用する。compass を全文ロードせず「案件の領域タグ + always」だけを grep + インラインタグで引く（INV47 の pull 規律を検証層へ広げる）。ただし全体走査が本質の軸（compass-rule-decay / stale-questions / stale-assumptions / 全 always 記号を母集合にする横断照合軸）は領域スコープで絞らず全記号を対象にする（検出力を落とさない・B-fed5）。領域が定まらない・タグの無い旧 scaffold では従来どおり全量読みにフォールバックする（後方互換・O3）。検査カタログの軸・区分・深刻度・温度は変えない（変えるのは各軸が読み込む記号の範囲だけ）。
• 下流の spec 生成物（.kiro/specs/<feature>/*.md）は、draft-content-dropped（Step 3.17）の突合相手としてのみ read-only で観測する（存在すれば読む・無ければ当該検査をスキップ）。外部ツールの成果物を書き換えない（INV1・アドオン原則）。突合相手の同定に使う - feature: 追記行は .intent/export-log/<packet-slug>.md にある。

Step 3: 検査カタログを適用する

• rules/validate-checks.md を読み、検査カタログの全検査を適用する（検査の集合・区分・深刻度は rules/validate-checks.md の表が正）。
• 深刻度の振り分け（L3 不一致の 要修正 / 推奨 の判定を含む）は rules の基準に従う。
• 境界検査の対象は .intent/export-log.md 最新行の packet のディレクトリ（同定はディレクトリ内 requirements.md の ## Source Packet 見出し一致が正）。過去 packet の下書きは設計上併存するため違反として扱わない。export-log 不在・解釈不能時は下書きの Source Packet 見出しへフォールバックし（複数ディレクトリ時は断定せず候補提示）、その旨を報告する。

Step 3.5: PBR 四観点を静的に確認する（read-only・破綻条件の探索）

• packet（active/ 配下、export 下書きがあれば併せて）を以下の四観点で読み、各観点の破綻条件が記述されているかを静的に確認する。記述が欠落していれば該当観点の指摘として深刻度別一覧に載せる（自動修正・対話確認は行わない）。
• 利用者観点: 利用者にとっての振る舞いの破綻条件（期待される振る舞いが崩れる入力・状況）が記述されているか。
• 運用観点: 障害・タイムアウト・悪意ある入力に対する fail-safe 設計（縮退・拒否・再試行などの挙動）が記述されているか。
• テスト観点: 等価分割・境界値分析に基づくテストケースが作成可能か。作成不可能なら境界条件の欠落として報告する。
• 保守観点: packet が内部に How（天井の固定）を抱え込み、実装エージェントの自由な設計を阻害していないか。
• いずれの観点でも、ハッピーパスの確認に留めず「この設計が破綻する条件（異常系・高負荷・不正入力）」を能動的に探す（確証バイアス緩和）。破綻条件が見当たらない場合は「未探索」ではなく「破綻条件の記述が欠落」として扱う。
• 本観点別確認は静的チェック項目であり、新たな対話ループ・状態機械・対話確認ツールを導入しない。対話的な観点別監査が必要なら、既存の reviewer subagent 運用（kiro-review 等）へ委ねる旨を Open Questions / 修正の提案に記す。

Step 3.6: 造語の疑いを名指しする（coinage-suspect・read-only・意味的）

• 最初に project-local な term-drift 配置物だけを探す: 対象リポ直下の .term-drift/、または対象リポ内の選択中 agent の設定ディレクトリにある skills/term-drift/SKILL.md のどちらかが見つかったら、この Step 3.6 の残りを実行しない。配置物の存在は「利用可能」の証拠ではないため、detect.md を読まない・term-drift rules を実行しない・用語の意味判定をしない・version / hash / 必要ファイル集合 / agent skill の互換性を判定しない。他の intent 検査は続け、利用者へ「リポジトリで npx intent-planner . --agent <選択中のagent> --with-term-drift --dry-run を実行して既存 installer の health を確認し、ready と表示された場合だけ選択中 agent の term-drift 専用 skill から本格点検へ進む」と短く案内する。intent-validate 自身はコマンドを起動しない（allowed-tools は Read, Glob, Grep のまま）。
• 配置物が一つも無い場合だけ、以下の従来検出を続ける: この分岐では新しい案内を出さず、従来の coinage-suspect の射程・温度を保つ。
• 母集合を読む: .intent/glossary.md（正規語彙の軽量台帳）を read のみで読み、「正規語」列とその「別表記・同義語」を母集合とする。行に語の状態（承認済み/暫定/否認済み）と言い換え例が書かれていれば合わせて読む（任意項目・スキーマの正本は台帳側）。.intent/glossary.md が不在なら母集合を空とみなし、本検出を一切発火しない（既存の validate 出力を変えない・後方互換）。
• 判定する（意味的・機械検査ではない）: intent 成果物（intent-tree / intent-compass / packets ＋ export 下書きがあれば）に現れる語のうち、母集合（正規語・別表記・同義語）のどこにも無い語を「造語の疑い」として名指しする。判定は意味的な読み（LLM 文脈での同義・表記ゆれの把握を含む）で行い、正規表現の機械的一致ではない。scripts/intent-check.mjs には一切寄せない。
• 台帳の状態を母集合の解釈に反映する（状態が在れば）: 状態が承認済みの語はチーム共通語として沈黙する。状態が明示の暫定の語は、台帳に載っていても「チーム合意が未了のまま使われている語」として候補提示してよい（未登録の造語の疑いとは言い回しを分け、承認済みへの昇格または言い換えの検討を添える）。状態が否認済みの語は沈黙集合に入れず、成果物に現れたら「一度否認された語の再発明の疑い」として、否認の台帳行（あれば言い換え例）を添えて名指しする。状態が書かれていない行・状態列の無い旧3列の台帳は「暫定」として読むが、検出の出力は従来どおり（登録済み＝沈黙）に保つ（後方互換・旧3列の台帳で挙動が変わる実装は誤り）。状態の登録・昇格は人が1語ずつ個別承認する別アクションで、本スキルは台帳を書き換えない。
• 除外条件: 次は造語の疑いとして名指ししない。
  • 固有名詞（製品名・人名・組織名 等）。
  • 既存の確立した英語の技術用語。
  • terminology 作法に従い初出に一行説明が添えられている正当な新語（terminology が既に統治する語を二重に拾わない）。
• 温度: 候補提示に留め断定しない（誤検知前提）。「これは造語かもしれない」という候補として挙げ、利用者の判断を奪わない。判定に迷う場合は挙げない。
• 沈黙: 造語の疑いが1件も無いときは、造語検出に関する出力を一切発火しない（無理に何かを造語扱いしない）。
• 言い換え案を添える（提示のみ）: 造語の疑いを名指しするとき、その語を寄せられる glossary 台帳の正規語（複数なら候補列挙）を「修正の提案」として添える（例: 「<造語> は glossary の <正規語> に寄せられる候補」）。名指しと同じく候補に留め断定しない。glossary に妥当な寄せ先が見当たらないときは寄せ先を断定せず「台帳に正規語の追加を検討」と添える。言い換え案は造語の名指しに連動し、検出が沈黙するときは言い換え案も出さない。
• 言い換えは提示までで自動改変しない: 言い換え・統合の案は read-only の報告に留め、canonical（intent-tree / intent-compass / packets）も glossary 台帳も。本スキルは案を名指しするだけで、ファイルを編集しない。実際の反映は人が承認してから行うである（本機能は提示まで・INV20）。

Step 3.7: 根拠なき結論を名指しする（groundless-conclusion・read-only・意味的）

• 背景: Intent はしばしば「人間が事象を要約した結論」だけで与えられ、その結論を導いた根拠（rationale＝理由・制約・前提・トレードオフ）が落ちる。結論は根拠から再導出できるが根拠は結論から再導出できない（非対称）。根拠が落ちた結論は否定する事実が来ても訂正できない（訂正可能性の喪失）。本検出は結論だけで根拠が辿れない箇所を read-only で名指しし、訂正可能性を点検する（A29・C18・INV36）。
• 判定する（意味的・機械検査ではない）: intent 成果物（intent-tree の意図・intent-compass の Invariant/Decision Rule・packets の決定 ＋ export 下書きがあれば）に現れる結論のうち、それを導いた根拠（理由・制約・前提・トレードオフ）が成果物から辿れないものを「根拠なき結論の疑い」として名指しする。判定は意味的な読み（根拠が別箇所・親 intent・Decision Rule の Why/Consequences に在るかの把握を含む）で行い、scripts/intent-check.mjs・必須フィールドの有無・正規表現の機械的一致には一切寄せない（INV2/A1）。
• 除外条件: 次は根拠なき結論として名指ししない。
  • 自明な意図（一般的に根拠の明示が不要なほど自明な判断）。
  • 既出の根拠を参照している結論（同一成果物・親 intent・関連 Decision Rule に根拠が在る）。
  • 別の意図・Invariant・Decision Rule が根拠を兼ねている場合。
• 訂正可能性の観点を添える: 名指しする結論には「その結論が否定する事実が来たとき、根拠から再評価できるか」の観点を所見として添える（根拠が辿れない＝再評価できない＝訂正不能のリスク）。
• 温度: 候補提示に留め断定しない（誤検知前提）。「根拠が辿れないかもしれない」という候補として挙げ、利用者の判断を奪わない。判定に迷う場合は挙げない。
• 沈黙: 根拠なき結論の疑いが1件も無いときは、本検出に関する出力を一切発火しない。
• 射程: 本検出の対象は当該 validate 実行の検査対象範囲（新規・差分の成果物）に揃え、既存 tree/compass 全体を無差別に遡及スキャンしない（ノイズ過多を避ける。遡及の棚卸しが要るときは opt-in の別経路として扱う）。
• 根拠の補完は提示までで自動改変しない: 根拠を添える更新案は read-only の報告に留め、canonical（intent-tree / intent-compass / packets）を自動で書き換えない。AI が根拠を捏造して結論を後付け正当化すると、防ぎたい訂正不能（brittle memory）を悪化させる。本スキルは「根拠が辿れない」と名指しするだけで、根拠の記入は人が承認してから行う別アクションである（A7/INV5・INV36）。
• gate にしない: 根拠なき結論の疑いは深刻度「情報」の一方向報告であり、export や実装を止めない（正当な省略＝自明な意図・既出根拠の参照を阻害しない）。

Step 3.8: 未検証の仮説を名指しする（unverified-hypothesis・read-only・意味的）

• 背景: packet を切る・decision slot を埋める決定地点で、エージェントは「map をコピーして出力先を変えるだけ」のような暫定の確信（仮説）で素通りしようとする。intent-packets の事前 probe（decision-probe.md）がこれを決定の瞬間に裁くが、probe が発火しない局面（probe 未導入の既存 packet・load-bearing 判定の漏れ・probe をすり抜けた確信）では「証拠の裏が無いまま確定された仮説」が成果物に残る。本検出はそれを export 前に事後で拾う。前節 groundless-conclusion（結論に根拠が辿れない＝保存の軸）とは検出軸を分ける（こちらは仮説に証拠の裏が無い＝検証の軸・A30・C19・INV37・DR61）。
• 判定する（意味的・機械検査ではない）: 成果物（packet の確信・Decisions の Human-fixed 値・compass の Decision/Invariant ＋ export 下書きがあれば）に残る仮説（暫定の確信）のうち、それを検証/反証する証拠が .intent/（compass の Invariant/Decision Rule・glossary・過去 deltas・関連 packets＝証拠 pool）から辿れないものを「未検証の仮説」として名指しする。判定は意味的な読みで行い、scripts/intent-check.mjs・必須フィールドの有無・正規表現の機械的一致には一切寄せない（INV2/A1）。
• 反証を第一に: 仮説を追認する証拠を都合よく引いて誤決定に権威付けしないよう、確信と矛盾する証拠（反証/未検証）を所見の第一に置く。証拠が .intent/ に実在し裏付けられた確信は誤検出しないよう意味判断で除外する（warn-only ゆえ誤検出の害は小さいが量を絞る）。
• A29 と軸を分ける: groundless-conclusion（結論の根拠欠落）と本検出（仮説の証拠欠落）を別検査として報告し、所見を混ぜない（同一箇所に両軸が当たっても重複検出にしない＝突合面が「根拠の保存」と「証拠の探索」で異なる）。証拠源は共有しうる（A29 が残す根拠が本検査の証拠 pool に入る相乗）。
• 温度: 候補提示に留め断定しない（誤検知前提）。「証拠の裏が無いかもしれない」という候補として挙げ、利用者の判断を奪わない。判定に迷う場合は挙げない。
• 沈黙: 未検証の仮説の疑いが1件も無いときは、本検出に関する出力を一切発火しない。
• 射程: 本検出の対象は当該 validate 実行の検査対象範囲（新規・差分の成果物）に揃え、既存 tree/compass 全体を無差別に遡及スキャンしない（遡及の棚卸しが要るときは opt-in の別経路として扱う）。
• コールドスタート回避（Fail-Safe）: 証拠 pool（.intent/）が空のときは「証拠の裏が無い＝即警告」にせず「証拠 pool が無いため判定不能」を明示する（合格とも誤標識しない）。
• 証拠の補完は提示までで自動改変しない: 証拠を添える更新案は read-only の報告に留め、canonical（intent-tree / intent-compass / packets）を自動で書き換えない。AI が証拠を捏造して確信を後付け正当化すると、防ぎたい drift をかえって悪化させる（A30 のプレモータム）。本スキルは「証拠の裏が無い」と名指しするだけで、証拠の記入は人が承認してから行う別アクションである（A7/INV5・INV37）。
• gate にしない: 未検証の仮説の疑いは深刻度「情報」の一方向報告であり、export や実装を止めない（正当な省略を阻害しない）。

Step 3.9: dangling 参照を名指しする（dangling-reference・read-only・LLM 文脈）

• 背景: canonical（compass）は番号付き相互参照（Anti-direction N / INV N / DR N）で結ばれ、pull 規律（全文を読まず該当 Invariant/Anti-direction だけを引く）は「参照先が実在する」ことを暗黙の前提にする。退避・統合・削除でブロックが動くと、参照先が消えて宙吊り（dangling reference）になりうるのに、validate に拾う軸が無かった（canonical-slimming で compass のブロック move が dangling を起こし無検出で通った実害＝INV42・C20・A35・DR67）。本検出はそれを export 前に拾う。Doorstop の suspect-link 相当。
• 判定する（LLM 文脈で読む・機械検査ではない）: 検査対象の成果物に現れる番号付き相互参照（compass の Anti-direction N / INV N / DR N）のうち、参照先が成果物内に実在しないものを「dangling 参照の疑い」として名指しする。判定は LLM が成果物を読んで参照先の実在を確かめる意味的な読みで行い、scripts/intent-check.mjs・grep・正規表現の機械的一致には一切寄せない（INV2/A1・既存3軸と質を揃える）。
• 対象を絞る: compass 内の番号参照（Anti-direction N / INV N / DR N）に絞る。[[memory-slug]]（memory は別リポゆえ validate から実在照合できず誤検知が多い）と packet の parent_intents 参照は対象外。番号振り直し（ID が別物に差し替わった）は射程外で、純粋な実在欠落に絞る。
• 既存3軸と軸を分ける: coinage-suspect（台帳に無い造語）/ groundless-conclusion（結論の根拠欠落）/ unverified-hypothesis（仮説の証拠欠落）と本検出（参照先の実在欠落）を別検査として報告し、所見を混ぜない（同一箇所に複数軸が当たっても重複検出にしない＝突合面が違う）。
• 温度: 候補提示に留め断定しない（誤検知前提）。「参照先が宙吊りかもしれない」という候補として挙げ、利用者の判断を奪わない。判定に迷う場合は挙げない。
• 沈黙: dangling 参照の疑いが1件も無いときは、本検出に関する出力を一切発火しない。検査対象に番号参照が1つも無い・compass 不在のときは本検出をスキップして他検査を続行する（エラーにしない）。
• 射程: 本検出の対象は当該 validate 実行の検査対象範囲（新規・差分の成果物）に揃え、既存 compass 全体を無差別に遡及スキャンしない（退避直後の全体点検が要るときは opt-in の別経路として扱う）。
• 参照の張替えは提示までで自動改変しない: 宙吊りの名指しは read-only の報告に留め、参照先を自動で張り替えて canonical（intent-tree / intent-compass / packets）を書き換えない。本スキルは「参照先が宙吊り」と名指しするだけで、参照の修正は人が承認してから行う別アクションである（A7/INV5・INV42）。
• gate にしない: dangling 参照の疑いは深刻度「情報」の一方向報告であり、export や実装を止めない（誤検知前提・Anti-direction 218）。

Step 3.10: 検査オラクル未紐づけの Invariant を名指しする（invariant-oracle-missing・read-only・LLM 文脈）

• 背景: compass の Invariant（壊してはいけない約束）は文章で書かれているだけで「破れたと分かるものさし（検査オラクル）」が隣に無く、守れているかを点検する手立てが約束のすぐ隣に無い。各 Invariant に「これを破ったらこう分かる」確認手立て（機械テストに限らず手順でもよい）を1行紐づけ、付けられない思想的な Invariant は「ものさし無し」と明記すると、約束が「努力目標の文章」から「破れたと分かる検査可能なもの」に変わる。本検出は、その紐づけが抜けている（オラクルも「ものさし無し」明記も無い）Invariant を export 前に拾う（Tessl「テストも intent」の intent-planner 版・C2/C8・A38・DR72・INV48）。
• 判定する（LLM 文脈で読む・機械検査ではない）: compass の各 Invariant（### <機能> 直下の INV N 項目）を読み、検査オラクル（破れたと分かるものさし）が紐づいているか・「ものさし無し（思想的制約）」と明記されているかを意味で確かめ、どちらも無いものを「オラクル未紐づけの疑い」として名指しする。判定は LLM が compass を読んで行い、scripts/intent-check.mjs・grep・正規表現の機械的一致には一切寄せない（INV2/A1・既存検出軸と質を揃える＝INV48「オラクルの有無・妥当性の判定は LLM 意味判断」）。
• オラクルの妥当性も見る（断定しない）: オラクルが在っても「破れたと分かる手立てになっていない」（例: 同義反復・観測不能・対象がずれている）と読めるものは候補提示してよい。ただし妥当性判定は誤検知前提で、迷う場合は挙げない。
• 既存検出軸と軸を分ける: coinage-suspect（台帳に無い造語）/ groundless-conclusion（結論の根拠欠落）/ unverified-hypothesis（仮説の証拠欠落）/ dangling-reference（参照先の実在欠落）と本検出（Invariant の検査オラクル欠落）を別検査として報告し、所見を混ぜない（突合面が違う）。
• 温度: 候補提示に留め断定しない（誤検知前提）。「ものさしが付いていないかもしれない」という候補として挙げ、利用者の判断を奪わない。
• 沈黙: オラクル未紐づけの疑いが1件も無いとき（全 Invariant にオラクル or「ものさし無し」明記がある）は、本検出に関する出力を一切発火しない。compass 不在・Invariant が1つも無いときは本検出をスキップして他検査を続行する（エラーにしない）。
• 射程: 本検出の対象は当該 validate 実行の検査対象範囲（新規・差分の Invariant）に揃え、既存 compass 全体を無差別に遡及スキャンしない（全体点検が要るときは opt-in の別経路）。
• オラクルの自動付与はしない: 未紐づけの名指しは read-only の報告に留め、オラクルを自動で書き加えて canonical（intent-compass）を書き換えない。本スキルは「ものさしが付いていない」と名指しするだけで、付与は人が承認してから行う別アクションである（A7/INV5・INV48）。
• gate にしない: オラクル未紐づけの疑いは深刻度「情報」の一方向報告であり、export や実装を止めない（誤検知前提・INV49 の warn-only 思想を継承）。

Step 3.11: 変更ファイルから影響する Invariant を逆引きして名指しする（invariant-impact-reverse・read-only・grep 単純照合・warn-only）

• 背景: Invariant は数十個あり、pull 規律（全文を読まず該当分だけ引く）の前提で、実装者（人間/AI）は「自分が触ったファイルにどの Invariant が関係するか」を手で思い出すしかなく見落とす。各 Invariant に付けた 影響パス（その Invariant が効くファイル/パスの目印・前 Step のオラクルと対）と、変更ファイルのパスを単純に文字列照合し、関係する Invariant だけを浮かせて「この変更はこの Invariant に触れる（確認はこのものさしで）」と示す。窓口は intent-validate に集約し、前 Step（オラクルの有無）と本 Step（変更→影響）を1回の実行でまとめて出す（C2/C10・A38・DR72・INV49）。
• 発火条件（変更ファイルのパスがあるときだけ）: 利用者が変更ファイルのパスを渡した・引き継いだ文脈に変更対象が明示されている場合に発火する。変更パスが得られないときは本 Step をスキップして他検査を続行する（エラーにしない・既定 off の drift-watch と同じく無入力では何もしない）。
• 照合する（grep の単純な文字列照合・意味判断ではない）: compass の各 Invariant に付いた影響パス（- 影響パス: <glob/パス断片> 等）と、変更ファイルのパスを単純に突き合わせ、一致した Invariant を浮かせる。これは意味判断を要さない単純照合ゆえ grep を補助に使ってよい（INV48 の利便性優先の例外＝「変更パスと目印の文字列照合」に該当）。影響パスが付いていない Invariant は照合対象から外れる（後方互換・壊さない）。
• オラクルと対で出す（窓口集約・DR72）: 浮かせた Invariant にオラクル（破れたと分かるものさし）が付いていれば、「この変更はこの Invariant に触れる → 確認はこのものさしで」まで一息で示す（前 Step 3.10 の成果と対で働く）。
• 温度: 候補提示に留め断定しない（誤検知前提）。影響パスの付け方が粗ければ無関係な Invariant も拾うため、「この変更はこの Invariant に触れるかもしれない」という候補として挙げ、利用者の判断を奪わない。
• 沈黙: 一致する Invariant が無い・変更パスが影響パスを持つ Invariant に当たらないときは、本検出に関する出力を一切発火しない。compass 不在・影響パスを持つ Invariant が1つも無いときは本 Step をスキップして他検査を続行する。
• gate にしない（最重要・INV49）: 逆引きは深刻度「情報」の一方向報告であり、export や実装を止めない。enforcement の gate（writeback 漏れ専用）や INV43 の外部書込 gate と混同して停止機構を足さない。誤検知前提の機能を gate にすると信頼を失い無効化される。
• 索引化しない（A38 将来候補の境界・Anti-direction 229）: 照合は grep の単純文字列照合に留め、ベクター DB・依存グラフ・GraphRAG 等の索引を先回りで足さない。大規模化で grep がボトルネック化したときの索引化は INV2 違反のため、規模を理由に利用者が明示 opt-in したときだけ開く L4 将来候補に留める。

Step 3.12: 陳腐化した compass 規律を名指しする（compass-rule-decay・read-only・LLM 文脈・意味的）

• 背景: compass の Invariant（壊してはいけない約束）や Decision Rule（判断基準）は数十個に育ち、pull 規律（全文を読まず該当分だけ引く）の下では「参照先は在るが中身が現実と乖離した規律」「もう長く引かれていない死蔵規律」が構造的に発見されない。既存軸は「参照先が消えた」（dangling-reference）「packet 側の追随漏れ」（invariant-stale-vs-compass）「未解決項目の滞留」（stale-questions / stale-assumptions）は拾うが、canonical の規律そのものの腐敗を拾う軸が無かった。本検出はそれを export 前に拾う（C2/C8/C10・A41・INV54・DR75）。
• 判定する（LLM 文脈で読む・機械検査ではない）: compass の各 Invariant（INV N）/ Decision Rule（DR N）を読み、次の3類型で死蔵規律を名指しする:
  • (a) 前提崩れ: 規律本文・影響パス（A38 記法の - 影響パス: 行）が名指すファイル/skill/値が現実に存在しない・変わったもの。影響パスの指す先の実在照合は意味判断を要さない単純パス突合ゆえ Glob/Grep を補助に使ってよい（INV48 の利便性優先の例外）。本文の名指し先が現実と乖離したかの判定は LLM の意味的な読み。
  • (b) 死蔵: active packet の parent_intents・近況の deltas / drift-log の言及から辿れない（引かれた形跡が無い）もの。証拠はファイル内の打刻・参照関係のみ（git 履歴は読まない）。
  • (c) 遺物参照: 参照する packet がすべて closed/archivedで現役の担い手がいないもの。
• 判定材料の制約（数値閾値・git 履歴を持たない）: 期間・回数の数値閾値で機械判定しない（「N 日引かれていなければ陳腐化」は INV2 違反）。時間軸の証拠はファイル内の打刻（compass の Updated (...) タグ・packet frontmatter の日付・deltas / drift-log の日付行）に限り、Read, Glob, Grep のままで Bash / git log を使わない（read-only 検査層の tool 契約）。A40-(2) の発火痕跡が実装されても本軸はそれに依存しない（無くても成立する判定）。
• 対象を絞る: compass の Invariant + Decision Rule に絞る。Anti-direction は対象外（母集合最大で洪水化リスクが高く DR75 の Revisit で将来再訪）。
• 既存軸と軸を分ける: dangling-reference（参照先の消滅）/ invariant-stale-vs-compass（packet 側の追随漏れ・時間軸）/ stale-questions / stale-assumptions（未解決項目の滞留）/ invariant-oracle-missing（オラクル欠落）と本検出（canonical 規律そのものの生死）を別検査として報告し、所見を混ぜない（突合面が違う）。名前も invariant-stale-vs-compass（packet 側の遅れ）と取り違えない。
• 温度: 候補提示に留め断定しない（誤検知前提・特に (b)(c) は状況証拠の「疑い」どまり）。判定に迷う場合は挙げない。
• 出力粒度（確度で分ける）: (a) 前提崩れ＝個別所見（当該 INV/DR の番号・根拠の逐語引用付き）。(b) 死蔵 / (c) 遺物参照＝既定は件数サマリ1行（invariant-stale-vs-compass と同型・個別列挙は利用者要求時のみ展開＝全件個別列挙で洪水化させない）。
• 射程: 陳腐化は「動かないもの・差分に現れないもの」を見る軸ゆえ全体走査が本質的に要る（当該実行の新規/差分に限定しない例外）が、出力は上記の粒度規律で絞る。
• 沈黙: 陳腐化の疑いが1件も無いときは、本検出に関する出力を。判定材料が読めない対象（ タグ不在・packets 不在・active/ が空 等）は「落差なし」と誤標識せずする（Fail-Safe）。compass 不在・Invariant/DR が1つも無いときは本検出をスキップして他検査を続行する（エラーにしない）。

Step 3.13: export 下書きの弱い受入基準を名指しする（requirement-oracle-check・read-only・LLM 文脈・意味的）

• 背景: packet を切る段（intent-packets の終端判定）では、受入基準を「誤った実装を落とせる観測できる基準」に締めている。ところが packet を export 下書き（requirements）へ変換する過程で基準が曖昧になっても、それを拾う検査が無かった。packet で締めた品質が下書きで失われる穴を、export の手前で拾う（C10/C27・A42・INV55・DR76）。
• 判定する（LLM 文脈で読む・機械検査ではない）: export 下書き（.intent/cc-sdd/<スラッグ>/*.md / .intent/openspec/<スラッグ>/*.md）の各受入基準を読み、「この基準を満たしたと言い張る誤った実装を、この基準で弾けるか」を意味で確かめる。弾けない弱い基準（観測できる入力・条件・期待結果が無い・主観語や願望だけ・例:「使いやすくする」「適切に動く」「高速に」）を名指しし、観測できる形（入力→条件→期待結果）への詰め直し候補を添える。観測できる基準（何を入れると何がどうなるかが書かれている）は挙げない。判定は LLM の意味的な読みで、scripts/intent-check.mjs・正規表現・キーワードリストの機械的一致には一切寄せない（INV2/A1・既存の意味検査軸と質を揃える）。
• 既存の品質/境界系軸と軸を分ける: requirements-smell（要求記述の字面＝曖昧語・主観語・比較級・弱い語・未定義代名詞）/ export-draft-mismatch（下書きと packet 定義の整合）と本検出（受入基準が誤った実装を弁別できるか）を別検査として報告し、所見を混ぜない（突合面が違う）。同じ弱い基準が requirements-smell（字面が曖昧）と本軸（誤実装を弾けない）の両方で挙がることは正常で、互いを黙らせない。
• 定義を二重に持たない: 「誤った実装を落とせる観測できる基準」の定義の正本は intent-packets の終端判定（what + constraints + oracle の oracle）にある。本軸はそれを export 下書きへ適用する検査であって、定義を validate 側に別立てで書き起こさない（参照に留める・Anti-direction 250）。
• 温度: 候補提示に留め断定しない（誤検知前提）。「この基準では誤実装を弾けないかもしれない」という候補として挙げ、利用者の判断を奪わない。判定に迷う場合は挙げない。
• 射程（初回は export 下書きのみ）: 対象は .intent/cc-sdd/ と .intent/openspec/ の下書き。intent-to-spec が出す読める成果物（.intent/nl-spec/）の受入基準は初回の対象外（運用で必要性を見て将来広げる・DR76 の Revisit）。
• 沈黙・後方互換: 弱い受入基準が1件も無いときは本検出に関する出力を一切発火しない。export 下書きが1つも無いときは本検出をスキップして他検査を続行する（「基準に問題なし」と誤標識せず、検査対象なしとして扱う・エラーにしない）。
• 詰め直しは提示までで自動改変しない: 弱い基準の名指しと詰め直し候補は read-only の報告に留め、下書きも canonical（intent-tree / intent-compass / packets）も自動で書き換えない。本スキルは「この基準では誤実装を弾けない」と名指しするだけで、詰め直しの記入は人が承認してから行う別アクションである（A7/INV5・INV55）。
• gate にしない: 弱い受入基準の指摘は深刻度「推奨」の一方向報告であり、export や下流の spec フローを止めない（誤検知前提・INV49 の warn-only 思想を継承）。深刻度が「推奨」なのは、弱い基準は着工を止める矛盾ではなく、直すと下流へ渡す下書きの信頼性が上がる品質リスクだから（requirements-smell と同格）。

Step 3.14: 関係定石の採用漏れを名指しする（starter-coverage-gap・read-only・LLM 文脈・意味的）

• 背景: 定石カタログ・個人台帳の候補提示（発火）は複数の宿主（discover / compass / packets / db-design / 実装開始時）で行われるが、どの宿主でも「当てはまりが弱ければ黙る」ため見落としが静かに通過しうる。供給側（発火）と検査側（validate）の両面を揃え、export の手前で「明白に関係する定石領域が一度も検討されていない」packet に気づかせる（A40・DR83 宿主⑤・INV57）。
• 判定する（LLM 文脈で読む・明白な組み合わせのみ）: active packet の Scope / Expected Behavior を読み、.intent/constraint-starters.md の領域インデックスと照らして「この packet が明白に触る技術面（例: 入力を外部公開する API 境界／永続データモデル／並行更新）に対応する定石領域が一度も検討されていない」ものだけを名指しし、どの領域ファイル（.intent/constraint-starters/<領域>.md）を見るかの詰め直し候補を添える。誤検知を避けるため明白な組み合わせに絞り、微妙な当てはまりは出さない。判定は LLM の意味的な読みで、scripts/intent-check.mjs・正規表現・キーワードリストの機械的一致には寄せない（INV2/A1）。
• 採否記録の器を読み、検討済みは黙る（INV57・DR84）: 発行ディレクトリの constraint-ledger.md を read し、当該 packet に関係する定石が採用・否認・保留のいずれかで検討済みなら名指ししない（採用漏れではない）。器が読めない環境では確度を下げるか沈黙側に倒す。目的・文脈が否認時から変わったと読める否認済みは、再検討の余地として名指してよい（機械条件なし・INV2）。
• 既存の品質系軸と軸を分ける: requirements-smell（字面の曖昧語）/ requirement-oracle-check（受入基準が誤実装を弾けるか）/ invariant-uninherited（compass 普遍 invariant の継承漏れ）と本検出（明白に関係する定石領域の未検討）を別検査として報告し、所見を混ぜない。
• 関係領域だけ照合する（INV57）: カタログ全定石との総当たりはしない。親カタログの領域インデックスから packet の技術面に合う領域だけを見る（最小コストの pull）。
• 温度: 候補提示に留め断定しない（誤検知前提）。判定に迷う場合は挙げない。
• 沈黙・後方互換: 明白な未検討が1件も無いときは本検出を一切発火しない。.intent/constraint-starters.md が無いときは本検出をスキップして他検査を続行する（「採用漏れなし」と誤標識せず、検査対象なしとして扱う）。
• 採用は提示までで自動改変しない: 名指しと詰め直し候補は read-only の報告に留め、packet の ## Safety / Invariants へ自動で採用しない（採用は人が判断・A7/INV5）。深刻度「推奨」の一方向報告で export・実装を止めない（誤検知前提・INV49 の warn-only）。

Step 3.15: 受入オラクルと実テストの対応の切れ・未対応を名指しする（oracle-test-link-missing・read-only・LLM 文脈）

• 背景: A38（invariant-oracle-missing）は「Invariant に検査オラクルが在るか」を見えるようにした。本検出はその実装後側で、packet の受入オラクル（## Validation の「誤った実装を落とすものさし」）が実装後、実際にどのテストで守られているかを見る。packet-format の任意節 ## Verification protocol は verified-by リンク（オラクル→実テストの対応）を保持できると定義済みだが、書いた後にテストが消えても誰も気づかない・そもそも対応が未記入のまま実装が done になる、という往復の穴を read-only で拾う（C38/C8/C10・A49・INV63）。
• 判定する（LLM 文脈で読む・機械検査ではない）: 各 packet の ## Validation の受入オラクルと ## Verification protocol の verified-by（対応する実テストのファイルパス+テスト名）を突き合わせ、次の2つを名指しする — (1) 対応の切れ＝verified-by が指すテストが実在しない（削除・改名された。実在照合は意味判断を要さない単純パス突合ゆえ Glob/Grep を補助に使ってよい＝INV48 例外。テスト名まで含む照合は意味読み）／(2) 未対応＝オラクルに verified-by が無い、または「未対応」と明示されないまま空いている。判定は LLM が packet を読む意味判断で、scripts/intent-check.mjs・正規表現の機械的一致には寄せない（INV2/A1）。
• 既存軸と軸を分ける: invariant-oracle-missing（compass の Invariant にオラクルが在るか）/ trace-downstream-missing（意図に対応する packet に下流リンクが在るか）と本検出（packet の受入オラクルと実テストの対応の実在）を別検査として報告し、所見を混ぜない（突合面が違う）。A38 のオラクル軸とは実装前/実装後の対で働く。
• 温度: 候補提示に留め断定しない（誤検知前提）。判定に迷う場合は挙げない。
• 沈黙・後方互換: 全オラクルの対応が健在な packet では本検出を一切発火しない。## Verification protocol 節が無い旧 packet は「未記入」として扱い警告対象にしない（不在＝未観測・後方互換の読み取り規律。遡及記入を強制しない・Anti-direction 304）。「未対応」と明示済みのオラクルは記入済みの誠実な状態として扱い、重ねて咎めない。
• 記入は提示までで自動改変しない: 対応の切れ・未対応の名指しは read-only の報告に留め、verified-by の記入は writeback（書き手フェーズ）が実測に基づいて行う別アクションである（検査層は書かない・A7/INV5）。深刻度「推奨」の一方向報告で export・実装を止めない（誤検知前提・INV49 の warn-only）。trailer 無し・verified-by 無しを咎めるのでなく「対応が辿れない箇所」を情報として示す（記録は任意・INV63）。

Step 3.16: 暫定・未定の決定が進行段階と矛盾して持ち越されているのを名指しする（provisional-carryover・read-only・LLM 文脈）

• 背景: intent-planner の根幹規律は「推測は人間がレビューするまで暫定」「未定スロットは再訪条件付きで保持」。しかし保持したまま packet の進行段階（state）が verifying/done へ進むのを見張る目が無い — 暫定のまま done になった決定は、誰もレビューしていないのに事実上の確定（既成事実）になる。器（未定の保持）が正しく機能しているほど見えにくいこの穴を read-only で拾う（C38/C3/C9/C10・A49・INV63）。並行案件 compass-rule-decay（compass の規律の陳腐化）の姉妹だが対象が違う（本軸は packet の決定の未回収）。
• 判定する（LLM 文脈で読む・機械検査ではない）: active/ 配下の packet の frontmatter（state）と ## Decisions を読み、次を名指しする — (1) 進行との矛盾＝state が verifying/done なのに 未定/暫定 のスロットが残る（特に前倒し5基準＝不可逆・複数モジュール波及・受入オラクル・セキュリティ床・複数 packet 拘束に該当するもの）／(2) 再訪条件の成立＝未定 スロットの Revisit when（再訪条件）が現在の成果物の状態から既に成立していると読める／(3) 未確認の暫定標識＝inferred/暫定 標識付きの記述が人確認の記録（利用者確定・Evidence の人確認）なく残存している。判定は LLM が packet を読む意味判断で、経過日数などの機械閾値・scripts/intent-check.mjs・正規表現の機械的一致には寄せない（INV2/A1）。
• 未定の保持そのものは罰しない（最重要・Anti-direction 300）: 警告対象は進行段階との矛盾（done なのに未回収）に限る。未定スロットの存在自体を減点しない — 未定の保持（理由・再訪条件付き）は正しい設計であり、器を萎縮させると推測で埋める逆効果（本軸が防ぎたい既成事実化そのもの）を生む。state が draft/ready のまま 未定 を保持する packet では沈黙する。
• 既存軸と軸を分ける: ambiguous-deferred-phrasing（確定文体に紛れた未確定動詞の字面）/ decision-slot-empty（スロットが空）/ compass-rule-decay（compass 規律そのものの生死）/ stale-questions / stale-assumptions（未解決項目の滞留）と本検出（packet の決定の確定度と進行段階の矛盾）を別検査として報告し、所見を混ぜない（突合面が違う）。
• 温度: 候補提示に留め断定しない（誤検知前提）。判定に迷う場合は挙げない。
• 沈黙・後方互換: 進行との矛盾が1件も無いときは本検出を一切発火しない。## Decisions 節が無い旧 packet は「未記入」として扱い警告対象にしない（不在＝未観測・後方互換の読み取り規律）。
• 確定は提示までで自動改変しない: 名指しと確定を促す候補提示は read-only の報告に留め、暫定の確定・state の変更は人の宣言による別アクションである（自動確定・自動昇格・state の自動変更をしない・Anti-direction 303・A7/INV5）。深刻度「推奨」の一方向報告で export・実装を止めない（誤検知前提・INV49 の warn-only）。

Step 3.17: 下書きの中身が下流の生成物で落ちているのを名指しする（draft-content-dropped・read-only・LLM 文脈）

• 背景: 下書きは「渡した」だけでは下流の生成過程で静かに落ちる。実測（36 export × 下流 spec の突合・2026-07）では、下書きが引いた意図の参照のうち下流の requirements に残るのは約3分の2、生成された各タスクへ不変則参照が転記される率は1割強だった。写像（下書きが受入基準の材料を運ぶ・INV75）と案内（フェーズごとにヒントを手渡す）を直しても下流の生成の癖として再発しうるため、減衰を見張る（C54・A60・DR122）。
• 判定する（LLM 文脈で読む・機械検査ではない）: export 下書き（.intent/cc-sdd/<スラッグ>/*.md）と、それを渡して下流が生成した成果物（.kiro/specs/<feature>/*.md）を読み比べ、次を名指しする — (1) 意図の参照の落ち＝下書きが引いた Invariant / Decision Rule / 親の意図の参照が下流の requirements / design / tasks のどこにも残っていない／(2) 受入基準の材料の落ち＝下書きの ## Acceptance Material 由来の判定条件が下流の requirements の受入基準に現れていない。判定は LLM が両者を読む意味判断で、生存率のスコア化・閾値判定・scripts/intent-check.mjs・正規表現の機械的一致には寄せない（INV2/A1）。
• JIT 二層入力も同じ軸で判定する（INV95・DR175）: 確定材料の欠落、対象 packet の Agent-discretion と同一項目の Revisit when から運んだ非拘束候補の 再確認候補の拘束力昇格、無関係な Tree / Compass / archive の全量注入を下書き→下流の生存・強度問題として名指しする。export-draft-mismatch の packet→下書き整合責務とは分離する。全量注入は全文と分かる構造的・意味的な証拠がある場合だけ検出し、単一の必要参照を誤検出しない。候補が無い場合は候補の生存・昇格検査を黙ってスキップする。
• 突合の相手は記録された対応を優先して同定する: export 記録の分割ファイル（.intent/export-log/<packet-slug>.md）の - feature: 追記行を一次の手がかりとし、無ければ下書きの ## Source Packet の packet 名が下流の成果物に含まれるかで補助照合する。どちらでも同定できないときは「突合不能」を1行で告げ、推測で対応づけない（誤検知を出すくらいなら黙る側に倒す）。
• 既存軸と軸を分ける: export-draft-mismatch（下書きと packet 定義の整合）/ requirement-oracle-check（下書きの受入基準が誤実装を弁別できるか）と本検出（下書きの中身が下流の生成物で落ちていないか）を別検査として報告し、所見を混ぜない（突合面が違う）。
• スコア化しない: 「生存率 何％」の数値化・閾値判定を持たない（INV2）。どの参照が・どのファイルで落ちたかを名指しするところまでで、良し悪しの点数を付けない。
• 沈黙・後方互換: .kiro/specs/ が無い（cc-sdd を使わない・直接実装する案件）ときは本検出をスキップして他検査を続行する（「落ちなし」と誤標識せず、検査対象なしとして扱う・エラーにしない）。落ちが1件も無いときは本検出に関する出力を一切発火しない。
• 自動改変しない・gate にしない: 名指しと補い直しの候補は read-only の報告に留め、下流の成果物も canonical（intent-tree / intent-compass / packets）も自動で書き換えない。深刻度「推奨」の一方向報告で、export や下流の spec フローを止めない（誤検知前提・INV49 の warn-only）。

Step 3.18: packet 間の共有契約カバレッジを照合する（cross-packet-contract-coverage・read-only・warn-only）

• Impact Analysis で共有契約と明示された新規・更新対象だけを、出典参照が同じ active packet の ## Safety / Invariants と既存 plan.md へ辿る。少なくとも1 packet に保護担当と検証方法が届くこと、複数担当の保護内容が両立すること、統合時オラクルがあることを意味で照合する。
• 未担当・相反する保護・統合時オラクル欠落だけを、共有契約の出典と関係 packet 名付きで名指しする。複数担当そのものは矛盾にせず、invariant-uninherited / packet-scope-overlap / oracle-test-link-missing と所見を混ぜない。
• 共有契約がない案件では軸ごと沈黙する。archive は読まず、既存 packet へ遡及適用せず、canonical を自動改変しない。深刻度は「推奨」の一方向 warning で、export・実装を止めない。

Step 3.19: 価値の中心に直結する能力の未着手を名指しする（capability-starvation・read-only・warn-only）

• intent-tree の North Star / Current Drift、packets/plan.md の工程計画 / Walking Skeleton、active packet の frontmatter state、export-log だけを突き合わせる。価値の中心に直結する packet が未 export・未着手のまま、補助的 packet の完了だけが先行している疑いを、LLM の意味判断で候補提示する。packet の存在や親参照だけを価値到達の証拠にしない。
• 日数・完了件数の固定閾値、score、grep / scripts/intent-check.mjs による判定を持たない。該当する canonical 能力、未 export の packet 名、先に完了した補助 packet 名を、Step 4 の規律どおり逐語引用で根拠固定する。
• 価値の中心の packet が export 済み・進行中、または Walking Skeleton / 最優先として進んでいる健全な計画では沈黙する。North Star / Current Drift 相当が無い、active packet が複数ない、または関係を読めない場合は「未検証」として軸をスキップし、「落差なし」とは言わない。
• goal-without-packet は packet 自体の欠落、本軸は packet が在るのに価値へ届かない疑いを扱う。成功指標は既存の l1-metric-missing / decision-success-signal で扱い、新軸へ混ぜない。深刻度は「情報」に留め、優先順位・state・canonical を自動変更せず、gate にしない。

Step 3.20: 成果記録の出所不足を名指しする（outcome-provenance-missing・read-only・warn-only）

• 読む場所: Packet単位の分割delta .intent/deltas/**/*.md を優先して読み、分割側に無い旧形式の記録は .intent/deltas.md から読む。同じ観測が両方にある場合は二重に報告しない。成果記録のない既存deltaもそのまま読める後方互換を保つ。
• 判定する（LLM 文脈で読む・機械検査ではない）: 「成果についての学び」の各観測について、誰が計測したか、いつ計測したか、どこで計測したか が意味のある値を持つかを読む。空欄や未記入のプレースホルダーは不足として扱い、欠けている項目名をこの固定順で一つの所見にまとめる。同じ入力には同じ所見を返し、grep・正規表現・scripts/intent-check.mjs に判定を寄せない。
• 沈黙条件: 3項目が揃う観測と、成果記録がない通常案件では所見を出さない。
• 独立した警告: 他の検査軸と所見を混ぜず、深刻度「推奨」で候補提示する。read-only のまま canonical を変更しない。警告があっても検証と後続工程（記録・export・実装）は継続し、停止条件や総合 gate にしない。

Step 4: 報告する（一方向・修正は提案のみ）

根拠固定の横断規律（evidence-anchored finding・全所見にかかる・新しい検出軸ではない）: 以下は既存の全検出軸（coinage-suspect / groundless-conclusion / unverified-hypothesis / dangling-reference / invariant-oracle-missing / invariant-impact-reverse ほかカタログの全軸）＋ PBR 四観点＋境界検査が出すすべての所見の出し方にかける横断規律であり、7つ目の検査軸として並置しない（Step 3.x を増やさない・INV50・DR73・Anti-direction 230）。

• 逐語引用で根拠を固定する: 各所見は、根拠となる canonical（intent-tree.md / intent-compass.md / packets）からの**逐語引用（verbatim quote）**をファイル名とともに添える。引用文字列は改変しない（要約・言い換えをしない・verbatim）。

• 裏づけできない所見は要修正に上げない: ある所見が canonical からの逐語引用で裏づけられない場合、その所見の深刻度は「要修正」に上げない（1段下げて「推奨」どまりにする＝OQ-eae-2。根拠は弱いが指摘の芽はある所見を「情報」へ埋没させない）。逐語引用で裏づけられた所見は、カタログの深刻度の目安どおり従来どおり要修正で出す。

• 判定は LLM 意味判断・機械照合に寄せない: 「その逐語引用が所見を支えているか」の判定は agent の意味的な読みで行い、grep / scripts/intent-check.mjs / 正規表現の string-match には寄せない（引用が意味的に的外れでも文字列一致で通る表層一致の罠を避ける・Anti-direction 232・INV2/A1）。深刻度 cap も「機械で自動減点」せず「裏づけできない所見は要修正に上げない」という報告規律として持つ。

• 各軸の添え書きと二重にしない: 各検出軸固有の添え書き（coinage-suspect の言い換え案・groundless-conclusion の訂正可能性の観点・invariant-oracle-missing の付与の観点 等）は軸固有の観点に絞り、根拠の逐語引用は本 Step 4 に一元化する（OQ-eae-3・重複して冗長化させない）。

• 【異常系】canonical が空/未作成のとき: 逐語引用の裏づけ対象そのものが無いため「引用の裏づけ不能」を明示し、所見を要修正に上げない（コールドスタートで誤って全所見を抑圧しない＝unverified-hypothesis の Fail-Safe と同型）。

• 温度は既存軸のまま: 本規律を足しても、既存軸の沈黙・候補提示・自動改変しない・gate にしないという温度は保たれる（behavior-preserving・warn-only・INV49 の思想を継承・export/実装を止めない）。

• 検出結果を深刻度別（要修正 / 推奨 / 情報）の一覧で提示し、各指摘に深刻度とともに検査 ID（rules/validate-checks.md の表の ID 列）を併記する（例: 要修正 invariant-conflict: …）。

• 各項目に「根拠（ファイルと該当記述）」と「修正の提案（再実行すべきスキル or 修正方針）」を必ず添える。

• 未検証対象とその理由を明示し、スキップした検査は ID で特定する。

• 残った Open Questions を提示する。

• 自動修正は一切行わない。

Output Description

次工程の skill を案内する場合は、「intent-improve を実行して」のような自然文で伝える。共有 rule のスラッシュ記法は利用者向け出力へ転写しない。

出力先はターミナルである。 出力には raw HTML（<details> / <summary> 等の折りたたみ UI）を使わず、詳細は素の Markdown 見出しで区切って退避する（ターミナルでは生タグがそのまま表示され読めなくなるため）。[[...]]（memory / delta 用の wikilink 等）の内部記法は、delta / memory ファイルへの記録では正当だが、人向けのターミナル出力ではそのまま出さず普通の語に開く（リンク先の名前を自然文で綴る）。

読み手: 検出結果を見て是正するか判断する人間開発者。 この出力で最初に掴ませること: 「要修正が N 件・推奨が M 件。直すべきはこれ、再実行すべきコマンドはこれ」。検査 ID・未検証対象の列挙は判断材料の詳細なので、件数と要修正項目より後に置く。

出力は結論（件数と要修正）を先頭に立てる。

• 判定サマリ（先頭・1行）: 要修正 N 件 / 推奨 M 件 / 情報 K 件。要修正が 0 件なら「重大な問題なし」と明言する。
• 領域スコープの対象数（領域スコープで実行した回のみ・判定サマリの直後）: rules/domain-scope.md を適用して部分ロードした回は、読み込んだ記号数と全記号数を明示する（例:「並行 + always = 41 記号 / 全 829 を対象。compass-rule-decay は全記号を走査＝本質的例外」）。無指定で全量読みした回は添えない（従来どおり）。
• 要修正の一覧（次）: 各項目に検査 ID + 根拠（ファイルと該当記述）+ 修正の提案（再実行すべきスキル or 修正方針）。読み手が最初に手を付けるべき塊。
• 詳細: 推奨 / 情報レベルの検出一覧（同形式）、未検証対象（スキップした検査の ID を含む）とその理由、人間が確認すべき Open Questions。
• 修正の提案には次に実行すべきコマンドを含める（例: intent-compass の再実行）。
• coinage-suspect の指摘では、修正の提案欄に正規語への言い換え・統合の更新案（寄せ先の正規語、または妥当な寄せ先が無ければ台帳への正規語追加の検討）を添える。提示のみで自動改変せず、反映は人が承認してからの別アクションとして扱う。
• groundless-conclusion の指摘では、修正の提案欄にどの根拠（理由・制約・前提・トレードオフ）が辿れないかと訂正可能性の観点（その結論が否定する事実が来たとき再評価できるか）を添える。根拠の補完は更新案の提示のみで自動改変せず、記入は人が承認してからの別アクションとして扱う。
• unverified-hypothesis の指摘では、修正の提案欄にどの仮説（暫定の確信）に証拠の裏が無いかと反証/未検証の観点（.intent/ の証拠と矛盾しないか・裏取りに何の証拠が要るか）を添える。groundless-conclusion（結論の根拠欠落）とは別欄として分け所見を混ぜない。証拠の補完は更新案の提示のみで自動改変せず、記入は人が承認してからの別アクションとして扱う。
• dangling-reference の指摘では、修正の提案欄にどの番号参照（Anti-direction N / INV N / DR N）の参照先が宙吊りかと復旧の観点（参照先が退避・統合・削除のどれで消えたか・元の項目を本体へ戻すか参照を現役の番号へ張り替えるか）を添える。既存3軸とは別欄として分け所見を混ぜない。参照の張替えは更新案の提示のみで自動改変せず、記入は人が承認してからの別アクションとして扱う。
• invariant-oracle-missing の指摘では、修正の提案欄にどの Invariant に検査オラクル（破れたと分かるものさし）が紐づいていないかと付与の観点（機械テスト・手順のどちらで「破れたと分かる」か・付けられない思想的制約なら「ものさし無し」と明記するか）を添える。既存4軸とは別欄として分け所見を混ぜない。オラクルの付与は更新案の提示のみで自動改変せず、記入は人が承認してからの別アクションとして扱う。
• invariant-impact-reverse の出力では、各項目にどの変更ファイルがどの Invariant の影響パスに一致したかと、その Invariant に**オラクルが付いていれば確認手立て（ものさし）**を添える（「この変更は INV N に触れる → 確認はこのものさしで」）。これは検出の指摘でなく逆引きの案内ゆえ、修正提案でなく「触れる Invariant の確認を促す」案内として出す。誤検知前提（影響パスが粗ければ無関係も拾う）で断定せず、export/実装は止めない（warn-only）。
• compass-rule-decay の指摘では、修正の提案欄にどの Invariant/DR がどの類型（前提崩れ / 死蔵 / 遺物参照）で陳腐化しているかと整理の観点（前提崩れなら本文・影響パスを現実に合わせて更新するか規律ごと退避するか・死蔵/遺物参照なら現役の担い手が本当にいないか再確認のうえ intent-improve で再整合するか）を添える。(a) 前提崩れは個別に根拠の逐語引用付きで、(b) 死蔵 / (c) 遺物参照は既定で件数サマリ1行（個別列挙は利用者要求時のみ）。既存の staleness / 整合系軸とは別欄として分け所見を混ぜない。整理は更新案の提示のみで自動改変せず、記入・退避は人が承認してからの別アクションとして扱う。

報告の平易さ点検（利用者向け報告・出力直前・共通）

利用者へ向けた報告（進捗・完了・確認事項の提示。ターン末尾の要約を含む）を出す直前に、次を点検する（INV105・DR208）。対象は利用者向けの報告文だけで、内部の記録（.intent/ 配下の canonical・ログ）の書き方には適用しない。

• 内部文書の文をそのまま転写しない: 直前に読んだ・書いた内部成果物（tree・compass・packet・Open Questions）の文面は内部の語彙で書かれている。報告では、その内容を初見の読み手に通じる言葉で言い直す（事実・意味は変えない）。
• 識別子を本文の主語にしない: 確認事項・作業単位を示すときは、まず「何を・なぜ」が単体で通じる一文を置き、識別子（Open Question 番号・packet 名・記号・工程名）はその後ろに参照として添える（例: 「…を確かめてから始めてください（整理番号: OQ-xxx-1）」）。平易化のために識別子・記録への参照を削らない（記録へ辿れなくなる）。
• 通じるかの合図: 1文に未説明の内部語が3つ以上並んだら詰め込みすぎの合図（機械カウントではなく意味の読みで）。単体で通じなければ、平易に書き直してから出す（事実・意味は変えない）。
• 比喩・曖昧な言い方だけで意味を渡さない: 報告の土台は正確さ（意味が一意に読める記述。平易さはそれを保ったまま易しく書く手段）。基準のない程度語（「かなり」「うまく」等）だけで結果を伝えず、観測できる事実で書く。比喩を使うなら直後に正確な言い直しを必ず併記する（確立された専門用語・世間の意味のままの一般語は無理に開かない）。
• この点検は事後の記録と対で働く（予防だけで閉じない）: 報告が通じなかった実例は、drift-watch が on のとき drift-log へ症例として残し、次の予防に使う。

Safety & Fallback

• 読み取り専用: いかなるファイルも作成・変更・削除しない。修正は提案にとどめ、再実行すべきスキル or 修正方針を必ず添える。
• .intent/ 不在のみ停止条件: セットアップ手順を案内して終了する。
• 成果物の一部欠落は非ブロッキング: 検証可能な範囲のみ検査し、未検証対象と理由を明示する。
• mode.md 不在は停止せず standard 既定で続行し告知する。
• アプリケーションコードは変更しない（INV6。read-only のため書き込み経路自体を持たない）。
• 下流の spec 生成物（.kiro/specs/）は read-only で観測するのみで、書き換えない（INV1）。.kiro/specs/ が無い案件では draft-content-dropped をスキップし、他検査を続行する。