# 阶段 5 R0 章节预协商协议（v0.3 P1-5）

**问题**: v0.2 R1 启动时，3 author 直接按"角色 → 章节"映射独立写。但**章节边界**经常有模糊地带：

- §9 风险既有架构风险又有实现风险，PM 觉得也该写商业风险——3 个人写重复
- §10 验收 PM 写场景，工程师写测试细节，但"5 维 AC"里"状态切换"算业务还是测试？——遗漏
- §5 工程师写界面元素表，但有些 UI 文案 PM 也写了——重复

**v0.2 解决方式**：靠 R2 互相 review 发现重复/遗漏，再 R3 修。**代价是 R2/R3 多消耗 token**。

**v0.3 改进**：R1 之前先开一个 **10 行的章节预协商会议**，明确每个 author 的章节"主笔/参与/不碰"边界。

---

## 协议

### 时机

阶段 5 R0 阶段，在 R1 派 3 author 写之前。

### 输入

- `{项目}/scene-anchor.md`
- `{项目}/proposal-v1.md`
- `{项目}/assumptions.md`
- `{项目}/debate-log.md`

### Controller 做的事

派一个**轻量级 author-coordinator agent**（用 general-purpose subagent），prompt：

```
你是 PRD 终稿章节预协商主持人。任务：根据本项目特点，给 PM/架构师/工程师 3 个 author 出一份"章节分工备忘录"。

读项目 V1 方案，决定每个章节谁主笔、谁副笔、谁不碰。

输出格式（≤ 15 行）：

| 章节 | 主笔 | 副笔 | 边界说明 |
|------|------|------|---------|
| §1 项目背景+收益 | PM | - | 业务收益必须有依据 |
| §2 用户画像 | PM | - | - |
| §3 算法/目标函数 | 架构师 | - | - |
| §4 数据需求+模型 | 架构师 | - | - |
| §5 详细功能 | 工程师 | PM 副笔界面文案 | 工程师写 5 列表，PM 副笔按钮文案 |
| §6 流程图 | 架构师 | - | - |
| §7 边界异常 | 工程师 | - | - |
| §8 成功度量 | PM | - | - |
| §9 风险与依赖 | 架构师写 9.A-C / 工程师写 9.D-F | PM 副笔商业风险 9.G | 不重复 |
| §10 验收标准 | PM 写 10.1-10.5（业务场景） / 工程师写 10.A-C（测试细节） | - | 边界：业务场景=用户行为；测试细节=自动化 |
| §11 依据清单 | PM | - | - |
| §12 附录 | 工程师 | - | - |

特殊情况：
- 本项目是 {功能型/策略型/架构型/修复型}，所以某些章节 ... 调整
- {V1 中有特殊需求的}
```

输出到 `{项目}/drafts/r0-chapter-negotiation.md`。

### 然后才启动 R1

R1 时 3 author 各自 prompt 里**强制引用 r0-chapter-negotiation.md**：

> "你的章节主笔范围以 r0-chapter-negotiation.md 为准。如果发现你被分到一个跟你能力不匹配的副笔章节（如工程师被分到副笔商业风险），请只写不超过 3 行的提示性内容，剩下让主笔补完。"

### 工作量

R0 多 1 个 Agent 调用（轻量，约 1-2K token）。但能省下 R2/R3 因为重复/遗漏带来的额外修订（典型可省 2-5K token）。**净收益**。

---

## 跟 v0.2 协议的兼容

v0.2 协议（STAGE5-COAUTHORING-PROTOCOL.md）的 R1/R2/R3/合并 流程不变。R0 是新增的"前置预协商"。

完整流程：

```
R0 预协商 → R1 独立写 → R2 互 review → R3 主笔修订 → Controller 合并 → R4 跨章节平滑 reviewer → 终交付
```