peiiii / development-delivery

Development Delivery

目标

每个任务都交接结果；commit、push、PR、release、deploy 和不可逆操作须用户明确授权，或有当前项目可核对的既有明确授权。

进入门

进入时确认：

• 可观察目标和交付范围；
• 适用验证已经通过且证据未因后续修改失效；
• 适用 Review 已无未关闭 findings；
• 工作区中的用户或其它任务改动已经隔离；曾切换 worktree 时，已取得草稿迁移及源区查漏证据，规则、文档和复盘也已纳入本次交付范围；
• 外部动作的对象、范围和授权明确。
• active contract 存在时，本次交付对应 stable acceptance IDs 已明确且证据当前有效。

前置条件不成立则返工，不在 Delivery 修代码或设计。

轻量交付

用户可操作的产品变化默认执行[用户验收交付](references/user-acceptance.md)，不等用户索要链接；取得当前范围有效 AI 验收结论后，按该合同交齐入口、操作与预期、验证边界和状态。未发布不是省略验收入口的理由。

没有外部发布授权时也要完成：

• 汇报结果、证据、未验证链路、主观确认项和残余风险；
• 判断生成物保留及项目已有的变更说明、版本记录和迭代记录是否适用；
• 判断已形成稳定证据的用户可见结果是否需要项目内容材料；
• 明确 commit、push、release 和 deploy 已因未授权跳过。

专项路由

提交范围、版本说明、产品发布、文档部署和 Git 主线协调以当前项目的明确合同为准。每个决策只读取当前需要的一个项目专项方法；项目没有发布合同，不把“提交成功”或“产物构建成功”称为完整发布。维护发布机制或修复发布失败时读取[版本演进门](references/release-evolution.md)。专项 owner 只完成自己的发布或交付子目标，不重新编排上游开发阶段。

博客候选门

项目有内容发布 owner，且适用 Validation/Review 已形成稳定证据时，按项目合同判断是否准备内容材料；内容发布仍遵守独立授权。

发布语义

• 发布前明确对象、版本、环境、授权范围和可观察完成点；自然语言宏只按项目权威登记解释。
• 外部等待只在完成点、风险、失败或需决策时更新；状态未变不发心跳。重试遵守 owning workflow 的幂等与恢复合同。
• 一次发布按项目合同核对产物、部署、可用性和回滚或恢复；已成功的不可逆步骤不重复执行。
• 上下文不能确定发布对象时只问一个短问题；存在“只、仅、不包含”等限制词时以更窄授权为准。

外部动作

• 用户只要求“提交”时，只在当前任务分支精确 stage/commit；是否合并、推送及目标分支按用户授权和项目 Git 合同判断。禁止混入无关 WIP 或把隔离分支报告为主线完成。
• 发布使用仓库既有 release flow，不以零散原子命令伪装完整闭环。
• 发布完成必须覆盖授权范围内适用的产物、说明、部署后验证和分支状态。
• 可恢复分叉、并行 WIP 或隔离分支只是中间状态；合入主线的任务按项目合同安全集成，不污染活跃区或要求用户手工处理本可由系统恢复的步骤。
• 部分发布或外部失败优先进入专项恢复分支；不得重复发布已经成功的不可逆步骤。
• active contract 下只返回 acceptance_updates 与 parent_status；artifact、版本或 release 不能完成 parent-goal，交回 lifecycle 执行 completion gate。

输出

报告范围、证据、授权与执行结果、缺口、恢复入口及残余 WIP；验收交付一次给齐入口、步骤和预期。有 active contract 时报告 stable ID 更新并返回 parent；不得把部分完成表述成全部完成。完整开发或授权发布的 Delivery 完成时，返回 parent_status=ready-for-retrospective 与交付证据，由 Lifecycle 路由复盘后再做整体完成判断；仅授权发布而直接进入 Delivery 的任务也要完成这一交接。外部发布成功、长时间等待结束或用户催促均不跳过；纯调查、设计或 Review 的限定单阶段产物不因此扩大范围。

本阶段不修改产品实现、不关闭 Review findings，也不把内部工程记录直接拼成用户 release notes。