# mockup-conventions.md 结构整顿（代号 B）— 审计发现 + 整顿设计

> **日期**：2026-06-25
> **类型**：核心规则真源（`docs/internal/mockup-conventions.md`，2629 行）重复/冗余审计 + 结构整顿设计
> **状态**：✅ **全阶段执行完毕（2026-06-25）** —— P0–P7 全部 owner 逐项拍板 + 分阶段单 commit 落 master（见 §4 阶段表 commit 哈希）。P5（物理归拢）owner 拍板不做。审计完成（全文 100% git-show 核对覆盖）+ 安全网就位（备份 + xref manifest）。
> **关系**：B 在 2026-06-25 真源规则健康审查（A 路线）审 mockup-conventions（5/11）时诊断出结构问题而立项；与 `2026-06-25-cross-ai-authoring-gate-design.md`（跨 AI 机制硬化，§Part 6 = 本任务纪律真源）同源。
> **纪律真源**：`cross-ai-authoring-gate-design.md` §Part 6 —— git show = 唯一 ground truth；Edit old_string 取自 git show 干净原文；禁 subagent 读取/审查；逐条 owner 确认；发现工具污染即停。

---

## 0. owner 重定向（2026-06-25）—— 本设计的灵魂

初版方案（高价值子集，defer 高 churn 的 a 拆分 / c 重排 / mass-renumber）被 owner 否决，重定向为：

> 「我认为你推荐不做的地方需要重新考虑，就是因为它的内容比较多，我怀疑有很多重复且没有必要的规则，可以看看有没有更好的方式来做，而不是因为涉及面广，所以不动。你可以先备份一下，以免改了之后找不到相关联的地方。」

三条重定向：
1. **不接受"涉及面广所以不动"**——要找**更稳健的方法**处理大 blast radius（= 改前建完整跨引用 map、改后逐项核对零孤儿），而非回避。
2. **真问题假设 = 很多重复 + 不必要的规则**——B 的核心是**证据驱动的重复/冗余/过期审计**（= A 路线方法应用到本文件），据发现砍并，不是机械重排/拆分。
3. **先备份**。

**审计结论**：owner 假设成立——确有真重复（F1 强）、四处分散的 Legacy ID Map（F2）、碎裂的 M23 家族（F8），以及一处确认的 stale bug（F5 M41 Notification 节点）。

---

## 1. Baseline 实核（别信估值）

| 项 | 任务/直觉估值 | git-show 实核 | 偏差 |
|---|---|---|---|
| 文件体量 | 2629 行 | 2629 行（HEAD blob `543bc257`，内容 sha `60b73fd7`）| — |
| M23 注释家族占比（item a "≈1000 行/40%"）| 40% | M23 core 418–846(429) + M23.6/9/10/11/7 1196–1464(269) + M33 1611–1645(35) ≈ **733 行 / 28%** | 估值虚高 ~36% |
| 最大已用 M base 号（item d "M51 已占"）| M51 | M50/M51 均占；M100/M110 另一套；base **52–99 全空** → 空闲号 = **M52** | 确认 |
| M49 撞号 blast radius（item d "~17 处/4 文件"）| 4 文件 | **live 引用跨 40 处**，但多数是 design-process 的**另一个 M49**（Design Quality Contract，不动）或历史层（不回溯）。真正要改的 Library Fidelity M49 集中在 4 文件，**须逐处分类** | 需逐处分类，禁盲 sed |

---

## 2. 安全网（处理大 blast radius 的"更稳健方法"，owner 要的"先备份"）

- **整文件备份**：`docs/internal/_backups/mockup-conventions.HEAD-543bc257a3a3.bak.md`（内容 sha 校验 = HEAD）。git HEAD 本身也是持久备份（每阶段单独 commit → 任意中间态可回滚）。
- **跨引用清单**：`docs/internal/_backups/mockup-conventions-xref-manifest.md`（495 行）—— 每个待动 ID 的 live 引用 file:line 全列（已排除历史层）。**用法：任何砍并/重号/删除某 ID 后，对该 ID 此清单逐行核对 → 每处已更新或显式保留 = 零孤儿。**
- **机检 gate**（每阶段后必跑）：`pnpm audit:rule-load-map`（路由表覆盖）+ `node scripts/audit-artifact-routing.mjs`（def+route+wakeword 三件齐全）—— 验 jump 表/唤醒词没断。

---

## 3. 审计发现（证据行号来自已核 == HEAD 的文件）

> 分类：**DUP**=真重复 · **SCATTER**=同主题分散 · **STALE**=过期 · **COLLISION**=撞号 · **PLACEMENT**=物理错位/碎裂 · **MISFILE**=归属错文件 · **OVER-FRAG**=过度细分（待评估）。
> 每条标：证据 / 置信 / 风险 / blast radius。

### F1 [DUP, 高置信] 「写后必跑机检」两处实质重复
- **证据**：§M-LIFECYCLE ②AFTER（L1116–1121）与 §M-DISCIPLINE.SYNC（L2543–2556）。两者同为"编辑 confirmed/写后批次 → 跑 conformance/integrity 机器输出、禁目测、同步交付层、handoff 留痕"。同日（2026-06-18）同 W3/W5 修复血缘并行新增 → 天然重叠。
- **M-LIFECYCLE 自承**："本闸把已有规则钉到三时点，不重造规则、只锁触发"（L1104）——它本就是 triggering layer，与 M-DISCIPLINE.SYNC 的 after-write 触发同义。
- **风险**：中（两处都有 live 引用：M-LIFECYCLE 8 处 / M-DISCIPLINE 14 处）。**正解**：以 M-LIFECYCLE 三时点为骨架，M-DISCIPLINE.SYNC 收敛为指向 ②AFTER 的指针 + 保留其独有的「状态转移触发 + handoff marker」语义；不硬删，避免断引用。

### F2 [DUP, 高置信] Legacy ID Map 散落四处
- **证据**：M-COLOR（L267 + L414 "M10→§C1, M25→§C2, M26→§C3"）/ M-INTEGRITY（L905 + L1098 "M27→§I1, M28→§I2, M34→§I3"）/ M-DISCIPLINE（L2569 Legacy ID 关联）/ M43（L2277 Legacy ID 关联）。**四处各自维护一份 legacy→new 重定向**。
- **风险**：低。**正解**（= item e）：建单个「Legacy ID Map」段集中所有 legacy→new 重定向 + 收编 stub（见 F4），各 umbrella 段的 legacy 行改指向它。

### F3 [SCATTER, 中置信] 「改既有物别重画」主题分散四处
- **证据**：§I5（L1079 替换前 diff/最小 delta/不丢用户改动）+ §M42.3（L2386 就地改优先/禁旁路克隆）+ §M46（L2400 probe instance 可改性/禁自画 overlay）+ §M-LIFECYCLE ①BEFORE update 行（L1113 指向 I5）。
- **判断**：**非纯重复**——各有不同 trigger（替换既有节点 / clone 放置 / library instance 迭代）。已互相交叉引用。**稳健解 = 轻量 see-also 簇**（在三处加统一"同主题"交叉链 + 一句话边界区分），不硬合并（硬合并丢 trigger context，违反"举一反三"原则）。owner 若认为可更激进合并，列为 disposition。

### F4 [COLLECTION, 低风险] 四个 legacy stub 分散
- **证据**：M27（L1136 →§I1）/ M28（L1142 →§I2）/ M30（L1465 →M32）/ M34（L1646 →§I3）。jump 表 L61 已列为"legacy stub"。
- **⚠️ 实核例外**：M30 有 **28 处 live 引用** + 实质指针正文（L1467–1471，不止一句"merged"）——比纯 stub（M27/28/34 各一句）重。收编时 M30 的"icon synonym 已并入 M32/M35"指引需保留落点，不能简单删。
- **正解**（= item e）：M27/M28/M34（纯 stub）收进 F2 的统一 Legacy ID Map；M30 因引用多 + 有指引，评估保留独立 stub 或在 Legacy ID Map 给加长条目。

### F5 [STALE, 高置信 —— 已实核确认] M41 引用过期的 Notification 组件集 + 旧轴模型
- **证据**：M41（L2004–2005）"必用 TVU `Notification` component instance（`component_set 4482:1197` master variant `4482:1204`, theme=dark, **status=pop confirm**）"。
- **实核**：`prop-aliases.json` 明确当前 = **set `1408:17154`** 的 **form/type 两轴模型**（2026-06-10 重构，form 含 dialog/alert/pop confirm/slide）；旧节点 `4482:1197`/`4482:1204` 在 figma-data **已不存在**（grep 零命中）；catalog L553 自标同款"旧模型残留 🟡 需 dedup-verify"。M41 的 `status=pop confirm` 是**已删除的 status 轴**命名。
- **正解**：M41 节点引用更新为 `1408:17154` + 轴改 `form="pop confirm"`（落 fix 前 live Figma 复验一次，不凭 figma-data 单证）。**这是 owner「不必要/过期规则」假设的实锤之一。**

### F6 [STALE, 中置信] M0 mapping 示例用旧 Notification 命名
- **证据**：M0 输出格式示例表（L216）"confirmation modal | `prompt message` (待查) | pop-confirm variant | 🟡 skeleton"。`prompt message` 已于 2026-06-12 改名 `Message`（catalog L205），且"pop-confirm variant"是旧轴。
- **正解**：刷示例为当前命名（低优先，示例性质）。

### F7 [COLLISION, 中风险] M49 撞号（= item d 核心）
- **证据**：本文件 §M49 = Library Fidelity Umbrella（L2580），design-process.md §M49 = Design Quality Contract，**同号同名 scope 不同**。L2582 已有 2026-06-25 临时消歧注（design-process 应有镜像注）。
- **正解**：本文件 Library Fidelity M49（含 M49.1–M49.4）→ **M52**；逐处分类 40 live 引用中指向 Library Fidelity 的（task 列：mockup-conventions 内 9 + WAKE-WORDS §M49.1 + design-walkthrough SKILL M49.3/.4/binding + tvu-design-mockup SKILL M49.1），改号；design-process M49 不动；撤两处消歧注。**逐处分类、禁盲 sed**（清单见 §2 manifest）。

### F8 [PLACEMENT, 中风险] 物理顺序碎裂（= item c）
- **证据**：① M23 家族碎裂两处——M23 core + M23.6–.16 在 L418–846，但 M23.6/M23.9/M23.10/M23.11/M23.7 在 L1196–1464（夹在 M29 与 M30 之间），M23.7 更被排在 M23.9/10/11 之后。② M45→M44→M43→M42 倒序（L2032→2081→2126→2285）。③ M39/M40/M41 在「历史背景」段之后（L1940+）。
- **判断**：jump 表（L10–61）按 trigger 导航，物理序**不影响 scoped-load 功能**——纯 reader/git 体验。**最值得做的只有 M23 家族归拢**（碎裂最 reader-hostile）；M45→M42 倒序、M39-41 错位是低 ROI churn。**风险**：移动段落 = 大行 churn + 易断 anchor 链接（40+ 跨文件 anchor）。列为 disposition：仅归拢 M23 家族 / 全量重排 / 不动。

### F9 [MISFILE, 中置信] M23.16 是 meta 规则，可能错置
- **证据**：M23.16（L770 "规则优先于范本：防继承 pre-规则范本债务（meta · cross-cutting）"）自标 "meta · cross-cutting"。它讲的是"照抄范本前先用规则校验"的元方法，与 M23（UX 注释画法）无直接关系，只是因催生场景在 PRD 卡而挂这。
- **正解候选**：评估移到 meta-rules.md（触发器层）或保留但明确其 cross-cutting 性质。低优先，列 disposition。

### F10 [OVER-FRAG, 待评估] M23 子规则是否过度细分
- **观察**：M23 有 14 个子条（M23 / .6 / .7 / .8 / .8.1 / .9 / .10 / .11 / .12 / .13 / .14 / .15 / .16）。部分高度相关：.12（紧邻）+.13（sizing）可能可合；.14（双语行距）+.15（段名层级）都是"卡内排版"；.10（语言）+.11（scope）+canonical 结构是"卡内容三件套"。
- **判断**：这是 owner"不必要规则"假设最需要 owner 在环的部分——**但每条都有独立 trigger + 实证血缘**，合并需谨慎（违反 §Part 6"不为简化而简化、零 R1"）。**建议作为独立深评估**：逐条判 keep / merge-into-sibling / demote-to-bullet，owner 逐条拍。不在第一批机械执行内。

### F11 [BLOAT, 高置信 —— owner 2026-06-25 P3 review 提出] 实证段是复盘级内容、污染规范规则
- **证据**：几乎每条 M-rule 挂一段 `实证 — <date> <TICKET> <产品名>：<多子句事件回放> + 逐字用户原话`（如 §M42.3「实证 — 2026-06-17 BM-1047 V3：…用户多次纠正：'记得是修改…'」）。这是 **retrospection 颗粒度**（ticket 号 + 逐字引语 + 多子句回放），不是规范规则该承载的；是文件膨胀大头（量级 > F1/F2）。
- **owner 原话**："看起来是复盘文件，包含在里面有什么意义吗 / 至少应该提炼一下，别带上 BM-1047 这类的文本"。
- **区分：提炼非删光** —— 终末锚点有价值（说明规则为何存在、防反复质疑重立）；问题在**形态**。
- **owner 拍板政策（2026-06-25）= 提炼为一句 + retrospection 指针**：每条实证 → 一句症状/根因 + （详 `retrospection/<file>`）；去 ticket 号 / 逐字引语 / 多子句回放。
- **⚠️ 前提（别丢唯一记录）**：提炼前逐条核该实证在 `retrospection/` 有无完整落点；**有** → 提炼 + 指针；**无**（inline 实证 = 唯一记录）→ 先确认是否保留细节 / 迁去 retrospection 再提炼。
- **范围**：触及 ~57 条规则**绝大多数**实证段——大 + 判断密集，独立阶段（P7），fresh session 做。

---

## 4. 提议分阶段执行（每阶段 = 独立 commit + 机检验证；owner 逐阶段确认）

> 排序原则：先低风险高确定（修 bug + 去真重复），后高风险（重排/重号），最后判断密集（过度细分评估）。每阶段后跑 `audit:rule-load-map` + `audit-artifact-routing.mjs` + 对动过的 ID 核对 xref manifest。

| 阶段 | 内容 | 对应 finding | 风险 | 依赖 |
|---|---|---|---|---|
| ✅ **P0** (da18c8de) | 审计 spec + 安全网（备份 + xref manifest） | — | 低 | done |
| ✅ **P1** (e54474ff) | 修 stale bug：M41 Notification 节点/轴 + M0 示例刷新 | F5, F6 | 低 | done |
| ✅ **P2** (5c82f937) | 去真重复 + 收编：M-DISCIPLINE.SYNC 收敛指向 M-LIFECYCLE②（F1）；建统一 Legacy ID Map 段收编 M27/M28/M34 stub（F2/F4）；M30 特判 | F1, F2, F4 | 中 | done |
| ✅ **P3** (6ff2dd26) | see-also 簇：I5/M42.3/M46「改既有物」统一交叉链 + 边界区分（F3） | F3 | 低 | done |
| ✅ **P4** (68e1528b) | M49 撞号重号 → M52：逐处分类 40 引用、改 Library Fidelity 指向、撤消歧注、Legacy ID Map 补 M49→M52（F7） | F7 | 中-高 | done |
| ❌ **P5**（owner 拍板不做） | 物理归拢 M23 家族（F8）—— owner 2026-06-25 拍板**不做**（靠 jump 表导航，物理序不影响 scoped-load，高 churn 低 ROI） | F8 | 中-高 | — |
| ✅ **P6**（owner 逐项拍板，2026-06-25） | F9/F10 子规则整顿，分项执行：**G1** (6bac6929) M23.12+.13 合并 placement&sizing；**G2** (dc283d51) M23.14+M23.15 合并卡内排版；**撞名修** (04be87d1) canonical 卡结构 `#### M23`→M23.0；**M23.16 升格** (1c80f2d5) → meta-rules §触发器 Q；**G3** owner 拍板 M23.10+.11 保留不合并 | F9, F10 | done |
| ✅ **P7+B** (68e1528b) | 实证段外移至文末 §实证档案（方案 B）—— 使 scoped-load 读规则正文不被历史稀释；不进 jump 表故不路由 | F11 | done |

---

## 5. 待 owner disposition 的决策点

1. **F3 合并力度**：see-also 轻量交叉链（推荐，保 trigger context）vs 更激进合并成单条「Edit-Existing Discipline」umbrella？
2. **F8 物理重排范围**：仅归拢 M23 家族（推荐）/ 全量重排 M-rule 物理序 / 完全不动（靠 jump 表）？
3. **F8/拆分（原 item a）**：owner 重定向后，"拆 M23 到独立文件" 是否仍要评估？（实核 28% 非 40%；与 M-COLOR C4/M33/M48/M49 耦合 → 若拆需迁 jump 表+skill+跨文件 ref。建议：先做 P1–P4 砍重复后看体量再定，不在第一批。）
4. **F10 过度细分**：是否授权逐条评估 M23 子规则合并？（判断密集、需 owner 在环、违"零 R1"风险——建议单独一轮）
5. **执行批次**：P1–P4（低中风险、高确定）先做掉，还是要我先把某一阶段做完给你看效果再继续？

---

## 6. 诚实边界

- M41 节点修复落 fix 前须 live Figma 复验（figma-data 是派生产物，触发器 O §派生产物子面）。
- 物理重排（P5）的 anchor 断链风险只能靠 xref manifest 逐条核 + 机检兜底，无法 100% 自动保证——这是高 churn 操作的固有成本。
- M23 子规则合并（F10/P6）有"为简化而简化"风险，必须逐条 owner 拍，AI 不自作主张砍规则。