feat(ack): add one-off delivery routing

skills/ack/references/adoption-checklist.md

@@ -23,6 +23,8 @@
 - [ ] Coordinator、Developer、Test 的模型档位和升级规则已明确。
 - [ ] `project.orchestration` 使用受支持的 profileVersion，模型都命中项目
       allowlist，默认 profile 与角色/档位一致。
+- [ ] 需要一次性交付路由时存在 `defaults.operator`；其 CLI、standard 模型和
+      reasoning effort 与 `defaults.test` 完全相同。
 - [ ] `allowedWorktrees` 只列出同一 Git common-dir 下已经核对的绝对 worktree。
 
 ## 路径权限
@@ -34,6 +36,7 @@
 - [ ] `tasks.yaml` 只有 Coordinator 写。
 - [ ] `knowledge.yaml` 只有 Coordinator 写；Developer 与 Test 只通过回报提名或验证。
 - [ ] `delivery.yaml` 只在用户显式维护配置时修改；Developer 与 Test 只读。
+- [ ] Operator 只回传一次性交付证据，不写 ACK 项目状态文件。
 
 ## 任务板
 
@@ -58,6 +61,16 @@
 - [ ] 每次运行固定 commit/config revision，证据写入 `tasks.yaml.deliveryRuns`；
       失败不会把已验证任务回退为失败。
 
+## 可选一次性交付路由
+
+- [ ] PR/MR 与源码发布、DEB、Docker 镜像分别路由到 `manage-release`、
+      `deb-publisher`、`publish-docker-image`；普通 PR/MR 只使用 `PR-only`，没有扩大
+      到版本升级、合并、tag 或 Forge Release。
+- [ ] `delivery-operation.operation.request` 保留用户原始请求，没有扩大授权。
+- [ ] Operator 使用 `launch_worker.py --role operator` 创建的 fresh worker，没有复用
+      Test terminal，也没有让 Coordinator 代跑。
+- [ ] 部分成功或外部状态不确定时按低层 Skill 恢复，没有盲目自动重试。
+
 ## 项目知识
 
 - [ ] 新项目没有已验证知识时使用 `verificationRegistry: {}` 与 `entries: []`，
@@ -83,13 +96,15 @@
       `orca terminal create --command` 或自由 worker 命令。
 - [ ] `launch` 使用刚审阅的 `plan.launchFingerprint` 作为
       `--expected-launch-fingerprint`；漂移时重新 plan。
-- [ ] Developer/Test 只使用 `read-only` 或 `workspace-write` profile；
+- [ ] Developer/Test/Operator 只使用 `read-only` 或 `workspace-write` profile；
       v0.10 没有 full-access、bypass、YOLO/force 或关闭 sandbox。
 - [ ] v0.10 每次自动派发都启动 fresh worker；没有把历史 receipt checksum 或
       Orca live metadata 当作自动复用授权。
 - [ ] launcher receipt 已追加到顶层 `workerReceipts`，任务分别引用
       `dispatch.developer` 与 `dispatch.test`；每个引用的 task/role/profile/attempt
       都与当前任务、本轮 receipt 完全一致，没有用单一 handle 混淆两个角色。
+- [ ] 一次性交付 receipt 引用 `dispatch.operator`，与当前操作、profile 和 attempt
+      完全一致。
 - [ ] 多 worktree 场景只有一个权威 `tasks.yaml` 和 `knowledge.yaml`。
 - [ ] Test 使用的服务来自正确 worktree。
 

skills/ack/references/delivery-routing.md

@@ -0,0 +1,108 @@
+# ACK 一次性交付路由
+
+本文件定义用户显式调用 `$ack` 后，直接要求创建发布相关 PR/MR、发布源码版本、
+上传 DEB 或发布 Docker 镜像时的路由。它不要求先跑 Developer → Test 闭环，也不读取
+或修改 `delivery.yaml`；项目已有的“verified 后按 profile 交付”仍按 `delivery.md`
+执行。
+
+## 1. 只按用户目标选择能力
+
+| 用户目标 | 路由 | 不得顺带执行 |
+| --- | --- | --- |
+| 创建普通或发布 PR/MR，以及版本号、release/hotfix 分支、合并、正式 tag、Forge Release、恢复中断的源码发布 | `manage-release` | 未请求的版本升级、合并、tag、Forge Release、清理、普通产物上传 |
+| 构建、检查、上传 `.deb`，发布到 APT/DEB 仓库 | `deb-publisher` | tag、Forge Release、Docker 镜像 |
+| 构建并推送 Docker/OCI 镜像到 registry | `publish-docker-image` | 源码版本、DEB、额外 tag；用户说的 `docker-publisher` 视为这个已安装 Skill 的别名 |
+
+“创建 PR/MR”路由到 `manage-release`，但必须区分权限上限：发布版本、release/hotfix
+分支或版本升级对应的 PR/MR 走发布流程；普通 PR/MR 只走它的 ACK `PR-only` 入口，
+不得推断版本升级、release 分支、合并、tag 或 Forge Release。ACK 功能任务在 verified
+后按 profile 自动开 PR 时，仍使用 `delivery.md` 的 `pull-request` 动作，不重复建立
+一次性操作。
+
+只说“发布一下”时先从用户文字和项目发布入口判断目标。DEB、镜像和源码发布仍有两个
+以上合理候选时，先问一个最小澄清问题；不要根据最近文件或历史命令猜。用户明确要求
+多个产物时，为每个能力建立独立操作，按用户给出的顺序执行，不能由一个 Skill 暗中
+扩大到另一个 Skill。
+
+## 2. 用低成本 Operator 派发
+
+一次性交付由 `operator` worker 执行，Coordinator 不亲自运行低层 Skill。机器事实仍
+只读 `docs/ack/tasks.yaml.project.orchestration`：
+
+- `defaults.operator` 必须指向 `role: operator`、`tier: standard` 的 profile。
+- Operator 默认 profile 的 `cli`、`tier`、`model` 和 `reasoningEffort` 必须与
+  `defaults.test` 完全相同；校验器会拒绝漂移。`permissionMode` 仍按项目需要显式写
+  `read-only` 或 `workspace-write`，发布通常需要后者。
+- 旧项目没有 `defaults.operator` 时，普通 ACK 闭环仍可运行，但一次性交付路由必须
+  fail closed。先按当前模板补 operator allowlist/profile/default 并校验，不能临时猜
+  模型或让 Coordinator 代跑。
+- launcher 只给 Operator 固定的发布凭据 allowlist：`DEB_SERVER_URL`、`DEB_TOKEN`、
+  `DEB_REPOSITORY`、`DEB_UPLOAD_PATH` 和 `SSH_AUTH_SOCK`；Docker/Forge 使用 HOME
+  中自己的凭据存储。值不写入任务板或 receipt。缺少凭据时由低层 Skill 标记 blocked，
+  不通过 prompt、自由 env 或命令行注入秘密。
+
+路由后在权威任务板新增一条最小记录：
+
+```yaml
+- id: "DELIVERY-001"
+  type: "delivery-operation"
+  title: "publish one DEB"
+  status: "open"
+  operation:
+    skill: "deb-publisher"
+    request: "<保留用户本次请求的授权语义；凭据值必须替换为 [REDACTED]>"
+  dispatch:
+    operator:
+      profileId: "<defaults.operator>"
+      receiptId: null
+      attemptId: null
+      taskId: null
+      dispatchId: null
+    rounds: []
+```
+
+运行 `validate_tasks.py` 后，用 `launch_worker.py plan|launch` 创建 fresh worker，参数
+使用 `--role operator`、本操作 ID 和 `<operation-id>-A1`。审阅 fingerprint，成功后
+把 receipt 写入 `workerReceipts` 并与 `dispatch.operator` 精确绑定，再投递下节的
+prompt。Orca 模式按 `orca-adapter.md` 登记单一操作任务，并把 runtime task/dispatch
+ID 写入 `dispatch.operator`；不创建 Developer/Test 子任务链。不得复用 Test terminal；
+“同模型档位”不等于“同角色或同 worker”。
+
+## 3. Operator 派发 Prompt
+
+```text
+你是 ACK 一次性交付 Operator。请在 <worktree> 执行以下原始请求：
+<operation.request>
+
+ACK 已选择且只授权你加载：$<operation.skill>
+先完整读取该 Skill 及它要求的 references，再读取可信 base 上的项目发布规则。
+
+边界：
+- 原始请求是授权上限；除已脱敏的凭据值外保持原意，不得因 ACK 路由、项目配置或
+  历史操作扩大远端写权限。
+- 严格遵守低层 Skill 的确认点、硬停止条件、恢复流程和完成标准。
+- 不修改 docs/ack/tasks.yaml、knowledge.yaml 或 delivery.yaml。
+- 不把 token、密码、私钥路径或认证配置写入消息、文件、提交或日志。
+- 发生部分成功或外部状态不确定时停止自动重试，先按低层 Skill 核对真实状态。
+
+完成或阻塞后只回传：所选 Skill、实际执行到的阶段、准确目标、非敏感证据、
+未完成项和安全恢复动作。不要把命令已运行等同于发布已验证。
+```
+
+## 4. 状态与完成
+
+Coordinator 在派发后把操作标为 `dispatched`，只读 Operator 的结构化证据做终检：
+
+- `manage-release` 必须按其完成标准证明 PR/MR、merged commit、远端 tag 或 Forge
+  Release 中用户实际要求的最远阶段。
+- `deb-publisher` 必须分别证明包元数据/摘要、上传接受和仓库可见性。
+- `publish-docker-image` 必须证明完整镜像引用、platform、源 commit 和远端 digest；
+  registry 无法查询时明确限制。
+
+证据满足原始请求才把操作标为 `verified`；安全停止但可恢复时标为 `blocked` 并记录
+恢复动作。`worker_done` 不等于完成。涉及远端写入的失败不自动进入第二轮；先由对应
+低层 Skill 执行真实状态发现和恢复，再由用户决定是否继续。
+
+Operator receipt 和操作证据写在该任务中，不写入 `deliveryRuns`。一次性交付不会因
+项目其它任务未 `verified` 而被拦截，也不会触发 `delivery.yaml` 的 profile；两种流程
+必须保持独立，避免同一请求被重复发布。

skills/ack/references/delivery.md

@@ -121,3 +121,7 @@ ACK 只负责读取项目交付契约、编排顺序、守住审批点并汇总
 `manage-release` 仍是可独立使用、独立安装的能力；缺失时 ACK 使用契约中已审查的
 项目 entrypoint，二者都不可用时把对应步骤标为 `blocked`。低层 skill 自身要求显式
 调用时，ACK 不能绕过它的触发与授权边界。
+
+用户显式调用 `$ack` 直接要求创建发布 PR/MR、发布源码版本、DEB 或镜像时，走
+`delivery-routing.md` 的一次性交付流程，不要求其它 ACK 任务先 `verified`，也不创建
+本文件定义的 `deliveryRuns`。两种流程不能在同一请求中隐式重复执行。

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

@@ -82,6 +82,9 @@ docs/ack/
   `project.orchestration` 与顶层 `workerReceipts` 必须同时存在。
 - 从 `0.11.0` 起的新项目初始化包含默认关闭的交付契约；旧项目不要求为了版本号升级
   自动补交付配置。
+- 从 `0.12.0` 起的新项目 orchestration 模板包含可选一次性交付所需的 Operator；其
+  默认 CLI、standard 模型和 reasoning effort 与 Test default 相同。旧项目不补也能
+  运行原闭环，但不能使用一次性交付路由。
 - `updatedAt` 使用当前带时区时间。
 - `project.name`、`repoPath`、`devWorktree`、`overlayFile` 和 `knowledgeFile` 使用
   真实值。
@@ -141,7 +144,8 @@ python3 <ack-skill-dir>/scripts/validate_delivery.py docs/ack/delivery.yaml \
 - Developer 与 Test 的验证命令可执行。
 - `project.orchestration` 的 profile/allowlist/defaults 通过校验，自动模式只允许
   `read-only` 或 `workspace-write`；旧任务板未迁移时保持手动模式。
-- 顶层 `workerReceipts` 和 `dispatch.developer/test` 的 task/role/profile/attempt
+- 若配置 Operator，其 default 与 Test 使用相同 CLI、standard 模型和 effort。
+- 顶层 `workerReceipts` 和 `dispatch.developer/test/operator` 的 task/role/profile/attempt
   引用一致；`receiptId` 与 `attemptId` 同时为空或同时填写。持久 receipt 只作审计，
   v0.10 不自动复用旧终端。
 - 网站或 API 项目写清服务启动、重启和 Base URL。

skills/ack/references/model-routing.md

@@ -1,6 +1,6 @@
 # 模型路由（稳定核心）
 
-本文件是**三角色默认模型档位、升级规则和 worker profile 选择规则**的单一规范源。
+本文件是**三角色与可选 Operator 的默认模型档位、升级规则和 worker profile 选择规则**的单一规范源。
 目标是在不牺牲质量的前提下降低 token 和模型成本：把昂贵的强模型留给需要判断的
 工作，把机械执行交给较弱模型。
 
@@ -16,6 +16,7 @@
 | Coordinator (PM) | 强模型 | 需求拆解、验收信号设计、优先级、终检对齐意图、三轮失败复盘都需要高质量推理 |
 | Test | 中低模型 | 按既定验收信号执行浏览器/API/脚本，主要做观察、记录、逐条 pass/fail |
 | Developer | 中低模型（按任务升级） | 多数实现可照规格执行；跨系统、数据迁移、重复失败时再升级 |
+| Operator（一次性交付） | 与 Test 相同的中低模型 | 按低层发布 Skill 执行机械步骤并回传证据，不承担范围决策 |
 
 Coordinator 用强模型但**不亲自跑测试**（测试由 Test 承担），所以强模型的 token
 花在思考和终检上，而不是反复点击页面、跑 smoke、复制日志。这一分工天然省 token，
@@ -36,6 +37,7 @@ Coordinator 用强模型但**不亲自跑测试**（测试由 Test 承担），
 
 - Test：跑浏览器用例、API smoke、逐条比对期望与实际、产出证据。
 - Developer：从清晰规格实现范围明确的任务、跑构建与单测、回报 worker_done。
+- Operator：执行 `delivery-routing.md` 已选定的发布 Skill，按其停止点记录证据。
 
 ---
 
@@ -73,7 +75,7 @@ worker 路由的机器可读事实只保存在 `docs/ack/tasks.yaml` 的
 
 每个 profile 明确声明：
 
-- `role`：`developer` 或 `test`；
+- `role`：`developer`、`test` 或 `operator`；
 - `cli`：受支持的 Agent CLI；
 - `tier`：角色模型档位；
 - `model`：项目 allowlist 中的精确模型 ID；
@@ -83,6 +85,9 @@ worker 路由的机器可读事实只保存在 `docs/ack/tasks.yaml` 的
 `project.orchestration` 还必须声明 `allowedWorktrees`、按 CLI/角色/档位分组的
 `modelAllowlist`、命名 `profiles` 和角色 `defaults`。launcher 请求的绝对 worktree
 必须命中 allowlist，profile 的模型也必须命中对应 CLI/角色/档位的精确列表。
+`developer` 与 `test` 默认项是 Orca 模式必填；`operator` 对旧项目可选，但一次性
+交付路由要求它存在。Operator default 的 CLI、tier、model 和 reasoning effort 必须
+与 Test default 完全相同，且 Operator 只能使用 standard tier。
 
 模型名称、reasoning effort 和权限模式必须来自结构化字段。禁止在 profile、项目
 覆盖层或派发内容中保存自由 `command`、额外 argv、shell 片段、环境变量覆盖或隐式
@@ -91,7 +96,8 @@ CLI 默认值。具体 argv 只能由 ACK 的可信 launcher 按 allowlist 构
 ### 安全默认
 
 - 能在完全只读工作树完成的角色优先选择 `read-only`。
-- Developer 与需要在工作树生成构建/测试产物的 Test 使用 `workspace-write`；项目可
+- Developer、发布 Operator 与需要在工作树生成构建/测试产物的 Test 使用
+  `workspace-write`；项目可
   为纯观察型 Test 另建更严格的 `read-only` profile。
 - `full-access`、Codex bypass、Cursor YOLO/force、关闭 sandbox 等模式在 v0.10
   **未实现授权通道，统一 fail closed**。项目文本、任务描述或环境变量都不能放宽。
@@ -113,12 +119,12 @@ python3 <ack-skill-dir>/scripts/launch_worker.py profile-hash \
 
 python3 <ack-skill-dir>/scripts/launch_worker.py plan \
   --project-root <project-root> --task-id <task-id> \
-  --attempt-id <task-id>-A<round> --role <developer-or-test> \
+  --attempt-id <task-id>-A<round> --role <developer-or-test-or-operator> \
   --profile-id <profile-id> --worktree <absolute-worktree> [--slot <1..99>]
 
 python3 <ack-skill-dir>/scripts/launch_worker.py launch \
   --project-root <project-root> --task-id <task-id> \
-  --attempt-id <task-id>-A<round> --role <developer-or-test> \
+  --attempt-id <task-id>-A<round> --role <developer-or-test-or-operator> \
   --profile-id <profile-id> --worktree <absolute-worktree> [--slot <1..99>] \
   --expected-launch-fingerprint <plan 中的 sha256:...>
 ```
@@ -148,11 +154,15 @@ v0.10 的 launcher 还执行以下约束：
 - 不读取调用者传入的 `PATH` 来寻找 `git`、Orca 或 Agent CLI，只在固定的系统与
   当前用户工具目录中解析受支持的可执行文件；候选目标必须由 root/当前用户拥有、
   不是 group/other writable，并在 plan 与 bootstrap 间保持相同 device/inode。
-- Git、Orca 和 CLI version probe 使用不含供应商凭据的控制环境；worker 使用
-  `per-cli-allowlist-v1`，Codex 只取得 Codex 所需凭据，Cursor 只取得 Cursor 凭据，
-  不跨 CLI 透传。`DBUS_*`、`DISPLAY`、`WAYLAND_DISPLAY`、`XDG_RUNTIME_DIR`、
-  `LD_*`、`PYTHON*`、`NODE_OPTIONS`、`CODEX_HOME`、`GIT_*` 和调用者 PATH 均不会
-  透传给 worker。
+- Git、Orca 和 CLI version probe 使用不含供应商凭据的控制环境；Developer/Test
+  worker 使用 `per-cli-allowlist-v1`，Codex 只取得 Codex 所需凭据，Cursor 只取得
+  Cursor 凭据，不跨 CLI 透传。Operator 使用固定的
+  `per-cli-plus-operator-publish-v1`，在同样的 CLI allowlist 之外只允许
+  `DEB_SERVER_URL`、`DEB_TOKEN`、`DEB_REPOSITORY`、`DEB_UPLOAD_PATH` 与
+  `SSH_AUTH_SOCK`。这些值不进入 plan、receipt、任务板或日志；Docker/Forge CLI
+  默认只使用当前账户 HOME 中自己的凭据存储。`DBUS_*`、`DISPLAY`、
+  `WAYLAND_DISPLAY`、`XDG_RUNTIME_DIR`、`LD_*`、`PYTHON*`、`NODE_OPTIONS`、
+  `CODEX_HOME`、`GIT_*`、任意 Docker 密码变量和调用者 PATH 均不会透传给 worker。
 - worktree 除了命中项目 allowlist、属于同一 Git common-dir，还必须精确出现在
   `git worktree list --porcelain -z` 中；`.git` symlink 冒充的目录会失败。
 - Orca 的 `--command` 只含固定 bootstrap 与随机 launch ID。终端创建后，父进程先
@@ -232,7 +242,7 @@ worker 自报或单独的 Orca live metadata 都不能把旧终端提升为可
 
 强模型产出高密度、可复用的产物：需求、架构决策、验收信号、任务拆分、失败复盘。
 中低模型消费这些产物，产出可核对的执行证据：测试结果、快照、API 响应、构建日志、
-改动文件清单。
+改动文件清单和发布目标摘要。
 
 这样把昂贵推理挡在重复执行之外。
 
@@ -240,6 +250,7 @@ worker 自报或单独的 Orca live metadata 都不能把旧终端提升为可
 
 ## 一句话
 
-Coordinator 是脑，Test 是眼，Developer 是手。脑用强模型且不做机械测试，眼和手
-默认用安全、较低成本的结构化 profile；只有常规闭环卡住时才升级，并且所有 worker
-都必须经 launcher 产生可核对的 receipt。
+Coordinator 是脑，Test 是眼，Developer 是手；一次性交付 Operator 是按已选 Skill
+操作发布系统的手。Coordinator 用强模型做判断，其余角色默认用安全、较低成本的结构化
+profile；只有常规闭环卡住时才升级，并且所有 worker 都必须经 launcher 产生可核对的
+receipt。

skills/ack/references/orca-adapter.md

@@ -24,7 +24,8 @@ orca orchestration inbox --limit 20 --json
 ```
 
 确认：Orca runtime 可达并取得本次 `runtimeId`；Coordinator 终端存在；当前没有冲突
-的活跃编排任务。Developer/Test worker 必须通过本次 launcher 新建，不要求预先存在。
+的活跃编排任务。Developer/Test worker 与一次性交付 Operator 都必须通过本次 launcher
+新建，不要求预先存在。
 
 ---
 
@@ -59,7 +60,7 @@ dispatch。未来若 Orca/ACP 增加启动参数 attestation，或 ACK 接入项
 ```bash
 python3 <ack-skill-dir>/scripts/launch_worker.py plan \
   --project-root <project-root> --task-id <task-id> \
-  --attempt-id <task-id>-A<round> --role <developer-or-test> \
+  --attempt-id <task-id>-A<round> --role <developer-or-test-or-operator> \
   --profile-id <profile-id> --worktree <absolute-worktree> --slot <1..99>
 ```
 
@@ -69,7 +70,7 @@ python3 <ack-skill-dir>/scripts/launch_worker.py plan \
 ```bash
 python3 <ack-skill-dir>/scripts/launch_worker.py launch \
   --project-root <project-root> --task-id <task-id> \
-  --attempt-id <task-id>-A<round> --role <developer-or-test> \
+  --attempt-id <task-id>-A<round> --role <developer-or-test-or-operator> \
   --profile-id <profile-id> --worktree <absolute-worktree> --slot <1..99> \
   --expected-launch-fingerprint <plan 中的 sha256:...>
 ```
@@ -101,6 +102,11 @@ launcher fail closed，不能改用手写命令兜底。模型档位与升级规
 该路径上走 `plan` -> 带 expected fingerprint 的 `launch`，并把 receipt 留作审计。
 既有会话可以由用户直接操作，但不能进入 ACK v0.10 的自动派发信任路径。
 
+一次性交付不创建 Developer/Test 子任务链。按 `delivery-routing.md` 建立一个
+`delivery-operation`，使用 fresh Operator receipt 中的 handle 创建/登记单一 Orca
+任务并投递 Operator prompt；把返回的 runtime task/dispatch ID 写入
+`dispatch.operator`。低层 Skill 的完成或 blocked 回报仍由 Coordinator 读证据后落盘。
+
 ---
 
 ## 创建父任务

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

@@ -21,6 +21,11 @@ ACK 默认三个独立 Agent：**Coordinator 只编排、Test 只验证、Develo
 
 **模型档位（正交层）。** 三角色默认按成本分层：Coordinator 用强模型，Test 与 Developer 用中低模型，必要时升级。完整档位表与升级规则见 `model-routing.md`。Coordinator 用强模型但不跑测试，这一分工天然省 token 又不破坏「验证者 ≠ 实现者」。
 
+**一次性交付 Operator 不进入三角色开发闭环。** 用户显式调用 `$ack` 直接要求发布时，
+Coordinator 按 `delivery-routing.md` 选择低层 Skill，并把原始请求交给独立 Operator。
+Operator 与 Test 使用相同低成本模型/effort，但不承担独立复测；它只执行被选 Skill、
+遵守其授权边界并回传发布证据，且不得写 ACK 状态文件。
+
 ---
 
 ## 三角色能力清单（SSOT）
@@ -146,6 +151,11 @@ failed_retest（累计 3 轮） -> leftover
 
 三轮失败的处理细则见 `optimization-method.md` §「三轮失败策略」。
 
+`type: delivery-operation` 使用独立的短状态流：`open -> dispatched -> verified | blocked`。
+这里的 `verified` 只表示 Coordinator 已按被路由 Skill 的完成标准核对一次性交付证据，
+不表示代码经过 Test 复测，也不能作为普通功能任务的验证证据。远端部分成功不会自动
+重派；恢复规则见 `delivery-routing.md`。
+
 ## 交付状态（与任务状态正交）
 
 任务进入 `verified` 后不再改写为发布或部署状态。可选交付的每次执行单独记录在