ss-review

在此工作流之前，请先完成一次/会话的 更新预检。

UI 设计审查

以注册表优先的产物边界

当 .styleseed/project.json 和 .styleseed/artifacts/index.json 存在时，先解析请求的产物 ID，然后仅读取 .styleseed/bundles/<artifact-id>.md 和 .styleseed/manifests/<artifact-id>.json。对于使用注册表的项目，绝不要回退到全局旧版 bundle。仅当不存在注册表时，旧版项目才可使用 .styleseed/effective-rules.md。

如果任一注册表文件存在，则要求两个文件都存在，且产物配置有效。仅使用所选产物的 bundle 和 manifest；注册表不完整时，不应将其视为旧版项目。仅当两个注册表文件都不存在时，才读取 .styleseed/effective-rules.md 和 .styleseed/manifest.json。如果所选 bundle 缺失或已过期，请报告缺失的证据；在仅审查的请求期间不要重新生成，也不要声称已验证其合规性。先检查任务适配性和语法连贯性，再检查框架惯例。对于非 Web 产物，将仅针对 React/Tailwind 的检查替换为当前适配器的渲染/导出检查。

审查范围

进行审查并提出建议；不要编辑实现或项目配置。修复问题的请求授权使用适当的编辑工具执行单独的实现步骤，但不意味着可以扩大此只读技能的范围。遵循范围更窄的用户请求。针对每项违规引用所选规范；区分核心问题、规范偏差、可选建议和缺失证据。以下库惯例仅适用于采用这些惯例的项目。

不适用场景

• 仅涉及无障碍问题 → 使用 /ss-a11y
• Nielsen UX 启发式评估 → 使用 /ss-audit
• 快速自动化检查 → 使用 /ss-lint
• 非 UI 代码（数据获取、业务规则）

审查文件：$ARGUMENTS

检查清单

1. 设计令牌与配方合规性

• 不使用硬编码的十六进制颜色（使用语义令牌：text-foreground、bg-brand 等）
• Tailwind 中不使用硬编码的 px 间距（使用 p-6 而非 p-[24px]）
• 图案几何形状/层级使用所选配方或显式语义变量
• 不在互不相关的配方中使用硬编码的通用 rounded-2xl + shadow + mx-6 风格

2. 组件惯例

• 使用 data-slot 属性
• 使用 cn() 合并 className
• 使用 React.ComponentProps<> 为 props 添加类型
• 支持通过 className prop 覆盖样式
• 使用命名导出（组件不使用默认导出）
• 不创建仅添加 className 的包装组件

3. 无障碍（a11y）

• 触控界面的触控目标 >= 44x44px；当适配器和经批准的组件规范支持时，以指针操作为主的桌面控件可为 36–40px
• 所有交互元素均有 focus-visible 样式
• 在需要时提供正确的 aria-* 属性
• 颜色对比度符合 WCAG AA（文本为 4.5:1，大号文本为 3:1）
• 动画遵循 prefers-reduced-motion
• 图像带有 alt 文本
• 表单输入框具有关联标签

4. 界面最佳实践

• 不存在水平溢出
• 交互元素之间的间距便于触控
• 在适配器有要求时处理移动设备安全区域内边距
• 桌面端密度/排版以及非 Web 画布/导出规则遵循所选适配器
• 文本在适配器要求的观看距离和支持的缩放比例下仍清晰易读
• 可滚动容器设置 -webkit-overflow-scrolling: touch

5. 性能

• 不存在不必要的重新渲染（保持引用稳定，并在需要时使用记忆化）
• 图像采用延迟加载
• 大型组件采用代码拆分

6. 排版

• 使用锁定的字体系列，以及符合设计配方的字体角色
• 字号、字重、行高和字间距遵循编译后的字体角色与获批令牌
• 在目标界面尺寸下，展示、标题、正文和说明文字角色仍然清晰区分
• 语言、文字脚本、换行和缩放不会导致内容被裁切或影响阅读
• 手册中的字体示例是默认方案，不能据此替换获批的字体比例

7. 间距一致性

• 间距使用一套持续维护的令牌比例，并遵循所选设计配方的主要节奏
• 偏离比例的数值有视觉调整、画布或平台方面的原因
• 使用 size-* 简写，而不是 w-* h-*
• 使用 ms-*/me-*，而不是 ml-*/mr-*（逻辑属性）
• 动效过渡使用设计令牌（duration-[var(--duration-fast)]）

8. 一致性（VISUAL-CRAFT.md §C0——“每个维度只选一种方案”原则）

UI 看起来像“AI 生成”的最大原因不是局部难看，而是各部分之间混杂无序。 检查是否有一套经过深思熟虑的角色系统，而不是要求每个组件的数值都相同。

• 遵循设计配方的圆角比例——表面、控件、紧凑选项和嵌套元素均遵循获批角色。例如，calm-consumer 允许外层表面使用 12–20px 圆角，并允许真正的紧凑选项使用胶囊形控件。应标记无法解释的偏差，而不是这种有效组合。
• 仅有一个明确的主要操作，并且只使用所选设计语法中稳定的语义、类别或品牌角色——不得有相互竞争的装饰性强调色调。
• 不得使用表情符号作为 UI 图标（将 🚗🧺⭐ 用作列表、导航、状态或类别标记）——它们会引入许多不可控的色调；应使用一套颜色为 currentColor 的线框图标。
• 状态色和类别色在所选设计语法与调色板下具有稳定的角色；严重程度仍可区分，普通状态也不会与紧急状态争抢注意力
• 不得使用未经约定的装饰性色调——其他颜色必须有明确的语义、类别、编辑或品牌角色
• 统一阴影风格——光线方向、比例和色调保持一致；不得混用黑色阴影与有色阴影、上方照明与下方照明。
• 整个文件使用同一图标系列、填充模式和描边粗细。
• 嵌套轮廓——使用设计配方中的嵌套圆角关系；对于同心圆角矩形，max(0, outer − padding) 是实用的默认值，但并非适用于所有形状的规则
• 控件高度一致——按钮、输入框和选择框使用统一的高度集合（例如 40px）。
• 错误和状态不得仅依赖颜色传达（还应使用图标和文本）。

输出格式

提供：

1. 评分：通过 / 需要改进 / 未通过
2. 问题：列出每项违规及其文件:行号
3. 修复方案：针对每项问题提供具体的代码更改