frontend-mix-validate

用途：作为手动混合提供方构建流程中的验证环节，对刚完成集成的应用执行完整校验，尽量修复可修复的问题，把无法修复的失败如实记录，交给后续步骤处理。\n\n主要能力：按集成摘要中记录的命令与工具链依次执行五类检查——安装（bun install 或依锁文件使用 npm install / pnpm install）、类型检查（如 tsc --noEmit、bun run typecheck）、代码检查（如 bun run lint、eslint .）、构建（如 bun run build 或框架等价命令）、测试（若存在测试脚本）。每一步最多尝试两次：第一次直接运行，失败后尝试一次针对性修复（读错误、改文件、重跑），仍失败则停止重试并记录。\n\n使用方式：以 $ARGUMENTS 传入集成摘要路径，用 Read 工具通读；从文件名去掉目录和 -integration-summary.md 后缀得到 run-name，用于输出文件命名。若 $ARGUMENTS 为空，向用户询问摘要路径；用户无法提供时，依据仓库推断技术栈（通过锁文件判断包管理器、通过 package.json 判断框架）。每个步骤结束后，按结果只输出一个文件到 .claude/artifacts/ 目录（目录不存在则创建）：全部通过时写 <run-name>-validation-summary.md，包含各命令及其退出码和“All checks passed.”确认；存在失败时写 <run-name>-validation-issues.md，逐条列出步骤名、失败的确切命令、截断的报错输出（最后 30 行）、最可能负责的文件和一句话根因假设，然后停止。\n\n限制：明确禁止掩盖真实缺陷，例如类型检查报错即为 bug；禁止为让测试通过而删除测试；禁止添加 // @ts-ignore、// eslint-disable、弱化类型或跳过步骤。遇到这类冲动时应停止并记录失败。完成后需告知用户所写文件的绝对路径及下一步：干净结果则调用 /frontend-mix-smoke 并传入集成摘要路径与验证摘要路径；有失败记录则切回 Opus 并调用 /frontend-mix-fix-validation，传入问题文件路径与计划路径。