FFS — 摩擦 → 修复 → 防护
利用会话摩擦来改进约束。当用户第二次必须重复某个纠正时，说明行文说明已失效，机械性防护措施可能是必要的。
架构
不要构建另一个规则生成器。使用现有的层级：
- 提取 — 一个对Agent会话转录进行确定性挖掘的工具，用于发现重复的用户纠正，并将每个纠正与之前的助手动作和之后的纠正动作配对。（对于基于 AgentsView 的设置，像
avmine.py rules这样的提取器可以做到；任何 JSONL 转录存储都可以用同样的方式挖掘。） - 分类 — 判断失败是否可机械检测。
- 生成与验证 — 将一组证据传递给约束现有的规则生成路径（例如
/omfg样式的命令），而不是重新实现它。 - 实施 — 将接受的输出保存为项目规则（
.omp/rules/<name>.md）或全局规则（~/.omp/agent/rules/<name>.md）。 - 验证 — 对规则引擎测试正面和负面示例；之后重新挖掘转录以确认纠正不再重复。
何时将摩擦变为规则
仅当全部条件成立时才创建规则：
- 用户至少两次纠正了同一行为，或者一次纠正伴随明确的安全后果。
- 违规行为在助手文本或工具参数中可机械识别。
- 无需猜测上下文即可说明安全的替代方案。
- 没有现有规则已经涵盖该模式。
否则将其路由到其他位置：
| 失败类型 | 归宿 |
|---|---|
| 可检测的命令、路径、标志或输出短语 | 规则 |
| 需要判断的多步流程 | 技能 |
| 稳定的偏好或原则 | AGENTS.md |
| 工具事实或过程 | 笔记 / 项目知识 |
| 一次性的历史纠正 | 日志 / 源记录 |
挖掘步骤
首先运行确定性提取器。如果不可用，搜索原始转录中的纠正短语并检查周围的助手轮次；不要仅从纠正本身推断违规行为。
对每个候选记录保留：
- 确切的用户纠正和时间戳
- 项目和稳定的会话ID
- 助手命令/文本刚好在其之前
- 纠正后的命令/文本刚好在其之后
- 跨不同逻辑会话的重复次数
- 建议的范围：项目或全局
- 正面测试（必须触发）
- 负面测试（不得触发）
不要使用自动生成的会话摘要作为证据。它们会转述和重复。请使用原始转录消息和工具调用。
规则生成交接
将投诉连同具体的之前/之后配对交给现有规则生成器，该生成器已经：
- 生成规则候选
- 验证其条件是否匹配助手历史
- 提供项目 vs 全局范围选择
- 允许在保存前修改
不要在提取器或本技能中重复该机制。
验证
对每个接受的规则，通过规则引擎（例如使用 OMP 的 TTSR）运行一个负面用例和一个正面用例：
omp ttsr test --rule <绝对规则路径> --source tool --tool <工具> '<错误输入>' -v
omp ttsr test --rule <绝对规则路径> --source tool --tool <工具> '<正确输入>' -v
第一个必须触发，第二个不得触发。一个阻塞安全路径的规则比没有规则更糟糕。
一周后，再次挖掘同一个纠正。零重复是规则起作用的证据。重复意味着条件遗漏了实际形式；请根据证据修改，而不是盲目扩大范围。
参考示例："puttys pls"
转录显示连续两天出现相同的纠正。在此之前，会话在远程测试台主机上运行不透明的一行 SSH/exec 命令，没有可见的终端。在此之后，它们通过命名的 putty-* 包装脚本启动可见的终端会话。
由此产生的项目规则（<project>/.omp/rules/visible-putty-operations.md）捕获了不透明的命令路径，允许可见的包装器，并获得了历史纠正事件的支持——三轮证据，而不是猜测。