# 风险与待决

> 列出 7 个最值得在动工前讨论清楚的风险点。每条给出对策或留作待决的备选方案。

## 风险全表

| ID | 风险 | 影响阶段 | 对策状态 |
| --- | --- | --- | --- |
| R1 | 无限循环（L2 改 SDD → 又失败 → 再改） | P3 | ✅ 有预算 |
| R2 | Agent 把 Bash 玩坏（inline JSON） | P2 起 | ✅ 已写入 prompt |
| R3 | 集成测试套件谁来写 | P3 | ✅ 初版方案 A |
| R4 | PRD/SDD 的 HTML diff 算法 | P4 | ⚠️ 初版粗粒度 |
| R5 | 与现有 EvolutionLoop 的关系 | P2 | ✅ 抽公共函数 |
| R6 | 跨 Unit 的命名 / 约定漂移 | P3 | ✅ Architect 强制后缀 |
| R7 | Token 成本失控（无限 retry × Opus） | P2 起 | ⚠️ 需配置全局上限 |

## 逐条展开

### R1 · 无限循环风险P3

**场景：**L2 失败 → 改 SDD → 再失败 → 再改 SDD…

**对策：**三层预算守护

- 每 unit retry ≤ 5 次（L1 内）
- 每 PRD rev 内 L2 修复轮次 ≤ 3 轮
- BugTriager confidence < 0.5 立即上报 L3

超出 → 项目挂起，发 SSE，等人类介入。绝不静默丢弃。

### R2 · Bash 中 inline JSONP2 起

参见 `CLAUDE.md` L91-99。所有需要带 JSON body 的命令必须先写 `/tmp/*.json` 再 `curl -d @file`。

**对策：** 1. 在 Coder / Tester / Integrator 的 system prompt 中强制声明铁律 2. 沙箱层 hook 检测 `-d '{...}'` 模式直接拒绝 3. Bash 工具增加 `jsonGuard` middleware（约 30 行）

### R3 · 集成测试谁来写P3

三种方案对比见 [L2 页 · 集成测试套件从哪来](loops-l2.html)。**初版选 A：Architect 同步产 integration/spec.json**，理由：

- 少一个 Agent，少一次握手
- spec 与 SDD 同源演化，不会脱节
- Architect 已经 Opus，能力够

若 P3 实测发现 Architect 写 spec 质量差，回退到方案 B 单独加 IntegrationAuthor。

### R4 · PRD/SDD diff 算法P4 · 待决

HTML 结构化 diff 比纯文本难。**初版策略：**section 级粒度，按 `data-rev` 属性区分新旧（每个 section 要么完全新，要么完全旧）。这避免文本级 diff 算法的复杂度。

**已知限制：**同一 section 内修改不会高亮，只能整段标 changed。

**P5+ 升级：**引入 `diff-dom` 做精细化 inline diff。但需要先看 P4 实测是否够用。

### R5 · 与 EvolutionLoop 的关系P2

EvolutionLoop（在 `packages/evolution/`）负责 Skill 进化，是另一套独立系统。DevLoopController 负责工程化代码开发。**两者不交叉**。

唯一耦合：`retryWithReflection()` 抽到公共包供两者共用。从 `evolution-loop.js` 抽出约 80 行代码，外部接口保持不变。

### R6 · Unit 命名漂移P3

BugTriager 输出 affected_units 是 string[]，靠字符串匹配 UnitRegistry。如果不同轮 Architect 用 `auth-be` / `auth-backend` / `auth-server` 三种风格，归因会丢。

**对策：**Architect 强制后缀（参见 [Architect · ④ Unit 拆解策略](agents-architect.html)）。Schema 校验同时强制 `id =~ /^[a-z]+(-[a-z]+)*-(be|fe|mw|db)$/`。

### R7 · Token 成本失控P2 起 · 待决

5 次 unit retry × 多 unit × 3 次 L2 修复 × Opus 模型 = 单项目可能烧几十刀。

**对策：** - project.json 加 `token_budget` 字段（默认 5M tokens / 项目） - LoopController 每次 callAgent 后累计，超出立刻挂起 - Tester 默认 Haiku（最便宜） - Dashboard 实时显示已用 token 与剩余预算

具体阈值由 P2 实测 token 消耗后再定。

## 开放问题

以下是**没在本 PRD 给答案**的问题，需要在 P1 启动会前敲定：

1. **多人项目 / 协作：**同一项目能不能两个人同时发 L3 反馈？目前默认是「队列化」，但 UI 怎么显示？
2. **代码归宿：**项目 shipped 后，`units/*/code/` 要不要自动提个 GitHub PR？还是留在 LemonBoss 文件系统里？
3. **跨 Unit 共享库：**R6 提到的 `shared/` 在 P1~P4 留空。但「auth utils 给所有 Unit 共用」是个真实需求，要不要提前到 P3？
4. **外部依赖（npm 包）安装权限：**Coder 跑 `npm install` 安装新包是否允许？目前默认禁，但很多前端 Unit 实际需要。
5. **失败后人工 takeover：**项目 blocked 后，人类能否在 Dashboard 里**手动编辑**某个 Unit 的代码再 resume？这要不要算 L3 的一种 action？

> _这五个问题不阻塞 P1 启动，但建议在 P3 前给答案。_

## 下一步

**动工前最后一关：**你（Yibo）读完整套 PRD，回复以下三个 yes / no：

1. 三层 Loop 的边界划分是否准确？特别是 L2/L3 之间的「失败时先修文档」是否同意？
2. 六个 Agent 的拆分粒度可以接受吗？有没有应该合并或拆细的？
3. 四阶段排序 P1→P4 是否合理？是否要把 UI 提前？

都 yes → 开 P1 PR。任一 no → 回来改这份 PRD 再说。