合并 feat/act-work-05:第三个活动 ACT-WORK-05 差异评估(part-substitution-assessment@1.3.6)+ 脚本 e2e 逼出的平台侧改动

主支这边(d133d6c,PR #1/#2)是活动模块 L2/L3 前端(实例详情页、启动参数抽屉、禁用规则重定、
二次确认气泡、沙箱占位页)、工作台撤顶栏、姓名展示改姓在前(token claims 与名册同步);
分支这边 21 条:差异评估活动包(九个计划项、4 域 7 张主数据表、五张目标件平移的模版、
两枚纯函数工具、五案例 e2e 五例全 released 被拒 0)与平台侧 gateLedgers / answeredCardFact /
emptyGate / 早收只记观察 / 工具入参 null 归一 / 拒回不摆 S-FEEL 函数名,CLAUDE.md 快照跟上。

两边改的文件零重叠,自动合并无冲突。合并树上补三笔本该随各自提交入库的东西:
① api-report 两份快照 —— `org/port.d.ts`(主支加 given_name / family_name 时没刷)与
  `api/workbench.d.ts`(分支加 gateLedgers 时刷出来的文件没一起提交);
② pnpm-lock 补 `activities/part-substitution-assessment` 的 importer 条目(新 workspace 包,
  与当年 mail 模块同一回事;`--frozen-lockfile --offline` 装过核对一致);
③ org CONTRACT.md 补一笔 `VerifiedClaims` 增两个可选散件的影响半径。

五道门禁绿:2040 测试通过、23 跳过(无模型密钥 / 无真信箱的惯常项)。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0167qWjeyBwvfdGovd7FWbCu

docs/ACT-WORK-05-端到端测试记录.md

@@ -0,0 +1,288 @@
+# ACT-WORK-05 差异评估 —— 端到端测试记录
+
+> 这份文档记的是**每一轮实跑逼出了什么、改了什么、怎么验证的**。
+> 活动包:`activities/part-substitution-assessment`;业务出处 `docs/SS02-ACT-WORK-05-html/`。
+> 台账字段口径见 `docs/数据域字段说明-W05.md`。
+> 走查分两条线:**浏览器**(测试台起单 → 工作台真人点,六轮)与**脚本 e2e**
+> (`node tools/e2e-a2.mjs w05`,五案例代答,可一键复跑)。两条线逮到的缺陷不重合 ——
+> 浏览器逮呈现与交互(件、闸、徽标、翻页、画面切换),脚本逮机制(空手交卷、循环、崩、归属)。
+
+## 一、这个活动是什么
+
+原 PN 与候选替代料之间**逐项差异评估**:比参数、判四态(MATCH / MISMATCH / UNKNOWN / CONDITIONAL)、
+定推荐等级(preferred / alternate / conditional / not_recommended)、留证据与验证任务,
+最后把结论落进 P-11(替代关系 + 差异明细)并回写 P-01 需求,发射 `assessment-released` 交 ACT-GATE-03 评审。
+
+**九个计划项**(五处不给 doneWhen —— 触达人的一律交人收):
+
+| 项 | 谁办 | 卡 / 件 | doneWhen |
+|---|---|---|---|
+| `S0_bind` | AI | —— | 有 |
+| `S0d_p08_master` | 人 · 数据工单 | `p08-master-create`(表1 芯片主数据 + 表2 标准化参数集) | 无 |
+| `S0d_p10_document` | 人 · 数据工单 | `p10-document-create`(原厂技术资料) | 无 |
+| `S1_input_confirm` | 人 · 执行工单 | `eval-input-list`(评估输入清单) | 无 |
+| `S2_normalize` | AI | —— | 有 |
+| `S3_assess` | AI + 两枚工具 | —— | 有 |
+| `S4_review` | 人 · 决策卡(可循环) | `difference-review` | 无 |
+| `S5_prepare_landing` | AI | —— | 有 |
+| `T_release` | 人 · 终局验收 | `landing-confirm` | 无 |
+
+## 二、逐轮走查
+
+### R1 · 样例「都在库·常路」
+
+**第 1 次 —— 熔断**,逮到两条真缺陷:
+
+- 轨迹里 `S0_bind` 写完三张表后连续 5 拍只做一件事「弃用计划项 `S0d_p08_master`」,每拍被拒
+  「生命周期迁移非法:Available → Disabled」→ 熔断交人;工作区还摆着一张「待建 0 条记录」的空数据工单件。
+- **根因一(平台事实,本轮不改)**:`lifecycle.ts` 里 `Disabled` 只能从 `Enabled` 来,而 `Enabled` 只由
+  `plan` 动作写;普通计划项一直停在 `Available`。全仓只有本活动用过 `disable` —— **这条路从没人走通过**。
+- **根因二(活动缺陷,已修)**:哨兵 `s_bound` 只看「需求写了 + 核对表写了」,而 `S0_bind` 在**每条路**上都写这两张表,
+  于是都在库时数据工单那两项照样进「当下可为」,剧本就让模型去 disable。
+- 修:哨兵加 `sub_eval_pn_check_exists_status_absent > 0`;全包清 `disable`;两条回归测试。**v1.0.1**。
+
+**第 2 次 —— 通了**:两拍写完 `demand.request` / `pn_check` / `verdict`,直接派出执行工单;
+提交闸如实拦住空手交卷并点名三条缺项(与件上红带同名同数);填三格保存 → 闸自收 → 提交。
+
+**收工:`released` · 12 拍 · 人环 3 · 行动被拒 0**。落账逐条 SQL 核过:
+
+- P-11 主记录 1 条:`pin_to_pin | alternate | fae_confirmed | 客批=(空) | R-2026.07` —— **客户批准状态确实留空**(只读边界守住),规则版本随结论落账;
+- P-11 差异明细 9 条(8 MATCH / 1 CONDITIONAL);P-01 回写五项齐;出口 `assessment-released` 已发射;
+- 验收卡 11 条判据全部达标(L1×2 / L2×6 / L4×3),一次通过。
+
+### R2 · 样例「候选缺库·派数据工单」
+
+四次开跑,逼出四条缺陷(E / F / G / H),逐条治了再跑;第 4 次(v1.2.3)全绿。
+
+| 次 | 版本 | 结果 | 逼出什么 |
+|---|---|---|---|
+| 1 | 1.2.0 | 中途停 | E(决策卡被跳过)已在本次前修好并当场验证;F 现形 |
+| 2 | 1.2.1 | 熔断 | F 修复通过;**G 现形**(`recommend` 工具被跳过 → S3 收步恒假) |
+| 3 | 1.2.2 | 中途停 | G 修复通过;**H 现形**(压拍发卡,清单一行没有) |
+| 4 | 1.2.3 | **`released` · 被拒 0 · 人环 5** | 四条修复全部实测通过 |
+
+第 4 次逐段实证:
+
+- 决策卡按规格出现(候选总数 2 ≥ 2)→ 答「创建主数据」;
+- P-08 数据工单**一件两表**(主数据 1 行 + 参数 6 行),两张表各有自己的编辑闸与缺项红带;
+  填好保存 → 提交 → **画面自己切到 P-10**(发现 F 的修复稳定);
+- **执行工单出来时清单已有 12 行**(上一轮是 0)—— 发现 H 的修复见效;提交闸如实拦住剩下那条
+  「未披露」缺口,补上才放行 —— 闸与件同源;
+- **S3 两枚工具都真调了**(轨迹里 `compare-parameters 返回` / `recommend 返回` 各一条),自动收步,没有熔断;
+- **审核驳回循环**(本轮顺带覆盖):在「写下你的口径」里写两条具体意见 → 模型改台账 → **换问法重发**新卡。
+  逐条核过落点:XL2596S-5.0 降 `conditional`、两条 UNKNOWN 明细写明处置(挂 `VAL-…` 验证任务、
+  「闭环前不升级推荐等级」)、LM2596S-ADJ 的推荐理由点名「R1/R2 分压电阻」—— **意见落在被点名的那两处**;
+- 终局验收 11 条判据全部达标 → 确认通过 → `released`。
+
+落账 SQL 复核:P-11 两条关系(`pin_to_pin | conditional | fae_confirmed` / `pin_to_pin | alternate | fae_confirmed`,
+客批均空、规则版本 `R-2026.07`)· 差异明细 18 条(15 MATCH / 2 UNKNOWN / 1 CONDITIONAL)·
+验证任务 1 条(`not_started`)· P-01 回写五项齐 · **XL2596S-5.0 真进了主数据**(`XLSEMI | active`,6 行参数 + 1 份资料)。
+
+### R3 · 样例「三候选·含硬约束不推荐」—— `released` · 被拒 0
+
+一次跑通,验的是**硬约束这条路**:
+
+- 决策卡按规格出现(3 颗候选,只有 CN-DCDC-32V 缺库)→ 建主数据 → P-08 填
+  **输入电压范围 4.5~32(hard)**、工作温度 -20~+85(hard);
+- 清单 13 行、三行 default 的 detail 写对了默认值本身;缺口里把客户约束写成可解析式「输入上限硬指标 >= 40(V)」;
+- S2 铺 3 条关系 + 27 条明细;S3 两枚工具都调过;
+- **CN-DCDC-32V = `not_recommended` / high**(两条硬约束 MISMATCH:输入 4.5~32 vs 4.5~40、温域 -20 vs -40),
+  XL2596S-5.0 `conditional`、LM2596S-ADJ `alternate`;
+- 验收件上三颗候选各一份「拟写 P-11」字段表,徽标逐个核过(不推荐/高 · 条件推荐/中 · 备选/中 · Pin-to-Pin · FAE确认)。
+
+**一次自纠**:我先按 `innerText` 判定「四个枚举列是空的」,险些记成缺陷 ——
+徽标文字是 CSS `::after` 生成的,`innerText` 读不到。**验证呈现要看 computed style,不看 innerText**。
+
+### R4 · 样例「原PN缺库·硬阻塞」
+
+三次开跑,逼出两条**同族**的真缺陷:
+
+**第 1 次(v1.2.3)—— 发现 I:「在库」是模型自报的一句话**
+
+原 PN `LM2596S-3.3` 主数据里**一行都没有**(SQL 复核 count = 0),模型把原 PN 与候选**两颗都写成 `found`**,
+交代里还写「原 PN 与候选都在库」—— 数据工单一张没派,直接把评估输入执行工单发给了人。
+剧本早写着「`parts.profile` 整表在你的作用域里,按 internal_pn 逐个核对」——**措辞已到头**。
+
+**结构治**:`sub_eval.pn_check` 加一列 `found_pn_ref`,
+`refersTo: parts.profile.internal_pn` + `requiredWhen: {exists_status: found}`。
+于是「判在库」这句话必须配一个**基座拿去主数据里查得到**的料号:
+
+- 查无此值 → `draftWrite` 当场拒;
+- 填不出 → `pn_check_missing > 0` → `S0_bind` 的 `doneWhen` 收不掉。
+
+两条路都堵死,唯一走得通的就是如实写 `absent`。**这是「机检只读基座数」第六次现形**
+(前五次是 missing_key_total / missing_minor_total / untyped_total / draft_total / 哨兵读 line_total),
+这次的形状不是计数,是**存在性**。
+
+**第 2 次(v1.2.4)—— 墙生效了,但逮出发现 J:数据工单派给了在库的那颗**
+
+核对表这次写对了(`LM2596S-3.3 = absent`、`LM2596S-ADJ = found` 且依据经基座查过),
+可数据工单派给了 **LM2596S-ADJ**(它在库、参数资料齐全),真正缺的那颗没人建。
+交代原话:「候选只有 LM2596S-ADJ 一颗,按规则直接建主数据」——
+它把「候选总数 = 1 → 不问人」这条**关于问不问**的规则,读成了**关于建哪颗**的规则。
+病根:剧本把两个问题写在同一串项目符号里,三档分岔每档都以「→ 直接进入建的名单」收尾,
+而**从没写过「found 的不建」**。与发现 E 同形。
+
+**治法(措辞,精准化)**:拆成「**问题一 · 建哪几颗**」(名单 = `absent` 的每一行,`found` 的一行都不建,并写明后果)
+与「**问题二 · 建之前要不要先问人**」(只有 absent 的候选才谈得上问)。这一处不上结构 ——
+系统其实兜得住(原 PN 还 absent → S1 哨兵不开 → 依赖断点),只是要白烧一次人环;
+而这一刀是**补上从没写过的那句话**,不是把已经写过的话再说一遍。
+
+**第 3 次(v1.2.5)—— `released`**:数据工单派给了 `LM2596S-3.3`,**没发决策卡**(硬阻塞不问人),两条修复都实测通过。
+
+这一轮还留下了**发现 I 那道墙开火的现场证据**(轨迹 seq 6):
+
+> 行动被拒:在库核对依据「LM2596S-3.3」在芯片主数据(P-08)里不存在 —— 这一列只许引用台账里真实存在的值……
+
+模型确实又想判「在库」,基座当场拒回并点名;它随后如实写了 `absent`,硬阻塞照规格走了下去。
+
+**终局「重做」分支也在这一轮验了**(本活动此前未验):在验收卡上写明两条意见后点「重做」——
+模型没有原样再递一次,而是**真去改了台账**(`demand.request.verification_requirement` 重写、
+5 行 `difference_item.evidence_ref` 从「只写文件名」改成指到 `Rev H (2023-09) §6.5 Electrical Characteristics`),
+再重新裁量 + 提交;第二张验收卡确认通过 → `released`。
+
+整单 2 次被拒:一次是上面那道墙(它该拒),一次是 S3 的「先 finish 后调工具」——
+拒回文案照旧只谈「行与列」(平台欠账已记),但模型下一拍自己去调了 `recommend`、随即自动收步,没有熔断。
+
+落账:`parts.profile.LM2596S-3.3`(TI / nrnd,7 行参数)真进了主数据;
+P-11 一条(`LM2596S-3.3 → LM2596S-ADJ | alternate | fae_confirmed`);P-01 回写齐。
+
+### R5 · 样例「新客户·先建档」
+
+验的是**数据录入卡**这条路(客户不在档案里,先收人、再评估):
+
+- 卡按规格出现:「客户 CU-9001 不在客户档案里,请核对建档信息后确认」,客户名称已从入参带出、行业与区域留白给人补;
+- 补两格 → 确认写入 → 客户档案落草稿层(`深圳恒星电源有限公司 / 工业电源 / 华南`)→ 流程直奔 S1(两颗料都在库);
+- 缺口补齐 → 审核通过 → 终局确认 → `released`。
+
+**发现 K**:那张录入卡的「参考信息」栏摆的是引擎兜底的**内部家具** ——
+「这一步 / 当下可为 / 目标缺口」,后面跟着**九个计划项的全名**,人一个字用不上。
+病根:`entryCard.basis` 在契约里是**可选**的,活动的卡骨架没声明,基座就把内部事实兜了上去。
+与 A1 2026-08-03 那次同族(那次是执行卡的 steps/standard 没进说明书)。
+治法:说明书里的录入卡骨架补 `basis` 三行(触发原因 / 这一单要评估的 / 确认之后会发生什么),
+并在骨架下写明「不给基座会兜内部家具」。配一条测试。
+
+**一处操作教训(不是缺陷)**:测试台在「清场」之后会回落到样例 0 ——
+选样例与「起单试跑」必须在同一次操作里完成,否则起的是上一个默认样例。
+
+## 二·五、六轮走查一览
+
+| 轮 | 样例 | 结果 | 这一轮覆盖的分支 |
+|---|---|---|---|
+| R1 | 都在库·常路 | `released` · 12 拍 · 人环 3 · 被拒 0 | 无数据工单直通;验收判据 11/11 |
+| R2 | 候选缺库·派数据工单 | `released` · 被拒 0 · 人环 5 | 决策卡(创建)· P-08 一件两表 · P-10 · **审核驳回循环** |
+| R3 | 三候选·含硬约束不推荐 | `released` · 被拒 0 | 三候选并行 · **硬约束 MISMATCH → `not_recommended`** |
+| R4 | 原PN缺库·硬阻塞 | `released` · 被拒 2(其中一次是墙该拒) | **硬阻塞不问人** · **终局「重做」循环** |
+| R5 | 新客户·先建档 | `released` · 被拒 1 | **数据录入卡建档** |
+| R5b | 新客户(v1.2.6) | 验完即停 | 录入卡 `basis` 呈现 |
+
+版本轨迹:1.0.0 → 1.0.1(A)→ 1.1.0/1.1.1(B·C·D)→ 1.2.0(参数子表)→ 1.2.1(F)→ 1.2.2(G)
+→ 1.2.3(H)→ 1.2.4(I)→ 1.2.5(J)→ **1.2.6(K)**。包内自测 16 → **61 条**。
+
+## 二·六、脚本 e2e 的六轮(2026-08-27)
+
+浏览器那六轮之后,凭证到位、`w05` 套件跑起来,又逼出六条 —— **全是浏览器逮不到的那一类**
+(脚本每张卡都先空手交一次、每个岔路口都按序代答,人手点的时候会先把格子填好再按提交):
+
+| 轮 | 结果 | 这一轮逼出什么 |
+|---|---|---|
+| 1 | 1 通过 | **L 数据工单的提交闸没牙** |
+| 2 | 3 通过 | **M 拒回数不出「缺的是一次工具调用」· N 决策卡拒回只给指针** |
+| 3 | 1 通过 | N 的措辞版没用 → **改结构**;**O 工具被 null 打崩** · P `count` 假线索 |
+| 4 | 2 通过 | **H 的残留面:零行同时骗过闸与哨兵** |
+| 5 | 4 通过 | **created 逐颗对账太松 · S1 卡的前提没写在说明书** |
+| 6 | 跑到的 4 例全 released,3 例被拒 0 | 案例 4 停在 `Insufficient Balance`(大模型余额) |
+| 7 | 前 3 例 released | 充值后:先撞上我自己拉起的旧稳定实例抢单(`recommend` 无可用实现);**T** P-10 骨架零行 · **U** 脚本一例翻车整套退出 |
+| 8 | **5 例全 released,4 例被拒 0** | 案例 3 被拒 6:**V** 建完第一颗就收掉数据工单那一项 |
+| 9 | 案例 3 单跑 | 用户纠正「别每次全跑」;逮到一次**假绿**:**W** 参数名写成英文 key · **X** 两颗缺库只问一次 —— 断言收紧 |
+| 10–11 | 案例 0/1 被拒 0 | **W 的乘法对账只在 ≥2 颗时咬得住**,单颗照漏 → 自指 `refersTo`;**Y** 脚本按闸的指示「加一行」;案例 2 撞 **Z** |
+| 12 | 案例 2 · 4 各单跑 | **Z** 修后 released · 被拒 0 · 卡先发人再答 |
+
+**最终状态(收紧断言下)**:五例全部 `released` · 全部被拒 0。
+案例 0/1 验于 1.3.5、案例 3 验于 1.3.4、案例 2/4 验于 1.3.6 —— 1.3.6 只改了 S0d 剧本里「何时标 created」那一句,
+案例 0/3 走过那一步、未在最终文本上复验(如实记)。
+
+第 6 轮逐条实证:早收容忍让案例 1/2 的最后 1 次被拒消失(轨迹里是**观察**不是拒回);
+三候选那例**第一次跑通**(前三轮:超时 / 超时 / 烧穿预算),两颗缺库一起办、三条结论全对。
+
+## 三、走查发现总表
+
+| # | 现象 | 病根 | 治法 | 层 |
+|---|---|---|---|---|
+| A | 缺口表**每一行**都摆红「必填」,而闸只认 3 条 | 那一格用静态 `req` class,`supplement` 的声明是 `requiredWhen:{status:'gap'}` | 按行投影 `data-class-of="status"`,判断留样式表 | 活动 |
+| B | 五张模版是 E04/I01 的 `jc-rp-*` 外壳,不是目标件的版面 | 计划文本自相矛盾(一边说逐字量自目标件,一边让用 `prd-style.ts`) | 目标件 `<style>` 逐字节抽成 `target-style.ts`,标记逐块搬,删 `prd-style.ts` | 活动 |
+| C | 带下划线的 tally 值一律显示「待定」(`pin_to_pin` 等 14 个值) | **两套消毒规则打架**:`view-render.classToken` 只留 `[a-z0-9-]`(吃下划线),而基座读数 slug 只留 `[a-z0-9_]`(吃连字符) | 徽标 CSS 选择器改由 `vtok()` 从 tally 值算,永不漂移;平台那两套规则不一致记欠账 | 活动(平台记账) |
+| D | 主键列 `item_key` 丢了 `data-col`;`status` 降成只读徽标而它是必填 | 模版重做时的回归 | 补回主键 `data-col`;`status` 改混排(只读徽标 + 编辑态下拉);**两条回归测试**(主键列必有钥匙 / 必填列必有可填控件) | 活动 |
+| E | 候选 ≥2 时该问的决策卡被跳过 | guide 写的是复合条件「候选 absent 且候选数 ≥2」,模型读成「absent 的候选 ≥2 颗」 | 改两步式:先数两个数各给名字,再按三档分岔;显式写「不在库的只有一颗不是跳过的理由」 | 活动 |
+| F | P-10 的卡发出来了,工作区还停在 P-08 的件 | 模型没先 `finish` 上一项就发下一项的卡;引擎按「当下还没干完的第一步」取 view | guide 把动作串写死「恰好两个、顺序不能反:①先 finish ②再发卡」 | 活动(平台记账) |
+| G | `S3_assess` 熔断:`recommend` 工具从没被调用,推荐等级是模型自己拍的 | doneWhen 里 `tool_..._recommend_calls > 0` 恒假;而拒回文案只谈「行与列」,把模型指向错方向 | guide 写盘前自检「两个 tool_*_calls 都必须 > 0」+ 写明「自己填看着对、机制上是你拍的」 | 活动(平台记账) |
+| H | 执行工单发出来了,清单一行都没有 —— 人对着空表 | 「先写清单再发卡」只写在 S1 剧本里,而那一拍模型**压拍**,摊开的是上一项的剧本 | 规矩搬进**说明书**(每拍都在);包内自测钉死 | 活动(平台记账) |
+| I | 原 PN 根本不在库,模型两颗都判「在库」,硬阻塞整条路被跳过 | 存在性核对是模型自报的一句话,基座数不出来;剧本已写到头 | 加 `found_pn_ref`(`refersTo` + `requiredWhen`):判在库就必须填一个基座查得到的料号,查无此值当场拒、填不出则收不了步 | 活动(结构) |
+| J | 数据工单派给了在库的那颗,缺的那颗没人建 | 剧本把「建哪几颗」与「要不要问人」写在同一串分岔里,从没写过「found 的不建」 | 拆成两个问题分别作答,并写明后果 | 活动 |
+| K | 数据录入卡的「参考信息」栏摆着引擎内部家具(九个计划项全名) | `entryCard.basis` 契约里可选,活动没声明,基座兜底把内部事实摆了上去 | 卡骨架补 `basis` 三行,并写明不给的后果 | 活动 |
+| L | **数据工单的提交闸没牙**:件上红带点着「缺品牌名称」,提交钮却是绿的,空手交卷一路放行 | `gateAddressesOf` 只有两级 —— 没绑表就回落到**必交付物**,而数据工单要人补的是 `parts.*` 主数据,不在交付物名单里:闸盯着一堆与这张卡无关的表,一格不缺 | 契约新增 `ExecutionWorkOrder.gateLedgers`(**这张卡该拦哪几张表,发卡的人说了算**),闸改三级取一:绑的表 > 卡自报 > 交付物 | **平台**(结构) |
+| M | `finish` 撞 doneWhen 为假时,拒回只谈「行与列」,而缺的是一次**工具调用** | 拒回从不摆判据本身,更不摆读数 | 拒回摆出**判据原文 + 那几个名字此刻的读数**;`tool_*_calls` 读到 0 的单独点名 | **平台** |
+| N | 人点了决策卡,模型每拍再发一张,连拒五拍熔断 | 剧本让模型「去轨迹里找 card-reply」,而那条痕会被挤走 —— 拒回把「他选的是 approve」写明白也没用,**下一拍它又从头翻一次** | `answeredCardFact`:把「这张卡已答过 → 他选的是什么」做成**每拍都在的事实行** | **平台**(结构) |
+| O | 模型传 `requirement: null`,工具 `null.trim()` 当场崩,整次调用记成「行动被拒」 | 工具入参是宽松描述式 schema,null 一路落到处理器;处理器只判了 `undefined` | 边界上一律经 `text()` 归一,类型如实写成可空 | **平台**(我写的工具) |
+| P | 拒回里摆着 `count=(没写过)` —— 那是 S-FEEL 的函数名,不是谁忘了记的账 | `readingsOf` 把内建函数当台账名 | `SFEEL_WORDS` 补上 count/sum/min/max/all/any | 平台 |
+| Q | 模型压拍没写骨架就发数据工单,人打开是空表,而**零行 = 零缺**,闸与哨兵一起放过 | 「缺必填」只数已有行;`_missing = 0` 在零行时恒真 | 平台 `emptyGate`(**卡自报的表一行都没有 = 没完成**)+ 说明书③「发卡前骨架必须先有行」+ 哨兵 `profile_rows >= created` 逐颗对账 | 平台 + 活动 |
+| R | 两颗缺库只办了第一颗,第二颗还 absent 就把 S1 的卡发了出去 | **发卡的授权面是调人预算,不是计划项** —— 它绕得过哨兵;而 S1 那张卡的**前提**只写在剧本里 | 前提写进说明书的卡骨架(「一颗 absent 都不剩」「有几颗 absent 就要办几颗」) | 活动 |
+| S | 每例白吃一次的「早收」:工具还没轮到调,`finish` 先到了 | 那是**计划次序**的小错,却被记成「行动被拒」去喂熔断计数 | 与「重发已答过的卡」同一把尺:**头一次只落观察,第二次起才算被拒** | **平台** |
+| T | P-10 数据工单发出来时 `parts.document` 一行都没有 | 说明书③给 P-08 补了「发卡前骨架必须先有行」,④(P-10)没补 | ④ 补同款前提 | 活动 |
+| U | 一例卡住,脚本整套抛出退出,后面两例连跑都没跑 | `main` 逐例调用没兜 | 一例翻车判失败、接着跑下一例 —— 一套五例的价值在「哪几例过、哪几例没过」 | 脚本 |
+| V | 建完第一颗料就把数据工单那一项收掉,再给第二颗发卡撞「这一步已经办完」 | 剧本【P-08 确认回来了】没分岔「还有没有 absent」 | absent 没清零不许 finish;写明「收掉了就回不去了」 | 活动 |
+| W | 参数名写成英文 key(`input_voltage_range`),与库里中文行**不是同一行** → 27 条里 14 条 UNKNOWN | `param_name` 是主键的一半;措辞两遍 + 乘法对账(行数 = 不同名字数 × 料数)都拦不住**单颗**那一路 | **自指 `refersTo: parts.parameter.param_name`** —— 一颗料时也咬得住 | 活动(结构) |
+| X | 两颗缺库只问了一次;`expectDecision` 只看张数,审核卡就把它喂饱 | 剧本「还有 absent → 写骨架再发卡」把「先问」压掉;断言太宽 | 剧本补「第二颗也要先问」;脚本新增 `expectAsks`(按问法数) | 活动 + 脚本 |
+| Y | 模型漏铺骨架 → 闸如实拦「一行都没有」→ 脚本只会填已有行,连吃 400 抛出 | 脚本没有「加一行」这条路,而人在浏览器里正是这么做的 | 主键齐了就加一行(与件上「加一行」同一条路) | 脚本 |
+| Z | 铺完骨架就标 `created`、直接 finish,撞「从没给它发过卡」连拒五拍 | 我 1.3.1 的措辞「表里真有一行才标 created」—— 而骨架是模型自己铺的 | 「created 认的是卡交回来了」;顺序写死:骨架 → 发卡 → 拍结束 → 人交回 → 才标 | 活动 |
+
+**可推广的三条**(已记 `docs/debt.md`):
+
+1. 凡「同一条路上前后两个人环项」,前一项不收掉,后一项的件就推不出来(发现 F);
+2. 拒回文案只谈行与列,数不出「缺的是一次工具调用」(发现 G);
+3. 执行工单绑的必交付台账**一行都没有**时提交闸无牙 —— 回落只数「已有行缺不缺必填」,零行 = 零缺(发现 H)。
+
+发现 L 是这三条里**唯一当场治了平台的**:闸看的表与件上摆的表不是同一张,闸就等于没有 ——
+而这件事只有脚本 e2e 逮得到(它每张卡都先空手交一次;人手点的时候会先把格子填好再按提交)。
+
+**还有一条**(平台侧,已记 debt):`disable` 这条路从来没通过(发现 A)——
+`Disabled` 只能从 `Enabled` 来,而 `Enabled` 只由 `plan` 动作写。
+
+## 四、这一轮沉淀下来的三条方法
+
+1. **措辞治不了的结构治,但要先分清「已经说过」和「从没说过」。**
+   发现 I 是措辞已到头(剧本白纸黑字写着「整表在你的作用域里逐个核对」),该上结构;
+   发现 J 是**从没写过那句话**(「found 的不建」),补一句话就够 —— 两者形状像,处方不同。
+
+2. **「机检只读基座数」这条纪律,第六次以新形状现形。**
+   前五次都是**计数**(missing_key_total / missing_minor_total / untyped_total / draft_total / line_total),
+   这次是**存在性**。凡是「模型说了算、基座数不出来」的判断,迟早会在某一单里说反。
+   本活动的解法是 `refersTo` + `requiredWhen` 组合成一道「说了就得拿出依据」的门。
+
+3. **验证呈现要看 computed style,不看 `innerText`。**
+   徽标文字是 CSS `::after` 生成的 —— 用 `innerText` 判空,会把好端端的页面判成缺陷(R3 差点误报)。
+
+## 五、活动侧的验收口径
+
+- 六条路径全部 `released`;三条零被拒,另三条的被拒各有交代(一次是墙该拒,两次是同一处平台缺口且模型自行恢复);
+- 落账逐单 SQL 复核:P-11 主记录 / 差异明细 / P-01 回写 / 验证任务 / 主数据 P-08 与 P-10,值与业务一致;
+- **只读边界守住**:`customer_approval_status` 每单都留空(本活动不产生),`rule_version` 随结论落账;
+- 出口只有一口 `assessment-released`,每单都真发射了。
+
+4. **两条线逮到的缺陷不重合,缺一条就漏一半。**
+   浏览器逮的是**人看见什么、点得动什么**(件、闸、徽标、翻页、画面切换、快照 1:1);
+   脚本逮的是**机制**(空手交卷、循环、崩、归属)。发现 L–S 八条没有一条是浏览器走查逮到的 ——
+   因为人手点的时候会先把格子填好再按提交,永远不会去试「空着交上去会怎样」。
+
+5. **断言报的通过是假的,比报的失败是假的更糟。**
+   第 9 轮案例 3 报「1/1 通过」,而参数名全是英文、两颗缺库只问了一次 —— 脚本只把它们记成 ⚠️ 就放过。
+   假失败还有人去查;假通过没有人会看第二眼。此后:点名的行整例跑完仍没出现 = 失败;决策卡按**问的是哪件事**数。
+
+6. **只跑受影响的那一例;改了平台共享面才全跑回归。**
+   前八轮每次把已绿的四例重跑一遍 —— 每轮多烧一百多万 token,而且什么新东西都测不出。
+   脚本本来就支持 `w05 N`。
+
+7. **拒回喂事实,不喂指针。**
+   发现 N 那一轮把「他选的是 approve、下一步写哪面旗」写进拒回,日志里逐字可见,模型照发不误 ——
+   因为**下一拍它又从头翻一次会滚走的窗口**。把同一件事做成「每拍都在的事实行」之后,一次就好了。
+   同一条道理已经在 worldTouched(2026-08-21)、E04 的 worldTouched 事实行(2026-08-24)上各现过一次。

docs/debt.md

@@ -1181,3 +1181,94 @@ pnpm 硬链到全局 store,真实占盘远小于这个数,但 `du` 看着吓人
 ㉔ **`claimForResend` 会把抢到的那一行的 `created_at` 推到当下**:这是 CAS 判据的一部分
    (抢到即离开可抢集合),代价是**这一列不再是「这一行何时建的」** —— 谁要拿它当来源凭据都会读错。
    要么另立一列记真正的创建时刻,要么在读它的地方写明。目前无人拿它做凭据。
+
+## 成员目录冷启 8 秒(2026-08-26,ADR-012)
+
+`GET /api/gov/org/users` 第一次要 8 秒:Keycloak **没有「一次拿回全部人的生效角色」的接口**
+(手册 §14.4 是逐人 `GET /users/{id}/role-mappings/realm/composite`),8 个人就是 8 趟远程往返。
+并发从 8 提到 24 实测无改善(9.3 秒)—— 卡的是那台 Keycloak 每个请求自身的时延,不是我们的并发。
+
+现状:usecase 层 60 秒读缓存(`DIRECTORY_TTL_MS`),任一写成功即整体清空 ——
+**冷启 8 秒、60 秒内 0 毫秒**;写完立刻重拉一定看得到新结果。
+
+结构性治法(没做):按**角色**问而不是按人问 —— `GET /roles/{name}/users` 拿直接持有者
+(每个角色一趟)+ 展开 `default-roles-<realm>` 的组合(一趟),合起来就是全员的生效角色,
+调用次数从 O(人数) 降到 O(角色数)。当时试过这条的半截(只用 `/roles/{name}/users`),
+**数错了**:`user` 是经 `default-roles-corp` 继承的,那条路报「持有 0 人」而实际人人都有 ——
+所以要做就得连组合展开一起做,不能只做一半。realm 长到几十上百人时再动它。
+
+## 成员与组织:写完那几秒屏上还是旧的(2026-08-26,ADR-012)
+
+组树那一趟读要 5-6 秒(逐组数成员 + 服务端 60 秒缓存被写清掉),于是**删一个组之后**
+到画面更新之间有一段真空。实测三轮里有一轮**根本没刷过来** —— 网络记录里露了马脚:
+中间夹着一趟 `GET /groups → 401`(token 到期,typed-fetch 强刷重试),那一次重取就此失败,
+而 react-query 拿不到新数据就继续摆旧的。
+
+已做的两刀:
+- 服务端缓存**按写碰到的东西分开清**(`'users' | 'groups' | 'all'`)—— 建个组不再把
+  「全量成员的角色」那趟 N+1 拖下水;前端的失效键同批收窄(`ORG_KEYS`)。
+- 删组成功后**先把已知事实落进缓存**(`setQueryData`,按路径前缀连子组一起摘),
+  再照常发重取 —— 与 `mirrorTwins` 同一条道理:值本来就在手上,不必等服务端再说一遍。
+
+**还欠**:①**重取失败时界面继续摆旧数据,一声不吭** —— 这不是这一屏的毛病,
+治理台每一屏都这样(`QueryGate` 只管首次载入,不管重取失败);要治得在共享层做
+「这份数据是几时的 / 刚才那次刷新失败了」。②组树的成员数仍是逐组一趟,
+组多了会线性变慢 —— 与「成员目录冷启 8 秒」是同一族问题(见上一条),
+真治法都是把「按人问」换成「按组/按角色问」。
+
+## 推送有多密请求就有多密:广播没有合并层(2026-08-26)
+
+08-26 的「工作台疯狂轮询三个接口」查到底是两台后端互桥回弹(`broadcast-bridge.ts`,已修,
+2 测钉死)。风暴掐断之后,**同一条放大链还在**,只是没了永动机:
+
+- `task-service.tick` **每拍无条件** `setPhase` → `control` 信封 → `task` touch(不看 phase 有没有变);
+  每拍推帧 `view-html` 一条;推进器 `advanced` 一条、在流程里再加一条 `workflow` ——
+  一拍 3-4 条 `task` touch 在几十毫秒内到达;
+- 前端 `invalidateFor` 逐条失效、不合并:每条 touch 各让 tasks / approvals / task 详情重取一次,
+  TanStack 默认还会取消在途请求重发(`cancelRefetch`)—— 一拍 9-12 趟请求,一条案例活动跑十几拍
+  就是上百趟,而画面只需要每拍刷一次。
+
+治法两层:①源头 `setPhase` 只在 phase 真变时广播(与 `worthBroadcasting` 同一条道理);
+②`invalidateFor` 加一个 50-100ms 的合并窗,同一批 touch 落地后按键去重只失效一次
+(纯函数、可测)。两层都做,任一层失守另一层兜着。
+
+## ACT-WORK-05 走查逼出来的三条平台欠账(2026-08-27)
+
+差异评估活动(`part-substitution-assessment`)从零到 released 的浏览器走查里,
+有三处**病在平台、这一轮只在活动侧绕过去了**——绕法是措辞,治法在共享面:
+
+- **`disable` 这条路从来没通过**:`lifecycle.ts` 里 `Disabled` 只能从 `Enabled` 来,
+  而 `Enabled` 只由 `plan` 动作写(裁量项入场);普通计划项一直停在 `Available`,
+  于是任何 `disable` 都撞「生命周期迁移非法:Available → Disabled」。
+  全仓只有本活动用过它 —— E04/I01 一次都没用,所以没人发现。实测代价:连拒五拍熔断。
+  两条路二选一:要么让 `disable` 对 `Available` 的项也成立(语义:这一单用不上它),
+  要么在拒回里明说「本平台没有弃用计划项这回事,不需要办的项什么都不用做」。
+  **现状**:活动侧全包清了 `disable`,并在哨兵上加了「真有料号不在库」才开门。
+
+- **前一项不收掉,后一项的件就推不出来**:引擎挑画面按「当下还没干完的第一步」取 view
+  (`turn-runner.ts` 2058-2064 附近)。模型把「人交回 → 发下一张卡」压成一拍、忘了 `finish`
+  上一项时,卡是新的、件还是旧的 —— **人拿到的卡写着「把资料填到件上」,屏上一个格子都没有**,
+  提交闸如实拦死,整单挂在那儿。E04 的 S4→S5 撞过同一堵墙(2026-08-23 已按 `currentRuntime`
+  重算在办那一步治过一次),这次是**两个人环项前后相邻**的形状,重算也救不了 ——
+  两项都还 Active,第一步仍是上一项。
+  真治法:发人卡那一刻,若卡绑的项与当前推的 view 所属项不是同一项,要么按卡所属项推件,
+  要么把这件事如实说给模型(现在它一点回声都收不到)。
+  **现状**:活动侧把动作串写死「①先 finish ②再发卡」,配测试钉措辞。
+
+- **拒回只谈行与列,数不出「缺的是一次工具调用」**:`S3_assess` 的 doneWhen 里有
+  `tool_<工具>_calls > 0`(2026-08-03 立的「机检只读基座数」扩到工具那一条),
+  模型跳过工具、自己把推荐等级填了,于是 finish 恒被拒;而拒回文案只说
+  「是不是该写 N 行只写了 M 行 / 某一行缺了必填列」—— 把注意力全导向行与列,
+  模型连着五拍重写同样的明细,熔断。
+  真治法:收步判据里那半句若是 `tool_*_calls`,拒回就该直说「这一步的收步条件里还数着
+  某某工具的调用次数,当下是 0 —— 先去调它」。这是设计律「拒回的话是模型下一拍的行动指南」
+  在工具这一类上的缺口。
+  **现状**:活动侧在 guide 里写了写盘前自检。
+
+- **执行工单绑的必交付台账一行都没有时,提交闸无牙**:卡不绑表时闸回落到
+  必交付声明的台账(`gateAddressesOf`),而 `missingReadings` 只数「已有行缺不缺必填」——
+  **零行 = 零缺**,闸开着。实测:模型压拍把卡发出去、清单一行没写,人对着空表,
+  按得下提交、按下去什么也没发生。
+  真治法待议:若一张必交付台账本单一行都没写,闸该拦并说「这张表还没有内容」;
+  但也有活动是让人在件上加第一行的(那时零行合法)—— 得由活动声明区分。
+  **现状**:活动侧把「发卡前清单必须先有行」写进说明书(每拍都在),配测试。

docs/数据域字段说明-W05.md

@@ -0,0 +1,472 @@
+# 数据域字段说明 —— ACT-WORK-05 差异评估
+
+> 对应设计中心 → 数据域「ACT-WORK-05 · 差异评估」分组。字段以活动清单的台账声明为准
+> (`activities/part-substitution-assessment/src/manifest.ts` 的 `declarations.ledger`);
+> 主数据六张(`customer.profile` / `parts.profile` / `parts.document` / `demand.request` /
+> `substitution.relation` + `difference_item` / `validation.record`)的**物理结构**由平台基线
+> `apps/api/src/app/seed-mvp-data.ts` 的 `MASTER_OBJECTS` 物化(字段名与《SS02-SS03-SS04_Demo
+> 台账字段细化与统一方案》§4.2 一字不差),声明合并对基线是**纯 add-column**:
+> 活动只追加自己要用的列与标记(required / tally / refersTo / requiredWhen / distinct),
+> 不改基线已有列的语义。那份声明同时是**授权面**:没声明的列写不进去,也不会出现在件上、
+> 判据里、数据域的活动分组里。
+
+## 怎么读这份文档
+
+- **★ = 重点字段**。每张表挑 5–8 个,在「重点字段」小节里**按重要程度从高到低**排;
+  数据结构表里在列名后打 ★。
+- **【人填】= 人在活动过程中亲手填、提交后入库的字段**(执行工单 / 数据工单的件上编辑,
+  或数据录入卡)。这类字段**一律进重点**:它们是这一单里唯一不能靠 AI 补出来的事实。
+- 「写入者」一栏的口径与「约束」一栏的词表,与 `docs/数据域字段说明-E04-I01.md`
+  「怎么读这份文档」是**同一套**,不重复抄一遍:人(件上)/ 人(录入卡)/ AI / 工具 / 基座 /
+  承继;主键 / 自增 / 必填 / 建议填 / 取值域 / 引用 / 去重计数 / 脱敏。
+  requiredWhen 类字段(某一列到某个值才必填)统一写「条件必填 · <字段>=<值> 时」——
+  与 E04-I01 的「发布时必填」是同一种约束机制,ACT-WORK-05 的触发条件不止「发布」一种,
+  所以逐列写清条件,不套用那个专用词。
+- ACT-WORK-05 比 E04/I01 多两种「写入者」写法,单列在这里:
+  - **AI(据人的意见改)** —— S4 审核决策卡驳回、T_release 打回重做时,人写的是自然语言意见,
+    不是结构化字段值;基座按字面比对定位到哪一行,AI 照意见改那一行的具体列(同 PK 覆盖写),
+    意见本身不落进任何一张台账的某一列。
+  - **AI(抄自 input_gap.supplement)** —— `demand.request` 的 `application_scenario` /
+    `bom_position` 两列,人是在 `sub_eval.input_gap` 的「补充内容」列作答,S1 收口那一拍才由
+    AI 抄进 P-01;人没有直接编辑过 `demand.request` 本身。
+
+### 一览
+
+| 全景 | 台账地址 | 人读名 | 性质 | 本活动用到的列 | 人填列 |
+|---|---|---|---|---|---|
+| L-02 | `customer.profile` | 客户档案 | 主数据 · 共享 | 4 | 3(录入卡,仅新客户) |
+| P-08 | `parts.profile` | 芯片主数据 | 主数据 · 共享 | 12 | 12(数据工单件上) |
+| P-10 | `parts.document` | 原厂技术资料库 | 主数据 · 共享 | 9 | 9(数据工单件上) |
+| P-01 | `demand.request` | 客户需求主记录 | 主数据 · 共享 | 17 | 0(应用场景 / BOM 位经执行单由 AI 抄入) |
+| P-11 | `substitution.relation` | 替代关系主记录 | 主数据 · 共享 | 17 | 0(只审不改) |
+| P-11 子 | `substitution.difference_item` | 差异明细 | 主数据 · 共享 | 15 | 0 |
+| P-06 | `validation.record` | 芯片验证记录 | 主数据 · 共享 | 8 | 0(只写验证要求) |
+| — | `sub_eval.pn_check` | 料号存在性核对 | 本活动工作台账 | 6 | 0(决策卡定放弃) |
+| — | `sub_eval.input_gap` | 评估输入清单 | 本活动工作台账 | 8 | 3(补充内容 / 加行) |
+| — | `sub_eval.verdict` | 本次评估结论 | 本活动工作台账 | 14 | 0 |
+
+九步(0.5 拆两项数据工单):绑定与存在性核对(S0_bind)→(等待数据:S0d_p08_master →
+S0d_p10_document,人)→ 人补评估输入(S1_input_confirm)→ 标准化对照表(S2_normalize)→
+逐项评估(S3_assess)→ 人审结论(S4_review,可循环)→ 拟落账(S5_prepare_landing)→
+人放行(T_release)。四道人环里 S0d_p08_master / S0d_p10_document / S1_input_confirm 三道
+往台账里写下人亲手填的事实,S4_review / T_release 两道是审核与签字(人写意见,AI 据意见改台账)。
+
+---
+
+## 一、`customer.profile` 客户档案(L-02 · 共享主数据)
+
+本活动平时**不建这张表**,只在客户不在库(启动入参 `customerCode` 在 `customer.profile`
+里查无记录)那一刻代行建档职责:S0_bind 发一张数据录入卡,人核对名称与行业区域后确认。
+除此之外整个活动流程里再不碰这张表。
+
+**重点字段(按重要程度)**
+
+1. `customer_code` ★ 主键 —— 值取自启动入参 `customerCode`,AI 不许自编;人在录入卡上核对确认,不是自由填写
+2. `name` ★【人填】必填 —— 无名档案进不了正式表(与 E04 同一条墙);`customerName` 有给就 AI 预填,人核对
+3. `industry` ★【人填】建议填 —— 所属行业,录入卡上从零填
+4. `region` ★【人填】建议填 —— 区域,录入卡上从零填
+
+**数据结构**
+
+| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
+|---|---|---|---|---|---|
+| `customer_code` ★ | 客户编码 | text | 主键 | AI(抄入参 customerCode)/ 人(录入卡确认) | 老客户沿用,不经这张卡 |
+| `name` ★ | 客户名称 | text | 必填 | AI 预填(`customerName`)/ 人(录入卡) | 没传 `customerName` 就整格空着让人填 |
+| `industry` ★ | 所属行业 | text | 建议填 | 人(录入卡) | |
+| `region` ★ | 区域 | text | 建议填 | 人(录入卡) | |
+
+---
+
+## 二、`parts.profile` 芯片主数据(P-08 · 共享主数据)
+
+一张表:料号一行,标准化参数集是它的一个字段(一行一参数
+`参数名 | 值 | 单位 | hard/soft | 说明`,值是「未披露」的进 UNKNOWN)。库里按 `internal_pn`
+查无记录 → 发**数据工单**,人在工作区的件上从零建整条(可加行);有上传 datasheet 就
+AI 先按文本预填、人核对,没有就人全填;确认落草稿层,T_release 放行时才与其余表一起并入
+正式版。
+
+**重点字段(按重要程度)**
+
+1. `internal_pn` ★【人填】主键 —— 全链路只认它,不可自由文本
+2. `normalized_parameter_set` ★【人填】必填 —— 差异评估逐项比对的唯一输入;「未披露」进 UNKNOWN
+3. `lifecycle_status` ★【人填】必填 · 取值域 `active/nrnd/eol/discontinued/risk`
+4. `package` ★【人填】必填 —— 硬约束
+5. `specification_description` ★【人填】必填
+6. `brand_name` ★【人填】必填
+7. `datasheet_ref` / `datasheet_version` ★【人填】建议填(成对)—— 证据回链
+
+**数据结构**
+
+| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
+|---|---|---|---|---|---|
+| `internal_pn` ★ | 内部料号 | text | 主键 | 人(件上)/ 种子 | 已在库的候选(如样例里预播的 LM2596S-5.0)不经这张单 |
+| `brand_name` ★ | 品牌名称 | text | 必填 | 人(件上)/ AI 预填 | |
+| `manufacturer_name` | 制造商名称 | text | 建议填 | 人(件上) | 与品牌不一致时分开记 |
+| `specification_description` ★ | 规格描述 | text | 必填 | 人(件上)/ AI 预填 | |
+| `normalized_parameter_set` ★ | 标准化参数集 | text | 必填 | 人(件上)/ AI 预填 | 一行一参数,不建子表 |
+| `package` ★ | 封装 | text | 必填 | 人(件上)/ AI 预填 | 硬约束 |
+| `process_technology` | 工艺 | text | 建议填 | 人(件上) | 硬约束 |
+| `lifecycle_status` ★ | 生命周期状态 | text | 必填 · 取值域 | 人(件上,下拉) | |
+| `eol_pcn_status` | EOL/PCN 状态 | text | 建议填 | 人(件上) | |
+| `datasheet_ref` ★ | Datasheet 引用 | text | 建议填 | 人(件上)/ AI 预填 | |
+| `datasheet_version` ★ | Datasheet 版本 | text | 建议填 | 人(件上)/ AI 预填 | 有引用就该有版本 |
+| `application_scenarios` | 适配应用场景 | text | 建议填 | 人(件上) | |
+
+---
+
+## 三、`parts.document` 原厂技术资料库(P-10 · 共享主数据)
+
+按 `internal_pn` 查无资料记录 → 发**数据工单**(与 P-08 那张分开,一张表一张单,
+在 P-08 那张确认之后再发);S0d_p08_master 那一步先写骨架(`document_type` /
+`document_status` / `brand_name` 三格能填就填),人在 P-10 数据工单的件上补齐其余列。
+同一料号多份资料就多加几行,序号 `01`/`02`… 人自己续(不是自增列)。
+
+**重点字段(按重要程度)**
+
+1. `document_ref` ★【人填】必填 —— 资料文件链接,差异评估的证据引用要指到它
+2. `internal_pn` ★【人填】主键之一 —— 关联料号,与 P-08 同一个内部料号
+3. `doc_seq` ★【人填】主键之一 —— 同一料号下 01/02… 人自己续号
+4. `document_type` ★【人填】必填 · 取值域 —— `datasheet/app_note/reference_design/white_paper/sample_doc/commitment_letter/other`
+5. `document_title` ★【人填】必填
+6. `document_version` ★【人填】必填
+7. `document_status` ★【人填】必填 · 取值域 `valid/expired/pending/void`
+8. `citation_locator` ★【人填】建议填 —— 页码 / 章节 / 表格,证据定位精确到这里
+
+**数据结构**
+
+| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
+|---|---|---|---|---|---|
+| `internal_pn` ★ | 关联内部料号 | text | 主键之一 | 人(件上) | 与 P-08 那一行同一个键 |
+| `doc_seq` ★ | 资料序号(同一料号下 01/02…) | text | 主键之一 | 人(件上) | 不是自增列,人自己续号 |
+| `document_type` ★ | 资料类型 | text | 必填 · 取值域 | AI 预填骨架(S0d_p08_master)/ 人(件上,下拉) | |
+| `brand_name` | 品牌名称 | text | 建议填 | AI 预填骨架 / 人(件上) | |
+| `document_title` ★ | 资料标题 | text | 必填 | 人(件上) | |
+| `document_version` ★ | 资料版本 | text | 必填 | 人(件上) | |
+| `document_ref` ★ | 资料文件链接 | text | 必填 | 人(件上) | |
+| `citation_locator` ★ | 证据定位(页码/章节/表格) | text | 建议填 | 人(件上) | |
+| `document_status` ★ | 资料状态 | text | 必填 · 取值域 | AI 预填骨架(pending)/ 人(件上,下拉) | |
+
+---
+
+## 四、`demand.request` 客户需求主记录(P-01 · 共享主数据)
+
+S0_bind 新建 V1(客户 / 需求描述 / 原 PN 三项照入参原样落,启动时未收的 `application_scenario`
+/ `bom_position` 先不写);S1_input_confirm 人在评估输入清单上把这两项的「补充内容」补上,
+AI 收口那一拍原样抄回本表;S5_prepare_landing 放行前回写风险等级 / 验证要求 / 输出链接 /
+下一步动作 / 当前阶段五项(`current_stage = "gate03"` 那一刻这五项转为必填)。**本表没有一列
+是人直接编辑的**——人的手笔经由 `sub_eval.input_gap.supplement` 间接进来。
+
+**重点字段(按重要程度)**
+
+1. `request_id` ★ 主键 —— 需求编号,与 `eval_ref` 用同一串时刻数字铸出
+2. `customer_code` ★ 必填 · 引用 `customer.profile.customer_code`
+3. `request_description` ★ 必填 —— 客户需求原话,S0 落一次,不许改写
+4. `original_internal_pn` ★ 必填
+5. `application_scenario` ★ 建议填 —— 启动时未收,人在评估输入清单补的「补充内容」由 AI 抄进这一格(本表唯一带着人手笔的两列之一)
+6. `bom_position` ★ 建议填 —— 同上
+7. `risk_level` ★ 条件必填 · `current_stage=gate03` 时 —— 放行回写五项之一,取各候选风险最高档
+8. `verification_requirement` ★ 条件必填 · `current_stage=gate03` 时 —— 列出挂的验证任务号
+
+**数据结构**
+
+| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
+|---|---|---|---|---|---|
+| `request_id` ★ | 需求编号 | text | 主键 | AI | `REQ-` + 案号数字串 |
+| `customer_code` ★ | 客户编码 | text | 必填 · 引用 `customer.profile.customer_code` | AI | |
+| `requirement_version` | 需求版本 | text | 必填 | AI | 恒 `V1` |
+| `request_type` | 需求类型 | text | 必填 | AI | 恒「技术需求」 |
+| `request_description` ★ | 需求描述 | text | 必填 | AI | 入参原话,不改写 |
+| `input_snapshot_ref` | 输入快照 | text | 必填 | AI | `SNAP-` + 案号数字串 |
+| `original_internal_pn` ★ | 原内部料号 | text | 必填 | AI | |
+| `bom_position` ★ | BOM 位 | text | 建议填 | AI(抄自 `sub_eval.input_gap.supplement`) | 启动时未收 |
+| `application_scenario` ★ | 应用场景 | text | 建议填 | AI(抄自 `sub_eval.input_gap.supplement`) | 启动时未收 |
+| `technical_constraints` | 技术约束 | text | — | AI | 人加的 input_gap 行汇总成一句 |
+| `risk_level` ★ | 风险等级 | text | 条件必填 · `current_stage=gate03` | AI | 取各候选 `risk_level` 最高档 |
+| `verification_requirement` ★ | 验证/复测/确认要求 | text | 条件必填 · `current_stage=gate03` | AI | 列出所有挂的 VAL 号 |
+| `request_status` | 需求状态 | text | 必填 · 取值域 | AI | `pending → responded` |
+| `current_activity` | 当前 Activity | text | 条件必填 · `current_stage=gate03` | AI | 恒 `ACT-WORK-05` |
+| `current_stage` | 当前阶段 | text | — | AI | `assessing → gate03` |
+| `next_action` | 下一步动作 | text | 条件必填 · `current_stage=gate03` | AI | 恒「提交 ACT-GATE-03 评审放行」 |
+| `output_ref` | 标准输出链接 | text | 条件必填 · `current_stage=gate03` | AI | `RPT-` + 案号数字串 |
+
+---
+
+## 五、`substitution.relation` 替代关系主记录(P-11 · 共享主数据)
+
+一个未放弃的候选一条:S2_normalize 写骨架(不含推荐/风险/摘要)、S3_assess 用两枚工具的
+出参回填推荐等级与风险(**AI 原样抄,不改一字**)、S4_review 只审不改(人写意见,AI 据
+意见改具体列)、S5_prepare_landing 把 `analysis_status` 推到 `fae_confirmed`。**本活动没有
+一列是人直接编辑的** —— 人的动作是通过 S4/T_release 的决策卡意见间接改台账。
+
+**重点字段(按重要程度)**
+
+1. `substitution_relation_id` ★ 主键
+2. `eval_ref` ★ 必填 —— **本活动新增列(基线没有)**,评估案号,与 `pn_check` / `verdict` 同一个 `eval_ref` 串联全单
+3. `candidate_internal_pn` ★ 必填 · 引用 `parts.profile.internal_pn`
+4. `original_internal_pn` ★ 必填 · 引用 `parts.profile.internal_pn`
+5. `recommendation_level` ★ 必填 · 取值域 `recommended/conditional/alternate/not_recommended` —— 工具算,AI 照抄不改一字
+6. `analysis_status` ★ 必填 · 取值域 —— 分析层状态,S5 推到 `fae_confirmed`
+7. `risk_level` ★ 必填 · 取值域 `low/medium/high/critical` —— 工具算
+8. `rule_version` ★ 必填 —— 随结论落账,锁定 `R-2026.07`
+
+**数据结构**
+
+| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
+|---|---|---|---|---|---|
+| `substitution_relation_id` ★ | 替代关系ID | text | 主键 | AI | `REL-<案号数字串>-01/02…` |
+| `eval_ref` ★ | 评估案号 | text | 必填 | AI | 本活动新增列(基线没有) |
+| `request_id` | 关联需求编号 | text | 必填 | AI | |
+| `bom_position` | 关联 BOM 位 | text | 建议填 | AI | 照 `demand.request` 现值抄 |
+| `original_internal_pn` ★ | 原内部料号 | text | 必填 · 引用 `parts.profile.internal_pn` | AI | |
+| `candidate_internal_pn` ★ | 候选内部料号 | text | 必填 · 引用 `parts.profile.internal_pn` | AI | |
+| `substitution_type` | 替代类型 | text | 必填 · 取值域 | AI | `pin_to_pin/functional/parametric/other` |
+| `recommendation_level` ★ | 推荐等级 | text | 必填 · 取值域 | 工具(`recommend`)→ AI 照抄 | |
+| `recommendation_reason` | 推荐理由 | text | 必填 | AI(可按人的驳回意见改) | 工具 reason 扩写成人话 |
+| `difference_summary` | 差异摘要 | text | 必填 | AI | 「7 项比对:4 MATCH / 1 MISMATCH / 1 UNKNOWN / 1 CONDITIONAL」句式 |
+| `risk_level` ★ | 替代风险等级 | text | 必填 · 取值域 | 工具(`recommend`)→ AI 照抄 | |
+| `verification_requirement` | 验证要求 | text | 条件必填 · `recommendation_level=conditional` | AI | 列出 VAL 号 |
+| `validation_id` | 关联验证ID | text | — | AI | |
+| `analysis_status` ★ | 分析状态 | text | 必填 · 取值域 | AI | `ai_draft → fae_confirmed`(其余三档本活动不写) |
+| `analysis_report_ref` | 替代分析报告 | text | 建议填 | AI | `RPT-<案号数字串>` |
+| `confidence_score` | 证据可信度 | number | 建议填 | AI | 取各行 `confidence` 最小值 |
+| `rule_version` ★ | 差异规则版本 | text | 必填 | AI | 锁定 `R-2026.07` |
+
+> **只读边界**:基线在这张表上还建了 `customer_approval_status` / `customer_approval_at` /
+> `customer_approval_ref` 三列,由**独立审批流**维护;本活动的声明里没有这三列的写权
+> (禁令 `no-customer-approval-write`)。落账确认那一屏那一格是静态文案
+> 「未提交 · 由审批流程维护,本活动不产生」,不是可取值的 `data-slot`
+> ——审批流做起来后才改成真读数(见 `docs/debt.md`)。
+
+---
+
+## 六、`substitution.difference_item` 差异明细(P-11 子表 · 共享主数据)
+
+一条参数一条记录。S2_normalize 按原 PN 的参数集写骨架(不含四态/影响)、S3_assess 第一拍
+调 `compare-parameters` 拿到四态与风险后**原样抄回** `difference_status` / `compare_result` /
+`risk_level`,AI 自己只补写证据引用 / 影响说明 / UNKNOWN 去向;S4_review 驳回时人写的意见由
+AI 定位到具体行后改 `impact_statement` / `unknown_disposition` / `evidence_ref`。
+`substitution_relation_id` 标了 `distinct`,「几条关系已经有明细」就是数它的不同值数
+(S2 收步、S3 收步都读这个数)。
+
+**重点字段(按重要程度)**
+
+1. `substitution_relation_id` ★ 主键之一 · 去重计数 —— 「几条关系已有明细」就是数它的不同值
+2. `difference_item_id` ★ 主键之一
+3. `difference_status` ★ 必填 · 取值域 `match/mismatch/unknown/conditional` —— 工具算,AI 原样抄
+4. `compare_result` ★ 建议填 —— **本活动新增列(基线没有)**,工具出参原样存底,供复核
+5. `constraint_type` ★ 必填 · 取值域 `hard/soft` —— 决定这一项差异判得严不严
+6. `evidence_ref` ★ 必填 —— 证据引用,验收判据「证据链可信」逐行核对它
+7. `impact_statement` ★ 必填 —— MATCH 写「无」,其余写清对应用 / 验证 / 报价的影响
+8. `unknown_disposition` ★ 条件必填 · `difference_status=unknown` 时 —— **本活动新增列(基线没有)**,UNKNOWN 的去向(挂验证任务号 / 补来源动作)
+
+**数据结构**
+
+| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
+|---|---|---|---|---|---|
+| `substitution_relation_id` ★ | 替代关系ID | text | 主键之一 · 去重计数 | AI | |
+| `difference_item_id` ★ | 差异明细ID | text | 主键之一 | AI | `<关系id>-P01/P02…` |
+| `parameter_name` | 标准参数名 | text | 必填 | AI | |
+| `original_value` | 原物料参数值 | text | 必填 | AI | |
+| `candidate_value` | 候选物料参数值 | text | 必填 | AI | 候选没有这个参数写「未披露」 |
+| `parameter_unit` | 参数单位 | text | 建议填 | AI | 以原 PN 为准 |
+| `constraint_type` ★ | 约束类型 | text | 必填 · 取值域 | AI | 原 PN 那一行的 hard/soft |
+| `compare_result` ★ | 比对结果(工具出参) | text | 建议填 | 工具(`compare-parameters`)→ AI 照抄 | 本活动新增列 |
+| `difference_status` ★ | 差异状态 | text | 必填 · 取值域 | 工具(`compare-parameters`)→ AI 照抄 | |
+| `impact_statement` ★ | 影响说明(MATCH 写「无」) | text | 必填 | AI | |
+| `unknown_disposition` ★ | UNKNOWN 去向(验证任务号 / 补来源动作) | text | 条件必填 · `difference_status=unknown` | AI(可按人的驳回意见改) | 本活动新增列 |
+| `risk_level` | 风险等级 | text | 必填 · 取值域 `low/medium/high` | 工具(`compare-parameters`)→ AI 照抄 | |
+| `evidence_ref` ★ | 差异证据引用 | text | 必填 | AI(可按人的驳回意见改) | |
+| `confidence` | AI 置信度 | number | 建议填 | AI | 0~1 |
+| `rule_version` | 差异规则版本 | text | 必填 | AI | 锁定 `R-2026.07` |
+
+---
+
+## 七、`validation.record` 芯片验证记录(P-06 · 共享主数据)
+
+事实类表:本活动只在 S3_assess 给每个 UNKNOWN 差异项挂一行「验证要求」占位
+(`validation_status` 恒写 `not_started`),不经数据工单建 —— 真正测完、写测试结果是
+另一件事(下游活动或线下流程的事)。S4_review 驳回若要补验证任务,同样由 AI 加一行。
+
+**重点字段(按重要程度)**
+
+1. `validation_id` ★ 主键
+2. `validation_internal_pn` ★ 必填 · 引用 `parts.profile.internal_pn`
+3. `validation_status` ★ 必填 · 取值域 —— 本活动只写 `not_started`(占位待测)
+4. `next_validation_action` ★ 必填 —— 要测什么、什么条件
+5. `validation_type` ★ 必填 · 取值域
+6. `request_id` ★ 必填 —— 关联需求编号
+
+**数据结构**
+
+| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
+|---|---|---|---|---|---|
+| `validation_id` ★ | 验证ID | text | 主键 | AI | `VAL-<案号数字串>-01/02…` |
+| `request_id` ★ | 关联需求编号 | text | 必填 | AI | |
+| `validation_internal_pn` ★ | 验证内部料号 | text | 必填 · 引用 `parts.profile.internal_pn` | AI | 候选 |
+| `validation_type` ★ | 验证类型 | text | 必填 · 取值域 | AI | 恒 `pin_to_pin`(本活动只挂这一种) |
+| `validation_status` ★ | 验证状态 | text | 必填 · 取值域 | AI | 恒 `not_started` |
+| `test_condition` | 测试条件 | text | 建议填 | AI | |
+| `next_validation_action` ★ | 后续验证动作 | text | 必填 | AI(可按人的驳回意见改) | 要测什么、什么条件 |
+| `evidence_ref` | 验证证据引用 | text | 建议填 | AI | |
+
+---
+
+## 八、`sub_eval.pn_check` 料号存在性核对(本活动工作台账)
+
+S0_bind 逐个料号(原 PN + 每个候选)在 `parts.profile` 里核对一遍写下的表:原 PN 一行、
+候选各一行。`exists_status` 是这张表的核心结论 —— 两项数据工单的入场哨兵、S1 的入场哨兵
+都读它。候选 ≥2 且不在库时,S0d_p08_master 发决策卡问放弃还是创建,人选的答案决定这一行
+`exists_status` 改成 `abandoned` 还是等数据工单确认后改成 `created`。
+
+**重点字段(按重要程度)**
+
+1. `exists_status` ★ 必填 · 取值域 `found/absent/created/abandoned` —— 存在性检查的核心结论,S0d 两项与 S1 的入场哨兵都读它
+2. `internal_pn` ★ 主键之一
+3. `eval_ref` ★ 主键之一 —— 串联本单十张表的案号
+4. `role` ★ 必填 · 取值域 `original/candidate`
+5. `abandon_reason` ★ 条件必填 · `exists_status=abandoned` 时 —— 人在决策卡选放弃、没写理由时,AI 补写「负责人本轮放弃(未注明原因)」
+
+**数据结构**
+
+| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
+|---|---|---|---|---|---|
+| `eval_ref` ★ | 评估案号 | text | 主键之一 | AI | |
+| `internal_pn` ★ | 内部料号 | text | 主键之一 | AI | |
+| `role` ★ | 角色 | text | 必填 · 取值域 | AI | `original`(恰一行)/ `candidate` |
+| `exists_status` ★ | 在库状态 | text | 必填 · 取值域 | AI | `found`(在库)→ 或 `absent` → `created`/`abandoned`(数据工单/决策卡确认后改) |
+| `abandon_reason` | 放弃原因 | text | 条件必填 · `exists_status=abandoned` | AI(据人的决策卡选项改) | 人选放弃未写理由时 AI 补写默认句 |
+| `note` | 备注 | text | — | AI | 如「PCN 转 NRND」 |
+
+---
+
+## 九、`sub_eval.input_gap` 评估输入清单(本活动工作台账)
+
+S1_input_confirm 一拍写全:已绑定四项(status=ok)、待补两项(应用场景/BOM 位,status=gap)、
+默认可改三项(status=default)、逐颗候选「未披露」参数各一行(status=gap)、齐备项(原 PN 资料
+版本,status=ok)。**这张表是本活动唯一让人直接在件上补内容的执行工单载体**:人在
+「补充内容」列把 status=gap 的行填上答案,也可以加一行补充 AI 没列出的资料项、删一行标
+「不适用」。
+
+**重点字段(按重要程度)**
+
+1. `supplement` ★【人填】条件必填 · `status=gap` 时 —— 缺口行的答案,这一单里唯一不能靠 AI 补出来的事实
+2. `status` ★ 必填 · 取值域 `gap/default/ok` —— 决定哪一行必须有 `supplement`
+3. `item_key` ★【人填,加行时】主键之一 —— 英文短键;已绑定 / 待补 / 默认 / 待确认各占一批行
+4. `input_item` ★【人填,加行时】必填 —— 人读名,加一行 = 补充 AI 没列出的资料项
+5. `origin` ★ —— `ai` / `human-added`,标出哪几行是人加的(与 E04 `candidate.origin` 同一口径)
+6. `source_ledger` ★ 建议填 —— 缺口来自哪张台账(P-01/P-08/P-09/P-10)
+
+**数据结构**
+
+| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
+|---|---|---|---|---|---|
+| `eval_ref` | 评估案号 | text | 主键之一 | AI | |
+| `item_key` ★ | 输入项键 | text | 主键之一 | AI / **人(件上,加行时)** | 英文短键,如 `application_scenario` |
+| `input_item` ★ | 输入项 | text | 必填 | AI / **人(件上,加行时)** | 人读名 |
+| `source_ledger` ★ | 来源台账 | text | 建议填 | AI | |
+| `status` ★ | 状态 | text | 必填 · 取值域 | AI | `gap`(待补)/`default`(默认·可改)/`ok`(齐备) |
+| `detail` | 绑定值 / 缺口说明 | text | 建议填 | AI | |
+| `supplement` ★ | 补充内容 | text | 条件必填 · `status=gap` | **人(件上)** | 唯一的人手笔答案 |
+| `origin` ★ | 来源(ai/human-added) | text | — | AI | |
+
+---
+
+## 十、`sub_eval.verdict` 本次评估结论(本活动工作台账)
+
+一单一行的收口结论,挂着几面「人环走到哪儿了」的记账旗 —— 它们是下一步能不能开工的哨兵
+(与 E04 `crm_coverage.verdict` 同一种设计)。
+
+**重点字段(按重要程度)**
+
+1. `input_confirmed_total` ★ —— 评估输入已确认(人环凭据),S2 标准化那一步的入场哨兵之一
+2. `review_approved_total` ★ —— 差异结论已审核通过(仅通过时置一),S5 拟落账那一步的入场哨兵
+3. `landing_prepared_total` ★ —— 拟落账已备好,T_release 放行门的入场哨兵
+4. `summary` ★ —— 本次评估结论,归档件上的那段话
+5. `relation_total` ★ —— 替代关系条数
+6. `recommended_total` / `conditional_total` / `alternate_total` / `not_recommended_total` ★ —— 四档分布,归档件摘要与放行口 `assessment-released` 载荷都用它
+
+**数据结构**
+
+| 列名 | 人读名 | 类型 | 约束 | 写入者 | 说明 |
+|---|---|---|---|---|---|
+| `eval_ref` | 评估案号 | text | 主键 | AI | |
+| `request_id` | 需求编号 | text | — | AI | |
+| `rule_version` | 规则版本 | text | — | AI | 锁定 `R-2026.07` |
+| `original_internal_pn` | 原内部料号 | text | — | AI | |
+| `candidate_total` | 候选数 | integer | — | AI | 候选数组长度 |
+| `input_confirmed_total` ★ | 评估输入已确认 | integer | — | AI | 人环凭据 |
+| `review_approved_total` ★ | 差异结论已审核通过 | integer | — | AI | 人环凭据(仅通过时置一) |
+| `landing_prepared_total` ★ | 拟落账已备好 | integer | — | AI | S5 写完时置一 |
+| `relation_total` ★ | 替代关系条数 | integer | — | AI | |
+| `recommended_total` ★ | 推荐 | integer | — | AI | |
+| `conditional_total` ★ | 条件推荐 | integer | — | AI | |
+| `alternate_total` ★ | 备选 | integer | — | AI | |
+| `not_recommended_total` ★ | 不推荐 | integer | — | AI | |
+| `summary` ★ | 本次评估结论 | text | — | AI | 归档件上的那段话 |
+
+---
+
+## 十一、人填字段总表(按人办事的那一屏)
+
+| 活动 · 屏 | 卡的形式 | 落进哪张表 | 人亲手填的列 |
+|---|---|---|---|
+| S0_bind · 新客户建档(仅客户不在库) | 数据录入卡(entry) | `customer.profile` | `name` · `industry` · `region`(`customer_code` 由入参给,人核对) |
+| S0d_p08_master · 候选放弃/创建抉择(候选≥2 且部分缺库) | 决策卡(decide) | 间接改 `sub_eval.pn_check.exists_status` | 选项值(`create`/`abandon`/`custom:`,不直接写字段) |
+| S0d_p08_master · 数据工单·芯片主数据创建(P-08) | 执行工单(件上编辑 + 增删行) | `parts.profile` | 全部 12 列(`internal_pn` / `brand_name` / `manufacturer_name` / `specification_description` / `normalized_parameter_set` / `package` / `process_technology` / `lifecycle_status` / `eol_pcn_status` / `datasheet_ref` / `datasheet_version` / `application_scenarios`) |
+| S0d_p10_document · 数据工单·原厂技术资料创建(P-10) | 执行工单(件上编辑 + 增删行) | `parts.document` | 全部 9 列(`internal_pn` / `doc_seq` / `document_type` / `brand_name` / `document_title` / `document_version` / `document_ref` / `citation_locator` / `document_status`) |
+| S1_input_confirm · 评估输入与资料补齐确认 | 执行工单(件上编辑 + 增删行) | `sub_eval.input_gap` | `supplement`(缺口行必填);加一行时另填 `item_key` / `input_item` |
+| S4_review · 差异评估结论审核 | 决策卡循环(通过 / 驳回 + 意见) | 间接改 `substitution.difference_item` / `substitution.relation` / `validation.record` | 意见文本(AI 据此改 `evidence_ref` / `impact_statement` / `unknown_disposition` / `recommendation_reason`;推荐等级不许改) |
+| T_release · 评审放行与落账确认 | 验收工单(签字,可打回重做) | `parts.profile` / `parts.document` / `demand.request` / `substitution.relation` + `difference_item` / `validation.record` 并入正式版 | 裁决与意见(打回后 AI 按意见改台账本身,不开新行) |
+
+---
+
+## 十二、在数据域里看这些表时的几条提醒
+
+1. **主数据是共享的,物理表里还有别的用途留下的列,本活动不写它们**:
+   - `customer.profile` 还有 `grade` / `owner` / `payment_terms` / `credit_limit` /
+     `profile_tags` / `status`(报价链早先声明的客户主台账列)
+   - `parts.profile` 还有 `customer_pn` / `pin_to_pin_relation_ref`
+   - `parts.document` 还有 `document_date` / `source_contact_ref`
+   - `demand.request` 还有 `project_code` / `bom_id` / `customer_pn`
+   - `substitution.relation` 还有 `project_code`,以及客户批准三列 + `customer_feedback`
+     (见下条,单独说明只读边界)
+   - `validation.record` 还有 `customer_code` / `test_parameters` / `test_result` /
+     `issue_risk` / `sample_version` / `sample_lot` —— 本活动只写「验证要求」占位阶段,
+     不写实测结果(那是真验证发生后才有的事实)。
+
+   记录浏览里看到它们空着是正常的;判断一列还算不算数,以**活动清单的声明**为准,
+   不以物理表结构为准。
+
+2. **本活动往两张主数据表新增了列(基线没有,声明里 add-column 长出来的)**:
+   `substitution.relation.eval_ref`(评估案号,串联本单十张表)与
+   `substitution.difference_item.compare_result` / `unknown_disposition`
+   (工具出参原样存底、UNKNOWN 去向)。这三列只对 ACT-WORK-05 生效,不影响其它活动
+   对这两张表的读写。
+
+3. **`customer_approval_status` 是只读边界,不是本活动没做完**:基线在
+   `substitution.relation` 上建了 `customer_approval_status` / `customer_approval_at` /
+   `customer_approval_ref` 三列,由**独立审批流**维护;本活动的声明里没有这三列的写权
+   (禁令 `no-customer-approval-write`)。放行前那一屏那一格是静态文案
+   「未提交 · 由审批流程维护,本活动不产生」,不是取值的 `data-slot`(见 `docs/debt.md`)。
+
+4. **`parts.profile` 的标准化参数集是一个 text 列,不是子表**:`normalized_parameter_set`
+   存的是一行一参数的行语法「参数名 | 值 | 单位 | hard/soft | 说明」,四态比对工具的入参
+   都靠**解析这段文本**,不是关系型的多行记录 —— 用户当场定的口径,《SS02-SS03-SS04》
+   字面上写的 Structure / 子表在本平台落成这样(见 `docs/debt.md`「参数集是 text 列的行语法」)。
+
+5. **数据工单是零输入执行工单 + 工作区可加行的件**:料号在 `parts.profile` /
+   `parts.document` 里查无记录时,人从零建整条记录;确认落草稿层,T_release 放行那一刻
+   才与其余表一起并入正式版(平台铁律②:写只有草稿与意向,终局唯放行)。一张表一张单:
+   P-08 一张、P-10 一张。
+
+6. **试跑单默认也落真库**:与 E04 / I01 同一个开关(`sys.task.land_master`,测试台起单
+   默认打开)—— 跑一遍活动,新建的客户档案、料号、资料记录都会真的进正式表;要它不落,
+   起单时显式关掉。
+
+---
+
+*字段口径以 `activities/part-substitution-assessment/src/manifest.ts` 的
+`declarations.ledger` 为准;六张主数据的物理结构见 `apps/api/src/app/seed-mvp-data.ts` 的
+`MASTER_OBJECTS`;计划项与卡骨架见 `activities/part-substitution-assessment/src/case-model.ts`
+的 `ASSESSMENT_STEPS` 与 `NARRATIVE`;业务设计源见 `docs/SS02-ACT-WORK-05-html/`
+(活动流程与工单说明 / 一键启动入参说明)与《SS02-SS03-SS04_Demo台账字段细化与统一方案》。*

docs/活动开发规范.md

@@ -165,7 +165,7 @@ activities/<id>/src/ ──(pnpm activities:build)──> dist/{manifest.json,in
 | 门 | 在哪 | 规则 |
 |---|---|---|
 | **起单宽进** | `process.start` | 不按 Schema 拒缺项。三活动 `input.required` 一律空(宽进严出),起单补全卡那条老路实际不再触发(彻底移除记 debt) |
-| **执行卡提交闸** | 卡面 `gate` + 服务端 | 必填缺着按不下提交(`{ready,why,blanks}`,与放行门 L1 **同一个数同一套算法**);**服务端在收下回传之前也把一遍**(前端灰按钮只是给人看的)。看哪几张表:卡上绑了 blocks 看绑的;**没绑(执行卡零输入后是常态)回落到必交付物声明的 `ledgers`/`ledger`**(`gateAddressesOf`,有测钉着)。两边都空才不给闸 —— 没有依据的时候不拦人 |
+| **执行卡提交闸** | 卡面 `gate` + 服务端 | 必填缺着按不下提交(`{ready,why,blanks}`,与放行门 L1 **同一个数同一套算法**);**服务端在收下回传之前也把一遍**(前端灰按钮只是给人看的)。看哪几张表**三级取一**(`gateAddressesOf`,有测钉着):①卡上绑了 blocks 看绑的;②**卡自己声明的 `gateLedgers`**(零输入卡该给的就是它 —— 只有发卡的人知道这一张要人补哪几张表);③回落到必交付物声明的 `ledgers`/`ledger`。三级全空才不给闸 —— 没有依据的时候不拦人。**主数据类的数据工单必须给 `gateLedgers`**:它要补的表(`parts.*`)不在必交付物名单里,不给就回落到一堆无关的表、一格不缺,件上红带点着缺项而提交钮照样绿(2026-08-27 W05 e2e 实测) |
 | **提交门**(`submit` 预检) | engines | 机检(L1/L2)**必须为真**;裁量(L3/L4)**裁过即可**(裁成「不满足」照样能提交,裁断连理由随卡交给人 —— 一条只接受「是」的判据是一句教模型说谎的提示);**L4 带谓词时谓词说了算**(谓词真 = 已达标,模型那句相反的理由一并丢掉;谓词假才轮到裁量);必交付物按 ledger 地址数本单草稿行 |
 | **放行门入场哨兵** | CMMN sentry | **必须有 ifPart,且读基座数、认「办完了没有」** —— 只有 onPart 的哨兵等于「有人写过一笔就开门」,模型写个 `false` 就推开了(实测:跳过三步直达放行门) |
 | **熔断** | Harness | 连续 5 拍行动被拒 → 停问模型,发熔断卡把拒绝理由摆给人(比对削掉串位前缀、另开 60 条窗) |
@@ -252,7 +252,7 @@ activities/<id>/src/ ──(pnpm activities:build)──> dist/{manifest.json,in
 | `ask` | ~~已退役~~ | 基座原地转成零输入执行工单(字段名并进指导书);别再用 |
 | `entry` | `{itemId, ask, ledger, entryKey, fields, also?}` | 数据录入卡,挂起;确认那一下基座直写 |
 | `decide` | `{itemId, ask, options(≥2), basis}` | 决策卡,挂起 |
-| `human` | `{itemId, workOrder, card{title,ask,steps?,standard?,basis}}` | 执行/验收工单,挂起。**执行卡零输入**(2026-08-02 用户定):不摆 `fields` 不绑 `blocks`,填写全在工作区的件上(editGate + 孪生件),人按「保存」基座直写草稿层;必填由提交闸看住(闸回落到必交付物的台账声明) |
+| `human` | `{itemId, workOrder, card{title,ask,steps?,standard?,basis}}` | 执行/验收工单,挂起。**执行卡零输入**(2026-08-02 用户定):不摆 `fields` 不绑 `blocks`,填写全在工作区的件上(editGate + 孪生件),人按「保存」基座直写草稿层;必填由提交闸看住 —— **卡上加 `gateLedgers:["域.对象"]` 告诉闸这一张要拦哪几张表**,不给才回落到必交付物声明 |
 | `listen` | `{itemId, eventType, keyFilter, deadline}` | 立监听,挂起;时限必配 |
 | `finish` | `{itemId, rationale}` | 宣告一项完成;非人工激活的项就地过 Active 再收 |
 | `submit` | `{rationale, fields?}` | 提交放行 → 预检 → 发验收卡挂起 |