package-new

> 改名说明（2026-10-08）：本 skill 原名为「病种注入器」，因上架 SkillHub 需 name 为 ASCII 短横线格式，改为 package-new（展示名同步改为 package-new）。
> 正文与 references 中出现的「病种注入器」均为改名前的历史称谓，指同一 skill；本机技能目录名仍为 病种注入器（未改，以免打断既有路径引用）。

把服务包注入指定病种，产出该病种专属版本。

两条分支（先判分支，再谈其他）

分支判定在 Step 0 的入口闸门强制完成，不得跳过。

> ⚠️ 交付必须是"一套完整版本"（2026-10-08 用户硬要求；★ 2026-10-10 按用户裁定收窄）：页面本体 ＋ 本次应产出的产品功能清单 md ＋《更新说明》，三者同批交付。
> 文档只在两种情况下产出：① 新增页面（必写）② 结构级大改页（分区增删 / 骨架顺序变化 → 整篇重写）。其余一律不产出、不做基线复制平移、删除页不用声明、首次无基线不生成。规则见 规范D。
> 交付后用户若又改了 / 又加了页面，同一套操作再执行一遍（见「交付后再变更 · 增量同步」）。规则见 规范D。

> ⚠️ 两条分支的逐页依据互不通用：规范A 的 471 项绑死在通用型 46 页编号体系上，分支 B 完全不适用；分支 B 的逐页清单由 Step B3 现场扫出的残留矩阵承担。
> ⚠️ 源包类型判错 = 后面全错。若把专属包当成通用型跑，skill 只能做全局字符串替换，必然留下整包的前序病种语义残留（60+ 页量级）。这正是本 skill v3.0 立分支的直接原因。

适用范围（2026-10-07 用户裁定）

包构成（分支 A）

B 患者端 ×14 ＋ D 中心医护端 ×21 ＋ F 管理端 ×11 ＋ assets/（图表库 ＋ Font Awesome 6.4.0 的 CSS，字体二进制由首次运行下载）＝ 46 页

> ⚠️ A01 已删除（2026-10-07 用户确认）。历史规范（规范A / 规范B）中所有 A01 条目同步作废。
> 若源包内出现 A01* 文件 → 停下问用户，不得自行处置。

内置标准模板（assets/templates/）

> ⚠️ 包内不含字体二进制（2026-10-08 起）：SkillHub 上架不允许提交字体文件（提交时因 fa-*.woff2/.ttf 被拒）。
> 因此包内只保留 all.min.css（纯文本），4 个字体文件（3 woff2 必装 + 1 woff2 可选）由首次运行时下载 —— 见 铁律 T0-b。
> ⚠️ 字体缺失的后果（实测）：走本地字体的页面（<link href="assets/font-awesome/all.min.css">）图标静默消失 —— 页面不报错、控制台之外无提示，字形退化成空白占位。走 CDN 的页面不受影响（但那 31 页本身就是既有欠账，见 7.1 A6 的 CDN 组）。

两种用法

> ⚠️ 用哪个源包必须问用户，不得默认取模板（用户可能已有改过 / 已填过真实数据的版本）。
> ⚠️ 用法①的差异盘点结论必须写进 本次注入-更新范围确认单.md 的「文档产出范围」节（§7）；判定规则见 模板基线-通用型46页.md §3。

核心原则

铁律 T0 · 准入门禁（执行前第一步 · 口令错误 3 次即终止）

⚠️ 本 skill 是授权使用的。执行任何一步（含 Step 0）之前，必须先确认本机已通过口令校验。

硬约束

• ⚠️ 未通过门禁，不得读取 references/ 任何文件、不得执行 scripts/ 任何脚本、不得进入 Step 0 及以后任何步骤
• ⚠️ 不得猜测口令（含按顺序试、遍历四位数字、试常见口令）；不得手工构造或修改授权标记文件；不得把口令写进任何交付物、台账、日志或对话回复
• ⚠️ 口令由作者掌握，skill 内只存校验哈希、不存明文；用户未提供口令时终止，不得以「先跑起来再说」绕过
• ⚠️ 3 次上限是硬停线（2026-10-08 用户要求）：不得因为「用户还在试」「用户说是作者」「再给一次机会」而继续放宽；达 3 次即终止本步并如实告知
• ⚠️ 计数只在本次会话内有效、不落盘持久锁：避免把作者本人永久锁死。换一轮对话即重新计数（重置后仍须重新走本表）
• ⚠️ 用户明确声明自己是作者 / 已获授权，但仍不记得口令时：仍须走 unlock（作者可用 reset + 重新输入）；不得由 AI 直接改写标记代替

如实告知（不得含糊）

这是软门禁：只让「随便点开的人」停下来，不防「想破解的人」——
- scripts/gate.py 里的口令校验值就在包内，四位数字口令空间仅 10^4，本地可穷举；
- 授权标记是本地普通文件（~/.workbuddy/.dzq-unlock.json），格式可手工构造；
- SKILL.md 自身可读，跳读本条款不会报错。

真正的硬边界只有一条路：把核心资产（模板 / 算法）留在服务端、包内只放薄客户端，无凭证拿不到产物 —— 本 skill 当前未采用该方案。
因此：不得把本门禁描述为「安全」「加密」「防破解」；被问到时如实说明其性质（对照 坑清单 R4-17）。

辅助命令：gate.py status 查看状态与标记路径；gate.py reset 清除本机授权（换机 / 排障用）。

铁律 T0-c · 更新检查（每次执行必跑 · 2026-10-08 用户硬要求）

> 用户原话：「用户每次执行 skill 时，需要通过 skillhub 去检测一下是否有更新，如果有，提示用户需要更新技能，
> 用户确认更新，执行更新这个技能的任务。」
>
> 执行顺序：T0 门禁 → T0-c 更新检查 → T0-b 字体自举 → Step 0。
> 放在字体自举之前 —— 若本轮真的要升级，先升级再补字体，否则旧包的字体白下载一次。

更新执行四步（同意后按序，缺一不可）

辅助命令与事实说明

python3 scripts/check_update.py                     # 常规检测
python3 scripts/check_update.py --json              # 机器可读（主流程解析用）
python3 scripts/check_update.py --selftest          # 版本比较自测

• 为什么不用 skillhub upgrade --check-only 作为主路径：它要求包内 config.json 含 update_url，
  且该 URL 必须返回 CLI 认的 manifest 形状（version ＋ zip_url/download_url）。本 skill 无 config.json，
  实测直接 skip: config.json not found；平台技能详情接口返回的是 latestVersion.version，不是 CLI 认的形状。
  故主路径走 check_update.py（直查平台接口），同时在包内存在合法 config.json 时并行跑一次官方命令交叉印证（见脚本 --json 输出的 official 字段）。
• --force 是破坏性的：它 rmtree 目标目录后解压，本地未上架的改动会全部丢失。

硬约束

• ⚠️ 每次执行 skill 都要检测一次（含增量同步、排障、只跑某一步的场合；检测本身不是打包，也不构成升版许可 —— 见 T0-d）；不得以「刚才查过」「应该是新的」为由跳过
• ⚠️ 未经用户确认，不得执行更新；未完成整目录备份，不得执行 install --force
• ⚠️ 「本地高于平台」时只提示、不覆盖 —— 这种情况通常是本地有未上架的改动（例：本轮改动尚未发布时，本地 1.1.0 > 平台 1.0.1）
• ⚠️ 版本号由用户指定，不得自行累加（★ 2026-10-10 用户裁定）—— SKILL.md 的 version 唯一基线是平台实测版本（check_update.py 输出的「平台 X.Y.Z」）；本地 frontmatter 只是「下次要提交的号」，不是「已存在的版本」。
  真相：2026-10-10 本地记到 1.0.8，而平台实际是 1.0.4 —— 中间 4 个号从未上架，却被坑清单与规范当成既成事实引用。
  升版前先跑一次 check_update.py 对账；升不升、升到几，由用户定（坑清单 R1-34）。
  ⚠️ 打包与版本号的禁止自主动作另立一条铁律：见 T0-d。
• ⚠️ 更新成功后不得继续闷头干活：必须停下并建议重开一轮，避免旧规则继续驱动新版本
• ⚠️ 检测失败不得阻断也不能谎报「已是最新」——如实说「本次未能检测到更新」

铁律 T0-b · 首次运行资源自举（字体）

> 本 skill 的包内不含字体二进制 —— SkillHub 上架不允许提交字体文件（2026-10-08 提交时因 fa-*.woff2 / fa-*.ttf 被拒）。
> 包内只保留 assets/font-awesome/all.min.css（纯文本 CSS）；4 个字体文件由首次运行时下载（3 必装 + 1 可选，逐文件 sha256 钉死）。

硬约束

• ⚠️ 字体没补齐，不得进入 Step 0：字体缺失时页面不报错，但走本地字体的页面图标会静默消失（@font-face 加载失败 → 字形退化为空白占位，实测 document.fonts.check() 返回 false、图标宽度由 36px 掉回 32px 空框）。而 verify_pkg.py / review_pkg.py 都不检查字体文件 —— 不主动 check 就发现不了
• ⚠️ 不得用 CDN 顶替：页面必须走本地 assets/font-awesome/（规范B 明文禁止 CDN 图标库；review_pkg.py A6 组仍在判 FAIL 的「31 页仍走 CDN 图标库」就是这条欠账）。fetch 是把文件补到本地，不是把页面改成 CDN 引用
• ⚠️ 不得把字体二进制加回包内：重新打包上架前必须 strip
• ⚠️ 交付给用户的服务包应带字体：cp -R <模板> 时字体已在本地 → 产物自带，这是正常的（上架限制只针对本 skill 的上架提交包，不针对你交付给客户的服务包）。但若你的交付通道也有同类限制，需另行处理并告知用户

两态切换（工作态 ↔ 上架态）

python3 scripts/fetch_fonts.py strip    # 上架态：删除字体二进制（提交前必做）
python3 scripts/fetch_fonts.py fetch    # 工作态：复原字体（提审后立刻执行，否则页面图标全废）

铁律 T0-d · 打包与版本号 · 禁止自主动作（★ 2026-10-11 用户立规）

> 用户原话：「在我没有告诉你打包封版的情况下，不要打包，不要自行定义版本号。」

硬约束

• ⚠️ 不得以「顺手」为由打包：改完规则 / 改完模板 / 跑完校验，都不构成打包理由
• ⚠️ 不得以「版本号该升了」为由改 version：check_update.py 输出的平台版本只是对账基线（R1-34），不是升版许可
• ⚠️ 不打包如何交付：原地交付（给出文件路径 + 改动小结）；用户要 zip 时会明说
• ⚠️ T0-c 的检测与升级链照常保留（2026-10-11 用户确认）—— 「检测 → 提示 → 用户同意 → 整目录备份 → install --force」不受本条款影响；被禁的是 AI 主动发起的打包与升版

铁律 T1 · 非明确不改

病种需求未对该页面的展示逻辑作出明确调整时：

• ❌ 不得修改模板的布局与排版格式（网格列数、分区顺序、间距体系、对齐方式、卡片结构）
• ❌ 不得增加任何未明确的元素（图标、字段、按钮、区块、标签、文案、颜色、层级）
• ❌ 不得删除 / 合并 / 重排既有元素，即使看起来冗余
• ❌ 不得做"既然改到这里就顺便…"的顺带优化

只改需求字面明确指向的那一处。需求没提到 = 不动。要补位 → 先问；不确定 → 先问。

T1-b · 分支 B 例外条款（2026-10-03 用户裁定）

当且仅当走「分支 B」（源包 = 病种专属成品包）时，T1 的判定基准如下调整：

> 该例外只对分支 B 生效。分支 A 一律回到 T1 原文（非明确不改）。

铁律 T2 · 不读记忆、不写记忆

理由：病种页面必须由当次需求驱动，避免历史偏好污染输出；保证同一需求多次生成结果一致。

T3 · 交付物 ≠ 记忆

T2 禁止写记忆，但必须产出交付文件给用户（存用户指定目录，属交付物、非记忆）。

交付物分两层，缺任一层都不算「一套完整版本」（2026-10-08 用户硬要求）：

> ⚠️ 甲层是成套交付的硬要求：历史上只有乙层（"这次改了什么"），没有一份描述页面本身。甲层由 Step 6.7 产出、Step 7 的 A12 组把关，不通过不得交付。
> ⚠️ 2026-10-10 起甲层的口径：不是「每页都要有文档」 —— 文档是增量说明书（新增页 / 结构级大改页），不是页面全集目录。包内文档数 < 页面数是正常状态。

乙层 ＝ 唯一一份：本次注入-更新范围确认单.md（★ 2026-10-09 用户裁定）

> 用户原话：「输出的内容只有更新范围清单，其他的包外的 md 文档都不要。包内的保持不变。」
> 因此包外不再产出任何其他文件 —— 原先的台账 / 改动摘要 / 校验报告 / 缺陷登记 / 复核配置 / 源包判定单 / 资产清单 / 术语三色表 / 残留矩阵一律取消，内容按下表归位。

本次注入-更新范围确认单.md 固定 8 节（Step B4 / Step 5 收口时一次成稿）：

> ⚠️ §2–§4 的分析过程在对话里当场呈现、当场确认，确认后的结论进确认单 —— 目的是不留过程文件，但不丢证据。
> ⚠️ 确认单只增节、不拆文件：分支 B 出 §1–§8；分支 A 出 §1–§7 即止。
> ⚠️ 包外目录里除了这一份，出现任何其他文件都算违反本 skill。

> ⚠️ 回写边界：复核结束后允许向本 skill 自身回写（references/坑清单-已知缺陷与防复发.md、scripts/），这属于工具维护、不是写记忆。
> 但若要改 references/规范A / 规范B / 规范D / 规范E（改规范即改 skill 规则），必须先取得用户确认 —— 依据是用户级刚性约束「对 skill 内容 / 流程的任何修改必须经用户交互确认」，与"是否存在外部正本"无关（本 skill references 全部是本地资产，无外部正本，见文末 references 索引）。

覆盖范围与基线

分支 A（通用型源包）

> ⚠️ 若包内页数与上表不符（用户已增删过页面），以实际文件清单为准，并在 Step 0 与用户核对。
> ⚠️ 源包内出现 A01* 文件 → 停下问用户（与「A01 已删除」的既定基线冲突）。
> ⚠️ F 端特点：11 页全部走 CDN 图标库（须改本地，见 24-20）；每页均有 XX医院 绑定（1–32 处）；F06 含真实姓名「黄国栋」；F03 含糖尿病残留 hba1cValues；F11 含糖尿病量表 id。

分支 B（病种专属源包）

> ⚠️ 规范A 在分支 B 不适用 —— 其 471 项绑死在通用型 46 页编号体系上，与专属包（index.html / patient/* / scale/* / 英文驼峰命名等）不是一套。
> 分支 B 的"逐页清单"由 Step B3 现场扫出的残留矩阵承担（页 × 八类载体 × 命中）—— 结论写进 本次注入-更新范围确认单.md §8.3（不再单独出文件）。
> ⚠️ 分支 B 的产物保留源包原有页数与结构，不追求对齐 46 页体系（2026-10-03 用户裁定）。

占位符速查表（分支 A 专用）

> 分支 B 的源包里没有占位符——全是实体值。分支 B 的"替换清单"来自 Step B2 的术语三色表与 Step B3 的残留矩阵（两者均落在确认单 §8，不单独出文件）。

流程 Step 0–7（逐步执行，每步须用户确认后才进入下一步）

> 🔒 执行前先过 T0 门禁：python3 scripts/gate.py check（退出码 0 才继续；2 则向用户索取口令并 unlock）。
> 🔤 再过 T0-b 资源自举：python3 scripts/fetch_fonts.py check（退出码 0 才继续；2 则 fetch）—— 字体缺失时页面图标会静默全废，而所有校验脚本都查不出来。
> 未通过以上两项，不得读 references/、不得跑任何业务脚本、不得进入 Step 0。

Step 0 · 前置：源包类型判定（入口闸门）+ 确认基线与装配规范

0.0 ★ 源包类型判定闸门（强制，判错则全错）

python3 scripts/detect_source_pkg.py <源包目录>

三条判据（原始输出必须贴进台账与判定单）：

> ⚠️ 不要用「词频/词表」判源包类型。 初版曾用"高频专有短语 ≥3 条"作判据 2，实测把通用型模板也判成病种专属 ——
> 因为无监督提取出的 n-gram 全是滑动窗口碎片，且通用型模板本身就残留着历史底版的量表名。
> 判据 2 因此改为「具体实体值」（通用型写占位符、专属包写实体值，这是两者真正的分界），
> 高频专有短语降级为参考信息（打印出来供人工辨别，不参与判定）。
> 另：若源包目录里嵌套了另一个独立包（如 通用型全病程服务包/），工具会自动分离并提示，判定只针对主包。

判定 → 分支

必问三项（不可只靠机器判定）：

1. 这是什么包？（通用型模板 / 某个具体病种的成品包）
2. 若是成品包：前序病种是什么？目标病种是什么？（两者都写进台账）
3. 前序病种名一律以源码取证为准——不得凭印象、不得读项目记忆（铁律 T2）

产出：判定结论写入 本次注入-更新范围确认单.md §1（判据原始输出 ＋ 判定结果 ＋ 分支选择 ＋ 用户确认）。

0.1 装配规范（按分支取用）

再读取目标源包目录，核对实际页面清单。

> ⚠️ 源包从哪来必须问用户：① 用户自带目录 / zip；② 用 skill 内置模板（assets/templates/…）。
> 不得默认取模板 —— 用户手上可能是已改过、已填过真实数据的版本（误判会覆盖既有成果）。

0.2 确认基线状态（必问）

基线核对的现成手段（分支 A）

TPL="$HOME/.workbuddy/skills/病种注入器/assets/templates/通用型全病程服务包-V3.3"
diff -rq "$TPL" <用户源包目录> 2>&1 | grep -v '\.DS_Store'   # 空 = 与内置模板逐文件一致

详见 references/模板基线-通用型46页.md §3。

0.3 建立唯一包外产物：更新范围确认单

在用户指定目录创建 本次注入-更新范围确认单.md（包外只此一份，见 T3），先把 §1（源包判定）填上。Step 0–7（分支 B 另加 Step B0–B4）的每步确认结论逐节追加进去；状态在对话内保持，不再另立台账文件。包外目录里除这一份外不得出现任何其他文件。

0.4 前置声明

向用户声明：本次执行不读记忆、不写记忆；非明确不改（分支 B 另适用 T1-b 例外条款）；本次走分支 A / 分支 B。

输出：确认单已建，§1 已填（源包判定 ＋ 页面基线确认：页数 / 编号 / 文件名 / 基线状态）。

★ 分支 B 前置阶段 · Step B0–B4（逐页依据 = 规范C-源包解绑规范.md）

> 仅当 Step 0.0 判定为「病种专属」时执行。
> 目标：把前序病种语义从整包里解绑干净，再注入目标病种。
> 顺序硬约束：B1–B4 全部完成并经用户确认后，才允许进入 Step 1。

分支 B 的四条硬约束（对应审计四大教训）

1. 🟡 黄词的处置必须先于、或至少与 🟢 绿词替换同页成对完成。
   严禁"先全局替换病种名，周边语义以后再补"——审计实测产出「慢性胃炎术后需要扩肛」这类语义荒谬组合，且因旧值已 0 命中，现有 B1 组查不出来（新增 A9-3 专查，见 §7.0）。
2. 删除页必须同步：文件 / 全部入口链接 / 页面索引（＋ 若包内另有页数计数器则一并同步）。审计里出现过"入口清了、列表展示名还在"。
3. 镜像对必须同批处理：识别出的 B 端 ↔ D 端镜像页不得只改一端——审计中 B07 / B45 患者端已重写而 D18 / D22 等医生端整批落下（新增 A9-4 专查）。
4. 内容资产群整篇重写，不做字符串替换：入组问卷、科普文章库、病历模板、量表题库、标签库、科研队列、预警类型表、随访模板库——字符串替换会产出自相矛盾的题项。

执行顺序（Step 1–7 内的差异）

Step 1 · 确认机构与人员

必问三项（点选 + 自由输入，不要一次问太多）：

医生角色定义（写入前与用户对齐）

医生名未确定时的处理（必做）

1. 联网检索：「<医院名> <科室名> 医生」「<医院名> <科室名> 专家团队」，优先官网科室页
2. 来源优先级（从严）
   | 可用 | 不可用 |
   |---|---|
   | 医院官网科室/专家页 | 百科词条 |
   | 卫健委 / 官方挂号平台公示 | 自媒体、问答、论坛 |
   | 权威媒体报道 | 任何推测、拼接、同名猜测 |
3. 整理候选：姓名 + 职称/职务 + 来源链接，逐条标注出处
4. 点选让用户选定；用户选"仍不确定" → 保留 医生A/医生B 占位（合规做法，不得臆造）

必问：是否将真实医生姓名写入页面

演示 / 对外展示场景可能不宜用真名。先问，不默认写入：

硬约束

• 禁止编造医生姓名；检索不到就如实说明并保留占位
• 检索结果必须标注来源，不得把推测当事实
• 医生组名默认 <主诊医生名>组；若医院无此建制，与用户确认命名

输出：机构人员映射表（占位符 → 实际值）+ 实名写入决策，交用户确认。

Step 2 · 病种特点分析 + 三大上报场景核对

先联网检索该病种的「诊疗规范 / 随访指南 / 术后或康复管理常规」，作为建议依据。

再逐项核对三大场景（每一项给出「建议值 + 理由 + 依据」，用点选让用户确认或修改）：

① 症状上报（模板 B03-症状上报-患者端.html）

② 健康日记（模板 B05-健康日记-患者端.html）

③ 用药打卡（模板 B06-用药打卡-患者端.html）

粒度规则（硬性 · 不询问）：用药打卡一律按周，控件固定 .week-picker，全病种唯一口径。

• Step 2 不询问粒度，Step 5 确认单不列粒度项 —— 不得把它做成待选项
• 禁止改为按日（.time-picker / .day-picker）或按月（.month-picker）
• 全包不得出现 .day-picker / .month-picker
• 规则详见 规范B §5.1；机器校验 review_pkg.py A11 组（2026-10-07 新增）

该病种不需要某场景时

不得在本步直接删页面。→ 记入 Step 4 的「停用」建议（需用户确认，并检查引用与索引）。

硬约束：三场景的通道 → 分级 → 阈值必须前后同源，且与医生端承接页（D01 #alarmWrap / D11）一致。改一端必同步另一端。

输出：三大场景配置表（建议值 + 用户确认值），交用户确认。

Step 3 · 提出病种专项上报内容建议

基于 Step 2 的病种特点，提出该病种特有的（模板里没有、但临床上需要的）上报项。

建议项字段

条数与排序：建议 3–8 条，按推荐级别降序，避免一次给出过量项。

硬约束（因是通用型模版，建议必须严谨可靠）

1. 每条建议必须有病种依据，不得为凑数而建议
2. 明确标注推荐级别；不建议的项要写清原因（与现有通道重复 / 临床价值低 / 增加患者负担）
3. 不得建议上线未经临床验证的自评量表
4. ★ 2026-10-11 用户立规：不得向用户建议新增功能页面（页）。
   建议项的「归属」只能落在现有页面（症状上报 / 健康日记 / 用药打卡 / 其他已建上报页）——
   不得把「新增一个独立上报页 / 独立功能页」作为建议项提出，任何推荐级别（含「可选」「不建议」）都不行。
   - 边界（只禁"新增独立页"）：同一页内新增功能按钮 / 功能项 仍可建议
   （例：「在 B03 增加一个『疼痛评分』通道」✅；「新增一个『疼痛评分上报页』」❌）。
   - 用户主动提出时不受限：用户自己说要新增页面 → 照常走 Step 4.2 闸门
   （需求描述 → 功能需求卡 → 回读确认），并同轮给出中心医护端三段承接方案。
   - 页面清单的增减建议（4.6 硬约束 2）、功能按钮 / 功能项的新增建议（闸门 ②）不受本条影响。

输出：专项上报建议清单，用户逐项勾选。

Step 4 · 两端功能列表确认 + 新增功能征询 + 量表数量 + 增减建议

> ⚠️ 本步含三道强制闸门（2026-10-08 用户硬要求）· 分支 A / B 通用：
> 4.1 功能列表确认闸门 → 4.2 新增功能征询与需求二次确认闸门 → 逐页处置建议（4.3–4.6）→ 4.7 量表数量确认（★ 2026-10-11 收窄：不问方案、只问数量）。
> 三道闸门未取得用户明确确认，不得进入下一步、不得动任何页面。

4.1 ★ 两端功能列表确认（强制闸门）

向用户逐条列出两端的功能清单，交用户确认。未确认不得进入 4.2。

• 清单以当次源包的实际文件清单为准（分支 A 通常 B ×14 ＋ D ×21；分支 B 以实际页数为准）
• 用户可逐条或批量确认；用户提出异议的条目就地修订后重新列出，不得只改一处不回报
• 管理端（F 系列）清单在 4.6 单独列出与确认

产出：两端功能清单确认结果 → 写入 本次注入-更新范围确认单.md。

4.2 ★ 新增功能征询与需求二次确认（强制闸门）

4.2.2 需求描述必备要素（缺一项追问一项）

4.2.3 功能需求卡（逐条一份）

4.2 硬约束

• ⚠️ 新增必须成对：患者端上报页 → 中心医护端必须配套三段承接，不得单侧断档
• ⚠️ 编号规则（★ 2026-10-11 用户裁定 · 替换原「沿用包内既有编号体系」口径）：
  新增页一律不进 B / D / F 系列，统一命名为 X{NN}-{患者端|医生端}-{功能名称}.html ——
  X 大写；每端各自从 01 起（X01-患者端-疼痛评分上报.html / X01-医生端-疼痛评分处理.html）；
  模板原有页仍用 B/D/F；对应的《产品功能清单》md 同规则命名（X01-患者端-疼痛评分上报-A.md），
  不得新增 B/D/F 系列文档。原规则「新增页沿用包内既有编号体系」作废（规范B §9.1 / 坑清单 R3-30）。
  ⚠️ 「空号不补位、不重排」对模板原有页仍然有效 —— 该条只管原有页的删除与留空，与新增页走 X 体系并行不冲突。
• ⚠️ 需求未经二次确认的，一律不得进入执行
• ⚠️ 不得为凑数而建议新增：新增与否由用户裁定，AI 只负责提问、梳理与回读

产出：功能需求卡 ＋ 用户「正确」答复记录 → 并入 本次注入-更新范围确认单.md。

4.3 患者端（B 系列 14 页）★ 4.1 确认后的逐页处置依据

逐页给出处置建议：

B01 主页 / B02 我的 / B03 症状上报 / B04 我的档案（已无「患者基本信息」卡）/ B05 健康日记 / B06 用药打卡 / B07 我的量表 / B08 日程管理 / B09 日程管理-日历 / B10 健康宣教 / B11 上传资料 / B13 系统通知 / B14 健康报告 / B15 健康报告详情

> B04 我的档案 · 已无「患者基本信息」卡、D26 资料汇总同（2026-10-07 用户裁定）：两页 .patient-card 整块（12 个 .pi-item）与其 9 条 CSS 已删除，.content 内首个元素即「模块 Tab」+ .tab-scroll，4 个 tab 与全部 panel 保留。规范A 原注入项 4-15 / 19-6（患者卡 12 项字段）已作废。
> 同两页三个 tab 已改「平铺 + 时间降序 + 来源标签」（2026-10-07 第二轮裁定）：「就诊记录 / 院内化验 / 外院化验 / 本院检查 / 外院检查」五个分组外壳与 #visitCnt 计数全部移除；来源标签统一 .src-tag 四类（来源 院内/院外 + 渠道 his获取/患者上传），映射 REC_SRC、渲染 srcTags()。规则见 规范B §6.4、注入项见 规范A 4-16/4-17/19-9。
> 检查报告卡已并入化验卡 .lab-card（2026-10-07 用户裁定，杜绝第二套卡片样式）：renderExam() 改用 .lab-card + .lab-crow1（检查名称 · 日期 · 来源标签 · [重点] · 箭头）+ .lab-crow2（检查科室）+ .lab-body，展开区小标题/正文用 .lab-sec/.lab-txt，重点项用 .lab-badge 胶囊；.rep-* 17 条 CSS 与 srcIcon() 全部删除。化验卡与检查卡的外观与行结构必须逐项一致。⚠️ D28 的 .rep-acts/.rep-btn/.rep-tip 属健康报告操作区，与本卡无关。
> B10 健康宣教 · 已无 tab、无横幅（2026-10-07 用户裁定）：原两级 tab（「宣教打卡 / 科普小知识」）与顶部科普横幅（「疾病管理小知识」+ 正文）整体移除，.content 内只剩宣教打卡列表；标题固定为「健康宣教」。
> 页面内 PUSH_NODES / ARTICLES / FROM_MAP 的注入项照旧（规范A 10-1 ~ 10-4、10-6），原 10-5（科普区 4 类）已作废。
> 标准数值类上报项一律「拖动滑条 + 点选快捷值」（2026-10-07 用户裁定）：血压 / 血糖 / 体温 / 体重 / 心率 / 血氧 / 疼痛评分等定量指标，参照 B03 发热上报的「当前体温」，用 .trk-* 滑条 + .qk 快捷值（结构）与 mkNum() 工厂（实现）承载；禁止用 <input type="number"> / .bp-input / .weight-input 文本框。分级配色只用语义四色（绿 #0E9E56 / 黄 #B8890B / 橙 #E67E22 / 红 #D0021B），色带按阈值百分比分段（不是等分）。B05 健康日记的血压（收缩压 / 舒张压各一条滑条）与体重已在同轮完成改造。规则见 规范B §3.2.1（+ §5.3），注入项见 规范A 3-12 / 5-3 / 5-4 / 5-7，收尾核验 规范A 25-24 / 25-25。
> B02 我的 · 诊疗信息卡随病种类型切换（2026-10-07 用户裁定）：由 PACKAGES[].kind 决定卡面 —— 手术类（'surgery'）= 诊断名称 / 手术名称 / 手术日期（3 行），非手术类（'diag'，高血压 / 糖尿病 / 康复 / 儿童视力发育等）= 诊断名称 / 诊断日期（2 行）；首行统一叫「诊断名称」。卡面、修改表单字段、③ 确认弹层文案三处同时切换（medKind() / dateLbl() / recDate() / recFromHis() 派生）。
> 卡片右侧操作区固定两枚按钮：同步医院数据（前）+ 修改 / 去完善（后）。同步走接口取该患者诊疗数据并直接覆盖本地记录（不走清空确认）；成功后 toast「已从医院系统同步到诊疗数据」。原型接口由 mockFetchMed() 模拟，接真实接口只替换该函数。
> 规则见 规范B §5.5（+ 自检清单 C1b），注入项见 规范A 2-5 ~ 2-10。
> B11 上传资料 · 历史区已改口径（2026-10-07 用户裁定）：① 标题「历史上传记录」→ 「历史数据」（合规 规范B §2.4 B-4，review_pkg A6-3 对该页的 FAIL 已消除）；② 历史卡片新增审核三态胶囊 待审核（琥珀）/ 已审核（绿）/ 已驳回（红），文案表 HIS_STATE、类名 .his-tag.wait/.ok/.no（⚠️ 2026-10-10 由 .his-state 收敛为 .his-tag）；③ 历史卡片不显示文件大小（副行只留「类型」、时间归行3），待提交区 .pk-item 仍显示大小；卡片骨架统一为 规范B §3.3.3 的 .his-*；④ 演示种子 uploaded 6 条三态齐全、时间走 TS()，新提交一律 state:'wait'。规则见 规范B §3.3.1，注入项见 规范A 11-2 ~ 11-6，收尾核验 规范A 25-26。

4.4 中心医护端（D 系列 21 页）

D01 工作台 / D02 预警列表 / D03 患者列表 / D04 患者全景视图 / D08 标签管理 / D11 症状上报处理 / D12 用药打卡处理 / D13 患者量表处理 / D15 量表管理 / D19 科研管理 / D21 我的 / D22 资料管理 / D23 宣教管理 / D24 健康日记 / D25 患者日程（孤儿页，见下）/ D26 资料汇总（已无「患者基本信息」卡）/ D27 健康报告 / D28 健康报告详情 / D29 沟通 / D30 沟通会话 / D31 健康报告审核（2026-10-07 新增）

> ★ 2026-10-11 用户裁定：随访模块整体下线 —— D09-新建随访计划 / D16-随访管理 / D18-随访进度 三个页面文件已从模板删除，（D01、D21 两处指向 D16 的入口同步删除），编号 D09 / D16 / D18 留空、不复用；F06-随访计划管理（管理端）保留（管理端随访模板属另一条线，未在本次裁定范围内）。⚠️ 注入时不得把这三个 D 页加回来；规范A 中 D09 / D16 / D18 三段已作废。
> ★ D25-患者日程 保留为孤儿页（2026-10-11 用户裁定）：文件保留，但 D04 的三处入口（功能菜单项 / 「患者日程」区块 / 该区块 JS 生成的节点链接）已全部删除；患者端 B08 / B09 日程管理保留不动。

> D31 · 健康报告审核 —— 由 D01 主宫格「健康报告」进入。以患者为卡片，汇总全院待审核 + 待推送的健康报告（结构与 D22-资料管理 同构：概览条 + 搜索/筛选 + 患者卡）；点击患者卡 → D27-健康报告-中心医护端.html?name=<患者>。
> 审核/推送状态取自 localStorage 键 rptedit:<患者>，与 D27 / D28 共用同一把键，故三页状态恒一致。

> ⛔ D04 患者日程 · 已整体下线（★ 2026-10-11 用户裁定）——
> 原「三态节点（绿 .dot.on 已完成 / 红 .dot.od 逾期 / 蓝 .dot.off 待执行）+ .sc-nm 日程名 + 色板与图例」整块能力已从 D04 移除：
> ① 「日程管理」功能按钮（.func-* 宫格项）已删；② 「患者日程」展示区块已删；③ 该区块的 JS 节点渲染入口已删；
> ④ 配套的 .sc-* 三态 CSS 与 SCHED / renderSchedRow 等 JS 已按死代码一并清除。
>
> ⚠️ 注入时不得把日程区块加回 D04；规范A 的 4-10 / 4-14（D04 日程项）已作废。
> ⚠️ 患者端 B08 / B09 的日程管理不受影响、保持原样；D25-患者日程 文件保留为孤儿页（无入口）。
> ⚠️ 规范B §4.2.1 日程三态色板章节保留（B08 / B09 仍读同一套 patsched: 键与色板），但适用范围收窄为患者端两页（原先写的是「D04 / D25 / B08 / B09」）。

D01 功能宫格变更（2026-10-07，注入时不得破坏）

> ⚠️ 注入时若改病种导致功能增减，必须守住三条：① 主宫格只放 fc-a（业务蓝），展开区只放 fc-b（管理紫） —— 混用会被 review_pkg.py 的 A7-2 判 FAIL；② 两区一律每行 5 个（repeat(5,1fr)），项数超出即自动换行（★ 2026-10-11 后的基线：主宫格 5 项＝1 行；展开区 5 项＝1 行）；③ 不得为了"填满一行"去改 repeat(N,1fr) 的 N —— 列数口径全包唯一，改它等于破坏一致性。
> ⚠️ ★ 2026-10-11 追加：不得建议或自行添加功能宫格项（见 Step 3 硬约束 4）—— 宫格项与页面一一对应，加减都必须先由用户提出。

4.5 入口页 A01 —— 已删除，不适用

A01（原型入口页）已由用户从服务包中删除（2026-10-07 确认）。本 skill 全流程不再处理 A01：

• 通用型包为 46 页（B ×14 ＋ D ×21 ＋ F ×11），不含任何 A01
• 不再有「索引链接 + 三处计数」的注入与核验项（规范A / 规范B 的 A01 条目已同步作废）
• 若源包内意外出现 A01* 文件 → 停下问用户，不得自行处置

4.6 管理端（F 系列 11 页）→ 清单见 references/规范A「第 2.5 步」（下为速览）

> 上表为速览；逐字段清单以 references/规范A 第 2.5 步为准（26-1 ～ 36-6 共 44 项）。

硬约束（建议必须严谨可靠）

1. 不得为凑数而建议新增；每条建议附病种依据
2. 停用前必须检查：该页是否被其他页引用（失效链接）、是否在页面索引中登记
3. 停用后编号规则：保留空号、不重排（沿用包内既有做法）；在 TSV 剔除区追加留档
4. 新增必须成对：新增患者端上报页 → 医生端必须配套三段承接（D01 功能图标 + D01 #alarmWrap 预警展示 + D04 功能图标单患者入口），不得单侧断档
   （⚠️ 新增页须先由用户提出 —— AI 不得主动建议新增页，见 Step 3 硬约束 4；用户主动提出后按本节流程走）
5. 医生发起类业务（量表推送 / 健康报告 / 用药调整）须两端闭环齐全（规范B 第四章六项自检）—— ⚠️ 「日程管理」已不是医生端业务（2026-10-11 医生端日程下线）

4.7 ★ 量表数量确认（★★ 2026-10-11 用户裁定：不问方案、只问数量 · 在 Step 5 范围确认之前走完）

> 用户原话：「在向用户确认量表页功能的时候，去掉通过 excel 生成量表的功能提问选项，统一按照默认模拟量表的方式执行，可以问用户做几个模拟量表。
> 同时保留生成量表页面的功能，但不向用户展示，也不执行。」

4.7.1 ★ 唯一提问：本次做几个模拟量表

4.7.2 病种化改写（按用户给定的数量执行）

• 在模板既有量表库中取 N 条，按 Step 2 的病种特点改写：量表名 / 维度 / 题项措辞 / 计分口径（结构不动）
• 不产出 scale/ 页面：改的是 B07（患者端量表库）/ D15（医生端量表管理）/ F11（管理端量表管理）中的既有条目
• 六处同源登记照旧：B07 ↔ D13 / D15 / D19 / D04 / D30，同名量表措辞逐字符一致；机器判定 review_pkg.py A4 组
• 改写后的量表名与维度在 4.1 功能清单确认时一并列出交用户核对（不单独回读、无「解析确认」环节）

4.7.3 ⏸️ 冻结能力（保留在包内 · 不展示 · 不执行）

> 唯一例外（用户主动时恢复）：用户自己提交了量表原始文档 / 明确要求「按我的量表生成作答页」时 —— 才恢复走 规范E
> （解析 → 回读确认 → 生成 scale/<短名>.html ＋ 同短名报告提示词 md → 过 check_scale_docs.py）。
> ⚠️ AI 不得主动提起这条路径；用户没提，一律按 4.7.1–4.7.2 走。恢复执行时的完整流程见本文件 附录·冻结路径（文末）。

4.7.4 管理端 F11 的同步改造（★ 2026-10-11）

F11-量表管理-管理端.html 里的「导入题目 / Excel 上传 / 下载模板」整套 UI 已从模板删除
（它是「通过 Excel 生成量表」的唯一真实入口，留着与「不展示、不执行」矛盾）。
⚠️ 注入 / 改页时不得把它加回来；机器判定 = review_pkg.py A15 组（新增）。

输出：① 两端功能列表确认结果（4.1）② 功能需求卡 ＋ 用户「正确」答复（4.2）③ 各端功能增减建议矩阵（4.3–4.6）
④ 量表数量 ＋ 病种化改写后的量表清单（4.7）—— 四者均交用户确认，并一并写入 本次注入-更新范围确认单.md。

4.7-附 ★ 冻结路径（仅在用户主动提交量表文档时启用）

> 本节是 2026-10-11 之前的 4.7 全文，原样保留供恢复执行时对照。AI 不得主动引用本节、不得主动提议走这条路。

> ⚠️ scale/ 页不进 46 页编号体系：不占 B/D/F 编号、不单独出《产品功能清单》文档、不计入 A12-1 的页数统计；
> 但必须在《更新说明》里单列「新增量表页」（规范E §八）—— "不进编号"≠"可以不登记"。

Step 5 · 与用户确认更新范围与内容（最谨慎的一步）

> 前提：页面上的数组内容可能是用户已手工填过的真实业务数据。一旦覆盖不可恢复。

5.1 先问数据来源状态

• 当前包是「未改动的初版模板」还是「已经被人工改过 / 已填过真实数据」？
• 若是改过的：哪些页 / 哪些数据块是用户自己维护的？ 需用户指明。
• 用户未指明前，不得假设。

5.2 分档确认更新范围（多选，逐条确认）

5.3 逐条列出将改动的内容

按规范A 输出待改动项总表：

让用户逐条或按档批量确认。

5.4 选择落地方式（必提，由用户定）

> 不得默认采用 B；B 的改动范围超出 T1，须逐页取得用户明确授权。

5.5 必须给出的提示

1. 备份：改动前对全包做一次整体备份到 <包目录>_bak_YYYYMMDD_HHMM（用户指定位置）
2. 回滚方案：rm -rf <包目录> && cp -r <备份目录> <包目录>（必须在执行前与用户确认此命令可用）
3. 不可逆：一旦执行不可回滚（除非用备份还原）
4. 分批：建议按档位或按端分批执行、每批校验

硬约束

• 用户明确确认前，不得执行任何写操作
• 用户未回答"数据来源"前，不得进行档位 2 及以上操作
• 涉及用户已填数据的改动，若用户未指明字段，不得假设，必须先问

输出：本次注入-更新范围确认单.md §5（档位 ＋ 逐条清单 ＋ 落地方式 ＋ 备份与回滚方案），用户确认。
> 复核配置不再落盘：Step 7.0 按 §5 现场推导成临时配置（新值进 new_terms、被替换的旧值进 old_terms、易混用对进 pair_terms；有量化专病记录时补 specialty_record；分支 B 另补 debind 整块），跑完即删。

分支 B 的 Step 5 附加三项（缺一不得进入 Step 6）：

Step 6 · 执行

6.1 执行前差异盘点

对比源包与「初版模板」，确认是否存在未预期的既有改动；若有且用户未提及 → 停下报告，不得直接覆盖。

分支 A 的「初版模板」= skill 内置基线：

TPL="$HOME/.workbuddy/skills/病种注入器/assets/templates/通用型全病程服务包-V3.3"
diff -rq "$TPL" <源包目录> 2>&1 | grep -v '\.DS_Store'

• 无输出 → 源包是未改动的初版模板，正常进入 6.2
• 有差异 → 逐页判定「用户既有改动」vs「模板基线差异」，结论写进台账；涉及用户未提及的改动一律先停下问

> ⚠️ 源包来自模板本身（用户未带源包）时：6.1 免做差异盘点（复制件与基线必然一致），但仍要跑 detect_source_pkg.py 留证。
> ⚠️ 分支 B 不适用本条：专属包没有对应基线，改由 Step B1–B3 的资产清单与残留矩阵承担。

6.2 注入替换：严格按 references/规范A-病种注入执行清单-V2.md 执行，顺序：

第 0 步 全局 → 第 1 步 B 端 14 页 → 第 2 步 D 端 21 页 → 第 2.5 步 F 管理端 11 页 → 第 3 步 编码层 → 第 4 步 核验（不含 A01 段）

> 分支 B 的顺序不同：以"页"为单位，逐页执行 解绑 → 注入（同一页内成对完成），严格按 Step B4 处置清单走。
> 禁止"先全包解绑、再全包注入"的两遍走法 —— 两遍必然产生「目标病种名 × 前序病种概念」的中间态残留（见 T1-b 与 A9-3）。
> 镜像对必须同批处理：识别出的 B 端 ↔ D 端镜像页，在同一批里改完，不得先改一端。

6.3 新增页面：⚠️ 前置条件是 Step 4.2 闸门已过（且新增动议由用户提出 —— AI 不主动建议新增页）（需求卡已由用户回复「正确」）—— 未过闸门不得新建任何页面。执行时严格按 references/规范B-新建页面规范-V2-医患两端.md 走（同 4.2.5），逐项过其自检清单（含「0. 铁律闸门」7 项；含 §十一 E / H 的「历史卡片行序 ＋ 时间行文案」强制项，对照 §3.3.2 —— 历史卡片标准适用于任何新建的含历史数据页面，不是 B03 的个案）

6.4 每次改动

1. 先备份到临时目录
2. 大块删除用「行区间 + 首末行断言 + 上下行越界断言 + 自底向上」
3. 改完与备份跑 difflib，确认「删的行都在预期清单内、加的行只有预期的补位行」

6.5 交付前跑校验

python3 scripts/verify_pkg.py <服务包目录>

校验项：内联脚本语法 / 真实 DOM div 配平 / 失效链接（原「页面计数一致性」已随 A01 删除而移除）。

> ⚠️ 两脚本必须能真正跑完：review_pkg.py 曾因逐词逐文件直接读盘（53 页 × 50 词 ≈ 2600 次）被拖到超时甚至 SIGKILL —— 全部改走读盘缓存后完整复核约 4 秒。跑不完的校验等于没有校验。

分支 B 追加（解绑是否真的做干净，机器先过一遍）：

python3 scripts/scan_residue.py <服务包目录> --terms <临时目录>/术语三色表.txt    # 临时入参（结论进确认单 §8.3）
python3 scripts/review_pkg.py <服务包目录> --config <临时目录>/复核配置.json       # 临时配置，跑完即删

6.6 产出待复核件（本步不交付）

• 不写任何记忆
• 不新出文件：改动清单（改了哪些页 / 哪些块 / 多少处）＋ 遗留待确认项在对话里呈现，并由 Step 6.7 落进包内《更新说明》
• 确认单 §7 填上「文档产出范围」；状态记在对话里（「执行完成 · 待复核」）

6.7 ★ 文档产出（成套交付的甲层 · 按需产出 · 不可跳过）

> 依据 规范D。页面改完先判断本次哪些页需要文档，再产出；不要等复核发现缺陷再补。
> ★ 2026-10-10 用户裁定：文档不再逐页产出 —— 只在两种情况下产出，其余一律不产出。

6.7.1 ★ 先判「本次哪些页要文档」（只有两种情况）

以下改动一律不产出文档：改演示数据 / 数值 / 文案、改样式（颜色 / 字号 / 圆角 / 间距 / 图标）、功能点增删（分区与骨架未变）、出链入链少量增删、资产替换、逻辑与阈值调整、类名重构。

• ⚠️ 判据只有两条（「分区增删」「骨架顺序变化」）。不得把「改动很大」「涉及多页」「功能点 37→39」这类主观或量化感受当成结构级大改。
• ⚠️ 边界情形（拿不准是否构成分区增删 / 骨架重排）→ 按「不算」处理，并当场问用户，不得自行升级为「要重写文档」。
• 判定结果（新增页清单 ＋ 结构级大改页清单）在对话里列出，并写进确认单 §7。

6.7.2 明确不做的事（★ 2026-10-10 起）

6.7.3 按判断产出文档

> ⚠️ required_pages 必须显式给出 —— 它 = 本次新增页 ＋ 结构级大改页的清单（本次确实没有就写 []）。
> 键缺失时 A12 只报 WARN（「没声明」与「声明为空」是两回事），交付时必须已显式声明。

硬约束

• ⚠️ 文档一律占位符化：即使包内页面已填真实医院 / 病种 / 医生名，文档里也写 ⟨医院⟩ / ⟨病种名⟩ / ⟨主诊医生⟩（规范D §二 绝对禁令 1）
• ⚠️ 不改任何 .html：本步只产出 md
• ⚠️ 不产出文档是常态，不是缺失：包内文档数 < 页面数属正常状态，不得据此判「不成套」、也不得「顺手补齐」
• ⚠️ 不得把「改动大」当「结构大改」：越线产出文档同样是违规（用户要求「非必要不生成」）
• ⚠️ 新增页必须产出文档：这条是硬要求，不得以「非必要不生成」为由省掉
• ⚠️ 声明了就必须有（required_pages）：A12-1 会逐项核对；声明漏了则机器查不出（见 A12 明细「已知局限」），靠《更新说明》对照表 ＋ 确认单 §7 ＋ 交付前自检三处互证

• ⚠️ 不做基线复制平移：不得把源包基线整目录复制出来比对（那正是本轮要消除的动作）

• 状态记在对话里（「执行完成 · 文档已按需产出 · 待复核」）

• → 进入 Step 7 复核；复核通过后才交付

Step 7 · 交付前强制复核与根因追查（不通过不得交付）

> 复核不是"再检查一下"，是交付闸门。原则：可取证、全覆盖、就地修复、追到根因。
> 用户硬要求：同一个错误不得多次犯 —— 因此本步必须产出「防复发措施」并回写。

7.0 准备复核配置（临时文件 · 不落输出目录）

按确认单 §5 / §7 生成临时复核配置（写系统临时目录；复核跑完即删，不得落在用户输出目录）：

{
  "old_terms":  ["被替换掉的旧值1", "旧值2"],
  "new_terms":  ["新病种值1", "新病种值2"],
  "pair_terms": [["术后第", "入组第"]],
  "allow":      {"某通用词": ["允许保留该词的文件名.html"]},
  "expect_pages": 50,
  "docs": {
    "dir": "产品功能清单",
    "min_lines": 350,
    "update_note": "更新说明-20261010.md",
    "required_pages": ["本次新增页.html", "本次结构大改页.html"],
    "skip_pages": []
  },
  "specialty_record": {"name": "眼轴", "patient_page": "B16-XX打卡-患者端.html",
                       "overview_page": "D04-患者全景视图-中心医护端.html",
                       "doctor_pages": ["D31-XX上报处理-中心医护端.html"]},
  "hist_icon": {"extra": {}, "exempt_classes": [], "exempt_pages": []},
  "debind": {
    "prior_terms":    ["前序病种全量术语（🟢 + 🟡，取自 Step B2 三色表）"],
    "target_terms":   ["目标病种名与其同源词"],
    "conflict_pairs": [["目标病种名", "前序病种概念词"]],
    "timeline_terms": ["术后第", "手术日", "术前"],
    "dict_keys":      ["前序病种专属字典键"],
    "mirror_pairs":   [["B端页.html", "D端页.html"]],
    "allow_comment":  {"某词": ["允许保留该词的文件名.html"]}
  }
}

> ⚠️ debind 只由分支 B 填。分支 A 留空 → A9 组整体跳过，不影响既有 0 FAIL / 0 WARN 基线。
> debind 的字段口径见 规范C §10.1。

7.1 四层复核（每层都要有输出，缺一层视为未复核）

review_pkg.py 的分组含义：

A6 组明细（2026-10-01 新增 · 用户患者端反馈的机器化；A6-7~9 为同日二次反馈补入）

> B-7 空态文案、B-8 左对齐、B-10 品牌重复 属语义判断，仍为人工验收项（规范B §2.4）。
> A6-7 ~ A6-9 的反向自测：对未注入基线运行 → 报 29 条 FAIL（含 4 种标题栏高度、5 页图标混用、read-all / h-note / tt-wrap 越界），可完整复现用户两轮反馈的全部问题。
>
> A6-2 / A6-9 的豁免机制（2026-10-07 立）：两表共用 HDR_CHILD_ALLOW_EXTRA 一份依据 —— 同一个 .h-note 被两条校验同时覆盖，若只豁免其一会出现「A6-9 放行、A6-2 仍报」的自相矛盾。当前豁免 4 处右上角清单级功能位（B06 .h-mg / B10·B14 .h-note / B13 .read-all），每处均在该表内写明理由；业务功能入口不得豁免。
>
> 同轮按 B-1 / B-13 清理模板：B05/B06/B07/B08/B09 的 .tt-wrap / <div style="flex:1"> 包装层全部移除（.title 直接作子元素并补 flex:1），B05 副标题一并删除 → A6 28 → 17 条。
> A6-10 反向自测：对「标题栏背景已统一为深蓝、但字色未同步」的中间态快照运行 → 报 4 条 FAIL（B12/B13/B14/B15，逐页指出标题字色 var(--text) 与按钮字色 var(--primary) 应为白色）；对已修复包 → 0 FAIL；对既有眼科 / 肛肠两个交付包 → 0 FAIL（0 误报）。
> A6-11 正反向自测（2026-10-07，6/6 全过）：① 正向对未注入模板 → 0 FAIL；② 把通用项卡换到专属项卡之前 → 抓到；③ 在通用项卡之后再插新专属项卡（违反「插到最顶」）→ 抓到；④ 新专属项卡插到最顶（合规）→ 0 FAIL；⑤ 通用项词被整体替换（无法判定）→ 跳过不误报；⑥ 专属项卡标题含「运动」字样但顺序正确 → 0 FAIL（fails open，不误杀）。
> A6-11 判据为什么用白名单：专属项随病种变化、无法枚举；通用项是跨病种固定的一组 —— 枚举它才是低误报的可行判据。代价是「专属项卡恰好含通用项词」时放弃判定，宁可漏报、不可误杀。

A7 组明细（2026-10-01 新增 · 用户中心医护端四项反馈的机器化）

> A7 组反向自测：对交付包副本构造 8 处缺陷（删 header-ico、fc-a→fc-b、.t2 改占位、删趋势卡、把指标词塞回「最新上报数据」、KPI 改一位数、把趋势卡写成静态 DOM、趋势卡 KPI 写字面量）→ 全部被抓（8/8）；对已修复包正向跑 → 0 FAIL。
> A6 / A7 必须成对维护：此后凡新增一端的一致性规则，另一端同步评估是否有对称项 —— 避开「校验只长在被反馈过的那一端」的重复偏差（坑清单 R4-7）。
> ⚠️ 判定用「HTML 元素」而非「字符串存在」：A7-4 查趋势卡时须匹配 <div class="trend-wrap">，否则会被 CSS 里的 .trend-wrap{…} 规则误判为"已存在"（首版实测踩到）。
> ⚠️ A7-4b 反过来也要区分「静态元素」与「JS 模板串」：处理页的 '<div class="trend-wrap">'（带前导引号）是合法的动态模板，<div class="trend-wrap">（裸标签）出现在 HTML 区才是 FAIL —— 前者恰恰是正确做法（2026-10-05 D31 反馈固化）。
> ⚠️ A7-4b 的判据来源：趋势卡属单患者维度组件，而处理页默认态是全患者清单 —— 判错上下文会让"某个患者的曲线"冒充"这一屏的汇总"，比不显示更误导（规范B §1.4 D-5 判定句式）。

A8 组明细（2026-10-01 新增 · 用户「D21 底栏高度不一致 / 各页预警徽标数值不一致」反馈的机器化；同日晚扩充 A8-1b「视觉口径」）

> A8 组反向自测：构造 6 类缺陷（导航条写死 height:62px、导航项 padding 回退 6px 0、导航项字号回退 11px、某页徽标改 5、删 D29 徽章、D02 徽标改 9）→ 6/6 全被抓；正向跑交付包 → 0 FAIL、INFO 报出「徽标全站一致：4（覆盖 D01、D02、D03、D21、D29）」+「= D02 未处理真值 4」。
> A8-1b 反向自测：构造 8 类缺陷（D21 文字色回退硬编码 #8aa3bc、D21 选中态加回 font-weight:600、D02 徽章回退 16px、D03 底栏 z-index 回退 100、D21 去掉下圆角、D29 徽章去 font-weight:700、D21 上边框回退硬编码、D03 .nav-item 缺 gap）→ 8/8 全被抓；正向跑交付包 → 0 FAIL、INFO「底栏视觉口径全站一致：25 项 × 5 页」。
> ⚠️ 自测脚本必须清 _CACHE：read_cached 是模块级缓存，反复改写同一路径的副本包时会命中旧内容，导致「规则明明生效却显示漏检」—— 每次 run() 前 _CACHE.clear()（首版自测踩到，8 例全假阴性）。
> A7-3b 反向自测：删 .sub 载体、把 .sub 字号改回 16px、粗细改回 700 → 3/3 全被抓。

A9 组明细（2026-10-03 新增 · 用户《逐页未完全修改审计》的机器化 · debind 配置驱动 · 分支 B 专用）

> 立组依据：审计在专属包上跑完 skill 后，60+ 页仍留有前序病种语义，而当时所有机器校验全绿 —— 因为 B1 组只查"旧值残留"，而旧值（病种名）确实已经 0 命中了，残留的是没被列入旧值的那些词、以及旧概念与新病种名的共现。这是校验维度缺失，不是执行失误。

> 为什么 A9-3 必须独立成条：pair_terms 查的是「旧值 ↔ 新值」共存，而这里的问题是「新值 ↔ 旧概念」共存 —— 旧值已经改没了，old_terms / pair_terms 都抓不到。审计里 慢性胃炎术后需要扩肛 这类串就是这么漏过去的。
> 为什么 A9-4 用"命中集合比对"而不是"逐字段比对"：镜像两页的数据结构命名可能不同（B07 vs D18），逐字段比对会大面积误报；而"两端对同一批前序病种词的命中情况应当一致"是一条充分且低误报的代理判据 —— 一端清干净了另一端没清，一定命中不一致。
> A9 与 A3 的分工：A3（肛肠 / 痔病底版残留）是分支 A 专用的固定词表，不因分支 B 而扩充 —— 对某些目标病种（如肛肠科内换病种），创面 / 切口 / 术后 本身就是合法词，硬塞进固定词表会造成大面积误报。分支 B 一律走 A9 的配置驱动路径。

A10 组明细（2026-10-07 新增 · 用户「页面显示的今天都是 8 月 29 日」反馈的机器化 · 对照 规范B §5.4）

> 立组依据：模板以 2026-08-29 为「今天」编排全部演示数据，日期硬编码 → 页面永远显示 8 月 29 日。
> 改造方案 = 随包分发 assets/js/timeshift.js，页面加载时把数据按 今天 − 基准日 实时平移。

> A10 反向自测（2026-10-07，5/5 全过）：① 正向对已转换模板 → 0 FAIL；② 删掉 timeshift.js 引入 → 抓到；③ 把一个日期还原成裸字面量 → 抓到；④ 恢复写死的 nowStamp() → 抓到（A10-2 与 A10-3 双报，同一缺陷的两面，属预期）；⑤ 日期只出现在注释里 → 0 FAIL（不误报）。
> ⚠️ A10-2 的判定要用「剥掉 TS 调用后再找日期」：否则 TS('2026-08-29') 里的日期会被当成"未包裹"而全包误报。
> ⚠️ 注释里的日期必须放行：/* 数据基准日 2026-08-29 */ 是说明，不是显示值。
> ⚠️ TS() 的短格式守卫：10-14 天 / 10-15分钟 / 30-60% / 第 3-5 周 是范围量不是日期；但 09-02 周三 是日期 + 星期必须平移 —— 守卫要能同时满足这两侧（见 timeshift.js 内注释）。

A11 组明细（2026-10-07 新增 · 用户「用药打卡默认全部按周执行、不询问」裁定的机器化 · 对照 规范B §5.1）

> 立组依据：改造前的规则把「粒度」做成 Step 2 的待选项（日报 / 周报 / 月报），但 规范A 的 B06 / D12 执行清单里没有粒度项、review_pkg.py 也无对应校验 —— 决定接不住，会产出「日报粒度 × 周控件 ×「本周用药频率」文案」的自相矛盾页面。
> 现改为硬性按周：不再有需要承接的选择，同时用本组拦住"后人无意改回日/月口径"。

> A11 正反向自测（2026-10-07，6/6 全过）：① 正向对模板 → 0 FAIL；② 删掉 B06 的 week-picker → 抓到 A11-1；③ .week-picker 换成 .time-picker → 抓到 A11-2；④ B06 加 .day-picker → 抓到 1 条（载体页不双报）；⑤ 其他页 B04 加 .month-picker → 抓到 A11-3；⑥ B06 同时缺 week-picker 且含 .day-picker → 双报 2 条（同一缺陷两面，属预期）。
> ⚠️ 载体页判定用「前缀 + 可配置覆盖」，不写死文件名：cfg.med_page 优先，否则取 B06-*.html —— 与 A11-3 的分工靠"载体页跳过"避免同因双报。
> ⚠️ .time-picker 只在该页禁：B03-症状上报 的日期选择器就是 .time-picker，全包禁它会大面积误报。

A12 组明细（2026-10-08 立组 · ★ 2026-10-10 按用户裁定整体收窄 · docs 配置驱动）

> 立组理由不变：T3 交付物原先只有「这次改了什么」，没有一份「这页是什么」。
> 2026-10-10 的口径变化：文档不再逐页产出 —— 只在 ① 新增页 与 ② 结构级大改页（分区增删 / 骨架顺序变化）两种情况产出。据此 A12 组改为围绕「本次声明的需文档页清单」校验。

> ⚠️ required_pages 必须显式声明（本次确实没有就写 []）：「没声明」与「声明为空」是两回事 —— 前者是执行者漏做了这次判断（报 WARN），后者是「本次确无新增 / 无结构大改」（合法）。
> ⚠️ A12-1 已不再是「每页一份」：「页数 = 文档数」作废。包内文档数 < 页面数是正常状态，不得据此判交付不成套。
> ⚠️ A12 的已知局限（如实声明）：required_pages 是执行时自声明的清单 —— 机器能保证「声明了却没写文档」必被抓（A12-1），做不到「该声明却没声明」（机器无从知道哪页是本次新增 / 结构大改的）。后半段靠人工：《更新说明》对照表 ＋ 确认单 §7 ＋ 交付前自检第一条，三处互证。
> ⚠️ 为什么 docs 未配置只报 WARN 而不是 FAIL：机器不能替人判断「这次是不是一次正式交付」——模板基线跑、中途试探跑都不该被文档缺失判死。但文档产出是交付硬要求，所以未配置时必须报 WARN，且在 Step 7.7 交付判定里作为人工必查项（配置了 docs 就必须 A12 组 0 FAIL）。不得把 docs 留空当成「跳过校验」的手段。
> ⚠️ A12 只管「有没有 / 齐不齐 / 对不对形」，不管「写得准不准」 —— 内容准确性由 check_docs.py（C1~C10：命名 / 八节 / 功能点连续 / 篇幅 / 模拟数据 / 占位符 / 小节 / 待收口项要素）与 L2 需求层的人工取证承担。两个脚本都要跑，不能互相替代。
> ⚠️ A6 / A7 / A8 / A9 / A10 / A11 / A12 / A13 / A14 的成对维护约定照旧：凡新增一类交付面，同步评估是否需要在别处加对称项。
> A12 正反向自测（★ 2026-10-10 收窄版重跑 · 15/15 全过）：① 无目录 ＋ required_pages=[] → 0 FAIL；② 无目录 ＋ 声明非空 → A12-1 目录缺失 FAIL；③ 未声明 required_pages → WARN；④ 声明 2 页且都有文档 → 0 FAIL；⑤ 声明 3 页缺 2 份 → A12-1 FAIL；⑥ 声明页不在包内 → WARN；⑦ 孤儿文档 → INFO（不再 FAIL）；⑧ 缺「八、验收自检清单」→ A12-4 FAIL；⑨ 文档含多余「九、变更记录」→ 不报；⑩ 文档 120 行 → A12-5 FAIL；⑪ 缺版本 ＋ 缺日期 → A12-6 FAIL ×2；⑫ 更新说明无对照表 → A12-3 FAIL；⑬ 有对照表但无「版本」字样 → 不 FAIL（新口径已去掉该要求）；⑭ 更新说明过简 → A12-3 FAIL；⑮ 目录空 ＋ required_pages=[] → 0 FAIL。
> 零回归：skill 内置模板包跑 review_pkg.py → FAIL 80 / WARN 5，与改前完全一致（docs 未配置仍只报 WARN）。

A13 组明细（2026-10-10 新增 · 用户「B05 历史卡片还有 emoji 图标」反馈的机器化 · 覆盖三端 B·D·F · 坑清单 R1-33）

> ⚠️ 不全文扫 emoji：toast 文案里的 ✓ / ⚠️、代码注释里的 ⚠️ 都是正常用法，全文扫描会大面积误报。判据是「这个位置是不是图标位」＋「这个字面量是不是只有 emoji」。
> ⚠️ A13-1 的已知盲区（如实声明）：只能抓静态写死在标记里的 emoji。若 emoji 是运行时拼进容器的（如 '<div class="hist-mood">'+icon+'</div>'），容器源码里看到的是 JS 表达式 —— A13-2 正是为补这个洞而加（B05 就属于这种：emoji 存在 var icon 里）。
> A13 正向自测：对修复后的 skill 内置模板（46 页）→ 0 FAIL。反向：改动前的包跑旧版 review_pkg → FAIL 80 条中没有任何一条指向 B05 的 emoji（A6-4 的 <i class="…"> 正则扫不到 .hist-mood）—— 这正是 R1-33 记录的「结构盲点」。

A14 组明细（2026-10-10 新增 · 用户两次要求：「加规范」把图标规格变成机器判据 →「历史数据的各个卡片的样式也不一样，这个也要进行统一规范」· 规范B §3.3.3 · 坑清单 R3-14 / R3-15）

> ⚠️ A14 与 A13 是两层：A13 管「用什么图标」（FontAwesome 而非 emoji），A14 管「图标与卡片装成什么形态」。两组都要过，不能互相替代。
> ⚠️ A14-1 / A14-4 只认纯单类选择器（.his-ic{…}）—— 复合选择器（.his-t1 .big{…}）是页内局部修饰，不构成该类的基础规格，由 A14-2 单独把关。
> ⚠️ A14-4 与 A14-1 不重复报 .his-ic：图标四项由 A14-1 专管，A14-4 只比对另外五类（同一缺陷只报一次）。
> ⚠️ A14-5 必须先剔除注释再扫 —— 「某类已于某日删除」这类变更溯源注释里会正当引用旧类名（B03/D19 都有），不剔除必然误报成残留。JS 行注释用 (?<![:/])// 匹配，避免把 https:// 当注释起点。
> ⚠️ 基线真源是 规范B §3.3.3：改规格必须先改那一节、再改 review_pkg.py 的 HIST_ICON_SPEC / HIS_CARD_SPEC / HIS_OLD_CLASSES。两处不同步，校验会拿旧规格判新页面。
> ⚠️ A14 只证明「类名与数值对得上」，不证明「取色语义对」 —— B03 的「图标色 == 卡片左侧竖线色」仍属人工验收项。
> A14 正反向自测（2026-10-10 扩组后，11/11 全过）：正向对 skill 内置模板（46 页）→ 0 FAIL / 0 WARN，INFO 报「骨架类名命中 his-card、his-ic、his-t1、his-t2、his-time、his-top」；反向构造 → 全抓：B03 图标宽 36px（A14-1 单报）· B05 卡片圆角 10px · B06 主行字号 13px · B11 旧类名 .his-state 残留 · D19 缺 .his-t2 规则（骨架不完整）· D19 图标渐变底（A14-2）· 未登记新类（A14-3 WARN）· .his-time 改实线 · B03 旧类名 .hitem 残留。
> 两项「应不报」也验过：① 注释里引用旧类名 → 不报；② 改非骨架类 .his-tag 的圆角 → 不报（骨架只管骨架）。
> ⚠️ 反向自测的两个坑（本轮踩到）：① 必须每次 subprocess 独立跑（read_cached 缓存）；② 造缺陷要按「规则块内改属性」定位 —— 直接 str.replace('border-radius:10px', …) 会命中该属性在文件里第一次出现的位置（往往是别的组件），造出的"缺陷"根本没落在被测类上（首版 4 例因此假阴性）。

A15 组明细（★ 2026-10-11 新增 · 需求 4「Excel 生成量表能力冻结」的机器化）

> 立组依据：用户裁定「去掉通过 excel 生成量表的功能提问选项……保留生成量表页面的功能，但不向用户展示，也不执行」。
> 该能力在模板里的唯一真实入口是 F11-量表管理-管理端.html 的「导入题目 / 从Excel导入题目 / 下载模板 / 上传解析」整套面板 ——
> 删掉它，规则才自洽；不删，下一次注入又会有人把它用起来（规范与页面口径分裂）。

> ⚠️ A15 只管「Excel → 量表」这一条链路：不禁止其他页面用 Excel 做数据导出（F03-数据下载 的导出能力属独立功能，不在本组范围内）。
> ⚠️ .upload-zone / .uz-* 类名只在 F11 内属本组管辖 —— 其他页另有上传控件（如患者端 B11 上传资料）不受影响。
> ⚠️ A15 与 A13 / A14 的关系：A15 管「某个能力该不该出现在页面上」，A13 管「图标用什么」，A14 管「卡片长什么样」—— 三组各管一层，都要过。
> A15 正反向自测（2026-10-11）：正向对改造后的 F11 → 0 FAIL；反向对改造前的 F11 → A15-1 / A15-2 双报；对 F03-数据下载（合法含 Excel 导出）→ 0 FAIL（不误报）。

7.2 取证纪律（禁止凭印象）

每条复核结论必须附四类证据之一：

1. 脚本输出（verify_pkg.py / review_pkg.py）
2. 与备份的 difflib 逐行 diff
3. 关键词命中数（改前 vs 改后）
4. 无头实测结果或截图

> 「我记得改过了」不构成证据。未取证的条目一律记为「未复核」，不得计入通过。

7.3 复核清单（逐项打勾，未勾即未过）

7.3.1 需求层
- [ ] Step 5 确认单中每一条都有一条复核记录（条目 → 证据 → 结论）
- [ ] 用户明确要求「保留不动」的项，确认确实没动（diff 佐证）
- [ ] 用户明确要求「停用 / 删除」的项，确认入口、索引、TSV、计数四处都已同步

7.3.2 规范层
- [ ] 未向用户建议新增功能页（★ 2026-10-11 铁律）—— 本次执行中提出的建议项全部落在现有页面内；若确有新增页，动议来自用户（Step 3 硬约束 4）
- [ ] 未打包、未自行改版本号（★ 2026-10-11 铁律 T0-d）—— 除非用户明确说了「打包 / 封版 / 提交 / 上架」或给出版本号
- [ ] 规范A 对应页的必改项全部落实（配置项 B1/B2/B3 全过）
- [ ] 编码层（第 3 步）已清：糖尿病底版 / 肛肠底版 / 真实姓名 全包 0 命中（A1/A2/A3）
- [ ] 旧值在全包范围内为 0（不只本次改过的页）
- [ ] 新值在全包范围内确实出现（防漏改）

7.3.3 铁律层（T1）
- [ ] 改动都能对应到需求里的一句话（不能对应的=越界改动，回退）
- [ ] 无新增未明确元素（图标 / 字段 / 按钮 / 区块 / 标签 / 文案 / 颜色 / 层级）
- [ ] 无删除 / 合并 / 重排既有元素
- [ ] 未改布局与排版格式（网格列数 / 分区顺序 / 间距 / 对齐 / 卡片结构）
- [ ] 有疑问处都先问过用户，未自行补位

7.3.4 一致性层
- [ ] B04 ↔ D26 四组数据逐字符一致
- [ ] 量表库六处（B07 / D13 / D15 / D19 / D04 / D30）同名量表措辞一致
- [ ] 报告链路（B07 RPT_OF → B14 REPORTS → B15 DATA → D27 REPORT_SETS → D28 DATA_BY_PT）id 与名称对得上
- [ ] 报告详情「两类内容分派」（2026-10-09 用户裁定）：B15 / D28 每条报告带 type（scale / complex）；量表评估报告只渲染 ① 量表评估与报告、三块（②综合评估 ＋ ③体征监测 ＋ ④用药打卡）只在 type:'complex' 渲染；量表报告条目不含 score / rows / monitor / med。验收：抽 ?id=sc1 只看到一块、抽 ?id=cp1 四块齐全（对照 规范A 15-6b / 21-5b / 25-27，根因见 坑清单 R1-29）
- [ ] 症状通道（B03 ↔ D01 ALARMS ↔ D11）同源
- [ ] 宣教（B10 ↔ D23 CONTENTS ↔ D30 EDU_LIB）同源
- [ ] 日程（B08 ↔ B09）同源 —— ⚠️ ★ 2026-10-11 起医生端日程已下线：D04 的日程区块、D25 的入口均已删除，本条不再比对 D 端
- [ ] 患者后端 → 医生端承接成对齐全（新增上报页必有医生端三段承接）
- [ ] 患者端 UI 口径一致（A6 组 0 FAIL）：标题栏无副标题 / 无计数；历史区块 fa-clock-rotate-left + 历史数据 全包唯一；二级页标题栏背景唯一、文字颜色与背景明暗匹配（深底白字）；铃铛角标 = 待办数量
- [ ] 图标一律 FontAwesome（A13 组 0 FAIL）：全包三端无 emoji 充当图标 —— 图标位容器内容必须是 <i class="fa-solid fa-…"></i>；「只由一个 emoji 组成的字符串字面量」一律视为违规（规范B §0.5 第 4 条）；★ 且每个 fa-* 类名必须在包内 FA Free 的 all.min.css 里有定义（A13-3，防 Pro 专属图标渲染成空白 —— 坑清单 R4-27）
- [ ] 历史卡片新骨架（★ 2026-10-11 二次统一）：四个上报页（B03/B05/B06/B11）的卡片 —— 行2 无图标列（.his-ic 已删）、内容左对齐；卡片右上角有审核状态标签（待审核 / 已审核 / 已驳回，四页三态齐备）；右侧有删除按钮（.his-del，图标形式无文字、垂直居中跨行2/行3）；行1 周范围前带「第 x 周」；已驳回不显示驳回理由；行1/行3 其余口径不变（规范B §3.3.3）
- [ ] 历史卡片删除交互（人工验收）：仅 待审核 态可点删除 → 弹确认 → 真删（数组移除、列表实时减少）；已审核 / 已驳回 态按钮置灰不可点
- [ ] 历史卡片「统一骨架」跨页一致（A14 组 0 FAIL）：三页（B03/B05/B06/B11 ＋ 医生端 D19）均为卡片形态、类名与结构同为一套 .his-* —— .his-card 圆角 14px / 内边距 11px 12px / 间距 9px / 1px 边框 + 阴影；.his-ic 34×34 / border-radius:10px / font-size:14px；主行 14px/700、副行 12px、时间行 11px + 1px dashed 虚线分隔；无圆形 / 无渐变实心底 / 无旧类名残留；新增含历史数据的页直接复用 .his-*（A14-3 报 WARN 即为未登记）—— ⚠️ 取色语义（如 B03 图标色 == 卡片左侧竖线色）仍属人工验收项（规范B §3.3.3）
- [ ] 时间基准（A10 组 0 FAIL）：每页引入 assets/js/timeshift.js；日期字面量全部经 TS()/TS_RANGE()；nowStamp() / demoNow() / OP_DATE 均取真实当前时间（规范B §5.4）
- [ ] 用药打卡粒度（A11 组 0 FAIL）：B06 含 .week-picker 且不含 .time-picker；全包无 .day-picker / .month-picker —— 用药打卡硬性按周，未把选择做成待选项（规范B §5.1）
- [ ] 健康日记打卡区排序（A6-11 0 FAIL）：B05 中病种专属打卡项在前、通用项（运动/睡眠/体重…）在后；新增专属项插到最顶（规范B §5.3）
- [ ] 规范B §2.4「十四条硬规则」逐条打勾（B-7 / B-8 / B-10 为人工验收项）
- [ ] 医生端 UI 口径一致（A7 组 0 FAIL）：一级页标题栏「图标 + 名称」成对；宫格业务蓝在前、管理紫在后；会话头部两行（身份 / 诊断）且第一行姓名 / 性别年龄分级；量化专病指标独立成趋势卡；标题栏文字颜色与背景明暗匹配（深底白字）
- [ ] 趋势卡只在单患者上下文出现（A7-4b 0 FAIL）：D04 显示；处理页仅带 ?name= 时由 JS 动态插入，默认全患者清单不渲染；KPI 由当前患者记录派生（无字面量）
- [ ] D 端底栏与全局徽章一致（A8 组 0 FAIL）：五页底栏尺寸 + 视觉口径同款（25 项，实测均 50px 且计算样式 90/90 一致）；「预警」徽标五页齐备且同值 = D02 预警列表「未处理」条数
- [ ] 量化专病指标数据同源：患者端打卡页 ↔ D04 ↔ 处理页（单患者上下文），KPI 数值逐字符一致、曲线点数 = 患者端历史条数；处理页换 ?name= 时 KPI 随之变化
- [ ] 规范B §1.4「九条硬规则」逐条打勾

7.3.5 交付物层
- [ ] 甲层 · 成套产物齐备（重点项，2026-10-08 起；★ 2026-10-10 收窄）：① 服务包页面 ② 产品功能清单/ 按需产出的文档 ③ 更新说明-YYYYMMDD.md（含「页面 ↔ 文档」对照表 + 本次文档产出小结）
- [ ] 本次新增页都写了文档；结构级大改页（分区增删 / 骨架顺序变化）已整篇重写；其余改动过的页未产出文档（这是对的，不是漏）；删除页未加作废声明（新规则允许）
- [ ] required_pages 已在临时复核配置里显式声明（本次无新增页、无结构级大改则写 []）
- [ ] 邻页文档跟着改过：新增 / 删除页导致的出链、入链变化已同步进对应邻页文档 §四
- [ ] 量表页配套（条件项 · ★ 2026-10-11 收窄）：仅当包内存在 scale/*.html（即用户主动提交了量表文档）时才是必查项 —— 此时每张 scale/*.html 都要有同短名的 scale/*.md 报告生成提示词，check_scale_docs.py 退出码 0，《更新说明》已登记；包内无 scale/ 时本项不适用、直接视为通过（默认路径下不再产出 scale/）
- [ ] F11 无 Excel 生成量表入口（A15 组 0 FAIL）（★ 2026-10-11）—— 该能力已冻结，不得展示、不得执行
- [ ] 包外唯一产物齐备（★ 2026-10-09）：本次注入-更新范围确认单.md 已出，§1–§7 按分支填全（分支 B 另含 §8）；包外目录里不得出现任何其他文件 —— 台账 / 改动摘要 / 校验报告 / 缺陷登记 / 复核配置 / 源包判定单 / 资产清单 / 术语三色表 / 残留矩阵均已取消
- [ ] 备份存在，回滚命令已与用户确认可用

7.3.6 解绑验收层（仅分支 B，逐条过 规范C §10）
- [ ] C-1 前序病种术语（🟢🟡 全量）全包 0 命中（白名单例外逐条登记并写明理由）—— A9-0
- [ ] C-2 文件头注释 0 命中前序病种术语 —— A9-1
- [ ] C-3 时间轴口径全包唯一，无前序口径残留；文案 ↔ 数值 ↔ data-* 三者一致 —— A9-2 ＋ 人工数值比对
- [ ] C-4 残留矩阵每一行的处置都已完成并取证，无"未复核" —— 对照确认单 §8.3 逐行打勾
- [ ] C-5 镜像对全部成对同步，同源字段逐字符一致 —— A9-4
- [ ] C-6 删除页同步齐全（文件 / 入口 / 索引，＋若包内有页数计数器则含计数）—— 人工核对
- [ ] C-7 无「目标病种名 × 前序病种概念」共现 —— A9-3
- [ ] C-8 无前序病种字典键与注释残留；后端标识（model_version / model_code）未被误改 —— A9-5 ＋ 人工
- [ ] C-9 专属内容资产群（问卷 / 科普 / 病历模板 / 量表题库 / 标签库 / 科研队列 / 预警类型 / 随访模板）已按处置清单完成 —— 对照 Step B1 第 2 类清单

7.4 发现问题的处置（就地闭环）

1. 立即修复该处（不攒到最后）
2. 判定回归范围：

3. 重新取证；不得跳过重跑直接标记通过

7.5 根因追查（RCA）—— 「不要一个错误多次犯」

每个缺陷必须归因到四类之一：

判定顺序（逐层问，问到即止）

1. 清单 / 规范里有没有写这一项？→ 没写 = R1
2. 写了但含义有歧义、或与源码不符？→ R1
3. 规范没问题，是数据语义没对上（文案 / 数值 / 映射键）？→ R2
4. 规范没问题、数据也对，是执行时写错了（锚点 / 拼接 / 正则 / 选择器）？→ R3
5. 前面都对，但复核时没查出来（是用户或后来才发现的）？→ R4

回写落地（必须做，否则等于没追根因）

• R3 → 在坑清单对应类别追加一条（症状 / 根因 / 防复发 / 取证）
• R4 → 在 review_pkg.py 补上能查出该问题的规则，并用已知样本自测（如 sm10 / 患者01）
• R1 / R2 → 产出「建议回写内容」；等用户确认后再改 skill 内的规范文件（规范A / 规范B / 规范D / 规范E）
• R3 / R4 类直接追加进 references/坑清单-已知缺陷与防复发.md（skill 自身资产，属工具维护）；不再另出缺陷登记文件 —— 结论在对话里给出
• ⚠️ 复核发现的每个问题都要有落点：要么进坑清单、要么进确认单、要么在对话里说清 —— "发现过但没记录"不算完成

根因记录字段（写进坑清单条目；不再单独成文件）

7.6 复发判定与机制升级

• 坑清单里已登记过的坑再次发生 → 判为机制性缺陷
• 处理：停下，向用户报告三点 —— ① 该坑已登记却仍复发 ② 现有防复发措施为什么没拦住 ③ 2–3 个备选机制方案；用户选定后再继续
• 同一 R 类在单次注入中出现 ≥ 2 次 → 同样按机制性缺陷处理
• 禁止：把复发问题当新问题重新登记一遍了事

7.7 交付判定（全绿才交付）

任一不满足 → 不得交付，回到对应步骤。
通过后：更新台账为「已完成」，交付甲层成套产物 + 乙层六份交付物 + 复核结论摘要（含 WARN 项与「已知接受项」）。

交付后再变更（增量同步 · 2026-10-08 用户硬要求）

> 用户原话：「如果用户生成完后，又修改了某些 html 页面，或新增了 html 页面，也执行相同的操作。」
> 即：交付不是终点。页面再变一次，就按 6.7.1 重新判一次「要不要产出文档」 —— 只有命中「新增页 / 结构级大改」才产出（重写的文档升一版），其余改动不动文档。《更新说明》每次都要出。

触发条件（任一命中即走本节）：

执行路径（不对重走 Step 1–5 —— 需求已定，只跑变化面）：

硬约束

• ⚠️ 不得跳过文档产出：本次新增页 / 结构级大改页没写文档 = 不成套，不得交付；反过来说，非这两种情况的页面改动不需要、也不应该产出文档
• ⚠️ 不得整批重写文档：重写会抹掉 §九 变更记录与 §五 的"已于某日处理"标注，追溯链断掉
• ⚠️ 不得顺手补齐文档：改了数据 / 样式 / 文案 / 功能点的页就是不该产出文档；「既然打开了顺手补一份」属违规（规范D §七）
• ⚠️ 不得只改文档不改页面：文档是页面的描述，页面是事实来源（规范D §五）；发现文档与页面不符，先确认哪个是对的，再问用户
• ⚠️ 版本号只增不减：A → A2 → A3；不得复用已用过的版本号
• ⚠️ 变化面里若含跨页同源数据（同源键 / 量表库 / 报告链路 / 宣教库 / 患者端日程），按 7.4 回归范围跑 L4 全组

中止与异常处理

不适用场景

references 索引

> ✅ 本 skill 的 references 全部是「本地资产」——不存在任何外部正本（用户 2026-10-08 裁定：「以 skill 内这份为准，无外部的规范」）。
> 因此不必再与任何包外文件做 diff 对账；规范A / 规范B / 规范C / 规范D / 规范E / 规范F / 坑清单 / 模板基线清单 / scripts/ 一律以本 skill 内这份为唯一正本。
> 维护方式（按根因分类，见 Step 7 与坑清单）：
> · R3 / R4 类（执行手法、校验手段）→ 坑清单 可自动追加；scripts/ 可直接改（属工具维护，不是写记忆）；
> · R1 / R2 类（规范缺失歧义、语义错位）→ 产出「建议回写内容」，等用户确认后再改 规范A / 规范B / 规范D / 规范E / 规范F。这不是因为"有外部正本要同步"，而是用户级刚性约束：对 skill 内容 / 流程的任何修改都必须先经用户交互确认。
> ⚠️ 旧版本文中若仍有「外部规范副本 / 源头正本 / 回同步正本」的措辞，一律按本行口径理解（已失效）。

assets 索引

两种用法：① 基线参照（Step 6.1 差异盘点，用户自带源包时）；② 默认源包（用户未提供源包时，cp -R 到输出目录再注入）。

TPL="$HOME/.workbuddy/skills/病种注入器/assets/templates/通用型全病程服务包-V3.3"
diff -rq "$TPL" <源包目录>                              # 用法①：差异盘点
cp -R "$TPL" "<输出目录>/<目标包名>"                     # 用法②：作为注入起点

> ⚠️ 模板内不含 .workbuddy/（项目工作区）、标准版产品功能清单/、.DS_Store；这些不属于模板资产。
> ⚠️ 模板更新规范见 references/模板基线-通用型46页.md §4（新版另建目录，不覆盖旧版）。

scripts 索引

python3 scripts/gate.py check                                          # T0 准入门禁（退出码 0 才继续）
python3 scripts/gate.py unlock <口令>                                   # 首次授权（持久化到本机；口令错误 3 次即终止）
python3 scripts/check_update.py                                        # T0-c 更新检查（0=最新 / 3=有更新 / 2=检测失败）
python3 scripts/fetch_fonts.py check                                   # T0-b 字体自举（退出码 0 才继续）
python3 scripts/fetch_fonts.py fetch                                   # 缺字体时补齐（首次运行执行一次即可）
python3 scripts/fetch_fonts.py strip                                   # ★ 上架打包前：删掉字体二进制（打包动作本身须先获用户明确指示，见 T0-d）
python3 scripts/detect_source_pkg.py <源包目录>                       # Step 0.0 闸门
python3 scripts/scale_doc_extract.py <量表文档> --out <包>/scale/_src/量表解析-x.json   # ⏸️ 冻结路径：仅用户主动提交量表文档时（Step 4.7-附 ①）
python3 scripts/scan_residue.py <源包目录> --extract                  # Step B2 候选词
python3 scripts/scan_residue.py <源包目录> --terms <tmp>/术语三色表.txt  # Step B3 残留矩阵（结论进确认单 §8.3）
python3 scripts/verify_pkg.py <服务包目录>
python3 scripts/check_docs.py "<服务包目录>/产品功能清单"              # Step 6.7 文档内质（八节）
python3 scripts/review_pkg.py <服务包目录> --config <tmp>/复核配置.json  # 临时配置，跑完即删