用途：对渲染类改动做视觉验证，捕捉“代码正确但渲染错误”的缺陷，例如规格要求图标与文字内联，实际却堆叠。若 diff 未触及任何可渲染内容（组件、样式、story、设计稿、渲染器或 Web 源码），则说明并停止。
主要能力与用法：
- 渲染受影响状态。按优先级取首个可用方式：项目 AGENTS.md 的 Visual verification 章节所述方法；存在 .storybook/ 时用 build-storybook 构建并在空闲端口提供静态服务，通过 iframe.html?id=<story-id>&viewMode=story 渲染被改组件的 story；design-handoff 项目直接以 file:// 截图 study HTML；package.json 有 dev/start 脚本则启动并访问工单指定页面。找不到可渲染方式时记录“visual verification unavailable”并停止，不得静默通过。截图可用 scripts/screenshot-states.mjs（由 setup-visual-verify 安装，固定视口、禁用动画），否则用无头 Chromium/Playwright 以内联方式同样设置，输出每个状态一个 PNG 到临时目录并按状态命名。
- 全新视角评判。交给从未看过渲染或推理的新上下文，仅输入工单验收标准或用户规格原文、设计参考（已定稿 study、foundations 样本）、截图；刻意不给 diff 与推理。评判者只回答“这些像素是否满足这份规格”，返回结构化结论：pass/fail 及发现项，每项指明截图、问题与违反的规格行。若无法获得全新上下文，则停止并说明——自己评判自己的渲染正是此步要防止的失败。
- 修复循环：发现项回到实现，修复、重渲染、重评判，最多两轮；仍失败则继续但在 PR 中列出未解决项；若为根本性缺陷（布局错误、缺失状态）则以草稿开 PR。
- PR 证据：无论通过与否，最终截图放入 PR 供人工审查像素。不要提交到分支，改用一次性 ref 发布： slug=$(git rev-parse --abbrev-ref HEAD | tr '/' '-') tree=$(for f in "$SHOTS"/*.png; do printf '100644 blob %s\t%s\n' "$(git hash-object -w "$f")" "$(basename "$f")" done | git mktree) commit=$(git commit-tree "$tree" -m "visual-verify: $slug") git push --force origin "$commit:refs/pr-screenshots/$slug" 以固定该 commit 的 raw URL 内联嵌入，PR 关闭后由 worktrees:gc 回收。
适用场景：实现 UI 改动后，需要对照规格核验多状态渲染时。限制：依赖可用的渲染路径与独立评判上下文；Workflow 内的智能体无 Agent 工具，需由编排器单独运行评判阶段；截图在 PR 中发布方式有特定要求。具体收费、平台支持等资料未提供。