用途：在改动需要验证时执行并解读质量门，判断是否允许继续提交、发布或进入下一阶段。触发场景包括 lint、typecheck、tests、quality gate、验证改动等。核心要求是不能把“命令跑过”当作质量结论，必须说明跑了什么、为什么跑、失败在哪里、是否允许继续。
主要能力与工作流：一、评估所需检查，按改动类型判断跑 lint、test、typecheck 还是组合检查，并区分快速验证与全量验证。二、执行质量门，优先使用 package.json 中真实存在的脚本；没有精细脚本时说明为何只能跑更重的检查。三、分析结果，提炼失败文件、错误类别与根因，区分阻塞问题、建议问题和外部已知问题。四、给出放行结论，明确能否进入提交、发布或下一阶段，未跑的检查要说明原因与残余风险。
使用方式要点：避免用 pnpm run 执行质量门，因为它会触发依赖状态检查并可能自动 pnpm install，因 ERR_PNPM_IGNORED_BUILDS 返回退出码 1，掩盖真实 lint 结果。资料给出的做法是直接调用二进制，例如 & "node_modules.bin\eslint.cmd" . 与 & "node_modules.bin\vitest.cmd" run，或使用 npx <binary>（如二进制支持）。常见检查包括 pnpm lint、pnpm lint:md、pnpm test。
适用与限制：适合需要质量门决策的仓库工作流。若仓库提供 typecheck 或等价脚本应纳入；没有则必须明确缺少该层验证。全量测试成本过高时，优先运行与改动范围直接相关的测试文件或测试集。输出时要严格区分“脚本不存在”与“脚本通过”。反模式包括臆造脚本、原样倾倒失败日志、未跑全量却声称全部通过、用 pnpm run 触发不必要的依赖检查。交付前确认已按变更范围选择质量门、命令真实存在、已明确根因或残余风险、并包含能否继续的判断。