test(w05): 件② 补八条显式只读断言 —— risk_level 撞车骗过了泛化规则

评审变异实测三次逮到两个活洞:original_value 加一个 data-col 就能在验收
工单上篡改基准事实,63 条既有断言零告警;risk_level 同时是
substitution.relation 与 substitution.difference_item 两张表都声明的
字段名,「data-col 都在台账声明里」那条泛化断言按名字找归属,被这个撞车
巧合放过——它问的是「这个名字合法吗」,不是「这一格该不该可改」。

改成显式点名八个字段(明细表六列 + 收口两枚徽章),不再依赖泛化规则。
八次变异逐一验证:每个字段单独挂上 data-col 都能让新断言真红,
risk_level 那次额外确认了旧的泛化断言在同一次变异下仍然全绿
(复现评审报告的根因)。模版本身未改一字——它一直是干净的。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LKMZDwMbyKzjw6Hembwvet

activities/part-substitution-assessment/__tests__/activity.test.ts

@@ -527,6 +527,26 @@ describe('件② 差异评估结论审核', () => {
     expect(html).toContain('data-class-of="recommendation_level"');
     expect(html).not.toContain('<script');
   });
+
+  /*
+   * 评审 fix round 1(变异实测三次,逮到两个活洞):上面「逐条明细可改」只断言了新开放的
+   * 四列存在,「推荐理由…只读」只断言了 relation 整表不许挂 data-edit —— 两头之间漏了
+   * 「明细表里其余本该只读的六列 + 收口两枚徽章,不许被顺手多挂一个 data-col」这一段。
+   * 旧的泛化断言(「data-col 都在台账声明里」)治不了这个:它按名字问「这个字段合法吗」,
+   * 不是「这一格该不该可改」——`risk_level` 同时是 `substitution.relation` 与
+   * `substitution.difference_item` 两张表都声明的字段名,两个问题在它身上分岔:挂了
+   * data-col 依然合法(两张表都真有这一列),泛化规则因此被这个撞车巧合放过。
+   * 这里改成显式点名,不再依赖任何泛化规则。
+   */
+  it('明细表六列(参数项/说明/约束/原值/候选值/单位)与收口两枚徽章(推荐等级/风险)必须保持只读 —— 显式点名,不靠泛化的「字段已声明」规则', () => {
+    for (const col of [
+      'parameter_name', 'parameter_desc', 'constraint_type',
+      'original_value', 'candidate_value', 'parameter_unit',
+      'recommendation_level', 'risk_level',
+    ]) {
+      expect(html, col).not.toContain(`data-col="${col}"`);
+    }
+  });
 });
 
 /*