# 规则闸门咬合度体检 —— 服务样品（供评议）

> **状态**：供评议样品。不是订单、不是报价、不是对外发布稿；不含任何客户事实。
> **制作日**：2026-10-31 ｜ **读者**：方法所有者本人（评议用）
> **材料来源**（全部为本仓真实文件，只读）：`AGENTS.md`、`docs/工程规范/RULE-LIFECYCLE-STANDARD.md`、`docs/rules.json`、`ops/rules_check.py`、`ops/data/rules-check.json`（检查时点 2026-10-31 20:07:22）、`ops/data/gate_firings.jsonl`
> **外发限制**：样品内含内部仓名与内部路径，未脱敏不可外发。

---

## 0 一句话

把「我定了一堆规矩，但说不清哪条真在拦人」变成一张能当场判 **加机检 / 改判据 / 降级或删除** 的表。

---

## 1 服务定义（最小服务单元）

**暂名**：规则闸门咬合度体检（名字待你定，此处仅作指代）

| 项 | 内容 |
|---|---|
| 买方拿到的结果 | 对每条约定给出一个处置判断：它被机检咬住过吗？咬对了吗？该加、该改、还是该退 |
| 交付物 1 | 规则台账：分层（不变量/标准/实验区、护栏/轨道）+ 触发原因有无 + 机检映射 + 出处 |
| 交付物 2 | 咬合度表：窗口内运行次数、拦截次数、持续天数、集中度（必须带分母） |
| 交付物 3 | 三条落轨建议：每条含触发原因、落地判据、执行人 |
| 交付物 4 | 限制页：本报告不能推出什么 |
| 不交付 | 不写业务代码；不代改规则正本；不做 CI/流水线搭建；不联系你的团队或客户；不做合规与法律判断 |

**为什么是服务而非课程/工具**（条件陈述，不是成本排序）：判断依赖具体仓的规则集与历史流水，每个仓规则集差异大；目前没有稳定的规则 DSL 可复用，工具化要等这层稳定；课程无法替买方判「哪条该删」。

---

## 2 样品正文（对本人仓库实做，窗口 2026-09-26 → 2026-10-31）

### 2.1 材料与窗口

- 拦截流水 18,995 条运行记录，覆盖 21 个仓、48 条规则，时间 2026-09-26 至 2026-10-31（36 天）。
- 当日机检结果：17 个受检仓，正常 9 / 异常 8。
- 规则声明 `docs/rules.json` 共 7 条；这与流水里出现的 48 条规则不一致 —— 因为机检有**两条通道**：`rules.json` 声明的一条，和各仓 `ops/*.py` 自带自检（如 `ports.py check`、`products.py check`）挂日循环的另一条，两者没有统一登记。

### 2.2 方法（四步，各有产出）

1. **清点**：把所有成文约定列出来（`AGENTS.md` 8 个章节 + 各 `*-STANDARD.md` 正本），产出待判清单。
2. **分层**：按 `RULE-LIFECYCLE-STANDARD` 归到不变量 / 标准 / 实验区，并标护栏或轨道，产出分层台账。
3. **接闸**：核每条约定当前挂在哪条机检上（`rules.json` 的 `check` 字段，或 `ops/*.py` 的自检），产出「有闸/无闸/半闸」。
4. **看咬合**：以拦截流水为证据，算每条规则在窗口内「跑了几次、拦了几次、连续几天拦、是否集中在同一处」，产出咬合度表。

### 2.3 台账抽样（9 条，覆盖三类层与两种通道）

| # | 约定 | 层/类型 | 触发原因是否写着 | 机检挂点 | 窗口内咬合 |
|---|---|---|---|---|---|
| 1 | AGENTS.md 体积上限 13500B | 标准 | 只有阈值，无触发原因 | `rules.json: agents-md-budget` | 75 次 FAIL，跨 23 天连续 |
| 2 | 文档三档布局 | 标准 | 有正本 `DOC-LAYOUT-STANDARD.md` | `doc-three-tier-layout` | 54 次 FAIL |
| 3 | 根目录禁放图片 | 护栏 | 只有模式 `/*.png/` | `root-media-forbidden` | 30 次 FAIL |
| 4 | 流程图与代码防漂移 | 标准 | 唯一带 `note` 说明的规则 | `doc-flows-fresh` | 340 次 FAIL，占全部失败 55.6% |
| 5 | 新模块须由脚手架生成 | 轨道 | 唯一写了 `exemptReason` 的规则（附 3 条具名豁免） | `pdgen-modules` | 10 次 FAIL |
| 6 | 节点须申报闸门 | 轨道 | `notes` 里逐节点写豁免理由（语义域不设闸） | `workflow-node-declarations` | 0 次 FAIL |
| 7 | 端口先登记后使用 | 护栏 | 有正本 + 日期 + 豁免须带 reason | `ops/ports.py check`（**不在 rules.json**） | 未进流水 |
| 8 | 密钥不落地 | 护栏 | 写在「运营数据纪律」，无触发原因字段 | `ops/secret_scan.py` 存在，**是否挂日循环待核** | 未进流水 |
| 9 | 渠道写操作先过闸 | 轨道 | 写在 AGENTS.md，判据另见正本 | `ops/channel_check.mjs`（人工闸，无自动机检） | 未进流水 |

> 第 7–9 行是本次体检最该给买方看的三行：**越硬的护栏越容易落在流水之外**。这条判断只对本仓材料成立，不外推。

### 2.4 咬合度（带分母）

| 指标 | 值 |
|---|---|
| 总运行记录 | 18,995 |
| FAIL 记录 | 611（3.22%） |
| 出现过的规则数 / 曾咬到过的规则数 | 48 / 10（**38 条 36 天内零拦截**） |
| 「仓×规则」对数 / 零拦截对数 | 234 / 210（89.7%） |
| 失败集中度 | 前 5 条规则占全部 FAIL 的 90.7% |

前 5 条：`doc-flows-fresh` 340、`agents-md-budget` 75、`kit-rust-kit-declared` 55、`doc-three-tier-layout` 54、`root-media-forbidden` 30。

### 2.5 三条结论

**结论 1：闸门的分辨率不均，多数规则没有被检验过。**
证据：48 条规则中 38 条 36 天零拦截；234 个「仓×规则」对里 210 个零拦截。强度：**中**。三种解释同时存在且本材料不能区分 ——（a）规则被持续遵守，闸门在起预防作用；（b）规则测的是几乎不变的面，跑一万次也不会响；（c）规则已失效或指向的代码路径不再存在，没人发现。

**结论 2：真咬到的几乎都是「机械一致性」类，不是业务正确性。**
证据：前 5 条全部是文档-代码漂移、体积、目录布局、媒体文件位置这类可机械判定的项；而节点闸门大量豁免的理由清一色是「语义判断，工具判不了」（`ops/data/rules-check.json` 的 notes 段）。强度：**强**（两处独立材料互证）。含义：想用机检扣住「做没做成」，方向本身是错的，应先分层再谈接闸。

**结论 3：同一处反复咬 = 告警噪音，不是拦截力。**
证据：`agents-md-budget` 从 2026-09-29 到 2026-10-31 连续 23 天 FAIL、共 75 次，规则阈值至今未变；`doc-flows-fresh` 在单个仓最高 97 次 / 17 天。强度：**强**（数据直接支持），但「为什么没被处置」**未知** —— 材料里没有复审记录，不能断言没做过复审。可推断的只是：按 `RULE-LIFECYCLE-STANDARD` §4 应有的季度降级/删除动作，在这 33 天窗口内没有留下可见结果。

### 2.6 不能推出的（限制页，本次样品共 4 条）

1. **FAIL 次数 ≠ 事故次数**。流水是「每仓每次运行记一条」，75 次 ≈ 同一未修项被记 23 天，不是错了 75 次。
2. **零拦截 ≠ 规则无效，也 ≠ 规则有效**，见结论 1 的三种解释。
3. **窗口内含规则集变更**，前后规则与阈值不完全可比；跨窗口的趋势不能当结论。
4. **单机、单组织、36 天**，不构成对其他团队或其他技术栈的基准；本报告不含任何外部对比数据。

### 2.7 三条建议（各含触发原因 + 判据 + 执行人）

| 建议 | 触发原因（防什么坑） | 落地判据 | 执行人 |
|---|---|---|---|
| S1 给「零拦截」规则加一次归因 | 38 条规则零拦截，无法区分「被遵守」和「已失效」，剪枝无据 | 每条零拦截规则补一行：触发原因 + 上次真咬日期 + 判定（保留/降级/删除） | 规则所有者 |
| S2 反复咬同一处超 7 天自动转 WARN | 告警连续 23 天无人处置，闸门退化成噪音，团队开始无视红点 | 同一「仓×规则」连续 FAIL ≥7 天 → 状态降 WARN 并进周检待办 | 机检维护者 |
| S3 把流水外的护栏接进统一台账 | 端口、密钥、渠道三条硬护栏不在同一流水里，越硬越看不见 | `rules.json` 之外的自检项全部登记进同一份台账，缺一即报缺口 | 机检维护者 |

---

## 3 范围与排除

**含**：读买方指定的仓内成文约定、机检声明、CI/日循环挂点、历史拦截日志；全量清点规则条目；对不少于 8 条规则做深度判定；出四件交付物。

**排除**：语义类规则的自动判定；跨组织/跨语言基准对比；多仓集群的持续监控服务；代改正本或代写代码；合规、法律、安全渗透判断；对外发布稿的撰写。

---

## 4 验收标准（每条可判 pass/fail）

| 编号 | 判据 | 不通过的样子 |
|---|---|---|
| A1 | 每条结论带出处（文件 + 行号，或数据字段 + 时点） | 出现无出处的主张 |
| A2 | 台账覆盖率 100%：清点到但未进表的条目，须写明未进表原因 | 有静默漏项 |
| A3 | 咬合度表必须带分母（窗口长度、运行次数、样本仓数） | 只给次数或百分比 |
| A4 | 每条建议含「触发原因 + 落地判据 + 执行人」三要素 | 缺任一要素 |
| A5 | 限制页不少于 3 条「不能推出」的结论 | 只有免责套话 |
| A6 | 未知项标「未知」，不出现补造的客户名、预算、人数、期限 | 任一推断被写成事实 |

---

## 5 修改边界

- **含 1 次范围内修改**：限于现有材料与现有规则集内的事实纠错、表达、排序、表格增列。
- **不含**：新增数据窗口或新增仓、新增读者版本（对外版/客户定制版）、把诊断改写成实施方案、追加第二条服务线。
- **新增范围**另立差异记录，不并入本次；原范围继续有效。
- 你的原件（`AGENTS.md`、各正本、日志）全程只读，我不改；我改的只是我产出的这份稿。

---

## 6 缺项（不补造，如实标未知）

| 缺项 | 状态 |
|---|---|
| 买方是谁、是否只有一个人需要 | 未知 |
| 价格、周期、可承接容量 | 未知（本次未核算，也未设上限） |
| 你是否已在别处提供过同类服务、有无既有约定 | 未知 |
| 这条方法能否对外交付（涉密/内部数据边界） | 待你判；本样品用了内部仓名，未脱敏不可外发 |
| 外部团队是否真存在这个痛点 | 未知；本样品只证明方法可跑通，不证明有需求 |
| `ops/secret_scan.py` 是否已挂日循环 | 待核（本次未查挂点） |

---

## 7 下一步（二选一，不自动安排）

- **A**：拿一个外部仓（或脱敏副本）重跑一遍，验证方法在别人的规则集上是否同样成立 —— 得到的是「可复用性」证据。
- **B**：先在本仓把 S2、S3 落成机检改动，再谈对外 —— 得到的是「我自己在用」的证据。

两者都不改变本样品的范围与验收；选哪个只决定下一份证据是什么。