feat(ack): add project delivery workflow

skills/ack/references/adoption-checklist.md

@@ -4,7 +4,8 @@
 
 - [ ] ACK Skill 已全局安装或安装到当前项目。
 - [ ] 已运行 `skiff init ack --project <project-root>`。
-- [ ] `docs/ack/` 只包含项目自己的 `project.md`、`tasks.yaml` 与 `knowledge.yaml`。
+- [ ] `docs/ack/` 只包含项目自己的 `project.md`、`tasks.yaml`、`knowledge.yaml` 与
+      默认关闭的 `delivery.yaml`。
 - [ ] 旧项目缺少 `knowledge.yaml` 时，只补空文件及缺失的
       `project.knowledgeFile` 指针，没有重跑初始化或覆盖其它项目状态。
 - [ ] 项目中没有 ACK Skill 的复制目录或 `kit`、`framework` 软链接。
@@ -16,6 +17,8 @@
 - [ ] `tasks.yaml` 的 `project.overlayFile` 指向实际覆盖层。
 - [ ] `tasks.yaml` 的 `project.knowledgeFile` 固定为
       `docs/ack/knowledge.yaml`。
+- [ ] 新项目的 `project.deliveryFile` 固定为 `docs/ack/delivery.yaml`，顶层有
+      `deliveryRuns: []`；旧项目未采用交付能力时可无这两项。
 - [ ] 技术栈、运行、构建、单测和集成测试命令均来自项目证据。
 - [ ] Coordinator、Developer、Test 的模型档位和升级规则已明确。
 - [ ] `project.orchestration` 使用受支持的 profileVersion，模型都命中项目
@@ -30,6 +33,7 @@
 - [ ] 私有配置只读且不提交。
 - [ ] `tasks.yaml` 只有 Coordinator 写。
 - [ ] `knowledge.yaml` 只有 Coordinator 写；Developer 与 Test 只通过回报提名或验证。
+- [ ] `delivery.yaml` 只在用户显式维护配置时修改；Developer 与 Test 只读。
 
 ## 任务板
 
@@ -38,6 +42,22 @@
 - [ ] 真实任务的验收是可观测信号。
 - [ ] 已运行 `<ack-skill-dir>/scripts/validate_tasks.py` 并通过。
 
+## 可选交付
+
+- [ ] `delivery.yaml` 首次生成保持 `enabled: false`，没有根据 README/CI 自动启用。
+- [ ] entrypoint 只使用声明式工具 target 或仓库内无 symlink 的可执行脚本；没有
+      shell、自由 command、凭据值或环境变量值。
+- [ ] artifact、destination、environment 和 profile 引用均通过
+      `validate_delivery.py --tasks ... --project-root ...` 校验。
+- [ ] 默认 profile 只使用 preview/staging 与非 production 环境，停止在
+      `review_ready`。
+- [ ] stable 发布和 production 部署之前存在 approval 步骤；production 环境有
+      rollback 入口。
+- [ ] 本次 ACK 计划明确 profile、task IDs、目标、停止点和审批步骤；配置本身没有
+      被当作提交、推送、发布或部署授权。
+- [ ] 每次运行固定 commit/config revision，证据写入 `tasks.yaml.deliveryRuns`；
+      失败不会把已验证任务回退为失败。
+
 ## 项目知识
 
 - [ ] 新项目没有已验证知识时使用 `verificationRegistry: {}` 与 `entries: []`，

skills/ack/references/closed-loop.md

@@ -164,11 +164,12 @@ python3 <ack-skill-dir>/scripts/launch_worker.py launch \
 | 要保持基线分支干净 | 新 worktree（feature 分支）|
 | 小改动、追求快 | 当前 worktree |
 
-**项目状态（SSOT）只落一处**：无论开几个 worktree，`tasks.yaml` 和
-`knowledge.yaml` 都只认一个权威副本（通常在基线/协调所在 worktree），由
-Coordinator 单写。`project.orchestration`、顶层 `workerReceipts` 和任务 dispatch
-也只写入这个副本；不要每个 worktree 各留一份会分叉的项目状态。profile 解析、
-launcher 与 receipt 规则见 `model-routing.md` 和 `orca-adapter.md`。
+**项目状态（SSOT）只落一处**：无论开几个 worktree，`tasks.yaml`、
+`knowledge.yaml` 和可选 `delivery.yaml` 都只认一个权威副本（通常在基线/协调所在
+worktree）。Coordinator 单写任务、知识与 `deliveryRuns`；交付能力只在显式配置维护
+时修改。`project.orchestration`、顶层 `workerReceipts` 和任务 dispatch 也只写入这个
+副本；不要每个 worktree 各留一份会分叉的项目状态。profile 解析、launcher 与
+receipt 规则见 `model-routing.md` 和 `orca-adapter.md`。
 
 两种 worktree 方式都只允许 profile 中的 `read-only` / `workspace-write` 安全权限。
 v0.10 的 full-access 授权与撤销机制仍是 Deferred；launcher 遇到 full-access 或等价
@@ -191,7 +192,8 @@ v0.10 的 full-access 授权与撤销机制仍是 Deferred；launcher 遇到 ful
 7. 失败则用「复测失败再派发模板」重新发给 Developer，最多累计三轮。
 
 手动模式下同样遵守：worker_done / 复测报告都不等于最终结论、只有 Coordinator
-写 `tasks.yaml` 和 `knowledge.yaml`、三轮失败留档。
+写 `tasks.yaml` 和 `knowledge.yaml`、三轮失败留档。若本次确认计划还包含交付，所有
+选中任务 `verified` 后由 Coordinator 继续按 `delivery.md` 执行并写 `deliveryRuns`。
 
 手动交给用户已打开的会话不等于产生 ACK receipt。该会话可以完成本次显式 handoff，
 但不能因此进入 Orca 自动派发信任路径；后续自动派发仍需重新通过 ACK launcher

skills/ack/references/delivery.md

@@ -0,0 +1,123 @@
+# ACK 交付阶段
+
+本文件定义可选的 `verified -> review_ready/released` 交付阶段。开发、独立复测和
+Coordinator 终检仍由 ACK 原有闭环负责；只有选中的任务全部 `verified` 后才能进入
+交付。项目配置位于 `docs/ack/delivery.yaml`，运行证据写入
+`docs/ack/tasks.yaml.deliveryRuns`。
+
+## 1. 配置与授权不是一回事
+
+`delivery.yaml` 描述项目能怎样构建、上传和部署，不能单独授予远端写权限。ACK 在
+kickoff 的既有用户确认点同时展示本次 profile、remote、产物目标、环境和停止点；用户
+确认该任务计划后，才允许执行计划中准确列出的 `review_ready` 步骤。目标、remote、
+channel、environment 或 source revision 漂移时重新确认。
+
+`approval` 步骤始终是运行时硬门。`stable` 发布和 `production` 部署不能由 kickoff
+的一般确认代替，必须在该步骤取得本次明确授权。配置、历史 approval 或项目文档不能
+替用户授权合并 PR、创建正式 tag、覆盖版本、删除分支或生产发布。
+
+## 2. 配置快照与变更生效
+
+普通任务在 kickoff 时从可信 base commit 读取交付契约并记录 `configRevision`。本次
+分支对 `delivery.yaml`、引用的部署入口、CI 或 Agent 指令文件的修改不能扩大当前运行
+权限；这些改动经审核合并后从下一次任务生效。
+
+用户明确要求维护交付配置时：
+
+1. 读取现有配置、项目构建入口、CI、打包和部署事实。
+2. 用自然语言总结将新增、删除或改变的 artifact、destination、environment、profile
+   和权限边界。
+3. 只做最小配置修改，不把项目脚本复制进 ACK。
+4. 运行 `validate_delivery.py`；可安全执行的本地入口使用 dry-run 或无凭据环境检查。
+5. 把配置或入口变更作为待审核变更交付。本轮不使用新配置执行 publish/deploy。
+
+普通功能任务中若发现配置漂移，记录 `contract_drift` 并停止受影响的交付步骤，不为了
+通过流程而静默修改配置或跳过步骤。
+
+## 3. 交付契约结构
+
+- `entrypoints`：项目已有的 Make、Just、Task、Dagger 或仓库内可执行脚本入口。
+- `artifacts`：`deb`、`oci-image` 或 `file`，引用一个 build entrypoint。
+- `destinations`：APT、OCI registry 或 CI artifact；`channel` 区分 preview、staging、
+  stable。
+- `environments`：SSH host、Docker Compose、Kubernetes 或 custom；必须声明环境等级、
+  deploy 和 health check，production 还必须声明 rollback。
+- `profiles`：按顺序执行的步骤和停止点。默认 profile 必须停在 `review_ready`，不能
+  发布 stable 或部署 production。
+
+配置不允许 `shell`、自由 `command`、`env`、外部 executable、token、密码、私钥路径
+或凭据 URL。entrypoint 的 `requiredSecrets` 只能列大写 secret 名称，值必须由外部
+凭据系统或执行环境注入。复杂逻辑放在受版本控制的项目入口中。entrypoint 使用 argv
+语义执行，不能拼成 `sh -c` 字符串。
+
+## 4. 运行前检查
+
+1. 从 `tasks.yaml.project.deliveryFile` 解析文件；未引用或 `enabled=false` 时保持旧 ACK
+   行为，收尾停在 `verified`。
+2. 运行：
+
+   ```bash
+   python3 <ack-skill-dir>/scripts/validate_delivery.py \
+     docs/ack/delivery.yaml --tasks docs/ack/tasks.yaml \
+     --project-root <project-root>
+   ```
+
+3. 确认选中 profile 是 kickoff 已确认的 profile，所有 task 已是 `verified`，工作区与
+   服务对应正确 source revision。
+4. 检查 referenced entrypoint、delivery config、CI 和凭据边界是否在本次变更中被
+   修改；被修改时禁止用它们执行带远端写权限或 secret 的步骤。
+5. 检查本次步骤引用的 `requiredSecrets` 是否由外部环境提供，只报告名称和是否存在，
+   不读取、打印或持久化值。缺失时在第一次相关写操作前标记 blocked。
+6. 将已确认工作树固化为本地 source revision，再创建 `deliveryRuns` 的 `planned`
+   记录，绑定 task IDs、profile、source revision 和 config revision；推送仍等到对应
+   `pull-request` 步骤。
+
+## 5. 步骤语义
+
+按 profile 中的顺序执行，不自行插入或省略步骤：
+
+- `verify`：运行指定 entrypoint，失败即停止。
+- `pull-request`：在精确 source revision 上提交、推送任务分支并创建或复用 Draft
+  PR/MR。普通任务使用项目已确认的 Forge 流程；只有本次是版本发布生命周期且用户
+  明确要求时才调用独立的 `manage-release`。没有对应能力或认证时标记 blocked，不用
+  带 token 的临时 curl 兜底。remote 与 base branch 必须来自该步骤，不能临时猜测。
+- `build`：调用 artifact 的 build entrypoint。DEB 必须记录包名、版本、架构和
+  SHA-256；OCI image 必须记录完整引用、platform 和 digest。产物必须绑定当前 source
+  revision，不能在目标机器重新拉源码构建。
+- `publish`：验证 artifact/destination 类型兼容，上传精确产物。DEB 可使用已安装的
+  `deb-publisher`；Docker 只有在用户明确指定 `$publish-docker-image` 时才加载该
+  explicit-only skill，否则必须走契约中已审查的 upload entrypoint。项目入口只接受
+  刚校验的精确 artifact。preview/staging 使用不可覆盖的 commit/PR 标识，不隐式使用
+  `latest`。既没有可用 skill 也没有 upload 入口时标记 blocked。
+- `deploy`：把同一不可变 artifact 交给 environment 的 deploy entrypoint；获取目标
+  mutex 后执行，不能并发部署同一目标。
+- `health-check`：在对应 deploy 成功后运行环境 health check，记录可观测证据。失败时
+  按项目入口执行 rollback；rollback 未证明成功时不得声称恢复。
+- `approval`：停止并展示准确 artifact、destination/environment、source revision 和
+  回滚计划，等待用户本次确认。
+- `mark-ready`：所有前序步骤成功后将 Draft PR/MR 标为 ready，并写入最终证据。
+
+## 6. 状态与恢复
+
+`task.status=verified` 表示代码正确性通过；交付状态单独记录为 `planned`、`running`、
+`blocked`、`failed`、`review_ready`、`released` 或 `skipped`。部署或 Forge 暂时失败不把
+任务改回 `failed_retest`。
+
+重复运行先核对已有 branch、PR/MR、artifact 和部署目标，复用身份匹配的资源。相同
+ID 指向不同 commit、digest 或目标时停止，不覆盖或另建伪装成同一运行的资源。
+
+若恢复过程中修改了任何 tracked file，原 source revision 和交付证据失效：回到 ACK
+验证闭环，Test 重新复测后才能创建新的 delivery run。只有外部瞬时失败且 Git 内容未变
+时，才可从失败步骤继续。
+
+`review_ready` 至少记录：source/config revision、PR/MR URL、所有产物引用与 digest、
+部署环境和健康检查证据。最终回复分别报告代码验证、PR、产物、部署和未完成项，不能用
+“完成”掩盖其中某一阶段失败或待审批。
+
+## 7. 与低层 Skill 的边界
+
+ACK 只负责读取项目交付契约、编排顺序、守住审批点并汇总证据，不复制低层 skill 的
+上传、镜像或 Git 发布实现。`deb-publisher`、`publish-docker-image` 和
+`manage-release` 仍是可独立使用、独立安装的能力；缺失时 ACK 使用契约中已审查的
+项目 entrypoint，二者都不可用时把对应步骤标为 `blocked`。低层 skill 自身要求显式
+调用时，ACK 不能绕过它的触发与授权边界。

skills/ack/references/init-new-project.md

@@ -12,7 +12,8 @@
 3. `skiff` 命令可用。
 
 不要覆盖已有的 `docs/ack/project.md`、`docs/ack/tasks.yaml`、
-`docs/ack/knowledge.yaml`、`AGENTS.md` 或其它 Agent 指令文件。ACK 不会自动
+`docs/ack/knowledge.yaml`、`docs/ack/delivery.yaml`、`AGENTS.md` 或其它 Agent
+指令文件。ACK 不会自动
 修改 `AGENTS.md`、`CLAUDE.md` 或其它 Agent 指令文件。不要把 token、`.env`
 内容或其它私有配置写入 ACK 项目状态。
 
@@ -36,7 +37,8 @@ skiff init ack --project <project-root>
 docs/ack/
 ├── project.md
 ├── tasks.yaml
-└── knowledge.yaml
+├── knowledge.yaml
+└── delivery.yaml       # 默认 enabled: false
 ```
 
 如果任一目标文件已经存在，命令会拒绝覆盖。初始化过程不会创建 `kit`、
@@ -52,6 +54,14 @@ docs/ack/
 `knowledgeFile: docs/ack/knowledge.yaml`，不改写其它项目状态。生成后运行任务板、
 知识库和跨文件引用校验。
 
+### 旧项目补充交付配置
+
+`delivery.yaml` 对旧项目是可选能力；缺少它不会影响三角色开发与验证闭环。只有用户
+明确要求配置项目交付时，才从 `templates/delivery.template.yaml` 生成文件，同时在
+任务板补 `project.deliveryFile: docs/ack/delivery.yaml` 与顶层
+`deliveryRuns: []`。首次生成保持 `enabled: false`，按 `delivery.md` 展示并确认
+解析结果后才启用。不要重跑 `skiff init ack`，也不要改写已有任务或知识。
+
 ## 完善项目覆盖层
 
 编辑 `docs/ack/project.md`，填入：
@@ -70,9 +80,13 @@ docs/ack/
 
 - `ackVersion` 使用 ACK Skill 的合法 SemVer `VERSION`；从 `0.10.0` 起
   `project.orchestration` 与顶层 `workerReceipts` 必须同时存在。
+- 从 `0.11.0` 起的新项目初始化包含默认关闭的交付契约；旧项目不要求为了版本号升级
+  自动补交付配置。
 - `updatedAt` 使用当前带时区时间。
 - `project.name`、`repoPath`、`devWorktree`、`overlayFile` 和 `knowledgeFile` 使用
   真实值。
+- 新项目的 `project.deliveryFile` 固定为 `docs/ack/delivery.yaml`，并保留顶层
+  `deliveryRuns: []`。旧项目只有在采用交付能力时才补这两个字段。
 - `project.orchestration.allowedWorktrees` 使用已核对的绝对 worktree；模型
   allowlist、profiles 和 defaults 使用项目实际允许值。不要把完整启动命令、
   `extraArgs`、`env` 或任意 executable 写进任务板。
@@ -98,6 +112,14 @@ candidate 留在任务证据中，不会被派发。只有 Test 独立验证且
 `<ack-skill-dir>/scripts/run_verification.py`，不直接运行 path/args。关键约束应
 最终下沉为测试、lint、CI 或正式规范。
 
+## 初始化项目交付
+
+新项目的 `docs/ack/delivery.yaml` 保持 `enabled: false`、空能力表和空 profile。
+不要根据 README 或 CI 自动推断并启用发布/部署。用户用自然语言描述交付要求后，
+Coordinator 按 `delivery.md` 维护声明式配置：工具 target 与仓库脚本分开引用，产物、
+目的地、环境和有序 profile 使用稳定 ID。配置中不保存 shell、环境变量值或凭据
+正文；稳定发布和生产部署必须有显式 approval 步骤。
+
 ## 校验
 
 Agent 从当前 `SKILL.md` 解析 ACK Skill 目录后运行：
@@ -105,13 +127,17 @@ Agent 从当前 `SKILL.md` 解析 ACK Skill 目录后运行：
 ```bash
 python3 <ack-skill-dir>/scripts/validate_tasks.py docs/ack/tasks.yaml
 python3 <ack-skill-dir>/scripts/validate_knowledge.py docs/ack/knowledge.yaml --tasks docs/ack/tasks.yaml
+python3 <ack-skill-dir>/scripts/validate_delivery.py docs/ack/delivery.yaml \
+  --tasks docs/ack/tasks.yaml --project-root <project-root>
 ```
 
 同时确认：
 
-- `project.md`、`tasks.yaml` 和 `knowledge.yaml` 没有未替换的 `<...>` 占位符。
+- `project.md`、`tasks.yaml`、`knowledge.yaml` 和 `delivery.yaml` 没有未替换的
+  `<...>` 占位符。
 - `project.overlayFile` 指向真实文件。
 - `project.knowledgeFile` 指向 `docs/ack/knowledge.yaml`。
+- 新项目的 `project.deliveryFile` 指向 `docs/ack/delivery.yaml`；交付默认关闭。
 - Developer 与 Test 的验证命令可执行。
 - `project.orchestration` 的 profile/allowlist/defaults 通过校验，自动模式只允许
   `read-only` 或 `workspace-write`；旧任务板未迁移时保持手动模式。
@@ -125,9 +151,9 @@ python3 <ack-skill-dir>/scripts/validate_knowledge.py docs/ack/knowledge.yaml --
 
 完成后报告：
 
-- 创建或确认的三个项目文件。
+- 创建或确认的四个项目文件。
 - 检测到的技术栈和验证命令。
-- 任务板和项目知识校验结果。
+- 任务板、项目知识和交付契约校验结果。
 - 仍需用户补充的值。
 
 只有结构校验通过且必填项目事实完整时才称“初始化完成”；否则称“部分完成”，并列出

skills/ack/references/kickoff.md

@@ -23,15 +23,20 @@
 1. 先读 docs/ack/project.md、docs/ack/tasks.yaml（包括 project.orchestration），校验 docs/ack/knowledge.yaml 并
    用 `scripts/select_knowledge.py` 只读取当前任务相关的 active 条目，再读
    references/roles-and-permissions.md、closed-loop.md、optimization-method.md。
+   如果 tasks.yaml 声明 project.deliveryFile，再读取 delivery.yaml 与
+   references/delivery.md，但不要把配置本身当作执行授权。
 2. 写产品文档到 docs/（PRD / 交互 / 验收），把需求拆成任务，每个任务的验收写成可观测信号（可见文本 / API 结果 / 交互结果）。
 3. 按任务 scope 从 knowledge.yaml 推荐 active 知识，确认后把固定 revision 的
    knowledgeRefs 写入任务；不要派发 candidate 或全量知识库。
 4. 把任务写进 docs/ack/tasks.yaml（只有你写），校验 tasks.yaml 和 knowledge.yaml。
-5. 先把「产品文档 + 任务拆分 + 验收信号 + 适用知识引用」给我确认，不要急着派发。
+5. 先把「产品文档 + 任务拆分 + 验收信号 + 适用知识引用」给我确认；若启用了交付，
+   同时列明本次 profile、目标、停止点与审批步骤。不要急着派发或交付。
 6. 我确认后，按 ack 闭环循环：先用 `scripts/launch_worker.py` 校验结构化
    Developer/Test profile，审阅 plan 后用 expected fingerprint 创建 fresh worker，
    dispatch 开发 → worker_done → dispatch 测试独立复测 → 你读证据终检 → 回写 tasks.yaml；
    每个任务最多三轮，三轮不过记 leftover 并升级我复盘。
+7. 所选任务都 verified 后，只有本次计划包含交付时才按 profile 顺序执行并写
+   deliveryRuns；默认停在 review_ready，stable/production 步骤再次向我确认。
 ```
 
 ---
@@ -55,6 +60,9 @@ python3 <ack-skill-dir>/scripts/validate_knowledge.py docs/ack/knowledge.yaml --
 
 5. **停下来给人确认**：这是强模型该花时间的地方，不要跳过。
 
+如果 `delivery.enabled: true`，确认内容还必须列出：profile、关联 task IDs、构建产物、
+发布 channel、部署环境、PR 是否创建/标 ready、停止点，以及哪些步骤会再次审批。
+
 ---
 
 ## 第 2 步：决定 worktree
@@ -143,7 +151,16 @@ Coordinator 只内联本轮 `knowledgeRefs` 指向的少量知识，不要求 wo
 
 ---
 
-## 第 5 步：收尾
+## 第 5 步：可选交付
+
+所选任务都由 Coordinator 标记为 `verified` 后，若用户确认的计划包含交付，按
+`delivery.md` 执行所选 profile。先重新校验 `delivery.yaml`，固定当前 commit 和
+config revision，然后按有序步骤调用项目入口与已安装的低层 skill。每一步证据写入
+`tasks.yaml.deliveryRuns`；默认 profile 到 `review_ready` 即停止，stable 发布和
+production 部署必须在 approval 步骤再次确认。失败时保留任务的 `verified`，把
+delivery run 标为 `blocked` 或 `failed`。
+
+## 第 6 步：收尾
 
 一轮结束时 Coordinator 必须能回答 `optimization-method.md` §「结束条件」的问题：哪些 verified、哪些 leftover、各失败几轮、工作树是否干净、还有没有未处理项。
 
@@ -154,5 +171,5 @@ Coordinator 只内联本轮 `knowledgeRefs` 指向的少量知识，不要求 wo
 产品文档 + 验收信号写在前（你，强模型）→ 确认显式 `knowledgeRefs` → 从
 `tasks.yaml.project.orchestration` 解析安全 profile → 审阅 plan 并用 expected
 fingerprint 启动 fresh DEV/TEST → dispatch / 复测 / 终检循环 → 任务结论落
-`tasks.yaml`，验证后的
+`tasks.yaml` → 可选 delivery profile 到审核点，验证后的
 跨任务知识由 Coordinator 落 `knowledge.yaml`。

skills/ack/references/prompt-templates.md

@@ -256,6 +256,13 @@ Orca 模式下用 `orca-adapter.md` §「Test 回报复测结果」的命令发
 - 新增或更新：<active/stale/superseded entries written by Coordinator, or none>
 - 待验证 candidate：<remaining candidates or none>
 
+交付（未启用时写 n/a）：
+- run/profile/status：<delivery run id / profile / review_ready|released|blocked|failed>
+- PR/MR：<URL and head/base>
+- 产物：<reference, digest, destination>
+- 部署：<environment, health/rollback evidence>
+- 待审批或未完成：<approval/blocked step or none>
+
 工作树状态：
 - <repo_path>: <git status summary>
 - <dev_worktree>: <git status summary>

skills/ack/references/roles-and-permissions.md

@@ -12,7 +12,7 @@ ACK 默认三个独立 Agent：**Coordinator 只编排、Test 只验证、Develo
 
 | 角色 | 主要职责 | 验证方式 | 不应做的事 |
 |------|----------|----------|------------|
-| Coordinator (PM) | 需求拆解、定验收信号、排优先级、单写 `tasks.yaml` / `knowledge.yaml`、选择知识、向 Developer/Test 派发、跑三轮闭环、做最终 gate | 读 Test 证据并对齐原始意图（不亲自跑测试） | 修改源码、亲自复测、凭 worker_done 直接标 `verified`、自动激活未验证知识 |
+| Coordinator (PM) | 需求拆解、定验收信号、排优先级、单写 `tasks.yaml` / `knowledge.yaml`、选择知识、向 Developer/Test 派发、跑三轮闭环、做最终 gate；经确认后编排可选交付 | 读 Test 证据并对齐原始意图（不亲自跑测试）；核对交付证据 | 修改源码、亲自复测、凭 worker_done 直接标 `verified`、自动激活未验证知识、把配置当作发布授权 |
 | Test | 黑盒复测、回归验证、执行知识检查、独立验证知识候选、沉淀可执行测试、产出证据 | 浏览器、API、集成脚本、用户可见行为 | 修改应用源码、修改产品规格、写 `tasks.yaml` 或 `knowledge.yaml` |
 | Developer | 实现修复、写单元测试、运行构建和白盒验证、提名项目知识 | 单元测试、类型检查、构建、本地运行 | 修改产品规格与集成测试、写项目状态、标记 `verified`、绕过测试声称完成 |
 | User / Decision Owner | 决定范围、优先级、阻塞项是否继续 | 审阅报告和遗留清单 | 直接替代复测证据 |
@@ -109,6 +109,7 @@ ACK 默认三个独立 Agent：**Coordinator 只编排、Test 只验证、Develo
 | `<local_config>` | Read-only | Read-only | Read-only | 本地私有配置，不提交 |
 | `tasks.yaml` | R/W | Read-only | Read-only | 见下方「项目状态写入约定」 |
 | `knowledge.yaml` | R/W | Read-only | Read-only | Coordinator 单写；Developer/Test 通过回报提名或验证 |
+| `delivery.yaml` | 仅显式维护时 R/W | Read-only | Read-only | 声明项目交付能力，不保存凭据或执行授权 |
 
 ---
 
@@ -145,12 +146,28 @@ failed_retest（累计 3 轮） -> leftover
 
 三轮失败的处理细则见 `optimization-method.md` §「三轮失败策略」。
 
+## 交付状态（与任务状态正交）
+
+任务进入 `verified` 后不再改写为发布或部署状态。可选交付的每次执行单独记录在
+`tasks.yaml.deliveryRuns`：
+
+```text
+planned -> running -> review_ready | released
+                    -> blocked | failed
+planned -> skipped
+```
+
+`review_ready` 表示 PR、preview 产物和已授权的非生产部署证据已经齐备，等待用户
+审核；`released` 只用于用户明确批准后的 stable 发布或 production 部署。交付失败
+不会否定已经独立验证的任务，但必须保留失败步骤、revision 与日志引用。完整顺序、
+审批点和恢复规则见 `delivery.md`。
+
 ---
 
 ## 项目状态写入约定（并发安全）
 
-`tasks.yaml` 是任务事实源，`knowledge.yaml` 是跨任务项目知识事实源。为避免多
-Agent 并发写冲突：
+`tasks.yaml` 是任务与交付运行事实源，`knowledge.yaml` 是跨任务项目知识事实源，
+`delivery.yaml` 是项目交付能力事实源。为避免多 Agent 并发写冲突：
 
 - **只有 Coordinator 写 `tasks.yaml` 和 `knowledge.yaml`**。Test 与 Developer
   对它们都是只读的。
@@ -160,6 +177,8 @@ Agent 并发写冲突：
   知识。
 - 每次写入前先读最新内容，写入后更新顶层 `updatedAt`。
 - 单次写入应是一个任务的一次状态跃迁，避免整表批量重写。
+- `delivery.yaml` 只在用户显式要求维护配置时修改；运行只写
+  `tasks.yaml.deliveryRuns`，不能反向改写能力定义。
 
 全项目范围的 `must`、`never` 或权限类规则还需要 User / Decision Owner 确认。
 关键约束应最终下沉为测试、lint、CI 或正式规范；知识条目保存触发条件、原因和