vow-enforcement

意志の力に依存するルールは、プレッシャーの下で破られます。 強制によって信頼を獲得するには、正しい道を 唯一の道にします。

誓約の強制

問題

ODCV-Bench によると、目標が相反する場合、エージェントは自ら課した制約を 30〜50% の頻度で破ります。現場の専門家の総意も、ソフトルールが 150 を超えると、新しいルールだけでなく、すべてのルールへの遵守率が低下することを示しています。

核心となる洞察は、「settings.json はファイアウォールであり、CLAUDE.md は従業員ハンドブックである」ということです。ハンドブックは指針として機能します。ファイアウォールは強制手段として機能します。この2つを混同すると、誤った安心感が生まれます。

3つの強制レイヤー

レイヤー	メカニズム	遵守率	例
ソフト誓約	スキルの指示、CLAUDE.md のルール	約 80%	「まずテストを書く」「コミットを小さく保つ」
ハード誓約	フック（PreToolUse/PostToolUse）、settings.json の権限設定	約 100%	--no-verify をブロックする、ファイルサイズの上限を強制する
念能力審判所	出力をチェックする外部バリデーターエージェント	決定論的	Lint チェック、テスト実行、制約監査

ソフト誓約はモデルの遵守に依存します。追加コストが低く、簡単に反復できますが、目標が相反する状況では信頼性に欠けます。制約に判断が必要な場合、違反しても危険ではなく単に煩わしい場合、または適切なルールが何かをまだ模索している場合に使います。

ハード誓約は、フックと settings.json の権限設定を通じて、禁止された操作の実行を事前にブロックします。制約が二者択一である場合、違反が実害をもたらす場合、またはソフト誓約が繰り返し破られた場合に使います。

念能力審判所は、フェーズ完了後に出力を監査する外部バリデーターエージェントを起動します。制約に分析が必要な場合（パターンマッチングでは対応できない場合）、フックではルールを表現できない場合、またはチェックにコードベースのコンテキストが必要な場合に使います。

誓約の分類プロトコル

新しい制約を追加する場合は、次の手順に従います。

手順 1：ソフト誓約として開始する

該当するスキルまたは CLAUDE.md にルールを追加します。これが最も低コストな方法です。コストはゼロで、数分で導入でき、遵守率は約 80% です。

手順 2：違反率を監視する

実行ログ、事後監査（imbue:justify レポート）、ユーザーからの苦情、関連する監査での念能力審判所の指摘を通じて違反を追跡します。

手順 3：必要に応じて昇格する

30 日間の期間における違反率が 20% を超えた場合：

• 二者択一の制約ですか？ ハード誓約（フック）に昇格します。
• 判断が必要な制約ですか？ 念能力審判所に昇格します。
• 曖昧ですか？ まずハード誓約を試します。誤検知が 10% を超える場合は、念能力審判所に移行します。

Night Market 誓約の一覧

既存の制約の現在の分類：

制約	現在のレイヤー	目標のレイヤー	備考
鉄の掟（失敗するテストなしで実装しない）	念能力審判所	念能力審判所	validators/iron_law.py がコミット順を監査します (#406)
--no-verify の禁止	ハード	ハード	すでにフックで強制可能
スコープガードの妥当性スコアリング	ソフト	ソフト	二者択一ではなく、判断が必要
作業証明の証拠	念能力審判所	念能力審判所	validators/proof_of_work.py が [Ex] 参照とステータスをチェックします (#406)
読み取り探索範囲の制限	ハード	ハード	並列実行の安全性を確保するため、fcntl.flock を使う vow_bounded_reads.py (#418)
コミットでの AI 帰属表示の禁止	ハード	ハード	フックが git commit コマンドをパターンマッチングします
Markdown の行を 80 文字で折り返す	念能力審判所	念能力審判所	validators/markdown_wrap.py が 80 文字を超える文章行を検出します (#406)
コミットでの絵文字の禁止	ハード	ハード	フックが git commit コマンドをパターンマッチングします

バリデーターの呼び出し

3つの念能力審判所バリデーターは、plugins/imbue/validators/ にある単独実行スクリプトです。それぞれ標準入力から JSON を読み取り、標準出力に判定 JSON を書き込みます。終了コードは 0（合格）、1（違反）、2（判定不能）です。例：

# Markdown wrap audit on a list of files
echo '{"files": ["README.md", "docs/guide.md"]}' \
  | python plugins/imbue/validators/markdown_wrap.py

# Iron Law audit on an explicit commit log
echo '{"commits": [
  {"sha": "abc", "ts": 100, "files": ["tests/test_x.py"]},
  {"sha": "def", "ts": 200, "files": ["src/x.py"]}
]}' | python plugins/imbue/validators/iron_law.py

# Proof-of-work audit on agent output
echo '{"text": "Tested foo [E1] [E2] [E3]. Status: PASS.", "min_evidence": 3}' \
  | python plugins/imbue/validators/proof_of_work.py

ミッションオーケストレーターとの統合：各フェーズの境界で適切なバリデーターを呼び出し（下記の念能力審判所プロトコルを参照）、終了コード 1 はブロッキングゲート、終了コード 2 は参考情報として扱います。

Vow の昇格基準

次のいずれかの条件を満たすと、Vow は昇格します。

1. 頻度：30 日間に 3 件以上の違反が検出された
2. 重大度：単一の違反によってロールバック、データ損失、または CI の障害が発生した
3. ユーザーによるエスカレーション：ユーザーが明示的に強制を要求した（「X を不可能にして」）

昇格プロセス

1. 証拠とともに違反パターンを記録します
2. フックまたはバリデーターエージェントを設計します
3. 強制メカニズムを単独でテストします
4. ソフト Vow と併せてデプロイします（シャドーモード）
5. 誤検知がない状態が 1 週間続いたら、ソフト Vow を廃止します

降格

次の場合、ハード Vow をソフト Vow に戻すことができます。

• フックの誤検知率が 10% を超える
• 制約が厳しすぎた（正当な作業をブロックしていた）
• 根底にある懸念が当てはまらなくなった

Nen Court プロトコル

Nen Court は、ミッションオーケストレーターのライフサイクルにおけるフェーズ境界で実行されます。

• specify の後：仕様の完全性を検証します
• plan の後：計画の実現可能性を検証します
• execute の後：Iron Law、加法バイアス、作業証明を検証します
• pr-prep の前：最終コンプライアンス監査を行います

バリデーターエージェントの契約

validator:
  name: iron-law-court
  constraint: "Tests must drive implementation"
  inputs:
    - git log with timestamps
    - diff of test files vs implementation files
  checks:
    - test file modified before implementation file
    - no test assertions changed to match output
    - coverage did not decrease
  output:
    verdict: pass | violation | inconclusive
    evidence: [list of specific findings]
    recommendation: [action if violation]

判定

判定	意味	アクション
pass	制約を満たしています	フェーズを進めます
violation	証拠を伴う制約違反です	修正されるか、ユーザーがオーバーライドするまでフェーズをブロックします
inconclusive	コンプライアンスを判断できません	人によるレビューのためにフラグを立て、ブロックはしません

ユーザーによるオーバーライド

ユーザーは Nen Court の判定をすべてオーバーライドできます。

• 「そのまま進める」または「オーバーライド」でブロックを解除します
• オーバーライドは今後の監査のために記録されます
• 同じ制約に対するオーバーライドが頻繁に発生する場合、強制を強めるのではなく、制約の見直しが必要であることを示しています

統合ポイント

• imbue:scope-guard：ソフト Vow 層です。適格性のスコアリングは判断を伴うため、スキルで扱うべきです。
• imbue:proof-of-work：混合型の強制です。証拠に関するルールはソフトですが、証拠の内容は Nen Court バリデーターで検証できます。
• imbue:justify：事後的な Nen Court 監査です。すでに、加法バイアス、Iron Law、テストのミューテーションに対するバリデーターエージェントとして機能しています。
• ミッションオーケストレーター：各フェーズの間に Nen Court のチェックポイントをゲートとして設けたフェーズルーティングです。

specify -> [Nen Court: spec review] -> plan
plan    -> [Nen Court: plan review] -> execute
execute -> [Nen Court: justify]     -> pr-prep

Nen Court が pass を返すか、ユーザーが明示的にオーバーライドしない限り、フェーズは進みません。

使用する場合

• コードベースに新しい制約を設計するとき
• 既存の制約に強制の抜けがないか監査するとき
• ルールにフックが必要か、スキルが必要かを判断するとき
• フェーズ境界で Nen Court の検出結果をレビューするとき
• 監査後に制約の昇格を提案するとき

使用しない場合

• 単一のタスクにのみ適用される一時的なルール
• すでにハード強制され、正常に機能している制約
• 制約によって学習が遅くなるような探索的作業

関連スキル

• imbue:karpathy-principles - このスキルが統制する議論的な層です（vow-enforcement は、どの原則をスキルからフックに昇格させるかを判断します）
• imbue:scope-guard、imbue:proof-of-work、 leyline:additive-bias-defense - vow-enforcement が分類し、昇格させる場合のあるソフト Vow の例です
• このスキルが統制するフェデレーションについては、docs/quality-gates.md#skill-level-quality-gate-composition を参照してください

完了条件

• レビュー対象のすべての制約が、分類の根拠を記録したうえで、いずれか 1 つの強制層（ソフト Vow、ハード Vow、または Nen Court）に割り当てられている
• 30 日間に 3 件以上の違反があったソフト Vow について昇格基準が評価されている：二値制約はハード Vow に、判断を伴う制約は Nen Court に昇格する
• フェーズ境界で呼び出される Nen Court バリデーターが、終了コード 0、1、2 を介して 3 つの判定（pass、violation、inconclusive）のいずれかを返す。終了コード 1 は、ユーザーが明示的にオーバーライドしない限り、フェーズの進行をブロックする
• ハード Vow をソフト Vow に戻す場合は、誤検知率（10% 超）または当てはまらなくなった具体的な懸念を記録している