# Design Spec & Process 体系完整性 Review — 起手 Prompt（可复用）

> **用途**：整体 review 这套设计系统的「规范 + 流程」体系是否优化、是否缺常见流程，按生命周期（0→1 / 1→1.x / 2→3）× 任务规模分层，对标业界最佳实践找真缺口。
> **怎么用**：新开一个 session，把下面 `=== PROMPT ===` 之后的全文复制发给 AI（或 `Read` 本文件后直接执行）。这是**诊断任务，不改真源**——产出 gap 报告 + 推荐，owner 逐条 ack 后才动规范文件。
> **与 `system-design-review.prompt.md` 的区别**：那份偏 mockup/产物质量的整体走查；本份偏「流程体系完整性 + 分层流程设计」。接手 AI 应先读那份看已覆盖什么，避免重造。
> **维护**：复用即改。落点约定 = `docs/internal/_prompts/`（file-based，避免 VS Code 扩展剪贴板编码问题）。

---

=== PROMPT ===

任务：整体 review TVU 设计系统的「规范 + 流程」体系是否优化、是否缺常见流程，并产出一份带业界对标的 gap 报告 + 分层流程建议。这是诊断任务，不是改文件——输出报告 + 推荐，由 owner 拍板后才动任何规范文件。

== 起手（强制，不可跳）==
1. 按 docs/STATUS.md §起手必读链路 完成 onboarding（L-core 4 份全文 + 命中的 L-ref）。
2. 用 subagent 并行读规范本体，别在主线一次性吞（这些文件加起来 ~2000 行，会撑爆 context / 触发 output 上限）。至少分这几组各派一个 subagent 回报结构化摘要：
   - 元规则组：AGENTS.md（硬规则表 + Mockup/Onboarding Gate）、docs/meta-rules.md、docs/working-principles.md、docs/FIGMA_AS_SOURCE_OF_TRUTH.md
   - 流程组：docs/internal/design-process.md（⭐ 已有 8 步流程，重点读）、docs/internal/_prompts/system-design-review.prompt.md（⭐ 旧 review prompt，先看它覆盖了什么，别重造）、docs/WRAP-UP.md
   - 产物约束组：docs/internal/mockup-conventions.md（M-rules）、docs/internal/code-conventions.md（R-rules）、docs/internal/component-affordances.md
   - 校验/发版组：V1_RELEASE_CHECKLIST.md、render-verification-report.md、a11y-contrast-report.md、figma-vs-sot-drift-report.md、docs/internal/backlog.md、design-review-queue.md

== Review 框架（两条轴必须分开，不许混在一起谈）==
轴 A — 生命周期阶段：
   - 0→1：全新产品/组件（discovery、需求澄清、信息架构、首版 mockup→code）
   - 1→1.x：在既有设计/产品上做增量（M46 instance 迭代、增量 code、回归校验）
   - 2→3：重构 / 大版本 / 迁移 / 组件 deprecation / token 废弃
轴 B — 任务规模：小任务 lane vs 大任务 lane。明确「小任务有小任务的流程、大任务有大任务的流程」——给出各自该跑哪几步、该跳哪几步，不要让小任务背大流程、也不要让大任务漏环节。

== 必须逐一核对覆盖度的流程环节 ==
Discovery/需求澄清 · Mockup 设计(Figma) · 产品需求→Code 设计 · 现有 mockup/产品设计的检查(audit) · 设计走查(design critique) · UX 体验地图(journey map) · persona/用户角色测试 · 可用性测试(usability) · QA 测试(功能/状态矩阵/视觉回归/a11y) · design token 治理(新增+废弃) · 版本迁移/deprecation。
对每个环节判定：✅已成文 / 📝部分 / ❌缺失——并指向具体文件:行。

【硬纪律：判"缺失"前必须先 grep/Read 实证】design-process.md 已覆盖 persona/journey/走查等，不许凭印象说"没有"。grep 没命中 ≠ 不存在，先排查拼写/字段/归属。每个 ❌ 都要附"我查了 X、Y、Z 都没有"的证据。
**更狠一条（2026-06-12 实证）：字段/机制存在 ≠ 失效模式被覆盖**。别看到"有 Acceptance 字段 / 有 F2-early"就判覆盖——必须核它**抓不抓得住实际出问题的那类 case**；抓不住就是 📝 部分，写清漏抓什么。

== 第二条核对轴：系统一致性 + 完整性维度（2026-06-12 新增，与上面流程环节并列必查）==
上面的流程环节是「生命周期轴」；但 review 还必须比对「系统横向一致性轴」——否则跨变体对齐、跨组件同语义布局这类问题会漏（实证：2026-06-12 owner 撞到才发现，原 checklist 没有这条轴）。逐一核对 [`retrospection/consistency-dimensions-audit-2026-06-12.md`](../retrospection/consistency-dimensions-audit-2026-06-12.md) 的 15 维尺子（D1–D15：跨变体对齐 / 跨组件同语义 IA / Figma→code 原子同步 / 交互态一致 / 命名一致 / a11y 范式 / API 公约 / **运行态数据态范式** / UX 文案 / 选用指引 / 组合范式 / 主题对等 / i18n 文本膨胀 / 成熟度标注）。每维同样 ✅/📝/❌ + file:line，且遵守上面"字段存在≠覆盖"硬纪律。该尺子外部锚定 Ant Design / Element Plus / Polaris / Material / Carbon。

== 对标业界（用来检验 + 补缺，不是硬塞）==
参考但不限于：Double Diamond、设计系统成熟度模型(Sparkbox/Figma DSM)、Atomic Design、Nielsen 10 大启发式 + 启发式评估、WCAG 2.2 AA、视觉回归 QA(Chromatic 范式)、W3C Design Tokens 分层、DesignOps、JTBD/journey mapping、任务分级(如 RICE/T-shirt sizing)。
对每条业界实践：说明它解决什么问题、本项目是否已有等价物、若引入该放哪个文件、按本项目量级是否值得（见下条 calibration）。

== 量级校准（关键，别开错药）==
本项目是【单一 owner(Nancy) + AI 代理(plan owner/executor)】模式，不是多人/多团队。所以：
- 凡是"多设计师评审会 / 跨团队审批 / 设计冲刺工作坊"这类重团队 ceremony，明确标注「不适用本量级」，不要推荐。
- 推荐的流程要适配"owner 同时握 design/code/release + AI 执行"的高集成、轻审批特点。
- 区分两类规范别混谈：① AI 协作元规则(AGENTS/meta-rules) ② 设计/工程产物流程(design-process/mockup/code conventions)。review 这两类时分开评。

== 产出物（一份报告，不改任何规范文件）==
1. 覆盖度矩阵：流程环节 × (生命周期阶段 + 任务规模) → ✅/📝/❌ + 现有文件:行。
2. 真缺口清单：每条带 severity + 业界对标参照 + 建议落点(放哪个文件) + 建议流程权重。
3. 分层流程提案：小任务 lane 与大任务 lane 各自的 step 清单；0→1 / 1→1.x / 2→3 三条生命周期各自的流程骨架。
4. 反向检查：现有流程里有没有"过度/冗余/小任务被迫背重流程"的地方，建议精简。
5. 优先级排序的 action list（哪些值得现在补、哪些 owner-gated、哪些标记为"业界有但本量级不必要"）。

最后：报告写到对话 + 落一份到 docs/internal/_plans/ 或 retrospection/（文件名带日期）。不要直接改 AGENTS/conventions/design-process 等真源——所有改动等 owner 逐条 ack。