用途：将已批准的静态 HTML 设计稿落地为 Drupal 主题化路由（Twig/SDC），在不丢失任何既有功能的前提下尽量贴近设计稿。设计稿是视觉上的约束标准，但不能成为删除其未展示功能的依据。
前提：存在静态 HTML 设计稿、单一 CSS 令牌来源（如 mockup 生成器输出的 Tailwind @theme 令牌），并使用 Playwright 作为验证工具。双关卡流程是轻量规范，而非工具。
每个屏幕的操作顺序：先读设计稿——路由清单、屏幕 mockup HTML（两套主题均需查看）、CSS 令牌来源中的精确数值，取值看数字而非目测截图。
关卡 1：对账表。实现前逐元素比对设计稿与现有路由，每项差异给出处理决定（对齐 mockup／保留现有／混合）及理由。需做视觉元素清单，逐项 diff 存在性、尺寸、表面填充、图标与位置，并单独提出全局设计系统决策。差异需分类：样式类通过设计令牌与既有共享组件对齐；结构/能力类不得为对齐 mockup 而删除可用功能；与既有决策冲突则暂缓并列出。修复应改在共享原语（SDC）上，并枚举全部调用点。
验证：对用户可见的改动运行 design-review 第 1-7 阶段，绑定断点（如 1280 与 390）与双主题截图，建立视觉差异台账，逐元素标注 match／可接受差异／需修复，并滚动完整屏幕。每个路由新增或更新 Playwright 规格，深色模式在规格内切换，空态/错误态断言标题与 CTA 渲染。
关卡 2：评审包。宣布完成前提供双主题前后截图、关卡 1 对账回顾、能力/行为变更标记、Playwright 状态，以及观察但未擅自应用的可访问性、性能、UX 建议。
测试规则：纯视觉变更应以“变更前后都通过”的测试证明未丢失能力；经关卡 1 批准的故意行为变更才走常规 TDD 并标注。
硬性规则：始终覆盖两套主题；遵守工作树纪律，变更前用 git rev-parse --show-toplevel 确认；不得用基线/快照更新掩盖差异；仅在绑定宽度对齐，不追逐其他宽度的像素一致；报告采用表格与数字而非形容词。
限制：资料未提供具体安装命令、收费信息或适用版本范围。