docs: 确认 C12（响应方式）和 E1（评测集复核方式）

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/architecture/m3-plan.md

@@ -189,6 +189,8 @@
 
 ### 第 2 步：投标侧结构识别和规则
 
+- 读标新增「响应方式」抽取（C12）：类别 × 方式 × 出处，规则优先；查标按响应方式决定「未找到响应」报不报、报什么级别。
+
 - `bid_structure`：偏离表、开标一览表、分项报价表、格式文件、资格证明附件；认不出时走兜底，并写进 `coverage`。
 - `rules` 模块：§2.4 的四组规则；需人工核对的条目和 `manual-checks` 接口。
 - 「报价」类清单项（C7）。
@@ -246,7 +248,7 @@
 | C9 | **新增：每条清单项的检查结论** | 新增 `check_item_result` 表（检查批次 × 清单项：结论、走的哪一层、投标侧出处、校验状态、原因码、token）。「已响应」也是 AI 结论，按红线 1、2 要能复核、能反馈；复查复用结果、覆盖范围也靠它。问题仍然只为没响应好的条目生成。需要新迁移，并同步 `data-model.md` |
 | C10 | **新增：扫描件投标文件** | 真实投标的资格证明、业绩合同多是盖章扫描件，OCR（S5）还没做，不处理的话会出一大片致命级「未找到」。MVP：候选分册里图片页占比超过阈值的条目，不出「未找到响应」，改出「该部分为扫描件，请人工核对」；资格类按名称回到资质库匹配；覆盖范围列出没有文字层的页码。S5 排在 M3 之后 |
 | C11 | **新增：检索方案** | 内存 BM25 + jieba（§2.2），改掉 `ref-bid-engine-analysis.md` §5.4 的 pg_trgm 写法 |
-| C12 | **待定（2026-11-04 新增）：每条要求怎么才算「响应了」** | 招标文件对响应方式的规定按类别不同（`evals/check/GUIDELINES.md` §2）：逐条响应、默认接受（只列偏离）、要证明材料（分投标时和中标后）、文件要在、平台内应答，同一份文件里常有几种，S07 还自相矛盾。建议：① 读标新增「响应方式」抽取，粒度是「类别 × 方式 × 出处」，规则优先、模型兜底，条款原文写了「提供……证明材料」的按条覆盖并记投标时 / 中标后；在清单页显示、可改，作为人工确认点。② 两处写法冲突时按更严的（逐条）处理，问题说明里同时引两处原文。③ 默认接受的要求没找到响应：一般要求记「按招标文件默认接受」、不出问题，结论带出处；实质性 / ★ 要求出「提示」级「请人工核对」，不出致命；正文里找到了不满足的值照常报。④ 证明材料是中标后提供的，投标时没附不报。⑤ 识别不出响应方式时按逐条处理（宁可多报），这一组「未找到响应」标明「招标文件未写明是否要求逐条响应」，写进覆盖范围；项目上给一个「本项目只列偏离」的开关，打开后这一组降为提示 |
+| C12 | **每条要求怎么才算「响应了」**（2026-11-04 新增，已按建议确认，decisions.md C12） | 招标文件对响应方式的规定按类别不同（`evals/check/GUIDELINES.md` §2）：逐条响应、默认接受（只列偏离）、要证明材料（分投标时和中标后）、文件要在、平台内应答，同一份文件里常有几种，S07 还自相矛盾。建议：① 读标新增「响应方式」抽取，粒度是「类别 × 方式 × 出处」，规则优先、模型兜底，条款原文写了「提供……证明材料」的按条覆盖并记投标时 / 中标后；在清单页显示、可改，作为人工确认点。② 两处写法冲突时按更严的（逐条）处理，问题说明里同时引两处原文。③ 默认接受的要求没找到响应：一般要求记「按招标文件默认接受」、不出问题，结论带出处；实质性 / ★ 要求出「提示」级「请人工核对」，不出致命；正文里找到了不满足的值照常报。④ 证明材料是中标后提供的，投标时没附不报。⑤ 识别不出响应方式时按逐条处理（宁可多报），这一组「未找到响应」标明「招标文件未写明是否要求逐条响应」，写进覆盖范围；项目上给一个「本项目只列偏离」的开关，打开后这一组降为提示 |
 | SK1 | 进度推送用 Valkey stream | 确认。补两处：发布用的客户端设短超时（现在 `valkey()` 没设，Valkey 挂掉时会卡住 worker，而不是只记日志）；SSE 连接池设上限 |
 | SK2 | 集成测试连 Compose 的 PostgreSQL | 确认。补三处：CI 直接跑 `init-roles.sh`，不再单独写一份建角色的 SQL；CI 加 Gotenberg；架构 §8 改掉 testcontainers 的写法 |
 

docs/decisions.md

@@ -4,6 +4,15 @@
 
 ---
 
+## C12、E1 · 2026-11-04 · 响应方式按建议处理；评测集挂问题的要求由另一个模型复核、用户抽查 20%
+
+| # | 决策 | 理由 |
+|---|---|---|
+| C12 | 按 `m3-plan.md` §7 C12 的建议：读标新增「响应方式」抽取（类别 × 方式 × 出处，规则优先、模型兜底，条款写了证明材料的按条覆盖并记投标时 / 中标后，清单页显示、可改）；两处写法冲突按逐条处理并引两处原文；默认接受的一般要求没找到响应不出问题、结论注明「按招标文件默认接受」并带出处，实质性 / ★ 出提示级「请人工核对」；中标后才交的证明材料投标时不查；识别不出按逐条处理，标明「招标文件未写明是否要求逐条响应」，项目上给「本项目只列偏离」开关 | 10 份样本里响应方式按类别不同、同一份文件常有几种，S07 自相矛盾（`evals/check/GUIDELINES.md` §2）；不区分会在默认接受的文件上大量误报致命问题 |
+| E1 | 评测集里挂了问题的要求（核对要求本身和响应方式），由另一个模型（Fable）复核，用户抽查 20%；不由用户逐条复核 | 节省用户时间。代价：读标阶段已经证明 AI 复核偏宽，评测结论要注明「金标准未经全部人工复核」；复核模型和写投标文件的模型（Opus）、查标模型（DeepSeek）都不同 |
+
+- **影响**：读标增加一项抽取（查标第 2 步做，和投标侧结构识别一起）；`check_item_result.verdict` 要加「默认接受」；评测报告的头条数字都带「金标准由模型复核、用户抽查 20%」的说明。
+
 ## C1–C11、SK1–SK2 · 2026-11-04 · 查标（M3）实现计划的待定事项：全部按建议，C1 补充真实样本
 
 依据 `docs/architecture/m3-plan.md` v0.2 §7。v0.2 是请 Fable 做顾问，深读参考项目的查标实现（`ref-bid-engine-analysis.md` §6），对照读标优化的教训重新评估后的结果。

evals/check/GUIDELINES.md

@@ -146,7 +146,7 @@
 2. **生成流程**：`build.py` 从读标正式清单和格式章生成规矩投标文件的结构化稿（`spec.json`）→ LLM 按风格改写表格行、补写散文 → `mutate.py` 注入问题、写响应清单 → `render.py` 渲染并回填位置。
 3. **渲染**：多数走 Chromium（HTML → PDF）；**至少 2～3 份走 DOCX → LibreOffice**（产品的真实路径），带合并单元格、多行单元格。资格证明、业绩合同中有一部分做成图片页，检验 C10。
 4. **自检**：冻结前用另一个模型跑一遍「找无意的偏离」，脚本扫一遍占位符和空表格，再由人抽查。
-5. **人工复核**：只复核**挂了问题的标注单元**（每份马虎的投标文件 25～40 个，20 份约 600～800 个）和各文件的响应方式记录；`ok` 的单元不复核。
+5. **复核**（决策 E1）：只复核**挂了问题的标注单元**（每份马虎的投标文件 25～40 个，20 份约 600～800 个）和各文件的响应方式记录，`ok` 的单元不复核。由另一个模型（Fable，和写投标文件的 Opus、查标的 DeepSeek 都不同）逐条复核，用户随机抽查 20%；抽查不一致的比例写进评测报告。所有评测结论都注明「金标准由模型复核、用户抽查 20%」。
 
 ## 6. 文件格式