mcpField
V
vow-enforcement

vow-enforcement

github.com/atholaAgent 工作流34375 次安装1 天前更新
代码仓库

关于 vow-enforcement

vow-enforcement 是用于代码库的约束设计与审查技能，帮助团队决定规则应依靠指引、钩子还是外部验证。它按约束性质和违规情况划分三种执行层级，并定义升级、降级与阶段审查流程。

主要功能

  1. 01划分软规则、硬规则和 Nen Court
  2. 02依据违规情况升级约束
  3. 03用验证器审查阶段产出
  4. 04支持用户覆盖审查结果

适用场景

  1. 01为代码库设计新约束
  2. 02检查现有规则的执行缺口
  3. 03决定规则应采用钩子还是技能
  4. 04在工作流阶段审查验证结果

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/athola/claude-night-market --skill vow-enforcement

安装后在 Claude Code 中输入/vow-enforcement确认已加载。

详细介绍

依赖意志力的规则在压力下会失效。 通过让正确的路径成为唯一的路径， 强制执行才能赢得信任。

誓约强制执行

问题

ODCV-Bench 发现，当目标发生冲突时，Agent 有 30-50% 的概率违反自我设定的约束。实践者的共识也证实：软性规则超过 150 条后，所有规则的合规率都会下降，不仅仅是新规则。

核心观点是：“settings.json 是防火墙；CLAUDE.md 是员工手册。”员工手册适用于指导，防火墙适用于强制执行。混淆两者会造成虚假的安全感。

三个强制执行层

层级机制合规率示例
软性誓约技能说明、CLAUDE.md 规则~80%“先编写测试”，“保持提交小而精”
硬性誓约钩子（PreToolUse/PostToolUse）、settings.json 权限~100%禁止 --no-verify，强制执行文件大小限制
念能力审判庭审查输出的外部验证 Agent确定性Lint 检查、测试运行、约束审计

软性誓约依赖模型合规。添加成本低、迭代容易，但在目标冲突时并不可靠。当约束需要判断、违规虽恼人但不危险，或者你仍在摸索正确规则时，请使用软性誓约。

硬性誓约通过钩子和 settings.json 权限，在禁止的操作执行前将其拦截。当约束是二元的、违规会造成实际损害，或者软性誓约版本屡次被违反时，请使用硬性誓约。

念能力审判庭会在阶段完成后启动外部验证 Agent 来审计输出。当约束需要分析（而非模式匹配）、钩子无法表达规则，或者检查需要代码库上下文时，请使用念能力审判庭。

誓约分类流程

添加新约束时，请按以下顺序操作：

步骤 1：从软性誓约开始

将规则添加到相关技能或 CLAUDE.md 中。这是成本最低的做法：零成本，几分钟即可部署，合规率约为 80%。

步骤 2：监控违规率

通过执行日志、事后审计（imbue:justify 报告）、用户投诉，以及念能力审判庭在相关审计中的发现来跟踪违规情况。

步骤 3：视需要升级

如果 30 天窗口内的违规率超过 20%：

  • 二元约束？ 升级为硬性誓约（钩子）。
  • 判断型约束？ 升级为念能力审判庭。
  • 不明确？ 先尝试硬性誓约。如果误报超过 10%，则改用念能力审判庭。

夜市誓约清单

现有约束的当前分类：

约束当前层级目标层级备注
铁律（没有失败测试不得实现）念能力审判庭念能力审判庭validators/iron_law.py 审计提交顺序 (#406)
禁止 --no-verify硬性硬性已可通过钩子强制执行
范围守卫价值评分软性软性需要判断，非二元
工作证明证据念能力审判庭念能力审判庭validators/proof_of_work.py 检查 [Ex] 引用和状态 (#406)
有界发现读取硬性硬性vow_bounded_reads.py 使用 fcntl.flock 确保并行安全 (#418)
提交中不得出现 AI 归属说明硬性硬性钩子对 git commit 命令进行模式匹配
Markdown 行宽限制为 80 个字符念能力审判庭念能力审判庭validators/markdown_wrap.py 标记超过 80 个字符的正文行 (#406)
提交中不得使用表情符号硬性硬性钩子对 git commit 命令进行模式匹配
验证器调用

三个念能力审判庭验证器都是位于 plugins/imbue/validators/ 下的独立脚本。每个脚本从 stdin 读取 JSON，并将 判定 JSON 写入 stdout，使用退出码 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 视为提示。

誓约毕业标准

满足以下任一条件时，誓约即可毕业：

  1. 频率：30 天内检测到 3 次或更多违规
  2. 严重性：单次违规导致回滚、 数据丢失或 CI 故障
  3. 用户升级要求：用户明确要求 强制执行（“让 X 不可能发生”）
毕业流程
  1. 用证据记录违规模式
  2. 设计钩子或验证器 Agent
  3. 单独测试强制执行机制
  4. 与软性誓约一起部署（影子模式）
  5. 连续 1 周没有误报后，停用 软性誓约
降级

硬性誓约可以降级为软性誓约，条件如下：

  • 钩子的误报率超过 10%
  • 约束过于激进（阻碍 合理的工作）
  • 底层问题已不再适用

Nen Court 协议

Nen Court 在任务编排器生命周期的阶段边界运行：

  • specify 之后：验证规格的完整性
  • plan 之后：验证计划的可行性
  • execute 之后：验证 Iron Law、增量偏向、 工作成果证明
  • pr-prep 之前：执行最终合规审计
验证器 Agent 契约
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：软性誓约层。价值评估 属于判断，应由技能处理。
  • imbue:proof-of-work：混合式强制执行。 证据规则属于软性约束；证据内容可由 Nen Court 验证器 验证。
  • imbue:justify：事后 Nen Court 审计。 它已作为验证器 Agent，用于检查增量偏向、 Iron Law 和测试突变。
  • Mission Orchestrator：在阶段间设置 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 - 本技能管理的 论述层（誓约执行决定哪些原则从技能 晋升为钩子）
  • imbue:scope-guard、imbue:proof-of-work、 leyline:additive-bias-defense - 软性誓约示例， 誓约执行会对其进行分类并可能将其晋升
  • 查看 docs/quality-gates.md#skill-level-quality-gate-composition 了解本技能管理的联邦机制

完成标准

  • 为每项正在审查的约束分配且仅分配一个 执行层（软性誓约、硬性誓约或 Nen Court），并记录 分类理由
  • 对 30 天内违规 3 次或更多的任何软性誓约评估 毕业标准：二元约束晋升为硬性誓约， 判断类约束晋升至 Nen Court
  • 在阶段边界调用的 Nen Court 验证器通过 退出代码 0、1、2 返回三种判定结果之一 （pass、violation、inconclusive）；除非用户明确覆盖， 退出代码 1 会阻止阶段推进
  • 记录任何从硬性誓约降级为软性誓约的情况， 并注明误报率（>10%）或 已不再适用的具体问题

评论

支持 Markdown