用途：systematic-project-qa 用于对完整项目做类似真实用户的 QA，先发现仓库自身的验证契约，再执行构建、lint、测试、启动等命令，并驱动核心用户流程，最终以证据说明当前状态。
主要能力：按步骤发现仓库 QA 契约，读取根目录说明、仓库文档与 CI/构建文件；可运行 python3 scripts/discover-project-contract.py --root . 来发现候选的安装、验证、构建、测试、lint 和启动命令；优先使用仓库定义的统一命令，如 make verify、just verify 或 CI 入口。定义 QA 范围时建立执行矩阵，覆盖基线验证、变更工作流和未变更但关键的业务流程，并参考 references/checklist.md。建立基线时先安装依赖，再运行一次规范验证门禁，并以健康检查、启动日志等可观察信号确认服务就绪。执行用户流程时通过 CLI、HTTP 端点、浏览器流程、worker 任务等公共入口驱动，记录命令、输入和可观察结果，先验证变更功能，再验证至少一个回归关键流程。诊断与修复时先稳定复现，再在源头修复生产代码或真实配置，不削弱测试来迎合错误行为，并补充最窄的回归测试。最终状态验证需从零重跑完整验证门禁和最重要的用户场景，并用 assets/verification-report-template.md 汇总证据。
使用方式：按资料中的六步流程执行；命令发现、清单、项目信号、问题模板和验证报告模板分别对应 scripts/discover-project-contract.py、references/checklist.md、references/project-signals.md、assets/issue-template.md、assets/verification-report-template.md。若仓库没有 QA 产物约定，临时产物放在 /tmp/codex-qa-<slug>。
适用场景：需要端到端验证项目、确认变更未破坏关键流程、或在修复回归后提供可复现证据时。
限制：mock 和 stub 只能作为本地单元测试边界，不能作为用户流程可用的最终证明；缺少凭据或本地前置条件时，只能验证可达的本地边界并明确记录被阻塞的实时步骤；没有规范验证命令时需说明所选假设；未提供收费、价格、平台或效果信息。