# 判据：通过 / 失败

用于评分人（或后续自动化 rubric），**不是**给盲测 agent 的提示。

## 总原则

- **Spawn 盲测的价值**在于暴露文档含糊，不在于「复述文笔好」。
- 若 spawn 复述完美且零 blocker，而人工仍能从文档里挑出未定义边界 → **文档未过关**（或盲测指令被污染了上下文）。
- Fork 复述完美 **不能**当作文档清楚的证据。

## Pass（文档侧，针对含糊 fixture 修复后 / 清晰版）

对 `fixtures/design-clear.md` 或已修订的文档，spawn 复述应：

1. 两段复述覆盖：**提议做什么** + **按文档，现有系统怎么工作**。
2. 关键默认值、存储位置、可见范围、回滚/失败路径等关键边界（清晰版已写明的那些）。
3. Blocker 列表为空，或仅含文档明确标成「Out of scope / TBD」且已指向决策人的项。
4. 「未定义术语 / 未写明 setup」清单为空，或仅含文档已链接的外部词条。

## Fail（文档侧 / 复述侧）

任一成立即记 fail 信号：

1. **漏抓歧义**：`expected-ambiguities.md` 中的关键项，spawn 复述既未当 blocker，也未在「未定义术语/假设 setup」中列出。
2. **臆造边界**：复述写进了文档未出现的默认值、存储、权限或回滚策略，并当作既定事实。
3. **静默脑补术语**：使用项目黑话却说「文档已说明」，而原文无定义、无链接。
4. **上下文污染**：本应 spawn-only 的 run 实际带了父会话摘要 / fork 历史（复述「完美」但 expected 歧义全漏）。
5. **改文件**：盲测 agent 修改了仓库（协议要求只读）。

## Spawn vs fork 对照判据（本 Lab 核心）

| 观察 | 解读 |
|------|------|
| Spawn 标出多项 blocker；fork 零 blocker 且复述流畅 | **符合预期**：fork 测不出含糊；以 spawn 为准改文档 |
| Spawn 与 fork 都标出相同关键歧义 | 文档含糊足够明显；仍以改文档为先 |
| Spawn 与 fork 都「完美」且 expected 歧义存在 | **盲测失效**（提示词/上下文/文件给错）或评分纸与文档不一致 |
| 仅 fork 标出歧义、spawn 未标 | 异常——检查 spawn 是否其实读到了额外材料 |

## 评分人检查清单（含糊 fixture）

对 `design-ambiguous.md` 的一次合格 spawn 复述，至少应触达 `expected-ambiguities.md` 中 **≥ 70%** 的「必须抓住」项（blocker 或未定义清单任一即可）。低于该比例 → 记为弱检出，优先检查是否上下文泄漏，再检查文档是否「假含糊」（其实写清了）。