feat(evals): 风格 B（两个分册、改写、自己的编号、干扰项 T01）；注入的三处待修项

- build.py：风格 B 分商务资格册和技术册，表格行按 rewrite.json 改写（数字对不上的改写丢弃，规矩靠构造
  保证），用自己的编号，每 12 行技术响应挪到商务资格册（T01）；干扰项写进 spec.traps。
- mutate.py：支持多个分册；表格的响应方式以档案的 mode 为准（评分要的技术规格表是 presence，不再把单元
  推成逐条响应）；「暂不支持」只套在功能类要求上，数值参数写不满足的值；「提供……方案 / 证明 / 报告」
  这类文件要在的要求不注入参数类问题。
- prompts/style-B.md、prompts/profile.md：风格 B 改写说明和招标文件档案说明（开发集用）。

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

evals/check/prompts/profile.md

@@ -0,0 +1,44 @@
+# 写「招标文件档案」的说明
+
+为查标评测集写一份招标文件档案（tender profile），供 `evals/check/build.py` 生成虚构的规矩投标文件。
+
+## 读这些
+
+- 档案格式：`evals/check/build.py` 文件头的 docstring，以及各 kind 的生成逻辑。
+- 响应方式的定义：`evals/check/GUIDELINES.md` §2（含本文件那一行的记录，记录不准时以招标原文为准，并在回复里说明）。
+- 招标文件全文（带句子编号 `[p页s句]`）：`evals/out/docs/<ID>/sentences.txt`
+- 读标正式清单（要分配 routes 的条目）：`evals/out/check/tenders/<ID>.items.tsv`（列：iid、类别、重要性、页码、标题）
+- 写好的档案可以参考格式（不要照抄内容）：`evals/out/check/tenders/S02.json`、`S04.json`、`S10.json`。
+
+**不要读** `evals/out/check/_sealed/`、`server/`、`prompts/`（仓库根目录那个）。
+
+## 只写一个文件
+
+`evals/out/check/tenders/<ID>.json`。不改仓库里的其他文件，不做 git 操作。
+
+## 要求
+
+1. `project`：项目名称、编号、采购人、代理机构、投标截止日期（`deadline`，YYYY-MM-DD）、投标有效期天数、最高限价或预算（元，纯数字字符串）、采购包（编号、名称、限价）。多包时只投一个包，写 `bidding_lot`，`ceiling_total` 填那个包的限价，只属于别的包的条目 routes 记 `na`。全部从招标原文取。
+2. `modes`：按类别（tech_param、substantive、commercial、qualification、scoring，必要时加 scope）记响应方式（explicit / implicit / evidence / presence / platform），evidence 写 `when`（bid 或 award）。每条带 `basis`：`p` 页码，`t` 从 sentences.txt 逐字复制、不少于 8 个字的片段（去掉 `<u>` 这类标记）。同一份文件里两处写法冲突时都记上，并在回复里说明。
+3. `forms`：按「投标文件格式」章的顺序列出投标人要交的全部格式文件。
+   - 叙述性的（投标函、授权委托书、声明函、承诺书）用 `kind: "text"`，`paragraphs` 照抄固定文字，填空处换成占位符（见 docstring），没有对应占位符的填空写成虚构的合理内容。声明函按规矩投标人的正确填法写；「如有 / 如是」而规矩投标人不适用的不列。
+   - 开标一览表 `price_summary`；分项报价表 `price_items`，`items` 写名称、数量、单位。**有分项最高限价或单价上限的，每项加 `ceiling`（元）**；上限是单价时再加 `ceiling_is_unit: true`。
+   - 偏离表 / 响应表 `response_table`：`route` 是 `tech_row` 或 `commercial_row`；implicit 的写 `only_deviations: true`，explicit 的写 false。表头照抄格式（脚本按表头文字决定每一列放什么，支持「序号 / 名称 / 要求 / 响应 / 偏离 / 说明」这些列）。**不是用来逐条响应、只是要求提交的技术文件**（例如评分要的「所投产品技术规格」表），加 `"mode": "presence"`。商务要求要逐项响应但格式章没给表的，可以自拟一张。
+   - 有固定行的表用 `fixed_rows`，响应栏按规矩填。
+   - 资格证明、评分证明材料放进**一个** `kind: "attachments"` 的表单（它会把全部附件渲染一遍）。
+4. `attachments`：规矩投标人要附的每份证明材料（按本文件要求来；写明「投标文件中无需提供」的、中标后才交的不附）。证书类 `scan: true`，`lines` 写虚构内容（单位名 {bidder}，信用代码 {credit_code}，有效期覆盖截止日之后至少一年，社保月份按要求的区间）。全部虚构，不出现真实企业或真实人名。
+5. `routes`：tsv 里**每一个** iid 都要分配：
+   - `tech_row`：技术参数、功能要求；`commercial_row`：商务要求（交货期、地点、质保、付款、售后响应等）；
+   - `attach:<附件 key>`：靠附证明材料满足的；`form:<表单 key>`：靠某份格式文件满足的；
+   - `prose` 或 `prose:<节标题>`：靠技术方案散文响应的（实施方案、售后服务方案等评分项）；
+   - 一条要求要走几处时用 `+` 连起来，例如 `tech_row+attach:a3`（表里一行，另附证明材料）；
+   - `na`：不需要投标人响应的（无效情形的列举、评审程序、日期、采购人义务、合同条款、说明标注规则的句子、别的包的条目）。
+6. `prose`：2～4 节虚构的技术方案叙述，每节 2～4 段，节标题要和 `prose:<节标题>` 对得上。**不写任何具体参数数值**，不出现别的项目名称。
+
+## 自查（用 Python）
+
+JSON 能解析；tsv 里的 iid 全部出现在 routes 里、没有多余的键；`form:` / `attach:` / `prose:` 都指向存在的表单、附件、节；modes 的 basis 片段都能在对应页逐字找到。可以把 build.py 的输出目录临时指到 scratchpad 试跑一次（不要写进仓库）。
+
+## 最终回复
+
+只写简短汇总：routes 各取值的条数、forms 列表（key + kind + 有无 mode）、modes 列表、拿不准的地方。

evals/check/prompts/style-B.md

@@ -0,0 +1,27 @@
+# 风格 B「简写型」改写说明（开发集用）
+
+你在为评测集改写虚构投标文件的技术响应表。输入是一组表格行，每行有编号 `key`、招标要求原文 `requirement`、规矩的响应 `answer`。按下面的风格改写，**只改写法，不改内容**：
+
+## 改写 `requirement`（招标要求那一栏）
+
+真实投标人常常不照抄要求原文。每行按下面几种做法之一改写（轮换使用，大约各占三分之一）：
+
+- **截断**：只留前半句或关键词，后面用「……」或直接截掉。例：「支持多种接入方式，包括有线、无线和蜂窝网络，并支持自动切换」→「支持多种接入方式……」
+- **改写**：换一种说法概括。例：「最小报文发送间隔不大于 50 毫秒」→「报文间隔≤50ms」
+- **去掉编号和标记**：删掉原文开头的序号、★、▲。
+
+## 改写 `answer`（投标响应那一栏）
+
+- 大约三分之一的行**只写值、不复述要求**：例「64GB DDR4」「支持」「3 年」。这些行只输出 `answer`，不输出 `requirement`。
+- 其余行用简短的说法，例「满足，单机 64GB」「支持，含硬件 BFD」。
+- **数值、单位、是否满足必须和原响应完全一致**：原响应写 64GB，改写后也必须是 64GB（不能写成 64G 或 65536MB）；原响应是满足，改写后不能出现「不支持」「部分」「可选」这类字眼。脚本会核对数字，对不上的改写会被丢弃。
+
+## 不要做的
+
+- 不要编造原文没有的参数、型号、品牌。
+- 不要改变响应的含义（满足的仍然满足）。
+- 例子里的设备和参数是虚构的，不要照搬到输出里。
+
+## 输出
+
+一个 JSON 对象：`{"<key>": {"requirement": "…", "answer": "…"}, …}`，只写 `answer` 的行省略 `requirement`。每个输入行都要有一项。