# 06-验收与测试锚点

对应架构文档第 11 节 MVP 验收标准，逐条映射到 requirement_id，并给出 M/V/C/P 覆盖和至少 3 类验收用例（happy / boundary / failure）。场景统一采用"贪吃蛇游戏"作为验收任务。

## REQ-01：Org Graph 三节点链路可触发

- 覆盖：M=`org_graph_definition`,`task`；C=`c_task_create`,`c_org_node_trigger`；P=`p_org_task_lifecycle`
- 验收用例：
  - happy：创建 `goal_text="实现贪吃蛇游戏"` 的 task，依次触发 planner/coder/validator 三个 org_node，`task.status` 按状态机正确流转
  - boundary：`max_concurrent_goals=1` 时，同时创建第二个 task，验证其落 `queued` 而不被立即调度
  - failure：`goal_text` 为空时 `c_task_create` 返回 `INVALID_PARAM`

## REQ-02：Planner 产出四类 Artifact 并通过校验

- 覆盖：M=`artifact`,`work_graph_run`；V=`v_task_detail`；C=`c_work_graph_plan`,`c_work_graph_execute`,`c_artifact_write`；P=`p_work_graph_execution`
- 验收用例：
  - happy：Planner Work Graph 跑完后，`artifact` 表中存在 `brd`/`prd`/`sdd`/`benchmark` 四条记录，且 `depends_on_artifact_ids` 血缘链完整（`sdd`→`prd`→`brd`）
  - boundary：PRD 中出现互相矛盾的场景假设时，一致性校验应在 `verifying` 态被拦截，触发 `reflecting` 而非直接放行
  - failure：`sdd` 生成时找不到对应 `prd` 版本引用，`c_artifact_write` 应拒绝写入（`depends_on_artifact_ids` 指向不存在的 `artifact_id`）

## REQ-03：Coder 依据 SDD 完成编码并自测通过

- 覆盖：M=`work_node_execution`；C=`c_work_node_run`；P=`p_work_graph_execution`
- 验收用例：
  - happy：Coder Work Graph 完成后产出 `code_diff` 与 `test_report` 两类 artifact，且 unit + integration test 全部通过
  - boundary：两个无依赖的模块并行编码，验证各自 `git_worktree_ref` 不冲突，合并后代码无冲突残留
  - failure：某模块单测失败，`work_node_execution.status` 应为 `reflecting`→`retrying`，达到节点级重试上限后冒泡为 `blocked`

## REQ-04：Validator 完成测试/Benchmark + 根因归属 + 结构化 bug list

- 覆盖：M=`bug_record`；C=`c_bug_record_create`；P=`p_validator_root_cause_trace`
- 验收用例：
  - happy：人为植入一个"边界撞墙判定错误"的 bug，Validator 应判定 `root_cause_category=coder`（而非 planning 或 skill_defect），且 `root_cause_detail` 引用具体 SDD 章节和代码位置
  - boundary：植入一个"PRD 未定义撞墙行为"的需求缺口型 bug，Validator 应判定 `root_cause_category=planning`
  - failure：三视角判断不一致时，流程应落在 `inconclusive_escalate` 而不是强行给出一个归因结论

## REQ-05：Org-level Loop 完整闭环

- 覆盖：C=`c_org_loop_route`；P=`p_org_task_lifecycle`
- 验收用例：
  - happy：REQ-04 的 bug 记录经 `suggested_route=fast_lane` 路由后直达 Coder，修复后重新进入 Validator，最终 `task.status=done`，全程 `loop_round` 从 0 增至 1
  - boundary：`suggested_route=full_replan` 时应回到 Planner 而非 Coder，验证路由分支正确
  - failure：连续 3 轮同一 bug 未收敛，`task.status` 应转 `blocked_pending_human` 且调度器继续执行队列中其他任务（若有）

## REQ-06：Graph Engine 断点恢复

- 覆盖：M=`work_graph_run`,`work_node_execution`；P=`p_work_graph_execution`
- 验收用例：
  - happy：在 `work_graph_run.status=running` 时人为中断进程，重启后能从已持久化的 `work_node_execution` 状态继续，不重跑已 `done` 的节点
  - boundary：中断发生在某节点 `retrying` 中途，重启后应恢复到该节点重试逻辑而非跳过
  - failure：持久化数据损坏（模拟）时，系统应明确报错并转 `blocked_pending_human`，而不是静默丢失进度继续跑

## REQ-07：执行器抽象层（Claude Code ACP 后端）可用

- 覆盖：C=`c_work_graph_execute`；对应 05 节 5.3（架构文档 7.2 节决策，2026-07-29：MVP 阶段只用 Claude Code ACP 一种后端，不再考虑 Hermes CLI）
- 验收用例：
  - happy：Claude Code ACP 后端下完整跑通 REQ-01~06 全部场景
  - boundary：`claude -p` 调用不加 `--bare`（见 A-1 spike 结论），确认额外冷启动开销在可接受范围内
  - failure：auto mode 分类器连续拦截 3 次或累计 20 次，返回 `CLASSIFIER_BLOCKED`，task 转 `blocked_pending_human`，`blocked_reason=classifier_blocked`

## REQ-08：Skill 自主迭代 + Git 可追溯可回滚

- 覆盖：M=`skill`,`skill_iteration`；V=`v_skill_audit_log`；C=`c_skill_update`,`c_skill_rollback`
- 验收用例：
  - happy：REQ-04 中判定 `root_cause_category=skill_defect` 的 bug 触发 `c_skill_update`，生成独立 Git commit，`v_skill_audit_log` 可查看该次变更
  - boundary：`triggered_by_bug_id` 缺失时 `c_skill_update` 应拒绝（不允许无来源变更）
  - failure：`c_skill_rollback` 到不存在的 `iteration_id` 应返回 `ITERATION_NOT_FOUND`

## REQ-09：循环终止与人工升级

- 覆盖：P=`p_org_task_lifecycle` 的 `blocked_pending_human` 分支
- 验收用例：（与 REQ-05 failure 用例共享验证场景）
  - happy：`blocked_pending_human` 后，人工在 `v_task_detail` 点击"人工干预"（`manual_resume`），任务能恢复到触发前状态继续执行
  - boundary：多个任务同时有一个 `blocked_pending_human`、其余 `queued` 时，调度器应继续调度 `queued` 任务，不被阻塞任务卡住
  - failure：`manual_resume` 在任务已经是 `done` 终态时调用，应返回明确错误而非误操作已完成任务

## REQ-10：预算护栏双层机制

- 覆盖：M=`budget_guardrail_config`；V=`v_budget_settings`；C=`c_budget_check`,`c_budget_config_update`；P=`p_budget_guardrail`
- 验收用例：
  - happy：配置 `limit_type=token_count, limit_value=<小值>`，运行到超限后任务自动转 `blocked_pending_human`，`blocked_reason='budget_exceeded'`
  - boundary：调高额度后（`c_budget_config_update`），`paused` 态任务能恢复调度
  - failure：`budget_guardrail_config` 触发的超限走 `blocked_pending_human`；Claude Code plan 额度耗尽走独立的 `p_usage_limit_wait` 子流程（见 REQ-14），两者不应共用同一个 `blocked_reason`

## REQ-14：Claude Code plan 额度耗尽的等待重试（架构文档 7.5 节决策，2026-07-29）

- 覆盖：M=`work_node_execution`（`status=waiting_for_quota`、`quota_wait_started_at`、`quota_limit_type`）；V=`v_dashboard`,`v_graph_visualizer`；C=`c_work_node_run`,`c_org_node_trigger`；P=`p_usage_limit_wait`
- 验收用例：
  - happy：模拟 `claude -p` 返回 `You've hit your session limit`，`work_node_execution.status` 转 `waiting_for_quota`，退避轮询后探测成功恢复正常执行，全程不产生 `blocked_pending_human`
  - boundary：`quota_limit_type=opus` 时不走退避轮询，直接降级到非 Opus 模型重试
  - failure：模拟超过超时阈值（`session` 8 小时 / `weekly` 9 天）仍未恢复，转 `blocked_pending_human`，`blocked_reason='usage_limit_wait_timeout'`

## REQ-11：项目创建与人机交互入口（架构文档第 13 节）

- 覆盖：M=`project`,`bug_record`；V=`v_project_setup`,`v_goal_composer`,`v_bug_feedback`；C=`c_project_create`,`c_task_create`,`c_bug_report_create`；P=`p_validator_root_cause_trace`（human_reported 起点）
- 验收用例：
  - happy：选择一个已有 Git 仓库的本地文件夹创建项目 → `.graphlemon/` 子目录被创建 → 通过 `v_goal_composer` 提出"实现贪吃蛇游戏"目标 → 成功创建 task 并进入 Org Graph
  - boundary：选择一个非 Git 仓库的文件夹，用户确认初始化后应执行 `git init` 并继续；用户不确认则整个创建流程中止，不留下任何写入
  - failure：对同一 `target_folder_path` 重复调用 `c_project_create`，应幂等返回已有项目而非报错或创建重复记录；`v_bug_feedback` 提交空 `description` 应被前端和后端双重拦截

## REQ-12：实时看板（架构文档 13.1 节决策 3）

- 覆盖：M=`execution_event`；V=`v_dashboard`,`v_graph_visualizer`,`v_task_detail`；C=`c_ws_subscribe`
- 验收用例：
  - happy：某 `work_node_execution.status` 变化后，`v_graph_visualizer` 对应节点应在可感知的短时间内（作为非功能验收目标，建议 ≤2 秒）完成着色更新，无需人工刷新页面
  - boundary：WebSocket 连接断开后自动重连，重连期间页面展示"实时连接已断开，正在重连"而不是冻结或报错崩溃；重连后能补齐断线期间遗漏的关键状态（通过重新拉取 `task`/`work_graph_run` 当前快照兜底，不要求完整补齐每一条中间事件）
  - failure：订阅一个不存在的 `project_id`，连接应被拒绝并返回 `PROJECT_NOT_FOUND`，而不是建立空连接后无声无息不推送任何数据

## REQ-13：原始日志控制台内查看 + 定时清理（架构文档 13.1 节决策 4）

- 覆盖：M=`execution_log_file`,`log_retention_config`；V=`v_log_viewer`,`v_log_retention_settings`；C=`c_execution_log_get`,`c_ws_log_tail`,`c_log_retention_config_update`；P=`p_log_retention_cleanup`
- 验收用例：
  - happy：某 Work Node 运行中，`v_log_viewer` 能实时滚动显示新追加的日志内容；节点结束后自动切换为静态模式，仍可完整查看
  - boundary：配置 `retention_days=1`，构造一条 `created_at` 超过 1 天的 `closed` 状态日志，清理任务运行后应转为 `purged` 且物理文件被删除；`v_log_viewer` 打开该日志时展示"已被清理"提示而非报错
  - failure：订阅一个不存在的 `node_exec_id` 的日志流，应返回 `NODE_EXEC_NOT_FOUND`；清理任务遇到某个文件删除失败（如被占用）时，应仅记录该项失败、不影响其余候选项的清理，且该条目下次周期继续重试

## REQ-15：Deploy Supervisor 蓝绿部署与自动回滚（PH5 新增，2026-07-30，见 `docs/supervisor-auto-rollback-design.md`）

- 覆盖：M=`deployment`,`deploy_health_signal`,`bug_record`（`root_cause_category=core_engine`）；C=`c_deploy_supervisor_stage`,`c_deploy_supervisor_health_check`,`c_deploy_supervisor_cutover`,`c_deploy_supervisor_monitor`,`c_deploy_supervisor_rollback`,`c_org_loop_route`；P=`p_deploy_supervisor_blue_green`
- 验收用例：
  - happy（正常 cutover 到 finalize）：graphlemon 自身仓库一处真实植入 bug（`self-development-feasibility.md` 第 3 节场景），标记 `root_cause_category=core_engine`，Coder 修复、Validator PASS、worktree 合并主分支后，Deploy Supervisor 依次完成 `staged→candidate_starting→health_check_running→health_check_passed→cutover_in_progress→live→monitoring`，监控窗口内四类信号均正常，最终 `monitoring_window_clean→finalized`，全程无需人工评审代码内容
  - boundary（路径 A：健康检查失败）：人为让候选实例的 `canary_task` 检查失败（如返回结果与预期不符），Deploy Supervisor 应立即判定 `health_check_failed`，不重试，直接走回滚路径 A（终止候选、`git revert`、发 `bug_record`），Live 全程未受影响，可通过对比 Live 进程 PID/端口在 cutover 前后未发生变化来验证
  - boundary（路径 B：post-cutover 异常回滚）：cutover 完成后，人为把 `validator_approval_rate` 信号推到偏离历史基线阈值（`VALIDATOR_RATE_DEVIATION_THRESHOLD`，05 节 §5.9）之外，Deploy Supervisor 应判定 `anomaly_detected`，走回滚路径 B，最终 `previous_instance_dir` 重新成为 Live，`rolled_back`，生产库数据在整个过程中未丢失（因为生产库本身没有被替换，只是替换了跑在它前面的代码进程）
  - failure（回滚本身失败）：人为让 `previous_instance_dir` 也无法正常启动（如故意损坏该目录），路径 B 的回滚应终态到 `rollback_failed→blocked_pending_human`，`blocked_reason='rollback_failed'`，且控制台展示的原因应清楚区分"自动恢复机制本身失效"与"代码内容有问题"两种情况，不能让用户误以为又需要人工评审代码