feat(check): 需人工核对（P2）和分项 / 单价上限（C7）

- 需人工核对：份数、密封、递交、CA 签章加密、解密、保证金这类文件里看不出来的要求，
  从正式清单按主题合并、带招标原文出处；manual-checks 接口按项目存勾选、写勾选人和时间，
  复查沿用；查标页加「需人工核对」一块，覆盖范围写明列了几条
- 「报价」类清单项：读标从采购需求的清单表规则读出分项 / 单价上限（checklist/price.py）；
  查标交给规则 PRICE.OVER_CEILING_ITEM 比对分项报价表，不交给模型；规则集 2026.11-r2
- 版面工具（分页、分行、归栏）挪到 document/pipeline/layout.py，读标和查标共用
- 评测：price_defects.py 从规矩投标文件派生只带报价问题的 4 份（P01、P02、P03）

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

docs/architecture/check-eval.md

@@ -176,8 +176,16 @@
 
 **读法：这个满分基本说明不了泛化。** 规则是在知道生成器怎么注入、见过开发词库措辞的情况下写的，投标文件版式也都出自同一个生成器。附加条件（P10）和多个报价（P12）的开发词库措辞直接落在规则的写法里，最需要留出集检验。为此做了两件事：规则按招投标文件的通用写法归纳（单元测试和 `bid-mini-forms.pdf` 都用开发词库以外的措辞）；评测集里没有的情形（超限价、跨页分项表、万元单位）只有单元测试。真实投标文件的合并单元格、扫描页、各地模板差异，要等国动真实投标文件来看。P01 / P02 / P03 / P11 / P13–P18 评测集里还没有注入。
 
-## 7. 下一步
+## 7. 第 2 步收尾：需人工核对、分项上限（2026-11-04）
 
-1. 第 2 步剩下的：需人工核对的条目（份数、密封、递交方式）和 `manual-checks` 接口；「报价」类清单项和分项 / 单价上限（C7、P03）；评测集补注入 P01、P02、P13。
+**需人工核对**（FR-M3-04、决策 P2，`check/manual.py`）：份数、密封、递交、CA 签章加密、解密、保证金这些投标文件里看不出来的要求，从正式清单里挑出来（技术参数、评分项、资格条件不算；写明免收保证金的不列；点名要交的文件归「文件要在」），按主题合并成最多 5 条（开发集 7 份招标文件每份 3～4 条，原始条目 12～48 条），带招标原文出处；查标页勾选，按项目存、写勾选人和时间，复查后还在。接口 `GET / PUT /projects/{id}/manual-checks`，`check_key` 用 `rule:MANUAL.<主题>`，清单改了勾选也还在。不生成「问题」，覆盖范围里写明列了几条。
+
+**分项 / 单价上限**（C7，`checklist/price.py` + 规则 `PRICE.OVER_CEILING_ITEM`）：读标时从采购需求的清单表（表头有「名称」和「单价上限 / 分项限价」两栏，表前一句写采购包）逐行读出名称、数量、上限，作为「报价」类正式条目并入清单，出处是表格那一行，不调模型；采购包一级的表不算。查标时这类条目不交给模型，规则拿分项报价表里同名分项的单价比，超了报致命，挂招标侧出处和清单项。名称要求很严（完全相同、去掉括注后相同，或重合度 ≥ 0.8），对不上的写进覆盖范围。开发集只有 S10 有分项上限，5 条全部读对；散文写法（「单价不得超过 × 元」）还不认。
+
+**评测集**：从规矩的投标文件派生 4 份只带报价问题的（`evals/check/price_defects.py`：只改一个分项单价，合价、合计、大小写跟着改，算术一致）：S01-B-p01、S04-B-p01（超总价限价 1 元 / 1%）、S10-A-p02（超采购包限价 1%）、S10-A-p03（分项单价超上限 1%）。S10 的分项上限加起来就是采购包限价，总价超限必然有分项超上限，生成器把这条一并记进金标准。21 份上规则问题 62 / 62 查出、误报 0；同样只说明规则和生成器对得上。
+
+## 8. 下一步
+
+1. 第 2 步还差：分项报价表和采购需求清单逐项对照（P13）、散文写法的单价上限。
 2. 第 3 步：D09（响应对象错位）、D06（负偏离未说明）的提示词 v3，token 预算、复查复用、重复条目分组。
 3. 留出集（S03、S06、S09，风格 B + C，封存的词库）和真实国动投标文件，在第 3 步冻结代码后只跑一次。

docs/architecture/m3-plan.md

@@ -10,7 +10,7 @@
 |---|---|---|
 | 第 0 步 评测集 | 试跑完成，继续扩充 | 规范 v0.2、留出集划分已定，留出集词库和风格 C 已封存；生成、注入、渲染、离线查标、评分工具已写；开发集 7 份招标文件、14 份投标文件第一版跑完，结果和发现见 `check-eval.md` §2 |
 | 第 1 步 链路打通 | ✅ 2026-11-04 | 见下方「第 1 步落地记录」 |
-| 第 2 步 规则 | 进行中 | 响应方式（C12）、文件要在、扫描件兜底、规则检查 `rules.py`（报价形式、形式要件、响应表）已上；需人工核对的条目、「报价」类清单项和分项上限（C7）还没做。见 `check-eval.md` §4–§6 |
+| 第 2 步 规则 | 基本完成 | 响应方式（C12）、文件要在、扫描件兜底、规则检查 `rules.py`（报价形式、形式要件、响应表）、需人工核对（`manual.py`、`manual-checks` 接口）、「报价」类清单项和分项上限（C7）。还差分项和采购需求逐项对照（P13）、散文写法的单价上限。见 `check-eval.md` §4–§7 |
 | 第 3 步 AI 响应匹配 | 进行中 | 整行上下文、提示词 v2；D09 / D06、token 预算、复查复用还没做 |
 | 第 4～6 步 | 未开始 | |
 

docs/architecture/openapi.yaml

@@ -2939,9 +2939,18 @@ components:
       type: object
       required: [check_key, label, checked]
       properties:
-        check_key: { type: string }
-        label: { type: string, examples: [正副本份数与装订] }
-        requirement_text: { type: [string, 'null'] }
+        check_key: { type: string, description: "rule:MANUAL.<主题>：SUBMIT、SIGN_ENCRYPT、DECRYPT、PAPER、DEPOSIT" }
+        label: { type: string, examples: [纸质投标文件的份数、装订、密封] }
+        requirement_text: { type: [string, 'null'], description: 代表这一主题的清单条目标题 }
+        related_items:
+          type: array
+          description: 同一主题的清单条目（公告、须知、无效情形里常各写一遍，按主题合并成一条核对）
+          items:
+            type: object
+            required: [id, title]
+            properties:
+              id: { $ref: '#/components/schemas/Id' }
+              title: { type: string }
         citation:
           oneOf:
             - $ref: '#/components/schemas/Citation'