0022 分阶段执行：研发阶段、闸口、测试验证阶段
背景
原来第 3–11 步一口气跑完，只在方案审核需要需求方决定时停下。很多团队的研发和测试是两拨人、两个节奏：研发完成要"提测"，测试同事先部署测试环境、准备数据，再验证，或者干脆人工测试；验证也可能想用另一个模型，在另一个时间进行。
代码评审通过之后、服务启动和功能验证之前，是天然的分界。
决定
- 分成固定的两个阶段：研发（方案设计 → 方案审核 ⇄ 修订 → 实现 → 代码评审 ⇄ 修复 → 提测说明）和测试验证（服务启动 → 功能验证 → 缺陷处理），中间一个闸口。不做任意切分、可配置的阶段：常见的交接点只有"提测"一处，任意切分会让状态、继续规则和手册都变复杂。阶段名在状态里用字符串（
develop、verify），以后增加阶段不用改格式。 - 研发阶段最后新增一步"提测说明"（builder，
handoff.md）。三种执行方式都写：连续时它是功能验证的输入，分阶段时是交给测试的单据，只做研发时是人工测试的依据。 - 闸口怎么走由执行方式决定，来源后者覆盖前者：配置
phases.mode→ spec 头部- 执行方式：→ 启动参数--phases。continuous（连续，默认）：直接进入测试验证，与之前的行为一致。gated（分阶段）：状态变为phase_done，进程正常退出、不占排队名额；通知对话"研发完成，可以提测"，外部通知新事件phase_done；等待提醒（waitingReminderHours）也覆盖这个状态。--resume --phase verify（或在闸口单独的--resume）开始测试验证，沿用研发阶段的结果。--verify-at在研发完成时预约开始时间（复用 0020 的定时任务）；研发完成时时间已过就直接继续。develop-only（只做研发）：写完提测说明后写一份研发报告并结束，状态为completed；之后仍可用--phase verify让流水线做测试验证。
- 测试验证阶段的选项写在
phases.verify，开始测试时也可以用参数临时指定：environment：local（本地启动服务）或deployed（对已部署的测试环境验证，需要功能目录中的test-env.md，没有就拒绝开始；不在本地启动服务）。agents：测试阶段的步骤（服务启动、功能验证、缺陷修复、复验）可以用单独的 agent，格式同顶层agents，可用paseoProfile。完成报告仍用顶层的 builder。defects：fix（当场修复并复验，原来的做法）、handback（只记录，退回研发阶段：在changes.md追加"测试验证退回"一节，开始新的一次尝试，按 0015 从方案设计增量处理，修复经过代码评审、重新写提测说明后再提测；次数上限为档位的缺陷修复轮数）、report（只记录，直接出报告）。
- 测试阶段开始前需求说明改过：按增量继续的规则回到研发阶段的方案设计。
- 测试同事接手：需求在自动新建的工作区中开发（0018）且研发已完成（或已在测试验证阶段）时，同一仓库任何工作区中的对话都可以开始或继续测试验证；通知转到那个对话，步骤仍放在需求的工作区、挂在那个对话下。研发阶段仍然只能从来源目录的对话操作。不在自动新建工作区中的需求，测试同事需要在同一目录的对话中接手（步骤 agent 使用对话的目录，见 0001）。
- 安全边界不变：测试环境只能是测试用途的环境；
test-env.md只写口令在哪里取，不写口令本身；提示词继续禁止连接生产环境、使用生产凭据。
影响
- 状态文件只增加可选字段（
phases、phase、verifyAt、handbacks、步骤记录的phase）和状态值phase_done，格式版本仍为 1。回滚到 1.6 后，旧引擎把phase_done当作可以继续的中断，继续时沿用研发结果、直接做验证，可以接受。 - 所有运行（包括连续方式）多一个"提测说明"步骤，通常几分钟。
- 外部通知按约定只增加了事件类型
phase_done和字段。 - 用时与用量可以按阶段统计（状态、完成报告）。
本页由仓库中的 docs/adr/0022-develop-and-verify-phases.md 生成。在 GitHub 上编辑