/clause-gate — 新規条項の誕生ゲート

規範文書（CLAUDE.md / .claude/rules/**）に条項を追加・移動・削除するときに通す 薄い順序表。判断ロジックは本 skill に実装しない —— 判定に使う 4 軸・基質適合テスト・ 繋留 3 分類は既存資産（docs/specs/m-1-opus5-migration/design.md §5.2 / §5.2.4）が正本であり、 本 skill が持つのは順序と記録先だけである。

• 設計 SSOT: docs/artifacts/clause-gate-routing-design-2026-07-26.md（v0.3）
• 台帳: docs/artifacts/clause-gate-ledger.md
• 機械検査: .claude/tests/rules/test_clause_gate_ledger.py

本ゲートは「追加を止める機構」ではない。 主契機は上記 pytest（出口の不動点）であり、 ゲートを経ずに常駐面を変えるとテストが落ちる。本 skill はそのとき何を判断し どこに記録するかの手順である（設計 §4.3）。

---

Step 0. 前提の確認

• 既存条項の再採点には使わない。 本ゲートはフロー（新規条項）専用である。 M-1 出口宣言 (a)(b) により、consolidation 系の棚卸しは再実行しない
• 対象が「規範文（守るべきこと）」か確認する。事実の記録・観測値・retro の知見は 条項ではない（それぞれ model-roster.md / docs/artifacts/ / knowledge 層が受け皿）

Step 1. 機構テスト → R3（決定的機構）

3 条件をすべて満たすか:

1. 機構が検査する入力にスキーマ契約がある（漂流する非構造入力を追わない）
2. exit-code 級の機械判定で合否が出る
3. 意味解釈が不要

• すべて YES → R3。docs/artifacts/clause-gate-ledger.md §C に 3 列（トリガのスキーマ出典 / 判定コマンド / 同時更新義務）を記録する。同時更新義務が「有」なら R3 に置けない（rule-002 型の恒常税を新規に作らないため）→ Step 2 へ
• 1 つでも NO → Step 2 へ

軸 3 = 不可逆ガードが R3 に入る場合は、R1 と二重化する（設計 §1.3 / 機構の沈黙を知る規範を残す）。

Step 2. 到達必要性テスト → R1 / R2

design.md §5.2.4 の繋留 3 分類を使う。

繋留先	判定
ファイル繋留（書式 / 規約 / parser 保守）かつ軸 3 = 可逆	R2（下記 3 要件を満たすこと）
イベント / フェーズ / コマンド繋留	R2 不可 → Step 3 へ
軸 3 = 不可逆ガード	R1（条件ロードは構造的に間に合わない）

R2 の 3 要件（連言 / 1 つでも欠けたら R2 に置けない）: (i) ファイル繋留である (ii) 実際の配送先を明記する（paths: glob / skill 名 / agent 名）(iii) 軸 3 = 可逆。

R2 に置いた条項が実は全域で必要だった場合、次の違反が検出イベントとして立ち、 R1 へ昇格する。この昇格は予算を消費しない（誤配の是正に予算を課すと是正が抑止される / 設計 §3.2）。ただし §B に「誤配の是正」と明記すること。

Step 3. 基質適合テスト → R5（却下）

「Opus 5 は指示なしでこれをやるか」

• YES → R5。書かない。旧基質（Opus 4.x 以前）での発火実績は新基質での必要性の証拠にならない
• NO → Step 4 へ

例外: 問うているのが「内側の検査」か「外部との突合」かで分岐する。自己検証（内側）は 基質が既定で行うため R5 に落ちるが、仕様・テストとの突合（外部）は機構でしか担保できず落ちない （M-1 Keep 2 の実測: 21 条項中 16 件が無効化されたが TDD 系 4 件は全件保全）。

Step 4. 軸 4（根拠） → R4 / Step 5

検出イベント数は trust-model.md §カウント単位（1 検証イベント = 1 カウント）で数える。

• 0 件 → R4。台帳 §D に記録して待つ。§D は台帳内にあるため、次にゲートを通すとき目に入る
• 1 件以上 → Step 5 へ

Step 5. 形式を決める（R1 内の形式）

配布列の 1 問（R1 に決まった場合のみ / D-1 決定 D5 / 2026-08-13 追加）:

この条項は私の環境・予算・他プロジェクト・個人名を参照するか → Yes なら docs/private/ へ（R1 に置かない）、No なら .claude/rules/ へ

これは新規条項が生まれる瞬間の 1 回の判定であり、既存条項の定期再判定ではない （時計を持たない = FR-5 / WC-11 に抵触しない）。

条件	形式
帰属がモデル固有の事実	SSOT 退避 = model-roster.md へ（新規ファイルを作らない）
軸 2 = 列挙	圧縮 = 意図 1 行に畳み、根拠は docs/artifacts/ へ
軸 2 = 意図	保全 = 原文のまま

Step 6. 予算処理（R1 に入る場合のみ）

R2 / R3 / R4 / R5 は予算を消費しない。R1 に入る場合のみ以下を実行する。

1. 台帳 §A の TOTAL を読む
2. 交換レートを決める:
   • TOTAL > 80 → net-negative（1 行追加 = 2 行退出）
   • TOTAL ≤ 80 → 1 対 1
3. 退出させる条項を選ぶ。交換相手の制約: 別途の理由で既に削除が決まっている条項は使えない （死に条項の備蓄を防ぐ / 設計 §3.2）
4. 退出先を決める（R2 降格 / R3 機構化 / R4 退避 / R5 削減）

Step 7. 記録して検査する

1. 台帳 §B に取引 1 行を追加（入場 1 行 + 退出 1〜2 行）
2. 条項を実ファイルに反映（PM 級: CLAUDE.md / .claude/rules/** は承認ゲートを通る）
3. 台帳 §A の該当ファイルの指令数と TOTAL を更新
4. 検査を回す:

bash .claude/scripts/py_invoke.sh -m pytest .claude/tests/rules/test_clause_gate_ledger.py -q

§A が動かない出入りもある。 指令カウントは RFC 2119 級キーワードの出現数であり、 箇条書き 1 行の削除は §A に現れない（2026-07-26 実測: phase-rules.md の退出は 12→12）。 §A は天井ゲージ、§B が通貨である。§A が動かなくても §B の記録は省略しない。

権限等級

• 本 skill の変更: SE 級（.claude/skills/ は .claude/rules/ ではない）
• 台帳 §A の指令カウント定義の変更: PM 級（通貨の定義変更）
• 判定 4 軸・決定木・基質適合テストの変更: PM 級（docs/specs/ の改訂）

参照

• docs/artifacts/clause-gate-routing-design-2026-07-26.md（設計 v0.3 / 判定順序 §2 / 通貨 §3 / 残る弱点 §8）
• docs/specs/m-1-opus5-migration/design.md §5.2（4 軸 / 決定木 / 基質適合テスト）/ §5.2.4（繋留 3 分類）
• docs/artifacts/retro-M1-2026-07-26.md §出口宣言 3 点
• docs/artifacts/hga-summon-log.md #18（routing 軸の根拠）/ #19（設計の敵対レビュー）
• .claude/rules/auto-generated/trust-model.md §カウント単位