audit

監査

調整ループを実行しています。成果物は設計とガバナンスに適合しているでしょうか。また、すべてのギャップは、調整に入る前に意識的に処置されているでしょうか。

監査ステージでは、RV 種別（RV-NNN）のレビューレジャーを使います。共通のレジャーの仕組み（オープンとプライム、起票、処置と解決、重大度と処置の語彙、統合、クローズゲート、レビューの実施場所）は lib:reference/review-ledger.md に記載されています。必ず読んでください。このスキルでは動詞を繰り返し説明しません。 以下では監査のレンズについて説明します。つまり、観点、モード、スコープ、調整ループで求められるエビデンス、そして監査固有の収集とクローズの手順です。

指摘事項はレジャーに追記のみで記録し、その所有権は各フィールドにあります。未解決のブロッカーがあると、監査→調整および調整→完了の移行が拒否されます（クローズゲートの要件です）。それ以外のすべての指摘事項を終端状態まで進めることは、このスキルの規律であり、バイナリの要件ではありません。監査の説明文は、レビューの ## Synthesis になります。

ディスパッチされたスライス — 生のエビデンスではなく、候補サーフェスをレビューしてください。 スライスが /dispatch によって駆動された場合、review/* と phase/* は不変のエビデンス参照（R2）です。監査／修正は、doctrine dispatch candidate create によって公開された候補インタラクションブランチに対して実施します（doctrine dispatch candidate status を参照）。レビューしたサーフェスをレジャーの ## Brief に記録し、doctrine dispatch candidate admit --review RV-NNN で承認を行った RV へのリンクを記載してください。

入力：

• スライスの実装済みフェーズとその検証エビデンス
• design.md（正本）、slice-nnn.md、plan.toml
• 関連する ADR と技術仕様（/canon を参照）

ツールの優先順位

利用できるハーネスに MCP レビューツールがある場合は、CLI よりもそちらを優先してください（lib:reference/review-ledger.md § Passing prose）。review unlock と review paths は CLI 専用のままです。

監査のレンズ

対象は常にスライスです — ターゲットラダーの第 1 段階です。 監査では対象のスライス（--target）を監査し、説明文に対象を格下げすることはありません。クローズグレードのトリガーは定義上満たされています（スライスの audit→reconcile→done をゲートします）。対象をあらためて導出しないでください。スライスを対象として RV をオープンしてください。

観点は reconciliation です。 このステージで調査するライフサイクル上の側面です。姿勢がある場合は、--raiser に指定し、新しい観点として追加しないでください（lib:reference/review-ledger.md §2）。

監査モード — 次のいずれかを選びます。

• conformance — スライスに紐づく、実装後の監査（通常はこちらです）。
• discovery — バックフィルまたは既存コードの調査。

セルフ監査（通常はこちらです）。 レビュアーと作成者を兼ねる場合は、--as <role> を使って両方の役割を担います。起票者は起票、検証、異議申し立て、再開、取り下げ、結論付けを行い、応答者は処置と修正を行います。役割はエージェントではなく行為に属します。--as は協調的な役割の表明であり、セキュリティ境界ではありません（lib:reference/review-ledger.md、「行為と役割」）。

処置の規約（監査固有）。 使用できる処置語彙については、lib:reference/review-ledger.md §4 を参照してください。仕様／ガバナンス関連項目に follow-up を使用してはいけません。それらはバックログではなく、調整の書き込みサーフェスに属します。すべての指摘事項は verified で終了します（観察事項が確認済みであることを示します。委任された指摘事項は、ブリーフの項目が作成された時点で確認済みとなります）。修正対応は調整で行い、別途記録します。指摘事項を fixed／remediated に変更しないでください。

プロセス

1. スライスのレジャーをオープンする（audit.md の作成に代わるものです）。スライスを対象とする reconciliation 観点の RV をオープンし、次にレジャーの ## Brief に、監査の観点（監査で調査する内容と、スライスに求める不変条件）を記入します。動詞とフラグについては lib:reference/review-ledger.md §1–§2 を参照してください。簡単なメモだけではクローズグレードの作業として不十分です。指摘事項はレジャーに記録します。 次にプライムします（lib:reference/review-ledger.md §2）：review prime はスライスのセレクターからパスセットを導き出し、台帳の古さを示すシグナルはそのパスセットをハッシュ化します。なくなったのは、手作業で管理していた古い domain_map（不要な作成コスト）であり、prime 動詞ではありません。記録されたソース差分から算出される slice conformance（ステップ 2）の機械的なドリフトシグナルは、prime を置き換えるのではなく補完します。

2. 証拠を集める（監査における分岐作業）：

   • 対象を準備する：プライマリチェックアウトのブランチを切り替えないでください。監査はコードがある場所、つまりプライマリツリー、ディスパッチ調整ツリー、リンクされたワークツリー、または採用済みカプセルツリーで実施します。その場で監査とクローズを行い、その後に取り込みます。レビューの書き込みを拒否されるのはディスパッチワーカープロセスのみです。1つの RV に対して同時に書き込めるのは1人です（lib:reference/review-ledger.md §6、「レビューの実施場所」）。

   • doctrine slice conformance <id> を実行し、その代数的な結果を読む — design.md で宣言された内容（design-target セレクター）と、git が実際に変更した内容（記録されたソース差分）の間にある、機械的なパス適合性の差分です。次の3つのセルが報告されます：

     • 未宣言（最も強いシグナル） — 編集されたものの、どの design-target セレクターにも含まれないパスです。それぞれが指摘候補です。スコープの逸脱、設計の更新漏れ、または文書化されていない変更の可能性があります。
     • 未実施 — 実際の編集に一致しなかった design-target セレクターです。宣言されたものの実施されていない作業、つまり作業の取り下げや古くなった設計を示します。
     • 適合 — 一致したパスの数です（それぞれに対応するセレクターがあります）。

     適合性は必要条件であり、十分条件ではありません。示すのは「どこを調べるべきか」であり、「合格かどうか」ではありません。未宣言／未実施は処置を検討する手掛かりとして扱い、自動的に指摘事項にしないでください。unavailable（レジストリが空）または incomplete（完了したフェーズに行がない）が報告された場合、その不足自体が指摘事項です。フェーズの完了時にレジストリが記録されていません。doctrine slice record-delta <id> PHASE-NN --start <oid> --end <oid> で初期登録するか、網羅範囲が部分的であることを記してください。部分的なレジストリを問題なしと見なしてはなりません。

   • 設計と計画で求められるテスト／チェックを実行し、さらに doctrine check gate を実行します。

   • design.md およびフェーズの VT- 基準に照らして、観測された動作を確認します。

   • 動作と設計が異なる箇所を記録します。各相違点が指摘事項です。

3. lib:reference/review-ledger.md §3–§4 に従って、すべての指摘事項を台帳に登録し、処置を決定します。 逃げ道を許さない圧力を維持してください。仕様／ガバナンスに関する指摘事項に follow-up を選んではなりません。調整ブリーフへのリンクを付けて design-wrong として処置し、登録者はブリーフの項目が作成された後に確認します。コードに関する指摘事項では、修正が大規模であるという理由だけで follow-up を選んではなりません。正当な根拠なしに tolerated としてはなりません。また、クローズゲートを避けるために真の blocker を格下げしてはなりません。design.md とガバナンスを読んでも適切な対応経路が不明な場合は、作業を止めて /consult してください。

4. まとめる。 監査の判断根拠をレビューの ## Synthesis として記述します（review-NNN.md に追記します）。クローズに至る経緯、残存するリスク、意識的に受け入れたトレードオフを記します（以前の audit.md に記載されていた文章です）。

5. 調整ブリーフを作成する。 review-NNN.md に専用の ## Reconciliation Brief セクションを追記し、## Synthesis とは分けます。これは監査から /reconcile への構造化された引き継ぎであり、仕様／ガバナンスに関する各指摘事項と、その対応先および書き込み対象を対応付けます：

   ## Reconciliation Brief
   
   ### Per-slice (direct edit)
   - design.md §3: the eviction model changed from edge-at-a-time to per-SCC —
     update prose to match implementation.
   
   ### Governance/spec (REV)
   - ADR-NNN: branch-point staleness description is wrong → REV modify
   - REQ-NNN: cordage scale target verified at 50k nodes → REV status active
   

   設計またはガバナンスに関わる、整合していない、または許容されていない指摘事項をすべて基にして、ブリーフを作成します。書き込み対象ごと（スライス単位の直接編集とガバナンス／仕様の REV）にまとめます。各項目には指摘事項 ID を記載し、必要な変更を具体的に説明します。 ブリーフの対象面に関するガードレール。 /reconcile が書き込むのは、直接編集するスライス単位の成果物（design.md、slice-NNN.md）と、REV 経由のガバナンス／仕様という、正確に 2 つの対象面だけです。ライターのスキルが実際に変更する対象面を指定してください。そうでないと、ブリーフは reconcile で行き詰まります。

   • 計画の基準は対象面外です。 plan.toml の EN-/EX-/VT-（および PHASE-NN）ID は追記のみで不変（起動時のルール）であり、reconcile で直接編集する対象面ではありません。計画の基準を変更しないと解消できない差異は、設計／計画へのエスカレーションであり、「スライス単位（直接編集）」のブリーフ項目ではありません。plan.toml を編集するブリーフ項目は書かないでください。
   • 適合性の検出結果では、文章ではなくレジストリの動詞を指定します。 「誤った未配信／スコープクリープ」という適合性の検出結果は、slice conformance が読み取る（slice-NNN.toml）セレクターレジストリ（doctrine slice selector rm／add）で修正します。design.md §6 は人間向けのミラーにすぎません。文章だけのブリーフ項目では、適合性の問題は解消されません。変更の要となるものとして slice selector の動詞を指定し、§6 の編集はそのミラーとして記載してください。

   人間向けの統合。 監査に重要な内容が含まれる場合は、関係するシステムの概要、重要な動作とその実装、関連するテスト、残るリスクを、人間がたどれるよう簡潔に示してください。判断で引用する重要な Doctrine ソースについては、それぞれがなぜ重要なのかを示し、正確な doctrine <kind> show <ID> コマンドを記載してください。より詳しい確認が役立つ場合は、必須とせずに /walkthrough または /pair を提案してください。人間がどのリスクを懸念しているかを尋ねると、統合内容の改善につながる場合があります。尋ねた場合は回答を活用し、理解度確認に変えないでください。実際の検出結果が裏付けている場合は、判断のリハーサルや根拠の検証に、短い模擬ピアチャレンジを任意で活用できます。情報源と、異議が過去のものかシミュレーションかを明確にしてください。新たな実質的な欠陥は RV 台帳に記載してください。人間が質問に答えられるかどうかは、検出結果でも受け入れ条件でもありません。プロジェクトのエンゲージメントに関する既定値と、人間が口頭で伝えた変更を尊重してください。

6. 収集（監査の末尾）。 破棄されるランタイムのフェーズシートから、長期的に残すべきリスク、判断、注意点を監査固有の視点として notes.md に集約し、その後、lib:reference/harvest.md に従って残りの収集（legs と sinks）を進めます。

7. reconcile への引き継ぎ。 調整ブリーフを作成し、すべての検出結果を終端状態にしたら、提起者としてパスを終了します — doctrine review conclude RV-NNN --basis …（または review_conclude）を実行し、監査で調べた内容を記載してください。これにより review status は done · await=none になります。その後に提起または再オープンされた場合は終了状態が解除されるため、その後に再度終了してください。続いて /reconcile に引き継ぎます。/close に直接引き継いではいけません。調整後の正となる情報を書き込めるのは reconcile だけであり、close は結果を確認するだけです。ライフサイクルの移行を記録してください： doctrine slice status <id> reconcile（数字のみ）。ブロッカーが未解消の場合、バイナリはこれを拒否します。

成果

• 監査証拠は構造化された RV 台帳（review-NNN.toml と、レビューの ## Synthesis および ## Reconciliation Brief）であり、手作りの audit.md ではありません。
• すべての検出結果には明示的な処置が記載され、終端状態になるか、取り下げられています。また、パスは --basis を指定して終了しています。
• 未解決の blocker は残っていません。残っていれば、close-gate に拒否されます。
• 調整ブリーフでは、すべての仕様／ガバナンス上の検出結果について、対象と書き込み面を対応付けています。
• /reconcile には、未加工の検出結果ではなく、完全で実行可能なブリーフを渡します。