# TVU 设计系统「规范 + 流程」体系 — Gap Report

> **生成日期**：2026-06-11  
> **性质**：诊断报告（只读），不改任何规范文件——所有建议等 owner 逐条 ack  
> **读法**：五节独立——先看覆盖度矩阵了解总体位置，再看缺口清单决策优先级，最后看分层流程提案和 action list  
> **量级校准**：本项目 = 单一 owner (Nancy) + AI 代理，不是多人团队。推荐方案已按此量级过滤：凡需要多人 ceremony 的业界实践都明确标注「不适用本量级」

---

## 读前声明（防"没有"判断失误）

本报告每个 ❌ 都来自以下逐一核查：
- 元规则组：AGENTS.md（全文读）/ meta-rules.md（全文读）/ working-principles.md（全文读）/ FIGMA_AS_SOURCE_OF_TRUTH.md（全文读）
- 流程组：design-process.md（1336 行全文）/ system-design-review.prompt.md（105 行）/ WRAP-UP.md（全文）
- 产物约束组：mockup-conventions.md（2283 行全文）/ code-conventions.md（1391 行全文）/ component-affordances.md（全文）
- 校验/发版组：V1_RELEASE_CHECKLIST.md / design-review-queue.md / backlog.md / 三份 report 文件

凡结论 ❌，均附"我查了 X/Y/Z 都没有"依据，见各节脚注。

---

## 第一节：覆盖度矩阵

说明：
- ✅ 已成文、有可执行规则/步骤  
- 📝 部分覆盖（有提及，但缺完整路径或强制 gate）  
- ❌ 缺失（grep + 全文读均未命中）  
- `→ 文件:章节` 指向具体真源位置

### A. 流程环节 × 生命周期

| 流程环节 | 0→1 全新 | 1→1.x 增量 | 2→3 重构/迁移 | 现有文件位置 |
|---|---|---|---|---|
| **Discovery / 需求澄清** | ✅ | 📝 | ❌ | `design-process.md §Pre-Phase 0` (L447–520) + `§Stage 0.5` (L640–765)；1→1.x = lite-version (US-3)；2→3 无专项 |
| **Mockup 设计 (Figma)** | ✅ | ✅ | 📝 | `mockup-conventions.md §M0-M48`；`design-process.md ③`；2→3 缺基线快照 protocol |
| **产品需求 → Code 设计** | ✅ | 📝 | ❌ | `code-conventions.md §R0-R23`；1→1.x = R7 场景 2 (已有产品增量)；2→3 仅 R7 场景 4 用户显式发起，无流程 |
| **现有 mockup / 产品设计 audit** | ✅ | ✅ | ✅ | `render-verification-report.md`；`figma-vs-sot-drift-report.md`；`AGENTS.md §Sprint Self-Audit` (L440–474) |
| **设计走查 design critique** | ✅ | 📝 | ❌ | `design-process.md ⑤ F1` (L43–44)；1→1.x F1 lite 条件 M49 部分简化；2→3 无 |
| **UX journey map** | ✅ | 📝 | ❌ | `design-process.md ⑦` (L662)；`§State-Completeness Enumeration` (L666–682)；1→1.x = lite-version；2→3 无 |
| **Persona / 用户角色测试** | ✅ | 📝 | ❌ | `design-process.md ⑥ Persona F2` (L46–47)；Stage 0.5 F2-early (L652)；2→3 无 |
| **可用性测试 usability** | 📝 | ❌ | ❌ | `design-process.md ⑥ F2-late persona simulation` 有角色模拟，但无正式可用性测试流程；非设计师自模拟 |
| **QA 测试 (视觉回归 / a11y / 功能矩阵)** | ✅ | 📝 | ❌ | `V1_RELEASE_CHECKLIST §a11y CI`；`render-verification-report.md`；`AGENTS.md §Sprint Self-Audit`；缺 QA 验收标准与设计规格绑定 |
| **Design token 治理（新增 + 废弃）** | ✅ | 📝 | ❌ | `working-principles.md §原则4/7`；`AGENTS.md 硬规则 #4`；`mockup-conventions.md §M-COLOR`；有规则无"token 发布 + 废弃"工作流 |
| **版本迁移 / deprecation** | ✅ | 📝 | 📝 | `V1_RELEASE_CHECKLIST`；`API_STABILITY.md`；`MIGRATION_TO_V1.md`；v1.0 迁移文档化好；ongoing incremental deprecation + 2→3 refactoring 过程缺失 |

### B. 流程环节 × 任务规模

| 流程环节 | 小任务 lane (icon swap / text fix / token patch) | 大任务 lane (full feature / component design) |
|---|---|---|
| **Discovery / 需求澄清** | ❌ 无 micro-discovery path | ✅ Stage 0 + Stage 0.5 完整 |
| **Mockup 设计** | 📝 强制走 M48/M49/M50 → 过度（见第四节） | ✅ 完整 M0-M48 |
| **产品需求 → Code 设计** | 📝 R7 场景判定有，但无"简化执行路径" | ✅ Pre-Phase 0 + R0-R23 |
| **现有 audit** | ✅ `pnpm audit:*` 系列可独立跑 | ✅ Sprint Self-Audit 全套 |
| **设计走查** | 📝 无"仅检查改动区域"的 lite F1 | ✅ F1 全 6-section |
| **QA 测试** | 📝 `pnpm test:render-verification` 可跑子集 | ✅ 完整 CI gates |
| **Design token 治理** | ❌ 单 token 改动无简化核查路径 | 📝 规则有，workflow 无 |
| **版本迁移** | ✅ Patch/minor changeset 清晰 | 📝 Major/breaking 有文档，2→3 过程无 |

---

## 第二节：真缺口清单

> 硬纪律：每个 ❌ 附我查了哪里的证据。无证据不列。

---

### GAP-01：2→3 生命周期（重构 / 大版本迁移）无专项流程
**✅ 已解决 2026-06-12（action B1）**：新建 [`migration-protocol.md`](../migration-protocol.md)（四阶段 + 轻重分档），`code-conventions.md §场景 4` 挂入口。  
**Severity: High**  
**业界对标**: DesignOps Migration Playbook；API Deprecation Policy；semantic versioning migration guides  
**证据**：
- design-process.md 全文：US-1/2/3/5/6/7 均是 mockup 任务，无"产品级大迁移"场景 (subagent 确认 ~40% 覆盖)
- code-conventions.md R7 场景 4 "TVU 规范校正" 需用户显式发起，仅说明"不在增量 scope 混入"，无执行路径
- V1_RELEASE_CHECKLIST: 仅覆盖 v1.0 这一次迁移，无通用迁移流程模板
- backlog.md: 无 deprecation 专项 entry 模板

**缺什么**：
1. 迁移前基线快照（API spec + token usage snapshot + 截图基线）
2. Breaking change 决策树（何时 major bump？何时 feature flag？）
3. Migration guide 写作模板（比 CHANGELOG 更细粒度）
4. Consumer adoption tracking（RC soak → 验收 → close）
5. Rollback plan template

**建议落点**：新建 `docs/internal/migration-protocol.md`；V1_RELEASE_CHECKLIST §RC Consumer Protocol 补一段  
**按本项目量级**：有必要，Notification breaking 2026-06-11 就是一次无流程的 2→3

---

### GAP-02：小任务快速通道（US-5.S Micro-lane）缺失
**Severity: Medium-High**（每天高频摩擦）  
**业界对标**: Change classification routing (major/minor/micro)；Patch lane in design system governance  
**证据**：
- design-process.md US-5 (小文案/单元素改动) 无 micro-path：`design-process.md:73` 的 US-5 skip 清单仅豁免 ⓪⑤⑥⑦，`①②③④⑧` 仍强制
- M48 / M49 / M50 三者均为"起手**强制** Gate"（`design-process.md:182` M48 起手 Rule-Coverage Self-Check / `:226` M49 Design Quality Contract 7-section / `:379` M50 One-Page Design Kickoff Packet，均 2026-06-05/06-11 新增）——单元素改动（icon swap / 改一个词）适配 M49 7-section 合同明显过度（10x 量级不匹配）
- 无任何文件定义"触发 micro-lane 的条件"或"micro-lane 允许跳过的 gate"

**缺什么**：
1. US-5.S 触发条件定义（单 element / 单属性 / 无新 interaction）
2. micro-lane 允许 skip 的 gate 清单（M49 baseline/delta/semantic 可跳）
3. micro-lane 必做的最小 gate 清单（before-after comment + 仅扫改动属性的 M-rules）

**建议落点**：`design-process.md §US-5.S Single-Element Swap Protocol`  
**按本项目量级**：必做，单 owner 日常高频，微改动背重流程严重影响效率

---

### GAP-03：Design Token 发布 / 废弃工作流缺失
**⚠️ 2026-06-12 校正：报告夸大，非真缺口 → action B2 砍掉**。核对发现：token **分层架构**已在 [`token-layer-strategy.md`](../token-layer-strategy.md)（L1 primitive / L2 semantic）+ 3 层管线（primitive 从 Figma 同步 + 手写 semantic/component，`audit:token-contract` gate）；**废弃周期**已在 `API_STABILITY.md`（删/改名要先留 ≥1 minor → major 移除）。下文初稿"仅隐含/缺工作流"的判断不成立；残余仅一份可选的串联清单，单 owner 价值低。  
**Severity: Medium**  
**业界对标**: W3C Design Tokens Format Specification；Style Dictionary token versioning；Figma Variables → CSS Variables publish pipeline  
**证据**：
- working-principles.md §原则 4/7：有 token 治理规则（what），无"新 token 怎么加 + 废弃 token 怎么退"工作流（how）
- AGENTS.md 硬规则 #4：颜色硬编码=bug，必须用 token，但没有"token 不够时怎么补 + 审批"流程
- a11y-contrast-designer-review：token 决策散落在 Group A/B/C/D 个案里，无通用的"token 废弃流程"
- V1_RELEASE_CHECKLIST 无 token governance 维度
- backlog.md 无 token lifecycle entry

**缺什么**：
1. Token 新增 checklist（命名规范 → Figma Variable 绑定 → CSS 变量发布 → 文档更新 → consumer impact）
2. Token 废弃协议（deprecated 标注 → sunset timeline → migration path → 移除 gate）
3. Token 分层架构声明（primitive / semantic / component tier）目前仅 working-principles.md 原则 4 隐含

**建议落点**：`docs/internal/token-governance.md` 新建（或在 `working-principles.md` 扩一节）  
**按本项目量级**：中等必要，token 数量增长后这会成为瓶颈

---

### GAP-04：RC Consumer 验收协议缺失
**Severity: High**（v1.0 直接阻塞）  
**业界对标**: RC soak testing；Consumer acceptance sign-off；Design system adoption tracking  
**证据**：
- V1_RELEASE_CHECKLIST.md §RC 测试通过：仅说"等用户决定哪些 consumer 做 RC 测试"，无协议
- STATUS.md Active 后续：`RC product testing (1): 等用户决定哪些 consumer 做 v1.0.0-rc.N 测试`
- backlog.md / design-review-queue.md：无 RC soak 协议条目
- 已有 `GETTING_STARTED.md`，但无 consumer 验收标准

**缺什么**：
1. RC soak 合格标准（持续多少天？哪些场景算覆盖？接受多少 non-blocking issue？）
2. Consumer sign-off 模板（谁签、签什么、阻塞条件）
3. RC → Stable 的决策 gate（owner 自行还是需要多个 consumer？）

**建议落点**：`V1_RELEASE_CHECKLIST.md §RC Consumer Acceptance Protocol`  
**按本项目量级**：必做（v1.0 直接阻塞）；但 single owner 可以简化为"自己跑 MicroApps Console 1 周无 critical issue"

---

### GAP-05：QA 验收标准与设计规格绑定缺失
**Severity: Medium**  
**业界对标**: Acceptance Criteria in Design Handoff (BDD-style)；Design-to-Test traceability；Status Matrix as QA spec  
**证据**：
- design-process.md ⑤ F1 设计走查：覆盖视觉 + UX 一致性，但输出是"走查 report 卡"而非"QA 可执行的验收标准"
- PROJECT_GOAL.md §Status Matrix tab："QA 视角的状态测试" 提过但无对应 design-to-QA 转换流程
- V1_RELEASE_CHECKLIST §a11y CI：覆盖 axe 自动化，缺功能矩阵验收
- code-conventions.md、mockup-conventions.md：无"设计规格 → QA checklist"转换步骤

**缺什么**：
1. F1 走查输出与 QA 测试用例的显式映射（或说明 F1 已足够）
2. State matrix（UX 变体网格）→ QA 测试用例的自动/手动转换协议
3. 功能性 QA 验收标准在 M23 UX 交付卡里的标准位置

**建议落点**：`design-process.md §④ UX 交付说明卡` M23 补一个 Acceptance Criteria 字段；或在 `docs/internal/qa-to-design-bridge.md` 独立定义  
**按本项目量级**：有价值（单 owner 自己做 QA 也需要此清单防遗漏）

---

### GAP-06：M↔R 镜像规则的维护漂移风险（**校正：是故意的镜像，不该合并**）
**Severity: Low-Medium**（长期维护风险）  
**业界对标**: Single Source of Truth；DRY principle for rule management  
**证据（实证，2026-06-12 校正——范围比初稿大 4 倍）**：
- `code-conventions.md` **自己就标了 8 处"code-side mirror of M…"**：R13↔M35、R14↔M31、R15↔M32、R16↔M33、R17↔M36、R18↔M37、R19↔M38、R23↔M43（初稿只点了 M35↔R13 / M37↔R18 / M36↔R17 三对，**实际 8 对**）
- 每对内容字面高度重复（如 M37 5-row reference probe table vs R18 100% 相同）

**风险**：一边更新忘记另一边 → 两套同源规则漂移 → 不同 AI 工具读到不同版本

**校正后的判断（与初稿不同）**：这些是**故意的镜像**——M-rule 管 **Figma 产物**、R-rule 管 **代码产物**，同一原则落在两个不同产出面，不是手滑复制。所以**不该合并成"共享协议节"**（合并会丢掉各自面的特异表述）。正确做法 = **加双向交叉引用**：每条 M/R 顶部标 `↔ 见 R##/M##（镜像，改此条必同步对面）`，让编辑时强制想起对面。  
**建议落点**：`mockup-conventions.md` / `code-conventions.md` 各镜像条目顶部加一行 `↔` 交叉引用（不新建文件、不合并）  
**按本项目量级**：建议中期做（不阻塞发版；交叉引用比合并轻、且不丢特异性）

---

### GAP-07：触发器过载 — 单 owner 量级不匹配
**Severity: Medium**（workflow 摩擦，非 correctness 问题）  
**业界对标**: Tiered governance（必做 vs 条件触发 vs 可选）；Design system maturity scaling  
**证据**：
- meta-rules.md **16 个触发器（A–P）** 全部是"命中即强制"（实测 `grep -cE '^### 触发器 [A-Z]'` = 16；本报告初稿误写"12 个 A-N"，2026-06-12 校正）
- AGENTS.md §Sprint Self-Audit A-J：**名义上** commit 后跑多类——但**实际比看上去轻**（见下方校正）：D/E/F/G 已是 exit-0 机械 gate（`AGENTS.md:462`）、H/I/J 已挂 staged-file 条件 pre-commit、纯 doc 已豁免（`:460`）；真正"每次人工做"的只有 A/B/C 三类，且 mockup-only commit 的 B（代码 bug 自查）本就无代码可查 = 空
- meta-rules.md §触发器 N（≥2 独立子任务 → 强制输出 parallelism plan）：改两个参数名也要先声明
- 触发器 F（5 条反模式自检）：明确标注"响应前强制"，对简短回答也适用

**本项目实际需要的触发器分层**：

| 层级 | 触发器 | 理由 |
|---|---|---|
| **Always-on** | A（元提醒）/ B（规则落仓库）/ O（产品真值优先）/ K（规则声明 enforcement 层）| 防止所有任务中最严重的失误 |
| **Conditional: code/design change** | G（plan owner/executor 分工）/ I（bug 诊断三层）/ L（不确定 ask）| 只在真正做改动时触发 |
| **On-demand: large task / batch** | M（排期查 tracker）/ N（并行声明）/ P（open-questions gate）/ J（grep 查重）| 仅大任务 / 团队协作适用 |

**建议落点**：`meta-rules.md §触发器清单` 加一列 "适用场景"；`AGENTS.md §Sprint Self-Audit` 区分 code-commit vs mockup-commit vs doc-only 的子集  
**按本项目量级**：重要，单 owner 的触发器要能快速判断"此刻适不适用"

---

### GAP-08：1→1.x 增量任务缺乏架构协调检查
**Severity: Low-Medium**  
**业界对标**: Architecture Decision Record (ADR) for incremental changes；"does this fit the IA" pre-check  
**证据**：
- code-conventions.md §Pre-Phase 0（5 步）：明确定义了 0→1 的产品定义 gate
- code-conventions.md §R6：1→1.x 增量任务"existing pattern > TVU library"但无"与既有 IA 协调"的前置检查
- design-process.md US-3 lite-version：Stage 0 lite = persona + journey + boundary + firmware 问题，但无"新功能是否符合既有 IA/UX flow"的检查点

**缺什么**：增量任务起手增加一步"现有产品 IA 协调检查"（新增的 element/interaction 是否与既有模式一致？是否会破坏已有 user flow？）

**建议落点**：`design-process.md §Stage 0 lite (US-3)` 或 `code-conventions.md §Pre-Phase 0` 增一个 "IA compatibility check" 步骤（一句话：读已有 page 的 IA，验证新功能的插入点是否合理）  
**按本项目量级**：轻量补充即可（1 个检查问题，不需要 ceremony）

---

### 不成立的缺口（有规则，容易被误判为缺失）

| 环节 | 真实状态 | 文件位置 |
|---|---|---|
| Discovery/需求澄清 | ✅ 已有 Stage 0 + Stage 0.5（含 persona + journey + open-questions gate） | `design-process.md §Pre-Phase 0` L447; `meta-rules.md §触发器 P` L633 |
| Persona 测试 | ✅ 已有 F2 stage 6 | `design-process.md ⑥ Persona F2` L46; Stage 0.5 F2-early L652 |
| Journey map | ✅ 已有 ⑦ 5-stage journey map + State-Completeness Enumeration | `design-process.md ⑦` L662–682 |
| Design critique | ✅ 已有 F1 walk 查（6-section audit） | `design-process.md ⑤` L43; M11 自审规范 L830 |
| QA / 视觉回归 | ✅ render-verifier + a11y CI + drift-gate | V1_RELEASE_CHECKLIST; render-verification-report.md |

---

## 第三节：分层流程提案

### 现状基线：各档实跑什么（`design-process.md:71-76` 实录，非估值）

> 大小任务**当前已分档**（不是一刀切），但最轻一档（小调整）对"换个图标"仍偏重——这是 micro-lane 要补的缺口。下表是"现在实跑什么"的事实记录；后面的百分比仅为粗略示意，以本表为准。

| 档位 | 触发条件 | 现在跑哪些步 | 现在跳哪些步 |
|---|---|---|---|
| **全新需求** (US-1/2，0→1) | greenfield 新产品 / 新页 | 全 9 步 + 上游**全套** discovery（角色 + 体验地图 + 边界态 + 数据/固件提问） | — |
| **增量改既有页** (US-3，1→1.x) | 在既有页加 / 改 feature | 9 步全走；上游走**简版** | — |
| **小调整** (US-5) | 改文案 / 调位置 / 换颜色单点 | 命名页 → Jira → 画图 → UX 卡 → 规则回流 + 起手三道闸（规则自查 / 设计质量合同简版 / 一页起手总控包） | 上游思考 / 设计走查 / 角色模拟 / 体验地图 |
| **纯 audit** (US-6) | 只审不改 | 只跑设计走查 → 结果回流 | 其余全跳 |
| **🆕 微改** (US-5.S，拟新增) | 单元素 + 单属性 + 无新交互/元素 | 标本次产品需求 delta（依 `:100-103`）+ 一行说明 + 涉色查 M-COLOR | 连起手三道闸也跳 |

**读法**：从上到下越来越轻。问题在 US-5 与 US-5.S 之间——现在没有 US-5.S 这档，单图标/单词改动被迫走 US-5 全套（含三道起手闸），这是每日高频摩擦的根。

### 两条任务 lane

#### 小任务 lane（US-5.S Micro）

**触发条件**（同时满足三项才用 micro-lane）：
1. 仅改 1 个 element 的单个属性（icon instance / fill color / text content / token patch）
2. 不涉及 layout mutation / 新 interaction / state 新增
3. 无新 element 引入

**允许 skip 的步骤**：M49 Baseline/Delta/Semantic 表格；⑥⑦ Persona/Journey；M50 Design Kickoff Packet；M48 仅扫被改属性相关 M-rules（而非全扫）

**必做最小集**：
1. R7 / US-type intent check（场景判定，1 句话）
2. ③ Mockup 改动 → 改版注释**沿用已有规则 `design-process.md:100-103`（2026-06-04）**：只标**本次产品需求维度**的 delta（版本对版本，开发/PM 关心的），按三类过滤——需求变更写 / 既有行为复现不写 / **AI 迭代轮次·走的弯路不写进效果图**。**不是**标 AI 改图的前后 diff（中间过程进复盘，不进 mockup 注释）
3. ⑤ F1 lite（仅检查改动区域，不全 6-section）
4. ⑧ 1 行 changelog（填本次需求改了什么、为什么）
5. 若涉及颜色/token：M-COLOR 一致性检查（不需完整 M-INTEGRITY）

> **注**：第 2 条的"产品需求维度、非 AI 迭代过程"原则不是 micro-lane 专属——它对所有档位（US-1/2/3/5/6）一律适用，真源已在 `design-process.md:100-103`。micro-lane 直接引用，不另造规则。

**验收标准**：改动 node 的改版注释标的是**本次产品需求 delta**（非 AI 迭代轮次）+ 没有引入新 M-COLOR 违规

---

#### 大任务 lane（US-1/2/3 Standard）

保持 design-process.md 现有 8 步流程，以下为关键增强点：

1. **US-1/2 (0→1)**：新增 §Stage 0 Token Inventory Check（在 Phase 0 前确认所需 token 是否已有，如缺则先走 GAP-03 token 新增流程）
2. **US-3 (1→1.x)**：Stage 0 lite 末尾加 "IA Compatibility Check"（见 GAP-08）
3. **US-6 (audit-only)**：明确 M49 lite 条件（仅 Semantic + UX + Content 三 section）

---

### 三条生命周期骨架

#### 0→1 全新（覆盖最强，仅轻微补强；百分比示意，实跑见上方现状基线表）

```
[前置] Token Inventory Check（确认所需 token 已存在）
  ↓
Stage 0 Full（persona + journey + boundary + data/firmware questions）
  ↓
Stage 0.5（Quality Contract + Design Kickoff Packet M50）
  ↓
① Page + Section → ② Jira → ③ Mockup → ④ UX 卡 → ⑤ F1 → ⑥ Persona → ⑦ Journey → ⑧ 规则回流
  ↓
Delivery Cleanup Gate（M22 前置验、M51 regression snapshot）
  ↓
[CODE] R0 Phase 0 → Pre-Phase 0 → R1-R23 visual implementation → R8 7步自检 → R9 交互补全
  ↓
[QA] render-verification + a11y CI gate
```

**补强**：① 前置 Token Inventory；② F1 走查输出显式包含 QA acceptance criteria（连接 GAP-05）

---

#### 1→1.x 增量迭代（覆盖中等，两处补强；百分比示意，实跑见上方现状基线表）

```
Stage 0 Lite（persona + journey lite + boundary + 数据问题）
  ↓
[NEW] IA Compatibility Check（新 element/interaction 与既有 IA 是否一致？）
  ↓
M21 Sibling Visual Contract Probe
  ↓
③ Mockup（仅改动部分）→ ④ UX 卡（简化版）→ ⑤ F1 Lite（与周边 sibling 一致性检查）
  ↓
[CODE] R7 场景 2 → R6（existing pattern > library）→ R17/R18 复用检查
  ↓
[QA] 增量 render-verification（只跑改动组件的 manifest entries）
```

**补强**：① IA Compatibility Check；② F1 Lite 的 sibling 一致性是主项，不是全 6-section

---

#### 2→3 重构 / 大版本迁移（覆盖最薄，需建流程；百分比示意，实跑见上方现状基线表）

> 此条完全缺失，以下是一次性 new 提案，等 owner ack 再写入规范

```
Phase A: Migration Baseline
├── 现有 API 快照（props/events/slots 全枚举）
├── Token usage snapshot（哪些 token 被改动组件使用）
├── 截图基线（render-verification manifest 当前快照）
└── Consumer dependency scan（谁在用，影响面）

Phase B: Migration Plan
├── Breaking change 决策树（是否 major bump？feature flag？）
├── Migration guide 初稿（old → new 映射表）
├── Changeset 文件（major，含迁移说明）
└── Owner ack gate（确认迁移方案可接受）

Phase C: Implementation
├── [CODE] breaking change 实现 → 新 API 全量测试
├── [FIGMA] 如有对应设计变更：design-process.md 完整 8 步
├── Migration guide 最终版（含实际 code diff 示例）
└── CHANGELOG 写迁移说明（含 §2 映射表格式）

Phase D: Verification + Consumer Adoption
├── render-verification 全量 pass（基线更新到新 API）
├── a11y CI 全绿
├── Consumer RC soak（见 GAP-04 RC 验收协议）
└── Burn-in clock 重置记录（v1.0 path）
```

---

## 第四节：反向检查 — 现有流程的过度/冗余

> 命中以下任一 = 小任务被迫背重流程，建议精简

### 过度 #1：Sprint Self-Audit A-J 全量（任何 commit 都跑）— ⚠️ 2026-06-12 校正：初稿夸大，已决定不改

> **校正**：核对真源后，"任何 commit 跑全 9 类"是**夸大**——`AGENTS.md:462` 显示 D/E/F/G 已是 exit-0 机械 gate、H/I/J 已挂 staged-file 条件 pre-commit、纯 doc 已豁免（`:460`）。真正"每次人工做"的只有 A/B/C 三类，且 mockup-only commit 的 B（代码 bug 自查）本就无代码可查 = 空。**结论：该过度基本已被现有机制自动消化，对应的 action A3 已砍掉**（见第五节）。下表保留作"理想分子集"参考，但不立规则。

**现状（校正后）**：脚本类（D-J）已按 staged 文件条件触发；人工类（A/B/C）按 commit 类型的理想分子集如下（仅参考，不强制）：

| commit 类型 | 必跑 | 可选 |
|---|---|---|
| code change | A（spec gap）/ B（实现 bug）/ C（doc lag）/ D（render-verif）/ E（canonical compliance）/ J（token contract）| H/I（icon 相关，仅 icon 改动时） |
| mockup change | A（spec gap）/ C（doc lag）| B/D/E/J（代码相关，可选 per-task） |
| doc-only | C（doc lag）| 其余全可选 |

---

### 过度 #2：M49 Design Quality Contract — 小改动 7-section 过度

**现状**：M49 Design Quality Contract 7-section 表（Baseline/Delta/Semantic/Feedback Inventory/UX/Simplicity/Content）  
**问题**：单元素改动（icon swap / text fix）适用 7-section 是 10x 过度  
**建议精简**：US-5.S micro-lane skip M49 Baseline/Delta/Semantic（改动自明），只保留 UX + Content 两 section 的 1 句话描述

---

### 过度 #3：触发器 N（≥2 子任务强制 parallelism plan 声明）

**现状**：`meta-rules.md §触发器 N` 任何 ≥2 个独立子任务强制输出 parallelism plan  
**问题**：改两个独立 CSS 变量也要先声明 parallelism plan，摩擦 >> 收益  
**建议精简**：门槛升为"≥3 个完全独立子任务 + 任意一个预计 >30min"，或降级为 Conditional（仅大任务 lane 适用）

---

### 过度 #4：feature branch + PR 流程（Owner override 已豁免但仍占文字篇幅）

**现状**：`AGENTS.md §Git 工作流` 完整 PR 流程文本（L151–301），虽然 Owner override 已落（L145），但 non-Owner 约束仍占满篇幅  
**问题**：单 Owner 项目中 non-Owner 操作频率极低，但 PR 仪式文字量与实际使用频率严重不符  
**建议精简**：重构为"Owner = 直 commit master（默认）+ non-Owner = feature branch + PR（见附录）"，主文档压缩为 2 行

---

### 过度 #5：WRAP-UP.md 缺 Figma Library 同步验证

这是"缺失而非过度"但放这里因为属于收尾流程——  
**现状**：WRAP-UP.md 覆盖 STATUS 更新 + Release 验证 + Retrospect 触发，但无"本 session 改过 Figma 设计系统库 → 验证 publish 状态"步骤  
**建议补充**：`WRAP-UP.md §Optional Gates` 加：若本 session 有 Figma library 写操作 → `pnpm sync:figma-library --verify-only` 确认同步完成

---

## 第五节：优先级排序 Action List

> 每条 = 建议（owner ack 后才动任何规范文件）

### 立即值得做（解决每日高频摩擦 / 直接阻塞 v1.0）

| # | 建议 | 落点 | 原因 |
|---|---|---|---|
| A1 | ✅ **已落 2026-06-12** — US-5.S micro-lane（触发条件 + 自判决策树 + 保守兜底 + skip 清单）| `design-process.md §跳步规则 + §起手自判档位` | 每日高频摩擦，ROI 最高 |
| A2 | ✅ **已落 2026-06-12** — RC Consumer 验收协议（soak 对象/时长/场景/合格线/sign-off）| `V1_RELEASE_CHECKLIST §RC Consumer 验收协议` | v1.0 直接阻塞 |
| A3 | ❌ **砍掉（2026-06-12 owner 决定）** — 原提"Sprint Self-Audit 按 commit 类型分子集"。核对真源后发现：D-G 已 exit-0 机械 gate、H/I/J 已条件 pre-commit、doc-only 已豁免，真正每次人工的只有 A/B/C，且 mockup-only 的 B 本就为空 → 该问题基本已自动成立，写规则是废话，不做 | — | 收益极小且与现有机制重叠 |

### Owner-gated（需要 owner 决策方向再动）

| # | 建议 | 落点 | 原因 |
|---|---|---|---|
| B1 | ✅ **已落 2026-06-12** — 2→3 迁移流程（四阶段 + 轻重分档 + 文件关系）| 新建 [`docs/internal/migration-protocol.md`](../migration-protocol.md)，并在 `code-conventions.md §场景 4` 挂入口 | Notification breaking 证明没有流程的代价 |
| B2 | ❌ **砍掉（2026-06-12 owner 决定）** — 核对发现报告夸大：token **分层架构**已在 [`token-layer-strategy.md`](../token-layer-strategy.md)（L1/L2）+ 3 层管线（primitive 从 Figma 同步 + 手写 semantic/component，`audit:token-contract` gate）；**废弃周期**已在 `API_STABILITY.md`（≥1 minor → major）。残余仅一份串联 front-door 清单，单 owner 价值低，不做 | — | 已基本覆盖，非真缺口 |
| B3 | QA 验收标准与 M23 UX 卡绑定 | `design-process.md §④ + mockup-conventions.md §M23` 补 Acceptance Criteria 字段 | F1→QA 转换目前靠人工判断 |
| B4 | ✅ **已落 2026-06-12** — 触发器适用场景分层（总是开 / 改动时 / 大任务时）| [`meta-rules.md §触发器适用场景分层`](../../meta-rules.md) 加分层表（不弱化、判不准当总是开）| **16 个**触发器全强制 = 摩擦 |
| B5 | 1→1.x 增量 IA Compatibility Check | `design-process.md §US-3 Stage 0 lite` 加 1 个检查步骤 | 防增量功能与既有 IA 撕裂 |

### 中期做（维护风险，不阻塞短期）

| # | 建议 | 落点 | 原因 |
|---|---|---|---|
| C1 | ✅ **已落 2026-06-12** — 8 对 M↔R 镜像双向交叉引用（M36/37/38 原已有 R 回指；补 M31/M32/M33/M35/M43 → R14/15/16/13/23 共 5 条）| `mockup-conventions.md` 各镜像条目头部加 `↔ Code 端镜像 R##` | 两套同源规则迟早漂移；交叉引用比合并轻且不丢特异性 |
| C2 | WRAP-UP.md 补 Figma Library sync 验证 gate | `WRAP-UP.md §Optional Gates` 新节 | 防止 Figma 改动未同步到 figma-data |
| C3 | 触发器 N 门槛升级 | `meta-rules.md §触发器 N` | ≥2 子任务的 parallelism plan 门槛过低 |

### 业界有、本量级不必要

| 实践 | 为何不适用 |
|---|---|
| 多设计师评审会 / 设计冲刺工作坊 | 单 owner，不存在多设计师协调问题 |
| 跨团队 token 治理委员会 | 单 owner，token 决策快速直接 |
| 正式可用性测试 session（5 用户法）| 单 owner 量级；F2 persona simulation 已够；正式测试需要外部参与者招募 |
| Architecture Review Board | 单 owner，架构决策在 owner 自己 |
| 分离 Design Ops 角色 | owner 同时握 design/code/release，无需分角色 |

---

## 附录：关键文件关系（防混淆）

| 文档 | 层次 | 核心职责 |
|---|---|---|
| `AGENTS.md` | 元规则框架 | AI 工具的身份 / 硬规则 / gate 判定 / git 工作流 |
| `meta-rules.md` | 元规则反模式 | 规则设计的反模式清单 + 12 个触发器 |
| `working-principles.md` | 工程实现原则 | Figma↔Code 具体实现规则（命名 / token / API 形态）|
| `design-process.md` | 流程 SoT | mockup 设计 8 步流程 + M22-M51 质控 gate |
| `mockup-conventions.md` | Figma 产物规范 | M0-M48 Figma 操作具体约束 |
| `code-conventions.md` | Code 产物规范 | R0-R23 Code 实现具体约束 |
| `V1_RELEASE_CHECKLIST.md` | 版本 gate | v1.0 DoD + 用户决策点 |
| `design-review-queue.md` | 设计侧观察 | 非闭合设计意图待裁定项 |

**分层职责**：元规则（AGENTS + meta-rules）→ 实现规则（working-principles）→ 流程 SoT（design-process）→ 产物规范（mockup + code conventions）→ 验收 gate（V1_RELEASE_CHECKLIST + reports）

---

*由 Claude Sonnet 4.6 生成，2026-06-11 | 等 owner ack 后才动任何规范文件*