用途
Triage 用于复现、诊断和修复失败的 Shiplight YAML 测试。如果应用本身已损坏，或当前行为与规格冲突，应报告这一不匹配，而不是围绕现状重写测试。
何时使用
在以下情况使用 /triage：
- 一次 Shiplight 测试运行失败
- 部署或 UI 变更破坏了既有测试
- 多个测试可能共享同一失败来源
- CI 需要一次尽力而为的修复/报告流程
在以下情况跳过 /triage：
- 从零创建新测试；改用 /create-yaml-tests
- 在没有失败测试的情况下验证 UI 代码变更；改用 /verify
- 测试已通过，任务只是质量改进
- 产品正在被有意重新设计，测试需要有计划地重写
所需上下文
在编辑 YAML 之前：
- 阅读 create-yaml-tests 参考指南 project-layout.md、updating-tests.md、test-implementation-guide.md 和 knowledge.md。
- 阅读失败区域、环境、认证、数据和工具相关的 knowledge/ 笔记。
- 阅读 specs/tests/ 下匹配的规格（如果存在）。
- 阅读 shiplight://yaml-test-spec 和 shiplight://schemas/action-entity。
事实优先级
当来源之间不一致时，按以下优先级处理：
- 明确的用户指令
- specs/tests/ 中的功能或旅程规格
- 现有 YAML 测试目标、步骤意图和 VERIFY 断言
- 当前应用行为
- specs/context.md 和 knowledge/ 中的项目上下文
- 智能体文档
- 智能体推断
如果当前应用行为与规格或测试目标冲突，应报告不匹配。不要静默改写意图以匹配当前行为。
工作流程
- 复现——运行指定目标；若未提供目标，则运行最窄的相关套件。如果失败看起来是暂时性的，在编辑前对最小受影响目标重跑一次。
- 理解——在打开浏览器或修改文件之前，阅读失败输出、相关 YAML、匹配规格、相关测试以及共享模板/函数/钩子。
- 按需检查——当日志和文件不足时，在浏览器中检查实时应用。使用失败所需的证据：DOM、操作、定位器、控制台日志、网络日志、截图或录制。
- 最小化修复——改动最小且正确的表面：YAML、模板、辅助函数、认证设置、环境数据或规格。除非共享同一损坏来源，否则不要触碰通过的测试。
- 验证并重跑——用 validate_yaml_test 验证编辑后的 YAML，然后重跑最窄的已变更目标。批量修复后，重跑原始目标一次。
- 反思——当本次会话产生持久性学习或纠正了过时假设时，更新 specs、specs/context.md 或 knowledge/。
护栏
- 当失败依赖当前浏览器行为时，不要猜测渲染后的 UI。
- 不要仅为让测试通过而删除断言、跳过必需步骤或降低覆盖。
- 如果预期产品行为已变更，先更新匹配规格，再更新 YAML。
- 如果应用已损坏，报告应用问题，而不是用测试改动掩盖它。
- 保留用户改动和无关工作。
- 优先聚焦修复，而非大范围重写。
- 编辑受影响步骤时，保持 ACTION 定位器和 VERIFY js: 缓存为最新，但不要搅动无关缓存。
- 在 CI 或非交互模式下，不要因等待用户输入而阻塞。做出保守的尽力决策并记录不确定性。
常见原因包括定位器过时、用户流程变更、断言漂移、认证过期、时序问题、共享模板/钩子、参数数据无效、环境问题以及真实应用缺陷。用证据决定最小正确修复。
报告
分诊后报告：
- 运行的目标命令及通过/失败结果
- 变更的文件
- 已修复、已跳过、仍失败或原本已通过的测试
- 覆盖或恢复的行为
- 应用/规格不匹配或未解决的阻塞项
- 已更新的 knowledge、context 或 specs