Development Lifecycle

职责与入口

只管理流程、阶段状态与完成判断，不复制阶段方法或动态项目事实。项目定义了意图宏时按其权威登记展开；解释、引用不执行。仅调查、设计、Review 等请求止于指定产物，不自动扩展为实现或发布。

worktree/主线并发遵守项目 Git 合同，保护既有改动并迁移本任务草稿。用户明确要求省 Token 且指定子代理时才读委派合同。

Task Understanding 给出目标、授权、验收、证据/未知、owner、风险与分类依据；仅澄清影响目标或关键选择的缺口。

分类与风险

按顺序选择 flow：

1. 新建独立产品，或目标目录仅有管理脚手架、没有服务本次目标的产品运行链路 → initialization；读取项目初始化，复用现有阶段并增加初始化门。仅规则接入/升级或已有产品新增功能不命中。
2. 恢复已有合同行为 → bugfix；预期未知先调查，不把新增需求当 bug。
3. 非 bug，且局部可逆、范围清楚、惯例路径、验证直接、无真实设计分叉或高风险边界 → trivial。
4. 其它变更 → standard。

风险独立：L0 普通文档/元信息；L1 局部低风险；L2 行为/交互；L3 跨 owner、持久化、协议或高影响规则；L4 发布、迁移、生产或不可逆操作。按内容而非扩展名或行数判断。trivial 仅 L0-L1；发现跨层影响或设计分叉升级 standard，复用有效证据。bugfix 有设计缺口时使用正式设计与方案 Review，保留修复目标。

task-type（feature/bugfix/small-change）与 flow 分别记录。observer 沿用七阶段；方案审查为 review，AI 验收为 validation/review。

风险 L3-L4 或用户要求大型、多阶段、低监督交付/验收时读取验收合同方法，登记 active contract 与稳定 ID；普通任务不普遍建 ledger。

四条流程

用户委托完整大型成果，且需跨工作项/上下文保持整体责任时，按需读取大型交付。它是交付组织方式，具体工作仍走以下 flow；仅设计/调查不扩大执行范围。

只有根因、路径与修后判定明确，L0-L1、单 owner、局部可逆且不改变跨层合同/状态/持久化/兼容/迁移/fallback 的 bugfix，才可内联修复设计并跳过独立方案 Review。记录 skip-design 与依据；其它 bugfix 走正式设计门。复现由理解阶段选择 reproduce 或 skip-reproduction 并说明证据，不新增 phase。

initialization 与 standard 共用阶段 owner、返工状态与整体完成门；大型交付可与任一 flow 组合，不另造流程。

standard 不因 diff 小跳过设计：设计含验收标准、必要测试矩阵并完成方案 Review；轻量方案不等于必须建长文档。plan 只在跨批恢复需要时建立，不是新增 phase。

当前阶段路由

一次只加载当前 owner，阶段只返回结果，不相互调用或回链：

• 理解、分类依据、事实与复现：development-task-understanding。
• 方案、验收设计与矩阵：development-design。
• 方案审查(mode=design)或实现审查(mode=implementation)：development-review。
• 按合同修改与迭代检查：development-implementation。
• 定向证明或最终 AI 验收(mode=acceptance)：development-validation。
• 可用入口、用户验收、授权内交付：development-delivery。
• 轻量反思与条件沉淀：development-retrospective。

跨会话或恢复读取执行状态与恢复；需要自主发现并成批修复质量差距、质量迭代宏、反复评审至满意或同类质量纠偏读取质量迭代收敛；建立或复查长期关注事项、创建/维护/执行周期事项、事实维护或资料冲突读取项目知识治理。只加载命中项。

AI 验收结合 Validation 合同证据与 Review 结论，不新增平行 Skill。方案 Review 不要求多代理。用户验收不适用于纯内部产物时说明依据，不强加产品运行环境。

状态与返工

完整开发或授权发布确定 flow 时将 retrospective_state=pending；限定单阶段任务不扩成完整交付。阶段返回 status(completed/skipped/rework/blocked)、结论、产物、证据、open_risks、rework_target、acceptance_updates 与 parent_status；无 active contract 时 updates 为空。阶段、Delivery、release 不返回整体 completed。

Delivery 完成后仅返回 parent_status=ready-for-retrospective。Lifecycle 随即路由 Retrospective，取得 retrospective_decision（原 owner 更新与证据，或 no-increment 及理由）才置 retrospective_state=completed 并检查完成；未完结果返工，进度汇报不改变状态。

• 理解或根因不明回 Task Understanding；模型缺口回 Design；编码偏差回 Implementation。
• 方案 Review 失败回 Design；实现 Review 有 finding 不得交付，修正后重验变化并复审。
• 验证失败按原因返工，受影响证据转 stale，不重复未变化风险的验证。
• 交付入口不完整留在 Delivery；外部失败由该阶段恢复，产物合同错误才回上游。
• 复盘发现结果不完整先返工，不将缺口改称后续优化。

有效合同形成或变化后，受影响设计与旧方案 Review 不再自动有效；若目标、Required 条件、能力边界或关键假设未被现行方案覆盖，先返回 Design 更新并复审，不能凭旧结论继续实现或发布。未变化部分不重跑。

跨会话、交接或上下文压缩前保存 flow、阶段/mode、retrospective_state、目标、授权、验收项、证据指针、open Required IDs 与 scope decisions；恢复先对账，不从版本或最新总结猜完成。

完成门

整体仅由本 Meta Skill 判定：最小完整结果成立；授权内无可关闭的必要缺口；适用验证有效、Review findings 清零；Delivery 已完成适用交接与用户验收合同；retrospective_state=completed 且有明确 retrospective_decision；未验证和主观项已披露。没有新增沉淀也要完成判断，但不为此创建空日志。包含复盘新增文件在内，本任务改动须全部归入交付范围；已切 worktree 时源区不得遗留本任务改动，未获提交授权时明确草稿位置与未提交状态。

完成判断分别核对实现、AI 验证和交付。用户验收适用时须有含本次改动的入口、完整使用链路、AI 先验与交接；缺项回 Delivery，擅自缩减目标回 Design。纯内部/限定产物按其范围核对。

区分已交付待用户验收、用户验收通过和任务关闭。约定必须用户确认时保持待验收；否则可结束开发交付。未回复不算通过，验收不新增已有授权之外的审批门。待验收可先做内部复盘，用户反馈更新同一记录。

active contract 的 Required acceptance IDs 必须全部 current passed，且 parent-goal 无未登记缺口；scope reduction（删减/降低标准或移出目标）须用户确认与 scope revision。局部发布、测试成功或写完文档不能替代此门。

未经明确授权不 commit、push、PR、发布、部署或不可逆操作。不得为形式制造无信息增量的文档、检查、审查或沉淀。