ui-review

UI 审查

1. 范围。 由调用方指定的范围；否则审查分支中有变更的屏幕；再否则审查 5 个顶级路由（references/sources.md，Finding the design）。
2. 标准。 优先采用已安装设计系统的 SKILL.md，然后采用 references/review-criteria.md（references/sources.md，The installed system）。
3. Lint。 对指定范围内的文件运行项目自身的 lint，并记录命令和退出代码（references/sources.md，The project's lint）。
4. 捕获每个视口下的每个屏幕，并在该视口运行无障碍扫描（references/sources.md，What counts as evidence）。
5. 明确目的，若未提供，则推断并标记为假设；若符合 references/sources.md（Inferring the purpose）中的条件，则停止。
6. 在本地构建中，探查屏幕涉及的每一类陷阱（references/sources.md，Trap probes）。每次探查都要记录测量结果，或说明未运行的原因。
7. 在每个视口下，依次检查已安装系统的规则，再检查标准 1 至 13（references/review-criteria.md）。
8. 按照 references/review-criteria.md（Sorting），对重复项、链式发现、system-caused 发现、无障碍问题、审美问题和偏离项进行分类。
9. 排序blocking、should-fix 和 note 级别的问题；每个级别内再按表面层级排序，然后按受影响的位置排序（references/review-criteria.md，Severity）。
10. 检查边缘情况，标记每种情况是否已呈现；同时检查屏幕上各组件规范中的 States 行（references/sources.md，Component specs）。
11. 最后撰写结论和摘要（Output）。

切勿交付：

• 没有引用所用文件中的标准，或基于审美偏好的发现。
• 仅依据描述、DOM 文本或源代码得出的发现。渲染结果才是证据，其他内容只能作为佐证。
• 将推断出的发现直接写成修复项。它只能作为用于确认该问题的检查项出现在 Next: 中。
• 未提供本次会话中的命令或截图，却声称某项功能正常或问题已修复。
• 已排序的、会改变语义的无障碍修复或产品决策。应由人来决定，并保留该发现。
• 仅凭截图得出的标准 13 相关发现或通过结论。必须使用 state-timeline.js 或进行探查。
• 首行、交付行和摘要彼此矛盾。

协调员发起审查时

将截图、标准和目的视为已给定，并完成整个流程；记录独立审查流程会询问的任何缺口。只有截图时，扫描和探查应标记为 not run: captures only，这可视为未运行的原因。报告应以状态行开头：Status: complete (blocking n, should-fix n, note n)、Status: complete (partial: <what was not reviewed>) 或 Status: stopped: <condition>；接着写 Commit: none，然后写答案和交付行。以文本形式返回报告或停止格式，不要写入文件。

输出

任何 blocking 级别的问题都会让结论变为 no；如果是推断得出的，则为 no，待确认 <能确定结论的唯一检查项>。只有 should-fix 级别的问题时，结论为 yes，修复后可发布；只有备注时，结论为 yes。第一行用通俗语言直接回答所问内容，不带标准编号或技能名称；只有结论为 no 时，才搭配“尚未就绪”。接下来是发布状态行，结论保持一致，用一个分句说明原因，并给出尚待人工判断的无优先级辅助功能问题数量。部分检查所得出的结论仅适用于已检查的内容。例如：Ready to ship: no. Enter in Email cancels the invite (blocking 1, should-fix 2, 3 accessibility questions for a person).

然后分为六个部分。

1. 审查记录。 来源、工具、视口、日期、标准文件、初审或后续审查、已标明为已提供或假设的目的、每项假设，以及所有缺失项。每项 n/a 标准都要说明原因（“8. 此屏幕上没有破坏性操作”）。
2. 摘要。 屏幕要求用户做什么、哪些部分有效，以及最需要关注的问题。
3. 问题发现（按严重程度分类）。每项都要说明观察到的情况、位置（屏幕和区域，或元素的角色和名称及其引用或选择器与截图，例如 button 'Save changes' @e34 (settings-1280.png)）、视口、界面的层级、标准的编号和名称或已安装系统的规则 ID、该问题为何影响此任务、证据类型和去重键（references/sources.md，“何为证据”），以及匹配的 trap/ 或 rule/ ID。system-caused 问题需指出相应的令牌、预设或组件。
4. 未展示的边界情况。 每项单独一行。
5. 供人工决策。 会改变语义的辅助功能修复、修复所需的产品决策，以及标准未涵盖的问题；每项都关联到某个问题发现或位置。
6. 未纳入项。 列出已舍弃的偏好，并说明原因。

空组填写“无”；界面没有问题时，备注仍应保留为备注。

只有在每项问题发现都有对应标准、可定位的位置、证据，且只列出问题出现时的视口后，报告才算完成。每项探查都必须有结果或说明原因；扫描必须在每个视口运行，或者注明 not run: captures only。最后一行写 Coverage:，列出已测量的路由、视口、主题和探查项目，然后列出未检查的内容。

直接运行检查，并将报告保存到 .ui-review/<date>-<flow>.md，截图放在同一目录中。聊天回复以回答行和发布状态行开头，列出每条已运行命令及其退出代码，为人工判断者最多列出三项（附默认选项），并以 Next: 和一条待粘贴的提示词结尾。该提示词要涵盖所有 blocking 问题，以及所有“展示与发送不一致”的问题，格式为“修复 X，使其满足 <检查项>”，例如“修复 Email 中的 Enter 键，使其发送 1 个 POST 请求”。system-caused 问题的修复需指出系统文件。每项 Next 检查都必须能在当前构建版本上失败。

如果检查中途停止，只返回导致停止的内容、对每个屏幕用途的一句简短推测，以及能解除阻塞的最简回复。