O que 统一设计系统 faz?
一个入口，覆盖所有设计领域。
资源加载规则
开始时加载注册表。各阶段按需加载该阶段的资源。 不生成用户偏好档案；技能架构见
skill-architecture.html，运行路线见skill-workflow.html，版本变更见CHANGELOG.md。
启动时加载
| 资源 | 为什么 |
|---|---|
manifest.md | 知道有哪些领域和资源 |
加载预算（硬上限）
本 skill 有 125 个文件；读完全部再动手 = 任务失败。
| 约束 | 值 |
|---|---|
| 启动加载（不计入预算） | manifest.md——注册表必读，不占额度 |
| 主文件外规则文件最多再读 | 4 个 |
| 这些文件合计 | ≤1200 行（真实总闸） |
| 单文件 >400 行 | 只读被点名的 § 节，不读全文 |
为什么是 4：真正的成本是行数不是文件数（Web 线 3 个必读仅占 1200 行的 37%）。文件数上限是防「东读一点西读一点」的启发式——4 个 × 平均 300 行 ≈ 1200 行，两个约束自洽。别把第 4 个额度当成默认余量随便花，花之前先走下面的落点决策。
预算按序花在：① 领域主文件（domains/web/distilled-playbook.md / domains/poster/MODE.md / domains/brand/MODE.md）② 该领域标「必须」的那份（如 domains/web/anti-slop/MODE.md）③ 确需具体数值时才读 shared/ 对应 § 节。
按当前结构，一次 Web 任务的必读是 3 个：distilled-playbook.md + domains/web/anti-slop/MODE.md + references/flow.md。素材三档、本地字体清单、工程坑 P1–P11 都在本文件，不必再下潜。第 4 个额度的设计用途：阶段 ④ 读 shared/react-bits-assets.md（§0 + §3，禁止整读 1626 行）。其余情形它就是余量（确需第 4 份时用，见「新规则往哪放」）。
领域原则按域分片（参考级，不占必读额度）：跨领域通用核心 shared/design-principles.md（§1.1–§1.12）+ 领域子集 shared/design-principles-web.md / shared/design-principles-brand.md / shared/design-principles-poster.md。加载方式：按当前领域只加载对应子集，按需取用（如 Web 任务的阶段①竞品分析 / ③记忆点设计才读 design-principles-web.md 对应节），参考级、不计入必读 3 个额度，不必通读通用核心全文。
references/gates.md 与 constraints.md 属于可选参考（判据细则 / 边界情形），不占这 3 个额度——需要再查，不需要就跳过。
禁止：为「理解全貌」通读所有被指向的文件；整读 shared/react-bits-assets.md（1626 行；选组件看 §3 分类 / §5 详解）或 shared/design-philosophies.md（选哲学看 §选择指南）；连读 4 个以上文件仍不动手。
新规则往哪放（落点决策，先走这里再动预算）
新增一条规则时，按序判断，前三步命中就不许新开文件：
- 所有领域、所有任务都需要？ → 放主文件（主文件不计预算——这是必须级规则的正确成本：每次都要用，就该每次都在）。判据：海报任务和 Web 任务没它都会做错。
- 只属于某个领域的流程？ → 并入该领域已有的必读文件（如 web 的并进
distilled-playbook.md），不新增文件。SSoT：宁可用小标题分区，也不开新文件。 - 只是数值 / 细则 / 查表？ →
shared/对应文件，保持参考级（不占必读额度，需要才查）。主文件若相关，留一行指针。 - 以上都不是、且确实每次必用？ → 才允许新增第 4 个必读文件。此时在「领域速查」登记它属于哪条领域线，并确认 1200 行总闸仍够（当前 Web 线用 439/1200）。
主文件警戒线：≤400 行。 超过时优先把「非每次必用」的内容按判据下沉回 references（留一句话判据），而不是继续膨胀——主文件涨一行，所有任务都付一次。
耗尽即停：用已读内容产出，交付时一行注明「跳过 X（加载预算）」。基于 3 个文件的完整方案 > 读 10 个文件没有产出。
交付前自验（不占加载预算）
产出 HTML 后，建议跑一次无头浏览器渲染（npx playwright screenshot / 本地 Chrome·Edge --headless --screenshot），至少在 1440 与 390 两个宽度各截一张，核对三件事：
- 首屏是否空白——动效若依赖 JS/IntersectionObserver 才显形，慢机器与截图场景会全白；首屏内容必须直接可见
- 是否横向溢出或文字贴边——检查区块的
padding简写有没有覆盖容器的左右内距 - 标题是否溢出——桌面宽度下标题超 3 行，说明
clamp()上限或字号错了
发现问题当场修，别交付没渲染过的页面。看代码看不出这三类问题。
自验预算（有上限，防止把自验做成无限返修）：最多 2 轮，每轮 2 张（1440 / 390），单轮 ≤90 秒。两轮后仍有问题就停手，把剩余问题写进交付说明——自验是发现三类结构性问题的手段，不是把页面调到完美。
7条核心设计原则
这7条原则是设计的灵魂指南。不是检查清单，是思考方向。
| 原则 | 核心问句 | 含义 |
|---|---|---|
| 有根基 | 知道为谁设计、解决什么问题 | 在动手之前搞清楚：目标用户是谁？看完页面后要做什么？核心要传达的一条信息是什么？没有根基的设计 = 自嗨 |
| 有灵魂 | 有一个统领性的调性，所有决策服务于它 | "如果这个页面是一个人，TA 的气质是什么？" 用一个词定义（如"精致"/"力量"/"叛逆"）。后续的颜色、字体、间距、动效都围绕这个词展开 |
| 有系统 | 所有元素服从同一套视觉语法 | 颜色、字体、间距、动效时长、交互反馈 — 建立统一规则后，每个新元素自动继承这套系统，不需要逐个决策。详见shared/system-design.md §2 设计起点选择 + §3 三参数影响矩阵 |
| 有记忆点 | 至少一个让人停下来看的东西 | 可以是独特的交互方式、一种材质感、一种文字处理方式、一种空间关系。不需要复杂 — 一个精心执行的简单创意，胜过十个粗糙的复杂效果 |
| 有温度 | 传递情绪，不只是堆砌信息 | 页面给人什么感受？安静、活力、温暖、神秘、科技感、自然感？情绪不是装饰，是设计的底层驱动力 |
| 有品质 | 交付必须完整可用，不能有半成品 | 每个状态都有交代（loading/empty/error/success），移动端适配完整，支持 prefers-reduced-motion，使用 CSS 变量 |
| 有匠心 | 你认真对待这个设计了吗？ | 不遗漏重要内容，不马虎，不以次充好，不随便制作。每一个细节都认真对待，全力以赴，不偷工减料 |
单一真源契约（SSoT · 改本文件前必读）
本文件过去的主要失效模式：同一规则被复制到 3–4 处——流程表格抄一遍、硬检查点抄一遍、质量门抄一遍、约束再抄一遍。 后果不是"更保险"，而是被当成重复的空勾选：勾一处就算过，规则实际失效。这正是"纸面遵守 ≠ 代码级遵守"的机制成因。
分层职责（新增内容按此归位，错位即视为缺陷）：
| 层 | 位置 | 只放什么 | 禁止放什么 |
|---|---|---|---|
| 定义层 | 「工作方式约束」约束0–9、「通用底线」 | 规则的唯一定义 | — |
| 流程层 | 自适应设计流程各阶段表格 | 何时做什么 + 查哪个文件 + 指针（"按约束X"） | 禁止复述约束定义 |
| 门禁层 | 第四阶段执行门禁、质量门、工程坑门禁 | 核验动作 / PASS 阈值 / 体检问句 | 禁止重申制度性定义 |
归位测试（加规则时必问）：这条是在定义规则，还是在核验规则？ → 定义进定义层，核验进门禁层，二者只能落一处。 → 进一步：判断类（品味/连贯/丰富度，无法机械判定）归质量门；事实类（能用 grep/ls/断言验证）归工程坑门禁。归错层，这条规则就失效。
设计流程（6 阶段）
| 阶段 | 做什么 | 交付物 |
|---|---|---|
| ① 调研与需求 | 提取隐性需求、判领域、定三参数 | 需求复述（CP1 用）+ 三参数 |
| ①.5 主动推演 | 把一句话需求延伸成完整 brief | 延伸后的 brief |
| ② 灵感锁定 | 直接锁 1 个最高级方向（四轴之一） | 方向 + 核心张力（CP2 用） |
| ③ 构思与叙事 | 信息架构、滚动叙事、意图映射 | Intention Map（强制；未产出不得进 ④） |
| ④ 系统设计 | 设计语法、动效盘点、能力盘点；动效/交互组件先查 shared/react-bits-assets.md §0（兑付状态：11 个本地 ✅，其余 🌐 需联网）+ §3 海选，只用 ✅ 或自创等效 | 系统设计表 + 能力清单 ≥8–10 项（须注明组件来源：react-bits ✅ / 🌐 / 自创） |
| ⑤ 视觉实现 | 字体 / 色彩 / 版式 / 素材落地 | 页面产物（HTML/CSS/JS，形态见 shared/code-generation-strategy.md §3.1；含字体与素材的落地或降级声明） |
| ⑥ 交互与交付 | 交互、性能、三套门 | 过门禁的成品（CP4 用）+ usage-log.md 追加一行（日期 / 任务 / 种子 / 鼠标族 / 组件） |
走到哪一阶段，才读
references/flow.md的哪一节——不必通读。每节含「做什么 / 具体内容 / 查阅什么」三列。
领域分叉（重要）：上面 7 步是 Web 的完整流程。另两个领域走自己的线，别套 Web 的阶段与门禁：
- 海报 →
domains/poster/MODE.md§8 的 5 步：定尺寸 → 定主张 → 选家族 → 排三层 → 缩略图自检 - 品牌 →
domains/brand/MODE.md的 B1–B5：策略（9 问法）→ 视觉模式 → Logo → 品牌板 → 产出
视频 → domains/video/MODE.md：先判该不该用（§1）→ 定角色与体积（§2）→ 选路线（§3）→ 做融合（§4，违和感 90% 在接缝）→ 过 V1–V9 交付检查。
工具是旁路，不在主闭环里：PPT / 视频导出 / 翻新审计 / 设计思维 各自独立触发（见「领域速查」），与 6 阶段并行，不占阶段编号。
工作方式约束 0–9（速查）
| # | 规则 | 判据 / 例外 |
|---|---|---|
| 0 | 用户明确指令 > 通用默认 | 与硬规则冲突时指出并给替代；用户坚持则遵从 |
| 1 | 直接锁最高级方向，不抛平行选项 | 四轴之一（极致克制 / 密度 / 运动 / 材质）做到尽头；不以实现难度为降级理由（难度只影响实现路径，不影响方案） |
| 2 | = 约束1 的场景展开 | "随便"→1 个方案；"给 2–3 个对比"才多方案 |
| 3 | 改动一次只问一个问题 | 多问 = 用户无法归因 |
| 4 | 精致度优先于速度 | 动效无动机 / 节奏全平 / 状态缺失 → 停下修 |
| 5 | section 数由规划定 | <5 须写明「为何极简适合本 brief」；禁凑数、禁偷懒 |
| 6 | 模式是种子，不是骨架 | 禁「选风格→套骨架」，须当场重组 |
| 7 | 种子驱动连贯契约 | 每个维度要么与种子共振，要么写明「刻意省略」 |
| 8 | 反保守生成纪律 | ≥3 种技术语言；交互须真实；文字也要动 |
| 9 | 素材库取用纪律 | 先锁种子 → 同族本页 ≤1 → 写使用声明 |
| 10 | 方案冻结，禁顺手捞现成 | 先列「方案需要什么」再查「手上有」；替换必须写「原定 / 实做 / 为何不等价」，静默替换=失败 |
完整规则、边界情形与原理（含约束 0 的冲突裁决细则）见
references/constraints.md。约束 0 优先级最高，凌驾其余约束与门禁（工程底线除外）。
门禁速查（交付前必过）
| 门 | 时机 | 查什么 | 不过怎么办 |
|---|---|---|---|
| 执行门禁 | 进 ⑤ 之前 | 能力盘点 ≥8–10 项（必含 ≥1 文字动效 / ≥1 WebGL·Canvas / ≥1 GSAP·滚动编排）；同族重复须给种子理由（查 usage-log.md）；联网获取记录（抓什么→从哪→结果，A3）；交付形态受限时按可达上限给足并注明受限原因，禁虚构也禁默默缺项 | 补盘点再进 |
| 质量门 7 条 | ⑤ 末 · ⑥ 前 | 交付须给 PASS/HOLD 决定（taste-rules.md §8，禁「整体不错」式放行）； critique 10 维 + 媒体/动效/布局是否「克制而丰富」+ 种子连贯 + 反保守 7 问 | 回对应阶段改，禁带半成品交付 |
| 工程坑门禁 P1–P11 | 交付前 | grep / ls 机械核验：字体落地、CDN 兜底、横向溢出、斜体降部… | 修到 PASS，禁止带 FAIL 交付 |
执行门禁与质量门的判据细则见
references/gates.md；工程坑 P1–P11 如下，属每次必用，不再下沉。
工程坑门禁 P1–P11（交付前逐条跑）
与上方质量门的分工（关键）：质量门判「好不好」——品味/连贯/丰富度，属判断类，靠审美，无法机械判定； 本门禁判「有没有坏」——会真实伤到可用性/观感的已知工程缺陷，属事实类，靠核验。 收录原则：只收能用 grep / ls / 运行时断言机械核验的项。判断类规则一律不进本门（留在质量门），否则会退化成"自证合规"的空勾选。 执行：交付前逐条跑，任一条 FAIL → 修复后重验，禁止带 FAIL 交付。
| # | 坑（真实踩过的） | 核验方式 | PASS 条件 |
|---|---|---|---|
| P1 | 只有背景动、内容不动（最常见、最伤"整体感"） | grep 每个内容 section 的滚动动画绑定 | 内容容器存在 scroll-linked 的 translateZ/scale/rotate，不是只有 opacity/clip-path；且背景与内容由同一 progress 驱动 |
| P2 | 景深/装饰层压住内容 | 查 z-index 堆叠 + pointer-events | 近景/装饰/噪点层 z-index 低于内容层，且全部 pointer-events:none |
| P3 | 转场闪烁/闪帧刺眼 | 查闪烁元素 opacity 峰值与 duration | 峰值 ≤ .4 且时长 ≥ .3s（可量化阈值，超出即刺眼） |
| P4 | prefers-reduced-motion 未真降级 | grep 该媒体查询分支 | 存在分支且其中关闭 WebGL/重动效/闪烁，非仅缩短时长 |
| P5 | 字体/JS 引用了但文件没落地 | ls 产出目录 assets/fonts/ 与 .js | @font-face 的 src、<script src> 指向的文件物理存在（单文件交付例外：改为核对交付里是否给了 @font-face 片段 + TTF 清单）；若用了 interactive-editing.js，其文件同样在场且页面已全面使用 CSS 变量（否则面板调不了参）（与质量门 6 同检，此处是核验动作） |
| P6 | CDN 依赖无兜底，库缺失即白屏/无光标 | grep CDN <script> 是否有降级分支 | 关键库加载失败时页面仍可读、光标不消失（隐藏系统光标必须在 JS 确认就绪后） |
| P7 | 动画动了非 GPU 属性 | grep transition/animation/GSAP 属性 | 仅 transform/opacity/filter（+相机参数），无 width/top/left |
| P8 | 移动端未降级 | 查断点下的 WebGL 开关 | ≤820px 关闭重 WebGL，走 CSS 3D 降级 |
| P9 | 撞了 AI-slop 字体 | grep font-family / @font-face | 显示字体不是 Inter / Fraunces / Instrument Serif（这三个已被用烂，见 anti-slop MODE.md） |
| P10 | 动效越档 / 曲线越族 | grep -oE "transition:[^;]*[0-9]+m?s" 与 grep -oE "cubic-bezier\([^)]*\)"；出现 transition: all 即记问题 | 所有时长落在 motion-rules.md §1 四档内、曲线 ⊆ §2 四族、无 all |
| P11 | 焦点不可见 / 控件语义缺失 | Tab 走一遍（或无头 page.keyboard.press("Tab") 后截图）；grep outline://s*none、role="dialog"（须带 aria-modal）、<th（须带 scope） | 每元素有 focus-visible（≥2px、对比 3:1）；弹窗焦点陷阱 + Esc；表格表头有 scope/caption（WCAG 2.4.7 / 1.3.1） |
沉淀回路（让门禁自我进化）：每修掉一个工程坑，就地把它转成一行可核验断言加进本表（写清核验方式 + PASS 阈值）， 而不是只写"下次注意"。判断类教训写进质量门，事实类教训写进本门禁——分类错了这条规则就失效。
已知局限（诚实标注）：本门禁只能拦已知且可核验的坑，拦不住品味失败与全新坑。 品味靠质量门 + 人眼验收；全新坑靠上面的沉淀回路逐步收编。
交付后：反馈 → 回哪一阶段
这是闭环的回边。先判定"哪一层错了"，再决定回退几格——直接从头重做是最贵的错误。
| 用户反馈 | 真正的问题在哪 | 回到 |
|---|---|---|
| "不是我想要的 / 理解错了" | 需求 | ① 重新对齐 |
| "太平了 / 太保守 / 像模板" | 方向定档不足 | ② 重锁最高级方向（四轴之一） |
| "结构乱 / 不知道看哪" | 信息架构与叙事 | ③ 重做 Intention Map |
| "不协调 / 各段不像一套" | 系统设计（语法不统一） | ④ 重建设计语法 |
| "就是不好看" | 视觉执行 | ⑤ 调字体/色/版式/素材 |
| "重做 / 重来 / 重新设计 / 换一个方案" | 明确要求新版本 | 全新重做（见下方三条硬规则） |
只改颜色 / 字体 / 间距 → 不必回阶段，直接改并跳过 ④ 执行门禁（见 references/gates.md 的 D 条）。
多轮微改（同一任务延续）：首轮交付后用户提「再调一下 / 换个感觉」，属同任务延续——直接进对应阶段（调色→⑤、换方向→②重锁），不必重走 ① 也不重复 CP1；把多轮改动归并后再统一交付，避免每轮都重新确认把用户搞烦。
中途改大方向（③ 之后）：用户说「换风格 / 方向错了」→ 回 ② 重锁（需求没变只方向错，不回 ①）；已写的代码按新方向重构而非修补，禁止在错误方向上继续堆细节（把"方向太平"当"视觉不好看"去调字号，改十轮也不会对）。
判错的代价：把"方向太平"当"视觉不好看"去调字号，改十轮也不会对——先归因，再动手。
重做 vs 修补（三条硬规则）
① 明确要求重做 → 必须全新版本，不许换皮 用户说「重做 / 重来 / 重新设计 / 换一个方案」时：
- 必须重新选种子（约束7）、重写 Intention Map，不复用上一版代码结构
- 交付说明必须列「上一版问题清单」：上一版错在哪几条 → 本版如何避免，证明不是同一方案换配色
- 判据：新旧两版的「版式家族 / 动效层数 / 字体角色」三项中有两项相同 → 这次是修补不是重做，须重来
② 「不合格」但没指明 → 三选一，别问开放式 用户只说「不合格 / 不满意 / 不行」时，不要问「你想要什么感觉」（用户答不出）。给三个选项让他指：
- 方向不对（气质错了）→ 回 ② 重锁种子
- 结构不对（该看的东西看不到）→ 回 ③ 重做信息架构与叙事
- 执行不行（方向对，就是没做细）→ 回 ⑤ 按
shared/taste-rules.md§1 六个变量逐项调
一次只问这一个问题（约束3），用户指完直接进对应阶段。
③ 修补上限：2 轮封顶，超了强制重做 同一页面的修补累计 2 轮后仍「不合格」→ 禁止第三次修补，必须升级为重做。 理由：两轮修补都没解决，问题就在方向或结构层，继续调视觉只是消耗——「把太平了当不好看改十轮」是已记录的失败模式。
🛑 CHECKPOINT（只问该问的）
本 skill 默认不问方向（约束1），但下面 5 个节点必须停一下。除此之外不要中途请示——频繁打断是另一种失职。
| # | 节点 | 停下来的理由 | 你要给用户什么 | 不该做什么 |
|---|---|---|---|---|
| CP1 | 需求解读完成后 | 理解偏差的代价最高 | 一句复述：页面类型 + 目标受众 + 调性 + 三参数（或默认 8/6/5） | 让用户在 2–3 个方向里选（违反约束1） |
| CP2 | 最高级方向锁定后 | 方向错了后面全废 | 1 个方向的形象化描述（≤3 句），问「这个方向对吗」 | 只报专业名词（字体名/色值），用户听不懂 |
| CP3 | 用户提改动要求时 | 一次改多处 = 无法归因 | 一次只问一个问题，确认后再问下一个（约束3） | 一口气抛 5 个问题 |
| CP4 | 交付前 | 未过门禁不得交付 | 质量门 7 条 + 工程门禁 P1–P11 的核验结果（哪几条 PASS、哪条跳过及理由） | 口头声称「已检查」而不给结果 |
| CP5 | 用户说「可以了 / 差不多了」 | 该停就停 | 一句收尾 + 还差什么（如有） | 继续加戏、自行开启下一轮优化 |
违反信号（自查）：连续 3 个阶段没有一次用户输入、且未在 CP1/CP2 停过 —— 说明你在替用户做决定，回退到 CP1。
不是 checkpoint 的事（问了反而糟）：选什么字体、用什么色值、section 放几个、动效用哪个组件 —— 这些是你的判断，不是用户的活。
用户意图路由
| 用户说什么 | 起点 | 说明 |
|---|---|---|
| "写一个页面/组件"（需求明确） | ①需求解读 → ②锁方向 → ③Intention Map → ④系统设计 → 交付 | brief 以用户明确需求为准；通用约束（含约束8）仅在用户未指定的维度兜底，不覆盖明确指令（约束0） |
| 「快速出活」「用现成主题」「换肤/换个主题」 | 主题快速线：读 assets/themes/README.md 速查表（明暗→场景→强调色三步）选 1 套 → 复制其 :root 变量 → 按品牌微调 --accent → 交付 | 仅当用户主动要求或明确赶时间时走；此时显式豁免约束6（依据约束0：用户指令 > 通用默认）。交付注明用了哪套主题、改了哪个变量。旗舰任务默认不走此线 |
| "帮我设计 landing page"（有方向需探索） | ①②之后直接锁定最高级方向继续 | 不要求用户确认方向 |
| "改一下这个页面的样式"（已有代码） | 从⑤视觉设计开始 | 诊断 + 最小修改；动效新增/替换须补「局部 Intention Map 动机表」（仅覆盖改动 section）；纯颜色/字体/间距修改豁免④执行门禁（见 references/gates.md 的 D 条） |
| "不知道用什么风格" | ①②直接给出最高级方向方案 | 不列 2–3 个平行方向让用户选（约束1） |
| "做品牌设计" / "做海报" | 加载对应领域文件 | 品牌 → domains/brand/MODE.md；海报 → domains/poster/MODE.md |
| "加个背景视频 / hero 放段视频" | 加载 domains/video/MODE.md | 先过 §1（是否非视频不可）→ §2 角色与体积上限 → §4 融合 → §9 V1–V9 检查 |
| "做个后台 / 管理台 / 数据看板" | 先定骨架与表格，别先做看板 | design-patterns.md §6.4 交付顺序：骨架 → 表格筛选 → 表单弹窗 → 看板 |
| 不确定 | 问用户 | 从零设计 / 修改现有 / 需要风格建议 |
领域速查
工具类（评审 / 翻新 / 思维 / 幻灯片 / 视频导出）的总览与选型见
tools/README.md。
| 领域 | 触发词 | 加载路径 |
|---|---|---|
| Web 页面 | landing page / 官网 / 营销页 | domains/web/distilled-playbook.md（推理层，先读）+ domains/web/anti-slop/MODE.md（反 AI 基线）；domains/web/integrated-rules.md（规则索引→shared/）+ domains/web/common-exceptions.md（例外裁决）；精确值查 shared/，CSS 查 domains/web/design-patterns.md / shared/css-patterns.md |
| 后台 / 管理台 | 后台 / 管理台 / dashboard / 数据看板 / CRM | domains/web/design-patterns.md §4 控件规范 + §6 后台界面（骨架/四类模板/密度）+ domains/web/integrated-rules.md §4 Token 契约 + shared/interaction-rules.md §7 键盘效率 |
| 品牌设计 | Logo / 品牌板 / 品牌设计 | domains/brand/MODE.md + domains/brand/brand-protocol.md + domains/brand/logo-concept-methods.md + domains/brand/visual-modes.md |
| 海报设计 | 海报 / poster / 宣传图 / 展架 | domains/poster/MODE.md（先定尺寸 §1 → 定主张 → 选家族 §3 → 排三层 §4） |
| Web 内嵌视频 | 背景视频 / hero 视频 / 产品演示视频 / 滚动视频 | domains/video/MODE.md（先判 §1 该不该用视频 → §2 角色 → §3 路线 → §4 融合 → §9 交付检查） |
| 设计评审 | review / critique / 评审 | tools/critique.md |