feat(check): 同一行按单元格；业绩条款不再误跳；重复条目只合并显示（C5 修订）

- 送给模型的「同一行」在有框线的表格里按单元格分行
- 「以合同签订时间为准」不再被当成「签订合同时才交」，要附合同的业绩评分项照常查
- 重复的要求各自判断，问题接口给出 duplicate_ids，查标页同组折叠显示、一起处理
- 决策 C5 修订记入 decisions.md；开发集召回 74%、致命级 25/32

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

docs/architecture/check-eval.md

@@ -203,9 +203,30 @@
 
 **读法**：两项都是确定的规则，没有改提示词、没有多花 token。响应错位报了 3 处（2 个单元），全对，规矩的投标文件上没有改判；第一版报错的 4 处（「13.56MHz」没算数字字母重合、「支持」当成别的内容、要求太短）修掉后才是这个数。偏离栏直读依赖投标文件的偏离栏写法，真实文件里偏离栏常写「无」「—」「见说明」，这些不会改判（不算不满足），只有明确写了不满足的字样才改。
 
-## 9. 下一步
+## 9. 第六轮：同一行按单元格、业绩条款不再误跳、重复条目只合并显示（2026-11-04）
+
+**改了什么**：
+- **送给模型的「同一行」按单元格分行**（有框线的表格；正文句子照旧按上下重叠）：垂直居中的格子、折行的长格不再串到上下行。要重跑模型（17 份约 225 万 token）。
+- **「以合同签订时间为准」不再当作「签订合同时才交」**：`applicability` 判断证明材料是不是中标后才交的正则把它也认成了「签订合同时」，业绩评分项（「需提供合同复印件……以合同签订时间为准」）因此被当作「没要求附材料」跳过。评分项的业绩条款几乎都这样写。
+- **重复条目**（决策 C5 修订）：每条照常单独判断；问题接口给出同一次检查里问题类型相同、要求原文完全相同的其他问题（`duplicate_ids`），查标页同组只显示一条，注明「清单里出现 N 处」，处理和撤销对整组生效。
+- **致命项重问（C3）先不做**：开发集 17 份上证据没通过校验的只有 5 条，致命级 0 条，C3 定的「不超过致命问题的 10%」已经满足，开发集上没有可测的对象；等真实投标文件上看到再做。
+- **评测集裁定 1 条**（`adjudication/S10-B-sloppy.md`）：t20 的漏响应不成立，技术方案正文完整响应了（生成器没认出风格 B 改写过的正文复述）；问题总数 150 → 149。另核实了 3 条疑似错误、不改：S10-A-low t16 正文只响应了一半；S04-A s21 / s22 是同一条认证要求在几台设备下各写一遍、投标文件漏了其中一台——清单把几台设备的同一要求合成了一条，按条目查看不出哪一台漏了，这是现在的局限。
+
+| 指标（17 份，按 149 个问题重算） | 第五轮（mismatch） | + 同一行按单元格（cellrow） | + 业绩条款（award，本轮） |
+|---|---|---|---|
+| 查标召回 | 109（73%） | 108（72%） | **111 / 149（74%）** |
+| 致命级召回 | 24 / 32 | 25 / 32 | **25 / 32** |
+| D06 / D09 / D13 | 53 / 7 / 9 | 53 / 5 / 9 | 54 / 5 / **10** |
+| 规矩响应的要求上的误报 | 84 / 620 | 81 / 620 | 81 / 620 |
+| 干扰项误报 | 30 | 27 | **24** |
+| 规矩的投标文件报出的问题 | 235 | 236 | 239 |
+| 输入 token（17 份） | 221 万 | 225 万 | 225 万 |
+
+**读法**：按单元格分行和上一轮基本持平（召回 -1、致命 +1、误报略少），在一次模型重跑的波动范围内，结构上更对，保留。D09 少的 2 条是响应错位判断依赖模型引用「照抄的要求格」，模型换了引用就不触发——它是补漏，不是主力。业绩条款的修正带来 D13 +1、D01 +1；规矩的投标文件上多了 3 个提示（新查的业绩评分项）。
+
+## 10. 下一步
 
 1. 第 2 步还差：分项报价表和采购需求清单逐项对照（P13）、散文写法的单价上限。
-2. 送给模型的「同一行」改用按单元格分行（现在还用句子重叠，跨格、合并格会串）；要重跑模型，等下一次改提示词时一起做。
+2. 第 3 步冻结前：确认各项改动的单元测试都有开发集以外的反例；冻结后跑留出集（S03、S06、S09，风格 B + C）和国动真实投标文件，各一次。
 3. 第 3 步：D09（响应对象错位）、D06（负偏离未说明）的提示词 v3，token 预算、复查复用、重复条目分组。
 3. 留出集（S03、S06、S09，风格 B + C，封存的词库）和真实国动投标文件，在第 3 步冻结代码后只跑一次。

docs/architecture/m3-plan.md

@@ -11,7 +11,7 @@
 | 第 0 步 评测集 | 试跑完成，继续扩充 | 规范 v0.2、留出集划分已定，留出集词库和风格 C 已封存；生成、注入、渲染、离线查标、评分工具已写；开发集 7 份招标文件、14 份投标文件第一版跑完，结果和发现见 `check-eval.md` §2 |
 | 第 1 步 链路打通 | ✅ 2026-11-04 | 见下方「第 1 步落地记录」 |
 | 第 2 步 规则 | 基本完成 | 响应方式（C12）、文件要在、扫描件兜底、规则检查 `rules.py`（报价形式、形式要件、响应表）、需人工核对（`manual.py`、`manual-checks` 接口）、「报价」类清单项和分项上限（C7）。还差分项和采购需求逐项对照（P13）、散文写法的单价上限。见 `check-eval.md` §4–§7 |
-| 第 3 步 AI 响应匹配 | 进行中 | 整行上下文、提示词 v2、偏离栏直读、响应错位、复查复用、硬预算；还差送给模型的同一行改按单元格、重复条目分组、致命项重问。见 `check-eval.md` §8 |
+| 第 3 步 AI 响应匹配 | 进行中 | 整行上下文、提示词 v2、偏离栏直读、响应错位、复查复用、硬预算；送给模型的同一行按单元格、重复条目只合并显示（C5 修订）；致命项重问按数据暂不做。见 `check-eval.md` §8–§9 |
 | 第 4～6 步 | 未开始 | |
 
 **第 1 步落地记录**（和本文设计不一致、或留到后面的，记在这里）：

docs/architecture/openapi.yaml

@@ -2879,6 +2879,10 @@ components:
             sections:
               type: array
               items: { type: string }
+        duplicate_ids:
+          type: array
+          description: 同一次检查里问题类型相同、要求原文完全相同的其他问题（清单里重复出现的要求，决策 C5 修订：各自判断，界面折叠显示）
+          items: { $ref: '#/components/schemas/Id' }
         presence: { $ref: '#/components/schemas/Presence' }
         carried_status:
           oneOf:

docs/decisions.md

@@ -4,6 +4,14 @@
 
 ---
 
+## C5（修订）· 2026-11-04 · 重复条目不合并判断，只合并显示
+
+| # | 决策 | 理由 |
+|---|---|---|
+| C5 | 修订原决策：清单里的重复要求**每条照常单独判断**，不聚组共用一个结论；只在查标页把文字完全相同的问题折叠显示「此要求出现在 N 处」，处理一条时可以连同组一起处理 | 开发集上按相似度 0.9 估算，文字几乎相同的条目常是不同的要求：「缴纳税收材料」和「缴纳社会保障资金材料」；共用一段评分说明的几个评分项；两台服务器各写一遍的同一条参数（一台响应了不代表另一台响应了，正是「响应对象错位」要查的）。合并判断会把这些判错。代价是多花一点 token（每份约 5%～10%） |
+
+- **影响**：`check_item_result.group_key` 不写入；问题接口按「问题类型 + 要求原文」给出同组信息，前端折叠显示。
+
 ## C12、E1 · 2026-11-04 · 响应方式按建议处理；评测集挂问题的要求由另一个模型复核、用户抽查 20%
 
 | # | 决策 | 理由 |