# 义务表起草规约

> 本文件只解决一件事：`slop_audit_text` / `slop_obligation_audit` 需要一张**义务表**，而插件**不自己拆义务**。这里是拆法。

---

## 一、为什么不让插件拆

一句话：**从文档倒推出来的义务，是「最佳实践清单」，不是「任务要求」。**

用它判承接，每一份写得中规中矩的文件都会通过 —— 真正的任务缺口被洗成「已满足」。
这比「不出结论」严重得多：它给了一个看起来完整、实际无效的答案。

所以分工是固定的：

| 谁 | 做什么 |
|---|---|
| 你（或你的模型） | 按任务原话拆义务、判覆盖 |
| 插件 | 逐条复核引文是否真的在原文那一行、状态是否自洽、结论是否越权 |

**插件只有一种能力是 100% 可靠的：核对「原文里到底有没有这句话」。** 那份活交给它，其余的别交。

---

## 二、三条硬规则

1. **只从任务原话出发。**
   拆义务时**先不看交付件**。看了文档再拆义务，拆出来的一定是文档已写的东西 —— 那就永远查不出缺口。

2. **3–6 条。**
   少于 3 条会漏；多于 6 条开始挑刺，且清单本身会变成新的噪音源。

3. **每条都必须能被「有没有写出这件事」判定。**
   写不出判定标准的义务，不要写。判不了就别装成能判。

---

## 三、从任务原话到义务：三步

拿一句任务原话举例：

> 为新产品上线，尽快给一套渠道落地方案。

**第一步：找动词 —— 它要求交付什么动作**
「给一套方案」→ 要有一个可执行的方案，不是资料汇编。

**第二步：把名词性要求逐条摊开**
「渠道」→ 选哪些渠道；「落地」→ 怎么进得去；「尽快」→ 什么时候做完。

**第三步：补上「缺了就推不动」的东西**
谁做、花多少钱、什么条件下开始 —— 任务没写，但缺了这件事就停在纸上。
这类标 `essential`。

拆出来大致是：

| # | 义务 | 来源 |
|---|---|---|
| O1 | 首轮进哪几个渠道？给出明确清单，不是候选池 | explicit |
| O2 | 每个渠道的准入条件：哪些已确认、哪些待核实、谁去核 | explicit |
| O3 | 时间安排：分几批、各批起止与判定点 | explicit |
| O4 | 谁负责、首月资源口径、每个动作的启动条件 | essential |

---

## 四、三种来源

| origin | 什么时候用 | 判错会怎样 |
|---|---|---|
| `explicit` | 任务原话直接要求 | 用多了 → 变成挑刺 |
| `essential` | 任务没写，但缺了这件事就推进不了 | 用多了 → 同上 |
| `optional` | 加分项，不写不算缺陷 | 配 `critical: true` 会被校验直接拒绝 |

`critical` 只标「缺了就不能推进」的。关键义务缺失会直接触发「需返工」，不要滥用。

---

## 五、每条填什么

```json
{
  "id": "O1",
  "question": "首轮进哪几个渠道？",
  "origin": "explicit",
  "critical": true,
  "coverage": "conflicting",
  "evidence": [{ "quote": "逐字复制的原文片段" }],
  "finding": "原文怎么说 —— 一句话讲清问题",
  "impact": "对推进有什么影响",
  "repair": "要补什么",
  "resolutionTest": "怎样算补齐"
}
```

**`evidence` 的规矩最硬：**

- `quote` 必须是原文的**逐字连续片段**，包括 `**`、表格竖线、全角标点。
  少一个字、多一个空格、抹掉一个加粗符号 —— 都会被判「引文未通过复核」，该条判定随之作废。
- 至少 4 个有效字符。`P2` 这种代号不算证据（它会在长文里随机会命中）。
- `line` 可写可不写。写了会核对；不写插件自己找。**写错行号比不写更糟**：它会让读者去错的地方核对。

**`repair` 与 `resolutionTest` 的区别：**

- `repair` 说「补什么」
- `resolutionTest` 说「补到什么程度算过关」——这一句要能被人一眼判，不能是形容词

反面例子：`"每条动作补负责人和日期"` —— 补了姓名和日期，错误前提照样在。
正面例子：`"首个必要动作补齐五项：明确对象、责任人、时间安排、交付物、启动条件"`。

---

## 六、四条禁令

1. **不许看着文档写义务。**（见规则 1）
2. **不许把「最佳实践」当任务要求。** 「应该有风险分析」不是任务要求，除非任务这么说了。
3. **不许一条拆成好几条凑数。** 同一处缺陷被重复处罚，会让「缺口数」变成噪音。插件会报「疑似重复处罚」。
4. **不许凭印象写引文。** 记忆里的句子和原文差一个字符，整条判定就废。**复制，不要回忆。**

---

## 七、一次完整的往返

1. 你按上面的规矩拆出 3–6 条 → 调用 `slop_audit_text`（带上 `task` 与 `obligations`），或直接用 `slop_obligation_audit`；
2. 插件逐条复核引文、检查状态自洽、去重、出台账；
3. 台账给出：**需返工 / 部分满足 / 满足** 三档之一，以及每条缺口的「要补什么 + 怎样算补齐」；
4. 如果出现「引文未通过复核」——**先怀疑自己，不要怀疑文档**。十有八九是引文抄错了。

---

## 八、常见错法

| 症状 | 病因 | 改法 |
|---|---|---|
| 所有义务都是「满足」 | 义务是从文档倒推的 | 回到任务原话重新拆 |
| 缺口数特别多 | 拆得太细，或把最佳实践当义务 | 压到 3–6 条，`optional` 不算缺陷 |
| 引文频频对不上 | 凭记忆写，或抹掉了 markdown 符号 | 复制原文，包括 `**` 和 `|` |
| 结论是「暂定」 | 有关键义务的引文没通过复核 | 修引文，不要改结论 |
| 每条都写「要补什么」，但作者改完还是不能用 | `resolutionTest` 写成了填表要求 | 改成「补到什么程度就能直接推进」 |

---

> 本规约只约束**怎么拆义务**，不判断方案好坏。判文件不判人。