用途
ss-verify 是 StyleSeed 工作流中的视觉验证环节，用于检查已渲染的 UI 或视觉产物是否符合其 StyleSeed 契约。它针对的是代码审查无法捕捉的“AI 生成感”问题：主视觉没有真正占据主导、下三分之一出现死白、卡片拥挤、Web 字体静默加载失败回退到 Times、渲染后出现两个互相竞争的强调色、文字在真实背景上不可读等。这些问题人眼半秒就能看出，但只读代码的门禁会全部漏掉。
主要能力
- 渲染 UI 并截图，然后以 StyleSeed 视觉门禁对截图进行感知评分。
- 覆盖的视觉检查项包括：眯眼测试（是否仍读作 AI 生成）、焦点是否唯一且真正主导、视觉平衡与留白、字体是否实际加载、实际可见的强调色数量、真实渲染背景上的对比度、节奏与光学对齐、桌面端字号比例是否合适、所选语法与配方是否在视觉上匹配、动效是否有目的性。
- 支持注册表优先的产物边界：当 .styleseed/project.json 与 .styleseed/artifacts/index.json 存在时，先解析请求的 artifact ID，再只读取 .styleseed/bundles/<artifact-id>.md 与 .styleseed/manifests/<artifact-id>.json，并使用 ss-resolve --artifact <artifact-id> --check 检查。
- 仅当两个注册表文件都不存在时，才使用 .styleseed/effective-rules.md 与 .styleseed/manifest.json，并用 ss-resolve --from-lock STYLESEED.md --check 检查。
- 区分仅检查模式与授权修复模式：仅检查时在临时工作区渲染与截图，不修改产品源码、配置或真实用户数据；获得授权的构建或修复任务中，只修复范围内的实现缺陷并重新渲染。
使用方式
- 渲染：通过当前适配器渲染产物。对于 product-ui，优先启动运行中的项目（Next / Vite 等），在后台启动开发服务器并捕获端口，然后用 Playwright 无头 Chromium 截图；也可使用浏览器 MCP。静态 HTML 文件可直接用 file:// 打开截图；孤立组件可渲染进最小临时页面后截图。截图视口为 mobile {width:390,height:844} 与 desktop {width:1440,height:900}，deviceScaleFactor 为 2。
- 评分：实际读取截图（Read the PNG），以视觉门禁逐项审视。
- 渲染状态或序列变体：对数据视图渲染空、加载、错误状态并分别截图；对序列产物检查封面、每个内容帧与结尾/CTA。
- 修复并重新渲染：仅检查模式返回发现与证据；授权修复模式修复代码后重新渲染再看。通过、最多三轮修复渲染、或遇到权限/工具阻塞时停止。
适用场景
- 构建流程中的最终视觉门禁，在 /ss-score 之后运行。
- 对已渲染 UI 或视觉产物进行视觉合规检查。
- 对社交轮播、幻灯片、文档报告、单帧等序列产物进行整组检查。
限制
- 必须实际看到渲染产物；没有渲染就没有视觉结论，应回退到 /ss-score 并说明视觉门禁被跳过，绝不编造“看起来不错”。
- 纯逻辑/配置且无视觉产物时不应使用，应改用相关功能或配置检查。
- 完全无法渲染（无浏览器、无 Playwright、无头被阻止）时，应说明情况并回退到 /ss-score。
- 快速提交前检查应使用 /ss-lint，/ss-verify 更重，会启动渲染器。
- 每次修复后必须重新渲染；通过阅读 diff 来验证视觉修复会违背该技能存在的意义。
- 不得更改已批准的身份标识，也不得为抬高分数而放弃核心底线。
- 缺失工具或门禁失败时应如实报告，不得虚构通过或进行无关安装。
- 清理时只停止自己启动的开发服务器，只删除自己的临时测试文件。
- 官方文本暂未提供。