docs: 查标实现计划 v0.2，确认 C1–C11、SK1–SK2；参考项目查标深读

- m3-plan.md：请 Fable 当顾问深读参考项目的查标实现、对照读标教训复评后的计划。
  先建评测集再写规则（金标准是虚构投标文件的响应清单）；每条清单项留带证据的结论；
  成本靠按章节打批、硬预算和复查复用控制；认不出、没查的都写进检查覆盖范围。
- decisions.md：C1–C11、SK1–SK2 全部按建议确认；用户的真实国动投标文件作为留出集，第 3 步冻结代码后再用。
- ref-bid-engine-analysis.md：新增 §6 查标深读；§5.4 的检索方案改为内存 BM25。

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

docs/decisions.md

@@ -4,6 +4,28 @@
 
 ---
 
+## 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），对照读标优化的教训重新评估后的结果。
+
+| # | 决策 | 理由 |
+|---|---|---|
+| C1 | 评测集按 `m3-plan.md` §4 自己写：用招标文件自己的格式章写虚构投标文件，同时写「响应清单」作为金标准，按招标文件整体留出，人工只裁定开发集上响应清单漏记的问题。**补充**：用户有一份真实的国动小程序投标文件，作为留出集里唯一的真实样本，第 3 步冻结代码后再要来跑一次，之前不看、不按它调 | 读标的三个坑（AI 标注偏宽、评分照搬规则、规则照样本调）分别由响应清单、只对照响应清单打分、多写法 + 留出来堵。真实样本只有一份，用来检验泛化最有价值 |
+| C2 | 不先定元数。按 token 设计预算；按投标文件章节打批，同一段正文只送一次；每次检查有硬预算，超出没查的条目写进覆盖范围；24 小时内复查时按「清单项内容哈希 + 分册版本哈希 + 提示词版本」复用结果。第 3 步实测后再定元数 | 参考项目每个项目只判约 90 条，我们 216～1348 条，量级不能照搬；可见的覆盖范围比一个上限数字更诚实 |
+| C3 | 模型说已响应，但证据没通过校验：不判已响应，记「未找到响应」，级别不降，记原因码，界面可筛；致命项允许重问一次（只给模型指的那一页）；这类问题占致命问题的比例单列指标，目标 < 10% | 红线 2；原因码和单列指标来自读标待确认区噪音的教训 |
+| C4 | 签章只提示位置和有无。主要检查格式文件里该填的地方（投标人名称、签字人姓名、落款日期）有没有填；「（盖单位章）」这类括注不算问题；图像检测只看签章位置附近有没有图像，结论只到「提示」；Word 稿和 PDF 稿都走规范化 PDF，同一套检查 | 电子签章常在投标平台里加盖，稿子里本来没有章；括注盖章后通常仍保留 |
+| C5 | 重复条目在检查时分组：同类别、同一个包、保守相似度；问题挂在组里编号最小的清单项上，其他成员的出处附上；复查对齐时组内任一成员对上就算同一个问题；分组记在检查快照里。读标阶段合并以后再做 | 读标同一要求常抽成三条，直接查会出三个一样的问题 |
+| C6 | 正式清单全查；待确认区、不在所投包、超出预算的条目写进覆盖范围 | 「全部都查，或者明确说没查哪些」 |
+| C7 | 补 `extract.price`，规则优先，模型只做结构化；允许手工新增「报价」类条目；不卡住总价和采购包两层 | 10 份里只有 S06、S10 两份有分项限价或单价上限 |
+| C8 | 分册类型：整本（默认）/ 资格证明 / 商务 / 技术 / 报价 / 其他，加自填名称；类型只用来排序检索候选，不限制范围；电子投标平台加密格式维护一张识别表 | 很多投标人一个文件装全部；用户常标错类型 |
+| C9 | 新增 `check_item_result`（检查批次 × 清单项的结论、所走的层、投标侧出处、校验状态、原因码、token）；问题仍只为没响应好的条目生成 | 「已响应」也是 AI 结论，按红线 1、2 要能复核、能反馈；复用结果和覆盖范围也靠它 |
+| C10 | 扫描件：候选分册里图片页占比超过阈值的条目不出「未找到响应」，改出「请人工核对」；资格类按名称回到资质库匹配；覆盖范围列出没有文字层的页码。OCR（S5）排在 M3 之后 | 真实投标的资格证明多是扫描件，不处理会出一大片致命级「未找到」 |
+| C11 | 检索用内存 BM25 + jieba，不用 PostgreSQL 的 pg_trgm / 全文检索 | 句子不进库（DM1）；中文全文检索要第三方扩展；内存索引便于测试和评测 |
+| SK1 | 确认：进度推送用 Valkey stream。补：发布用的客户端设短超时，SSE 连接池设上限 | 现在 `valkey()` 没设超时，Valkey 挂掉时会卡住 worker |
+| SK2 | 确认：集成测试连 Compose 起的 PostgreSQL。补：CI 直接跑 `init-roles.sh`、加 Gotenberg；架构 §8 同步 | CI 里的建角色 SQL 和部署脚本是两份，会漂移；投标样例有 Word |
+
+- **影响**：`m3-plan.md` 按此执行；`data-model.md` 加 `check_item_result`（迁移在第 1 步）；架构 §8、§13 同步；`ref-bid-engine-analysis.md` §5.4 的检索写法已改。
+
 ## Q1–Q4 · 2026-11-03 · 实质性条款的四个口径：全部按建议
 
 依据 `docs/architecture/extract-eval.md` §5（S01–S10 标注时遇到、规范里没定的情形）。