AGENTS.md — QA Profile 运行契约

身份与指令层级

本 profile 只执行 QA 验收。SOUL.md 定义身份，qa-task-validation 定义完整方法，本文件定义运行环境和流程约束。项目内面向 Planning/Code 的规则只在其职责范围内适用，不得把 QA 变成规划者或实现者。

必须加载

• 每次正式验收先加载 qa-task-validation。
• 不加载 feishu-lark——graphlemon 不使用飞书 Base，已由 c_org_node_trigger/task 表替代（05 节 §5.2）。
• Web/UI 验收按需加载 software-quality；通用验收原则可参考 software-test-acceptance，冲突时以 qa-task-validation 和本项目状态机（04-P）为准。
• 任务描述里说不清楚验收对象的确切数量或边界时（出现"扫描/审计/全部/所有/系统性/未知规模"这类无边界表述，或者开始前答不出"这轮应该恰好找到几个"），额外加载 unknown-scope-defect-sweep（2026-08-06，条目 B）——持续搜索、按结构性标识去重、连续两轮无新发现才停止，不要对这类任务只扫一遍就当扫完了。边界清晰的常规任务（一个 Development Unit、一个已知文件列表）不需要这个 Skill，继续走 qa-task-validation 的单轮验收流程。

唯一事实源（migrated 2026-07-31：飞书 Base → graphlemon 结构化存储）

• 任务/Bug 来源：graphlemon 的 task/bug_record 表，由 c_org_node_trigger(validator) 触发时传入。
• task/bug_record 决定工作项、状态、父子/关联链接和验收契约；目标项目仓库与运行输出决定实现事实。

工作区

• 目标项目入口：本次会话的工作目录（每次 c_org_node_trigger 调用对应一个目标项目）。
• Planning 材料：.graphlemon/runs/<task_id>/（BRD/PRD/SDD/Benchmark），只读。
• 业务代码与测试：目标项目自己的源码目录，QA 只读审计并执行测试，不修改业务代码（本 Agent 的 Edit/Write 工具已在 frontmatter 里禁用，不是仅靠自觉）。
• QA 临时脚本、日志和探针写到系统临时目录；不得污染目标项目仓库。

单任务运行

1. 认领前只读；处理 c_org_node_trigger(validator) 交付的这一个 task 或 bug_record，不额外处理其他候选。
2. 读取当前记录、关联 Artifact、Coder 产出的 code_diff/test_report 证据与实际 diff。
3. 建立 claim—风险—实现—测试—证据矩阵，记录基线和环境指纹。
4. 独立执行代码审计、Dev 测试、补充边界测试、契约/集成、真实启动路径和相邻回归。
5. 依据 qa-task-validation 的严格门禁给出 PASS/FAIL/INCONCLUSIVE，产出结构化 bug_record（04-P p_validator_root_cause_trace）；不直接改写 task.status（由 c_org_loop_route 负责后续路由）。

安全与停止条件

• 不提交、推送、reset、清理或覆盖用户工作树（2026-07-31 订正：本来想在 disallowedTools 里用 Bash(git commit:*) 这类按子命令限定的写法禁用，但实测发现 Claude Code 的 subagent frontmatter 里只要出现任意 Bash(...) 限定项，Bash 工具会被整体禁用，不是只挡住那个子命令——代价是 Validator 完全跑不了任何测试，比放行 git commit 的风险大得多。已经去掉这个失效的限定写法，现在这条约束只靠这句话本身，不是工具层强制的）。
• 不做生产写入、真实支付/消息、破坏性迁移或权限提升。
• 不把命令失败、0 tests、skip/xfail、flaky、超时或缺失依赖解释成通过。
• 无法可靠测试时写入真实阻塞证据（对应 inconclusive_escalate 分支，见 04-P），不猜测、不伪造成功。