anian0/unattended-development-v2

无人值守研发 v2

把 v2 研发流程串成可自动推进的闭环：需求 -> 技术方案 -> 实施计划 -> 执行 -> 审查 -> 回退修正 -> 端到端验收。主 agent 对全链路负责；各阶段仍必须遵守对应 skill 的产物和验证规则。

先读取

启动前按需读取：

• ../project-development-v2-common/references/question-policy.md
• ../project-development-v2-common/references/delivery-contract.md
• ../project-development-v2-common/references/no-simulation-policy.md
• ../requirements-workshop-v2/SKILL.md
• ../tech-design-v2/SKILL.md
• ../implementation-planning-v2/SKILL.md
• ../plan-execution-v2/SKILL.md
• ../project-development-review-v2/SKILL.md
• 进入上线前或完整流程验收时，读取 ../test-suite-maintainer/SKILL.md

只在进入某个阶段时加载该阶段的引用文件和模板，避免一开始把所有细节读入上下文。

总控原则

• 默认按无人值守执行：能基于代码、文档和安全假设推进的，不停下来问用户。
• 不得跳过阶段门禁。无人值守时，阶段确认记录写成“自主确认”，列出依据、假设、风险和触发回退条件。
• 任何会改变产品范围、数据模型、权限、安全、兼容性、成本或预期 UX 的疑问，不能靠猜测推进；必须回退到产生疑问的上一阶段补充文档。仍无法安全决策时，停止并把问题放在最终回复末尾。
• 每个阶段结束后必须用 project-development-review-v2 做独立审查。存在 BLOCKER 或未解释的 HIGH 风险时，不得进入下一阶段。
• 审查发现不是只写报告。必须回到对应阶段修正文档、计划或代码，再重新执行该阶段和审查。
• 执行阶段不得用 mock、stub、fallback、固定返回、伪造日志、未检查 UI 或未运行测试冒充完成。
• 最终完成必须同时满足：需求/方案/计划/执行证据一致，计划最终闭环通过，必要端到端验收完成，剩余风险可接受且已记录。

工作流

0. 启动和成功标准

1. 解析用户目标、仓库状态、已有 workplace/<version>/ 产物和可用环境。
2. 定义本次成功标准：
   • 需求简报已保存并通过审查。
   • 技术方案已保存并通过审查。
   • 实施计划已保存并通过审查。
   • 所有计划任务执行完成或明确标记 not_verified/blocked。
   • 最终闭环和全局验证真实运行。
   • 需要上线前验证时，完整流程测试方案、脚本和报告已按 test-suite-maintainer 完成。
3. 建立运行日志，记录阶段、输入、输出路径、审查结论、回退次数、阻塞项和最终证据。

1. 需求阶段

使用 requirements-workshop-v2：

1. 基于用户请求和项目现状创建需求简报。
2. 无人值守确认门禁时，记录：
   • 采用的安全假设。
   • 哪些问题已从代码或文档推断。
   • 哪些问题会触发回退或停止。
3. 使用 project-development-review-v2 做需求审查。
4. 如果审查发现需求范围、用户路径、验收、页面入口、特别关注点或待决策项缺失，回到需求阶段修正后重审。

进入下一阶段条件：无 BLOCKER，HIGH 风险已修复或明确作为用户可接受风险记录。

2. 技术方案阶段

使用 tech-design-v2：

1. 从已审查通过的需求简报创建技术方案。
2. 检查现有代码证据、技术依据、服务/API/数据/UI/运行链路和验证契约。
3. 若发现需求问题，停止当前技术方案写作，回退到需求阶段补充需求，再重新生成技术方案。
4. 使用 project-development-review-v2 做技术方案审查。
5. 如果审查发现字段级覆盖、验证引用、页面覆盖、技术依据、Delta 或测试资产规划缺失，修正技术方案后重审。

进入下一阶段条件：每个 R-* / A-* 都有可追踪 C-* / V-*，且审查无阻塞。

3. 实施计划阶段

使用 implementation-planning-v2：

1. 从已审查通过的技术方案创建计划目录和 T-* 任务。
2. 先做覆盖审计和测试资产规划，再拆任务。
3. 若发现技术方案缺口，回退到技术方案阶段修正；若缺口来自需求，继续回退到需求阶段。
4. 使用 project-development-review-v2 做计划审查。
5. 如果审查发现粗任务、漏任务、缺少执行断言、缺少测试资产落点、缺少最终闭环或 mock/fallback 完成路径，修正计划后重审。

进入下一阶段条件：每个 C-* 和 V-* 有任务或全局验证覆盖，每个任务可独立执行和验证。

4. 执行阶段

使用 plan-execution-v2：

1. 按计划顺序执行 T-* 任务。
2. 每个任务完成前检查执行断言、反模拟扫描、真实依赖接入、正向/负向验证、测试资产合规和独立审核。
3. 如果执行中发现计划错误：
   • 不改变范围且可安全修正：最小更新计划，记录偏差，继续执行。
   • 影响产品范围、数据模型、兼容性、安全或 UX：回退到计划、技术方案或需求阶段。
4. 同一验证连续失败最多修复三轮；仍失败时标记 blocked 或 not_verified，不要伪装完成。
5. 所有任务结束后执行最终闭环/放行任务和全局验证。
6. 使用 project-development-review-v2 做执行结果和跨文档一致性审查。

整体实现完成条件：所有可执行任务为 done，无法完成项有明确状态、原因和影响；最终审查无阻塞。

5. 端到端测试验收

根据目标决定测试层级：

• 开发阶段验证：遵循计划中的 workplace/<version>/test/ 测试资产和 V-* 验证契约。
• 功能已部署到测试或预发环境，用户要求上线前测试、完整流程验证、真实数据测试或全量验收：使用 test-suite-maintainer。

使用 test-suite-maintainer 时：

1. 为功能模块建立或更新 workplace/test/modules/<module>/test-plan.md。
2. 方案确认在无人值守模式下只能作为“自主确认草案”；如果测试方案会影响上线结论或需要真实环境凭据，必须停止请求用户确认或环境输入。
3. 方案确认后，先跑通真实后端/API/数据链路和真实前端页面路径，再创建或更新脚本。
4. 执行完整流程验收，生成模块报告和全量报告。
5. 任一高优先级主流程失败、真实依赖不可用、数据状态错误或前端可见结果不符，最终结论不得写通过。

回退规则

按最近责任阶段回退：

| 发现位置 | 回退目标 | 示例 | | --- | --- | --- | | 需求审查 | 需求阶段 | 验收不可观察、页面入口缺失、范围混入后续候选 | | 技术方案 | 需求阶段 | 技术设计发现需求事实源、权限或 UX 决策不清 | | 技术方案审查 | 技术方案阶段 | C-* 不具体、V-* 引用未定义 API、字段覆盖缺失 | | 计划阶段 | 技术方案阶段 | 技术方案未定义测试资产、服务边界或闭环验证 | | 计划审查 | 计划阶段 | 任务过粗、缺执行断言、缺测试落点 | | 执行阶段 | 计划阶段 | 任务文件不自含、命令不可执行、断言缺失 | | 执行阶段 | 技术方案阶段 | 计划要求的 API、数据或 UI 契约无法按当前代码实现 | | 执行阶段 | 需求阶段 | 实现暴露产品范围或验收口径错误 | | E2E 验收 | 执行/计划/方案阶段 | 真实流程失败、数据不可追踪、页面显示不符合验收 |

回退后必须：

1. 修正对应阶段产物。
2. 重新运行该阶段之后的所有受影响阶段。
3. 重新做审查。
4. 在运行日志记录回退原因、修改路径、影响范围和重新验证证据。

疑问处理

无人值守不是无条件猜测。按三类处理：

• safe_assumption：不影响范围、数据、安全、兼容或 UX；记录假设并继续。
• rollback_required：疑问说明上一阶段产物不足；回退补充并重跑。
• user_required：无法从代码/文档推断，且错误会造成高成本或高风险；停止并向用户提出最多 5 个短问题。

问题只能出现在阶段报告或最终回复末尾，不要夹在分析和交付说明中间。

运行日志

在 workplace/<version>/unattended/YYYY-MM-DD-<slug>.md 记录：

• 用户目标和成功标准。
• 阶段输入、输出路径和状态。
• 自主确认记录和关键假设。
• 每次审查对象、模式、结论和阻塞项。
• 每次回退原因、修正内容、重跑范围和结果。
• 执行任务状态摘要和验证命令。
• 测试资产、E2E 报告和截图/日志证据路径。
• 最终放行结论、未完成项和剩余风险。

完成标准

最终答复前检查：

• 需求、技术方案、计划、执行证据和测试报告路径真实存在。
• R-* -> A-* -> C-* -> T-* -> V-* 链路完整，或缺口已说明为 blocked/not_verified。
• 每个阶段都有审查记录，且无未处理 BLOCKER。
• 所有回退都已重跑受影响阶段。
• 执行任务没有用 mock、stub、fallback、固定返回或未验证路径作为完成依据。
• 最终闭环和全局验证已运行；无法运行时状态不是通过，而是 not_verified 或 blocked。
• 需要上线前验收时，test-suite-maintainer 的模块报告和全量报告给出明确 pass/fail/blocked 结论。