用途
verify-fix 用于确认某个 GitHub issue 是否已在本地代码库中真正修复。它强调必须在运行时观察行为，而不是依赖代码分析或构建成功等间接证据。
主要能力
- 抓取并理解指定的 GitHub issue 详情与预期行为。
- 读取 .ai/fix-<issue_number>.md 修复计划，了解开发测试通过或失败的情况、所做的改动及相关文件、已知问题或限制。若开发测试状态为 FAILED，需特别关注 Known Issues 部分，因为修复可能不完整。
- 构建并给产品打补丁：按 CLAUDE.md 中的补丁说明操作，包括构建变更模块（mvn clean install -Dmaven.test.skip=true）、从 zip 中提取新的产品包、将 JAR 补丁应用到 repository/components/patches/patch9999/、应用模板或 WAR 补丁，并启动服务器。
- 运行验证：必须针对运行中的产品实际测试修复。
使用方式
- 前端 bug：使用 Playwright，参考 CLAUDE.md 中的 “Interacting with the Frontend (Playwright)” 部分。若复现步骤已生成脚本（.ai/reproduce-<issue_number>.mjs），运行它以确认 bug 行为不再出现；若无脚本，则按 CLAUDE.md 的 Playwright 指南编写一个。将验证截图保存到 .ai/screenshots-<issue_number>/verify/，截图需展示正确行为（例如原本隐藏的元素现已可见）。
- 后端 bug：使用 curl 或针对运行中服务器的 REST API 调用。部署 API 或产品后，在尝试调用前先立即检查服务器日志是否有错误，遵循 CLAUDE.md 中的 “Troubleshooting / Log Analysis” 部分获取确切命令与过滤规则。若发现部署错误，立即报告，不要继续调用；若部署正常，则继续调用并比较结果。
什么不算验证
- ❌ “编译后的 bundle 包含修复逻辑”——对压缩后的 JS 进行 grep 不算验证
- ❌ “构建成功”——构建成功只说明代码可以编译
- ❌ “管理门户加载成功（HTTP 200）”——这只能说明服务器正在运行
- ✅ 修复后展示正确 UI 行为的 Playwright 截图
- ✅ 修复后展示正确 HTTP 状态或响应体的 curl 输出
- ✅ 服务器日志显示原本出现的错误已消失
报告
生成 .ai/verify-<issue_number>.md，包含：Issue 链接、Verdict（FIXED 或 NOT FIXED）、验证方法（Playwright / curl / 服务器日志）、执行的复现步骤（必须是运行时步骤，而非代码分析）、结果（观察到的运行时行为）、证据（.ai/screenshots-<issue_number>/verify/ 中的截图、curl 输出或服务器日志摘录，必须来自运行时）。
重要规则
- 服务器启动：启动命令与日志轮询循环必须放在同一个 Bash 工具调用中，并设置 timeout: 200000，不要拆分为多次调用。
- Playwright 最佳实践：等待元素而非使用固定 sleep（page.waitForSelector()、page.locator().waitFor()）。清晰记录断言，打印预期值与实际值，以便输出对制品有用。
适用场景
适用于需要确认 GitHub issue 修复是否在本地运行环境中真正生效的开发与测试流程，尤其是涉及前端 UI 行为或后端 API 行为的场景。
限制
资料未提供该技能的安装方式、收费模式、支持平台、维护者信息、开源许可及版本信息。