yyyyyhhhhh0639 规范执行 (Rule Enforcement) — 元层诊断
收敛层定位（2026-08-04 固化）
本技能是规范体系的最后一层——向下不建"元元层"，没有技能管本技能的执行。（"描述 ≠ 管"：references/ 等描述性文档组织已有规范，不构成"管本技能的执行"——不归因、不监督、不选修复手段）
- 正确用法：诊断失败实例 → 把规范折叠进现有执行点（流程步骤/模板/checklist），让执行靠流程推进而非靠"记得加载本技能"（记忆锚点/环境提示属触发补强——靠注入层可见性，不是事后回忆，不算"靠记得"）
- 错误用法：把本技能当作再建规则的理由（"rule-enforcement 说要管规范 → 再建一个规范技能"= 嵌套地狱）
- 自指约束：本技能自身的应用失败（如"忘记加载本技能"）同样是 L1 实例——用同一套模型归因，不需要第二层监督
- 数量红线：规范执行准确率与规则数量负相关；评估任何新规范先问"能折叠进现有执行点吗？"——不能则大概率不该建
- 越界信号（二维判定，2026-08-05 修正）：
- 性质维度——新建规范性文档（规则/管理逻辑/监督 RE 的技能）→ 越界，折叠更深；新建描述性文档（地图/索引，如 references/governance-architecture.md）→ 合法（不归因不监督）
- 使用维度——任何文档被当作规范引用（"文档说 X，所以必须 X"）→ 越界滑坡；缓解：描述性文档显式声明"地图非规则" + 引用时检查声明（与"本体 vs 索引摘要"同一判别机制）
When to Use
- 用户质疑"你没遵守规范/规则/约定"
- 自查发现应用失败（规范存在但没执行）
- 需要决定"规范为什么没执行 + 怎么修"（不是"再加一条规则"）
- 讨论规范体系本身的改进方向
核心模型：L0 / L1 两类归因（2026-08-04 修正版）
应用失败只有两类根因，四实例全部收敛于此（创建会话中用户质疑后修正）：
| 类 | 机制 | 典型实例 | 修复手段 | 信号 |
|---|---|---|---|---|
| L0 结构性 | 规则不可达（工具/系统层缺陷，提示词层免疫） | search_files 工具把 F:\ 转 /f/ 给 native rg |
工具层修复（patch 源码/配置），写规则无效 | 换了正确写法仍然失败；错误发生在工具内部 |
| L1 无意识遗忘 | 规则存在但决策时刻未检索（默认行为路径） | native 传 /f/、记忆判据未加载、lens 实证未分层 |
降低"依赖记得"：触发条件补强 / 判据流程化 / 操作化清单 / 主动前置 | 事后复盘"其实我知道这条规则" |
关键推论：
- 主战场是 L1（四实例中三例同属此类）——问题不是规则缺失，是加载失败
- "有意识违规"几乎不存在——违规本身即证明决策时刻未应用规则；事后引用规则是"追认"，不是"明知故犯"（判定：违规发生在引用之前 → L1）
- L0 是少数派，但修规则对它无效——先判别再选手段，避免"L0 问题用 L1 手段修"（写了规则也没用）
执行偏差的性质：
- 执行偏差是规范体系故障的信号，不是规范文本故障的证明——先归因，再修对应层
- 每个偏差必须个体归因（不能默认 L1，也不能默认文本问题）；归因前禁止直接修文本
- 规范设计定义：规范设计 = 文本 + 操作化 + 流程化 + 触发补强——评价标准是减少执行偏差，而非文本完备性；数量红线（准确率与规则数量负相关）即此标准的推论
规范体系四层修复框架：
| 组件 | 故障形态 | 修复手段 | 判定信号 |
|---|---|---|---|
| 文本 | 歧义/缺失/字面误导（"必存"无条件字面） | 修订文本（条件化） | 按字面执行后出错但规则可达 |
| 触发 | description 未覆盖决策时刻 / 索引截断 | 触发补强（场景词/锚定） | 事后才想起规则（分类先于触发） |
| 流程 | 判据是知识非步骤 | 操作化（N 步清单） | 知道但靠记性 |
| 工具 | 规则不可达（L0） | 工具层修复 | 换正确写法仍失败 |
实证：M2 判据审查宽松化 = L1（未加载判据）+ 文本歧义（"必存"字面）双因；反思未加载本技能 = 触发层（分类先于触发，description 补"反思复盘"场景词）
层选择原则：优先寻找可机械化的强制点（精确匹配/正则/限额/路径检测）→ 工具化（确定性执行）；半机械化（关键词级）→ 流程化 + 事后审计；语义（频率/价值/场景分类）→ 流程清单 + 审计兜底。规范执行可靠性 = 可机械化程度的函数——实证：磁盘验证因 memory() substring 匹配可机械化而确定性执行；判据四问因语义不可机械化而概率执行（本会话两次失败）。设计新规范时先问："哪部分可机械化？"——能工具化的优先工具化，只把不可工具化的留给流程。
诊断流程（应用失败时）
1. 定位失败实例（被质疑的 / 自查发现的）
2. 判别类：换正确写法仍失败 / 工具内部行为？ → L0
事后才想起规则 / 引用发生在违规之后？ → L1
3. L1 → 按"决策时刻缺什么"选手段：
缺触发（不知道何时该用） → 补触发条件：技能 description 纳入"决策时刻"场景
缺流程（知道但靠记性） → 判据流程化：写入前强制自检清单（如 memory 四问）
缺操作（判别表是知识非步骤）→ 操作化：调用前 N 步检查清单
缺时机（等质疑才执行） → 主动前置：默认先执行，不等被要求
4. 落盘（技能/记忆）+ git 追溯 + 验证下次生效——知识增量保存：内容级查重已覆盖 → patch 现有，不新建（见 session-knowledge-capture ④）
预防清单（固化≠执行）
- 固化不等于执行——规范写进技能/记忆只解决"存在性"，不解决"加载率"；每次落盘后问：决策时刻会被触发吗？
- 主动前置：下结论先分层、写记忆先跑判据、查重先内容级对比——默认先执行，不等被质疑；被动响应是应用失败
- 调查完整性：引用历史会话/文档前，确认覆盖了修正记录（如创建会话中对初始分类的修正）——只引用初始版本会固化错误（本次会话实证）
- 每轮失败实例记入对应落点的 provenance，形成"失败→修复→复发→再修"的迭代链（档案留痕，非预防机制——预防靠折叠进执行点；L1 失败者与档案读者群不相交，见 references/l1-failure-patterns.md）
与其他技能的分工（避免重复）
| 技能 | 职责 | 边界 |
|---|---|---|
rule-enforcement（本） |
诊断归因 + 修复手段选择（为什么没执行） | 元层诊断 |
execution-governance |
行为协议（审批门控/可验证声明/SOUL-USR 边界） | 怎么执行任务 |
session-knowledge-capture |
会话→知识落盘（含主动前置、证据层级原则） | 沉淀侧 |
memory-storage-management |
记忆价值判据四问 + 容量治理 | 记忆域规范 |
hermes-agent-skill-authoring |
SKILL.md 写作规范（frontmatter/描述预算/正文形态/内容级查重） | 形式层——管所有技能怎么写（含本技能）；不归因执行失败 |
curator |
技能生命周期（stale/归档/合并） | 资产维护，不做行为审计 |
规范体系全貌（分层/职责矩阵/监督关系/落盘链路/触发速查）：见 references/governance-architecture.md。
Pitfalls
- 把 L0 当 L1 修——工具层缺陷写规则无效；先判别"换正确写法是否仍失败"
- 把"事后引用"当"有意识违规"——引用发生在违规之后 = L1，不是明知故犯
- 引用初始版本不查修正——调查历史会话必须滚动覆盖后续纠正消息（作者自身已复发两次，证据链见 frontmatter provenance）；归因时确认引用的是本体（skill_view 加载）还是索引摘要（见 references/l1-failure-patterns.md）
- 规范体系无限膨胀——L1 主战场下，新增规则是低效手段；优先触发补强/流程化/前置
- 自查 ≠ 等他问——用户质疑前自己发现并归因，才是主动前置
- 引用规范前先验证磁盘当前状态——系统提示中的 USER.md/MEMORY.md 快照冻结于会话开始，磁盘文件可能已被用户手动修改/删除（2026-08-05 实证：审计 A2A 会话时引用已删的 R3 日期戳条目，违反"先验证再引用"）。审计历史行为、引用任何规范前：先读磁盘当前内容，不信任会话内快照
Verification Checklist
- 失败实例已归因（L0 或 L1，有判别证据）
- 修复手段与类匹配（L0→工具修复；L1→降低依赖记得）
- 落盘位置明确 + git 追溯 + 触发条件覆盖决策时刻
- 调查引用覆盖修正记录（不只初始版本）
- 未与 execution-governance / memory-storage-management 重复造轮