qa-review

qa-review 是新的统一质量入口。 它取代旧的“先 review、再 verify”双路径，统一负责：

1. 识别当前范围与风险边界
2. 做代码与架构层面的质量审查
3. 运行验证命令
4. 修复阻断项并回归验证
5. 写当前会话 artifacts/qa-review.json
6. 若当前契约仍要求 advisor / visual / closeout，再继续补齐对应证据

质量模式

• standard：默认模式。聚焦当前变更、相关配置和真实风险边界，避免无关扩查
• deep：高风险或长任务收尾模式。按 12 维做更完整的阻断性审查，并优先补齐证据链

若 contract.json 提供 qaMode 与 qaFocus，优先服从它。

审查维度

所有模式至少覆盖以下维度：

• 功能正确性：边界条件、空值、错误路径、真实数据流
• 安全性：鉴权、注入、敏感信息、权限绕过
• 可靠性：超时、资源释放、异常恢复、一致性
• 性能与容量：重复计算、低效查询、大循环 I/O、构建产物体积
• 可维护性：职责边界、重复逻辑、命名、死代码、过度抽象
• 交付契约：requirements / tasks / contract 是否真实满足

deep 模式下，再补查：

• 兼容性
• 可观测与运维
• 测试有效性
• 架构与依赖边界
• 易用性
• 可演进性

证据要求

阻断问题必须给出：

• 文件定位：{file}:{line}
• 观察到的现象
• 为什么构成阻断
• 具体修复方向

不要只给泛泛评价。

任务完成标准逐条核对

若存在方案包且 tasks.md 中有任务清单，必须逐条核对：

• 对每个已标记完成的任务，逐条对照其"完成标准"验证是否真实满足
• 完成标准必须是可独立验证的布尔条件——如果读完标准仍需要额外上下文才能判断，则该标准本身不合格，标记为 [-] 并写明原因
• 验证不依赖主会话上下文：任何人（或另一个 AI）读完标准 + 当前代码状态，应能做出相同的通过/不通过判定
• 核对结果写入 artifacts/qa-review.json 的 taskVerification 字段

验证命令

验证命令来源：

• .helloagents/verify.yaml
• package.json 的 lint / typecheck / test / build
• pyproject.toml 的 ruff / mypy / pytest

命令失败时：

1. 先说明根因
2. 修复阻断项
3. 重新运行相关命令
4. 直到通过，或命中真实阻塞

结构化证据

完成本次质量闭环后，立即调用：

scripts/qa-review-state.mjs write

写当前会话 artifacts/qa-review.json，至少记录：

• qaMode
• scope
• outcome
• conclusion
• findings
• fileReferences
• commands

若仍有阻断问题，outcome 必须写为 findings。 不要让运行时从自然语言里猜结论。

交付要求

• 没有看到验证输出，不能声称完成
• 没有写 qa-review.json，不能把当前结果当成可信质量闭环
• 若当前契约要求 advisor.json / visual.json / closeout.json，必须继续补齐