refactor(skills): slim ack/builder/deployer for layered loading

Move mode-specific steps into references so SKILL.md only keeps routing and fail-closed rules.

skills/ack/SKILL.md

@@ -1,97 +1,58 @@
 ---
 name: ack
 description: >-
-  初始化、检查并运行 ACK 三角色协作闭环。仅在用户显式调用 /ack 或 $ack，并要求
-  初始化 ACK、检查 .pouch/ack 配置、按 ACK 规划需求或修复 bug、指挥
-  Coordinator/Developer/Test 工作，配置测试环境与发版方式，重新部署测试环境
-  （内部调用 deployer），发布版本，或运行回归测试时使用。
+  初始化、检查并运行 ACK 三角色闭环。仅在用户显式调用 /ack 或 $ack，并要求
+  初始化 ACK、检查 .pouch/ack、按 ACK 做需求或修 bug、指挥
+  Coordinator/Developer/Test、配置或运行测试环境与发版、或跑回归时使用。
 ---
 
 # ACK 项目协作入口
 
-本 Skill 是 ACK 的完整能力包：`references/` 保存通用规范，`templates/` 保存项目
-状态模板，`scripts/` 保存校验工具。目标项目只在 `.pouch/ack/` 保存 `project.md`、
-`tasks.yaml`、`knowledge.yaml`、默认关闭的 `delivery.yaml` 和空的
-`regression.yaml`，不要复制或链接 Skill 内容。
+项目只在 `.pouch/ack/` 保存 `project.md`、`tasks.yaml`、`knowledge.yaml`、
+`delivery.yaml` 和 `regression.yaml`。不要复制 Skill 内容，不要修改 `AGENTS.md`、
+`CLAUDE.md`。
 
-开始时解析当前 `SKILL.md` 所在目录，记为 `<ack-skill-dir>`。所有通用规范、模板和
-脚本都相对此目录访问，不依赖固定的全局安装路径。
+开始时解析当前 `SKILL.md` 所在目录为 `<ack-skill-dir>`。优先
+`git rev-parse --show-toplevel` 作为项目根。
 
 ## 选择模式
 
-- 用户要求初始化、接入或安装 ACK：执行“初始化”。
-- 用户要求检查 ACK 是否可用、配置是否完整：执行“检查”。
-- 用户要求用 ACK 做需求、修复 bug 或继续任务：执行“工作”。修 bug 不写大 PRD；
-  飞书收件仍走本模式。
-- 用户用自然语言说明怎么部署测试环境、怎么发布版本，或要求增加、修改、关闭交付
-  流程：执行“交付配置维护”。测试环境绑定 deployer，发版写在同一份
-  `.pouch/ack/delivery.yaml`。
-- 用户要求部署、重新部署测试环境，或按已配置方式开始测试：执行“运行测试环境”。
-  内部加载 deployer skill，不在 ACK 里复制 compose/rsync 命令。
-- 用户要求发布版本：执行“运行版本发布”。
-- 用户要求回归、跑回归测试：执行“运行回归”。先布测试环境，再派 Test 按
-  `.pouch/ack/regression.yaml` 用浏览器或 API 执行。
+- 初始化、接入 ACK：执行「初始化」。
+- 检查配置是否完整：执行「检查」。
+- 做需求、修 bug 或继续任务：执行「工作」。修 bug 不写大 PRD。
+- 增改关闭交付、说明怎么布测试环境或发版：执行「交付配置维护」。
+- 部署或重布测试环境：执行「运行测试环境」（加载 deployer，不复制 compose）。
+- 发布版本：执行「运行版本发布」。回归：执行「运行回归」。
+- 任务板使用 Orca 时，编排命令见 [orca-adapter.md](references/orca-adapter.md)。
 
-始终先解析真实项目根目录。优先使用 `git rev-parse --show-toplevel`；不是 Git
-项目时使用用户指定目录或当前目录。不要修改项目的 `AGENTS.md`、`CLAUDE.md`
-或其它 Agent 指令文件。
+## 边界
+
+- 不覆盖已有 `.pouch/ack`；除用户确认的任务或 delivery profile 外，不擅自提交、推送、创建终端、新 worktree、发布或部署。
+- 不猜测命令、地址、worker handle 或模型名；无法确定写 `n/a`。
+- 不把完整 `tasks.yaml` / `knowledge.yaml` / `regression.yaml` 注入上下文；用对应 `select_*.py`。写回前跑完整校验。
+- 只有 Coordinator 写任务板、知识库、回归目录、`deliveryRuns` 和 `regressionRuns`。`delivery.yaml` 只在「交付配置维护」中改。见 [roles-and-permissions.md](references/roles-and-permissions.md)。
+- 知识检查只经 `run_verification.py` 的 registry ID；不把知识正文拼成 shell。
+- 自动 worker 禁止 full-access、bypass、关闭 sandbox、Grok `--yolo` / bypassPermissions。OMP `--approval-mode yolo` 只用于 OMP 审批（workspace-write → yolo，read-only → always-ask），禁止 `--auto-approve`，不适用于其它 backend。
+- 无清理证明不复用 worker；无密钥 `receiptHash` 或 Orca live metadata 不能授权复用。当前 Orca 走 fresh。`indeterminate` / `reconcile required` 不直接重试。
+- 产品失败才占三轮；环境失败写 `environmentIncidents`。见 [optimization-method.md](references/optimization-method.md) §4。
 
 ## 初始化
 
-1. 确认 `pouch` 可执行，并检查 `<project>/.pouch/ack` 是否存在。
-2. 不存在时执行：
+1. 确认 `pouch` 可执行。`.pouch/ack` 不存在则 `pouch init ack --project <project-root>`；已存在则不覆盖、转入「检查」。
+2. 按 [init-new-project.md](references/init-new-project.md) 完善项目状态。不从 README/CI 猜测并启用交付或知识；初始化 **不** 自动初始化 deployer 或 builder。
+3. 运行：
 
-   ```bash
-   pouch init ack --project <project-root>
-   ```
+```bash
+python3 <ack-skill-dir>/scripts/validate_tasks.py .pouch/ack/tasks.yaml
+python3 <ack-skill-dir>/scripts/validate_knowledge.py .pouch/ack/knowledge.yaml \
+  --tasks .pouch/ack/tasks.yaml
+python3 <ack-skill-dir>/scripts/validate_delivery.py .pouch/ack/delivery.yaml \
+  --tasks .pouch/ack/tasks.yaml --project-root <project-root>
+python3 <ack-skill-dir>/scripts/validate_regression.py .pouch/ack/regression.yaml \
+  --tasks .pouch/ack/tasks.yaml
+```
 
-   该命令从本 Skill 的 `templates/` 生成项目状态，不会在项目中创建 Skill
-   软链接或资源副本。
-3. 如果 `.pouch/ack` 已存在，不重复初始化、不覆盖文件；转入“检查”。旧项目只有
-   `project.md` 与 `tasks.yaml` 时，先报告缺少 `knowledge.yaml`。用户授权后，
-   从 `templates/knowledge.template.yaml` 生成这个缺失文件并替换项目名和时间；若
-   `tasks.yaml` 尚无 `project.knowledgeFile`，同时只补
-   `.pouch/ack/knowledge.yaml` 这一项。不要重跑 `pouch init`，也不要改写其它已有
-   项目状态。
-4. 读取项目的公开配置和文档，例如 README、语言清单、包管理清单、测试配置与
-   CI，确定项目名、技术栈、源码/规格/测试路径及真实可执行命令。
-5. 完善 `.pouch/ack/project.md`：
-   - 用实际项目值替换全部占位符。
-   - 无服务地址时把 Base URL 写为 `n/a`，不要虚构端口。
-   - 无法从项目证据确定的命令写为 `n/a`，并在结果中列为待配置项。
-   - 只写项目差异，不复制 `references/` 中的通用规范。
-6. 完善 `.pouch/ack/tasks.yaml` 的项目信息。纯初始化且用户没有提供真实任务时，
-   删除模板示例任务并保留 `tasks: []`；不要虚构需求或缺陷。
-   项目状态固定从当前项目根的 `.pouch/ack/` 推导，不写入 `repoPath` 或 `devWorktree`；
-   worker 默认在 `--project-root`（权威状态目录）工作，不再配置
-   `allowedWorktrees` 白名单（v0.19 起废弃）；需要隔离 worktree 时由 Coordinator 在
-   派发时显式指定。旧任务板中的 `repoPath`、`devWorktree` 仅兼容读取。
-7. 检查 `.pouch/ack/knowledge.yaml`。新项目没有已验证的项目经验时保留
-   `verificationRegistry: {}` 与 `entries: []`，不从聊天、README 或单次失败中
-   猜测并激活知识。
-8. 检查 `.pouch/ack/delivery.yaml`。新项目保留 `enabled: false`、空能力表和空 profile；
-   不从 README 或 CI 猜测、启用交付。旧项目没有该文件时仍可继续使用原 ACK
-   闭环；只有用户明确要求配置交付时，才按“交付配置维护”补齐。
-9. 检查 `.pouch/ack/regression.yaml`。新项目保留 `cases: []`。旧项目没有该文件时仍
-   可继续原闭环；用户授权后从 `templates/regression.template.yaml` 生成，并只补
-   `project.regressionFile` 与顶层 `regressionRuns: []`。不要从聊天虚构用例。
-10. 更新 `updatedAt`，并运行：
-
-   ```bash
-   python3 <ack-skill-dir>/scripts/validate_tasks.py .pouch/ack/tasks.yaml
-   python3 <ack-skill-dir>/scripts/validate_knowledge.py .pouch/ack/knowledge.yaml \
-     --tasks .pouch/ack/tasks.yaml
-   python3 <ack-skill-dir>/scripts/validate_delivery.py .pouch/ack/delivery.yaml \
-     --tasks .pouch/ack/tasks.yaml --project-root <project-root>
-   python3 <ack-skill-dir>/scripts/validate_regression.py .pouch/ack/regression.yaml \
-     --tasks .pouch/ack/tasks.yaml
-   ```
-
-11. 检查 `project.md`、`tasks.yaml`、`knowledge.yaml`、`delivery.yaml` 与
-    `regression.yaml` 是否仍有 `<...>` 占位符。
-12. 按下面格式报告。结构校验通过且必填项目事实完整时才称「完成」；否则称
-    「部分完成」或「阻塞」并列出待配置项。除非用户明确要求，不提交、不推送。
-    初始化 ACK **不**自动初始化 deployer 或 builder。
+4. 检查上述文件是否仍有 `<...>` 占位符。结构校验通过且必填项目事实完整才称「完成」。除非用户明确要求，不提交、不推送。
 
 ```text
 ## ack 初始化：完成 | 部分完成 | 阻塞
@@ -104,237 +65,42 @@ description: >-
 
 ## 检查
 
-1. 检查以下路径：
-   - `.pouch/ack/project.md`
-   - `.pouch/ack/tasks.yaml`
-   - `.pouch/ack/knowledge.yaml`
-   - `.pouch/ack/delivery.yaml`（旧项目可无；存在或被任务板引用时必须校验）
-   - `.pouch/ack/regression.yaml`（旧项目可无；存在或被任务板引用时必须校验）
-   需要查看任务内容时，使用 `<ack-skill-dir>/scripts/select_tasks.py` 解析完整任务板并
-   只输出项目配置、摘要和可工作任务；不要用 `cat`、整文件 `sed` 或等价方式把完整
-   `tasks.yaml` 注入上下文。完整性仍由校验器检查。
-2. 读取 `<ack-skill-dir>/VERSION`，对比 `tasks.yaml` 的 `ackVersion`。旧项目只有
-   `kitVersion` 时仍可读取，但建议迁移为 `ackVersion`。`ackVersion` 必须是合法
-   SemVer；从 `0.10.0` 起 `project.orchestration` 与顶层 `workerReceipts` 必须同时
-   存在。
-3. 查找未替换占位符，并核对项目根、覆盖层路径、Developer 白盒命令、Test
-   黑盒命令和 Base URL。
-4. 使用 `<ack-skill-dir>/scripts/validate_tasks.py` 校验任务板，使用
-   `<ack-skill-dir>/scripts/validate_knowledge.py .pouch/ack/knowledge.yaml --tasks
-   .pouch/ack/tasks.yaml` 校验项目知识和跨文件引用。如果存在交付配置或任务板声明了
-   `project.deliveryFile`，再使用 `<ack-skill-dir>/scripts/validate_delivery.py
-   .pouch/ack/delivery.yaml --tasks .pouch/ack/tasks.yaml --project-root <project-root>`
-   校验交付能力、顺序、安全边界和跨文件引用。如果存在回归目录或任务板声明了
-   `project.regressionFile`，再使用 `<ack-skill-dir>/scripts/validate_regression.py
-   .pouch/ack/regression.yaml --tasks .pouch/ack/tasks.yaml` 校验用例与跨文件引用。
-   只报告证据明确的问题，不因旧项目缺少可选交付或回归配置而宣称失败。
-5. 若存在 `project.bugIntake`，运行
-   `python3 <ack-skill-dir>/scripts/feishu_bug_intake.py check .pouch/ack/tasks.yaml`。
-   它只接受 `feishu-base` 和显式 profile；详细的飞书配置、凭据初始化和读取方式见
-   `references/feishu-bug-intake.md`。
-6. 检查知识引用能解析到固定 revision，candidate 仍留在任务证据中，且
-   `stale`、`superseded` 和 `archived` 不会被当作可派发的 `active` 知识。
-7. 若存在 `project.orchestration`，检查 profile、model allowlist、默认 profile、
-   允许 worktree、顶层 `workerReceipts` 与 `dispatch.developer/test` 的引用；receipt
-   必须绑定当前 ACK task、同一 role/profile/attempt，`receiptId` 与 `attemptId`
-   必须同时为空或同时填写。
-   缺少结构化路由的旧任务板只能使用手动模式，不能自动创建 worker。
-8. 检查不会自动修复或覆盖现有配置；用户明确要求修复后再修改。
-9. 若 `delivery.yaml` 已把 `intents.testEnvironment` 写成 `{via: deployer, env: <env>}`，
-   只读运行已安装 deployer skill 的 `scripts/deploy/check.py --project <project-root>`。
-   未通过时列入待配置，加载 deployer skill 的「检查」说明；不要在 ACK 里复制
-   compose/rsync 命令，也不要静默初始化 deployer。
-10. 用与「初始化」相同的报告格式，标题改为 `## ack 检查：…`。
+只读，不自动修复。核对清单见 [adoption-checklist.md](references/adoption-checklist.md)。用 `select_tasks.py` 看配置；跑与「初始化」相同的四个校验器。对比 `VERSION` 与 `ackVersion`（旧 `kitVersion` 仍可读）；从 `0.10.0` 起 `project.orchestration` 与 `workerReceipts` 必须同时存在。旧项目可无 delivery/regression，存在或被引用时必须校验。若有 `bugIntake` 再跑 `feishu_bug_intake.py check`。若测试环境走 deployer，只读跑其 `check.py`；未通过列入待配置，不要复制 compose 或静默初始化 deployer。用同一报告格式，标题改为 `## ack 检查：…`。
 
 ## 工作
 
-1. 若 `.pouch/ack` 不存在，停止并建议先用 `/ack` 初始化；不要静默初始化。
-2. 依次读取：
-   - `.pouch/ack/project.md`
-   - 运行 `python3 <ack-skill-dir>/scripts/select_tasks.py .pouch/ack/tasks.yaml`，只读取
-     `project`、`summary` 和默认可工作状态的任务；已知当前任务时传
-     `--task-id <ack-task-id>`。选择器会解析并校验完整任务板，并只附带选中任务引用的
-     receipt 与 delivery run。命中超过默认预算时用 `--task-id` / `--status` 缩小，
-     不直接回退为输出完整 `tasks.yaml`。
-   - 通过 `<ack-skill-dir>/scripts/select_knowledge.py` 从
-     `.pouch/ack/knowledge.yaml` 选择的当前任务相关 `active` 条目
-   - `<ack-skill-dir>/references/kickoff.md`
-   - kickoff 指定且与当前任务相关的 references 文件
-   - 若 `tasks.yaml.project.deliveryFile` 存在，再读取该 `delivery.yaml` 和
-     `<ack-skill-dir>/references/delivery.md`
-   - 若 `tasks.yaml.project.regressionFile` 存在，再读取该 `regression.yaml` 和
-     `<ack-skill-dir>/references/regression.md`
-3. 当前会话担任 Coordinator，遵守项目覆盖层中的命令、路径权限、模型路由和
-   worker 启动规则。项目覆盖层优先于通用示例命令。按 scope 推荐相关 `active`
-   知识，经确认后把固定 revision 的显式 `knowledgeRefs` 写入当前任务上下文；
-   不全量注入知识库。
-   `project.bugIntake.workflow` 为 `clarified-writeback-v1`（推荐）或
-   `reviewed-writeback-v1`（兼容旧项目）时，按
-   `references/feishu-bug-intake.md` 把飞书作为审核前的唯一协作区：先运行 check/plan，
-   读取用户填写的 Bug。新工作流中，用户只维护标题、详细描述和附件；Coordinator 根据
-   来源事实与项目上下文整理问题说明、期望效果和可观测验收标准，不在收件箱写修复逻辑，
-   只通过安全适配器写回同一飞书记录并回读确认。用户反馈后继续只在飞书修订。
-   用户针对当前 `draftRevision` 明确审核通过并亲自在飞书把状态改为 `已确认` 前，不创建
-   或刷新 `tasks.yaml` 任务、不启动 worker、不派发 Developer/Test，也不修改应用代码。
-   Coordinator 不得自行写入 `已确认`。审核通过后重新读取，要求 revision 与批准值完全
-   一致，才通过 `import-approved` 生成规范 `taskDraft`，原样写入最终版本、
-   `source.workflow`、`source.approvedRevision` 与 `source.approvedPayloadHash`；校验器重算
-   payload hash 通过后，再用 `mark-imported` 把最终任务 ID 与同一 revision 写回飞书，
-   才进入三角色闭环。未声明 workflow 的旧八字段配置只按
-   `read-only-v1` 兼容，不得写回；
-   标题、详细描述和附件是来源事实，不得把 Coordinator 推断伪装成用户原文；整行空白
-   记录按批次 warning 跳过。
-   按每条记录的 `sourceRef` 去重：仅 `open` 任务可刷新描述；
-   `dispatched`、`fixed_by_dev`、`retesting`、`failed_retest`、`verified`、`blocked` 和
-   `leftover` 只报告来源漂移，绝不覆盖；来源消失或读取失败时绝不删除已有任务。
-4. 新需求先写产品文档、任务拆分与可观测验收信号，更新 `tasks.yaml` 并校验，
-   然后交给用户确认。修 bug 写短问题说明、复现步骤和可观测验收，不写大 PRD；
-   Developer 先补会失败的用例再修。若启用了交付，必须默认把 `defaultProfile`、
-   目标、停止点和需要审批的步骤放入同一份计划，不能静默省略。用户可明确取消
-   本轮交付；确认前不派发实现，也不执行交付。
-5. 创建或更换 worker 时，只使用
-   `<ack-skill-dir>/scripts/launch_worker.py plan|launch` 读取
-   `tasks.yaml.project.orchestration` 的 profile。不得直接执行
-   `orca terminal create --command`，不得接受或拼接自由 command、额外 argv、
-   executable、env 或 cwd。必须先审阅 `plan.launchFingerprint`，再把它作为
-   `launch --expected-launch-fingerprint` 传入。派发前先寻找同一 ACK 运行内的空闲
-   worker；只有角色、profile、worktree 和启动身份仍完全匹配，且后端能清理历史消息、
-   返回可核对的新会话身份时才复用。不得复用正在工作、等待回报或状态不明的 worker；
-   任一条件不符、清理能力不存在或无法确认清理成功时创建 fresh worker。持久化
-   receipt 只作审计与 dispatch 关联，不能单独授权复用。当前 Orca 终端接口不能提供
-   可验证的历史消息清理，因此使用 Orca 时仍走 fresh worker。
-6. 用户已确认的任务按 ACK 闭环执行：Developer 实现与白盒验证；若
-   `intents.testEnvironment` 已启用，Coordinator 先按「运行测试环境」拉起服务，再
-   派 Test 独立黑盒复测。派发后先确认 worker 真正开始执行（terminal read 确认任务
-   注入；卡在审批提示、未回车或额度限制时按环境失败处理并报告），等待期间用
-   `scripts/worker_probe.py` 滚动检查活性，不盲等 `worker_done`。Coordinator 读取
-   证据终检并唯一写入 `tasks.yaml`。Developer 回报 `knowledgeApplied` 和
-   `knowledgeCandidates`，Test 回报 `knowledgeChecks` 和 `regressionCandidates`；
-   `candidate` 只有在独立验证和 gate 后才能由 Coordinator 写入或激活。
-   任务进入 `verified` 且改了用户可见行为或 API 后，按 `references/regression.md`
-   给出新增/更新/退役/无回归四选一，用户确认后写入 `.pouch/ack/regression.yaml`，
-   并把 case id 记入 `regressionRefs`。Test 只提名，不写该文件。
-7. 执行知识项的 `verification.ref` 时，只调用
-   `<ack-skill-dir>/scripts/run_verification.py .pouch/ack/knowledge.yaml
-   <verification-ref> --project-root <project-root>`。不要直接执行选择器返回的 path/args，
-   也不要给 runner 注入额外命令或参数。
-8. 不把 `worker_done` 或 Test 自报成功直接当作完成。三轮预算只计算 Test 已对齐正确
-   服务、数据和工具后实际执行验收所得的产品失败；环境失败不占复验轮次，不写
-   `failed_retest`，而写入 `dispatch.environmentIncidents`。Coordinator 先做一次有界、
-   安全的恢复；事件未解决、需要用户动作或会阻断本轮时，立即向用户报告原因、影响、
-   已尝试动作、下一恢复动作和明确的 `userAction`；即使已自动恢复，也要在最终报告汇总。
-   每项最多三轮有效产品复验，仍失败才记录 `leftover` 并继续其它任务。细则见
-   `references/optimization-method.md` §4。
-9. 关键的安全、正确性和兼容性约束应下沉为测试、lint、CI 或正式规范；
-   `knowledge.yaml` 只保存触发条件、原因与证据引用，不能替代可执行控制。
-10. 选定任务全部进入 `verified` 后，若 `delivery.enabled: true` 且用户确认的本次计划
-    包含交付，按 `references/delivery.md` 顺序执行 profile，并由 Coordinator 把证据
-    写入 `tasks.yaml.deliveryRuns`。任务状态保持 `verified`；交付失败只改变 delivery
-    run，不回写成任务失败。开发或测试环境完成构建、部署和健康检查后写
-    `validation_ready`，并把访问地址、验证范围和用户下一步交给用户；不能停在
-    `verified` 却声称整轮 ACK 已结束。默认 profile 最多到 `validation_ready` 或
-    `review_ready`，稳定发布和生产部署必须在对应步骤再次取得明确批准。
-11. Coordinator 最后标记整轮任务完成后，用 `scripts/reclaim_workers.py` 先
-    dry-run 审阅决策，再 `--apply` 回收所有只属于 `verified` 任务的 worker
-    终端，并核对关闭回执；历史 receipt 和任务证据继续保留。任何还被 `open`、`dispatched`、`fixed_by_dev`、
-    `retesting`、`blocked`、`failed_retest`、`leftover` 或未解决环境事件引用的终端
-    都保留，不设置 TTL，也不能因为同一终端还关联过 `verified` 任务而误关。若关闭
-    结果不确定，记录并报告，不重复关闭或伪报已回收。
+1. `.pouch/ack` 不存在：停止并建议先 `/ack` 初始化；不要静默初始化。
+2. 读 `project.md`；用 `select_tasks.py`（已知任务加 `--task-id`）和 `select_knowledge.py` 取当前任务相关 `active` 条目。超预算时缩小选择，不回退为完整 yaml。
+3. 新需求或尚未确认的计划：读 [kickoff.md](references/kickoff.md)。修 bug 写短问题说明、复现和可观测验收，不写大 PRD。
+4. 用户已确认后按 [closed-loop.md](references/closed-loop.md) 执行。当前会话担任 Coordinator，不亲自写代码或跑测试。
+5. 存在 `project.bugIntake` 时先完成「飞书收件」。创建或更换 worker 走「启动 worker」。若 `intents.testEnvironment` 已启用，派 Test 前先走「运行测试环境」。
+6. 知识 `verification.ref` 只经 `run_verification.py`。不把 `worker_done` 或 Test 自报成功当作完成。环境失败先有界恢复并报告 `userAction`；三轮产品失败记 `leftover`。
+7. 任务 `verified` 且改了可见行为或 API 后，转入「运行回归」收获用例。若本次计划含交付，再走对应交付模式；默认最多到 `validation_ready` 或 `review_ready`。
+8. 整轮完成后 `reclaim_workers.py` 先 dry-run 再 `--apply`，只回收仅属于 `verified` 任务的 worker。关闭结果不确定则记录，不伪报。
+
+## 飞书收件
+
+若存在 `project.bugIntake`，读 [feishu-bug-intake.md](references/feishu-bug-intake.md)。用户针对当前 `draftRevision` 明确审核通过并亲自把飞书状态改为 `已确认` 前：不创建或刷新任务、不启动 worker、不派发、不改应用代码。Coordinator 不得自行写入 `已确认`。未声明 workflow 的旧配置只按 `read-only-v1`，不得写回。来源消失或读取失败时不删除已有任务。
+
+## 启动 worker
+
+只使用 `scripts/launch_worker.py plan|launch`。不得直接 `orca terminal create --command`，不得拼接自由 command、argv、executable、env 或 cwd。读 [model-routing.md](references/model-routing.md)。先审阅 `plan.launchFingerprint`，再作为 `launch --expected-launch-fingerprint` 传入。派发文案用 [prompt-templates.md](references/prompt-templates.md)。派发后 terminal read 确认已开始；卡在审批、未回车或额度限制按环境失败处理。等待期间用 `scripts/worker_probe.py`，不盲等 `worker_done`。
 
 ## 交付配置维护
 
-1. 读取 `references/delivery.md`、deployer skill、模板、schema、现有
-   `delivery.yaml`、项目构建/发布入口和 CI。测试环境写成
-   `intents.testEnvironment: {via: deployer, env: <env>}`。若
-   `.pouch/deployer/<env>` 不存在或 deployer `check.py` 未通过：停止，加载
-   deployer skill 的「初始化」，不要在 ACK 里复制 compose/rsync 命令。发版仍指向
-   本文件的 profile。不要拆成第二份文档。配置只引用仓库内脚本或声明式工具
-   target，不保存 shell。本地 `npm run dev` / `go run` 写在 `project.md` 的
-   Developer 白盒命令里，不算测试环境部署。
-2. 若旧项目首次启用，生成 `.pouch/ack/delivery.yaml`，在 `tasks.yaml.project` 增加
-   `deliveryFile: .pouch/ack/delivery.yaml`，并增加顶层 `deliveryRuns: []`；不改写其它
-   项目状态。首次生成保持 `enabled: false`，先展示 diff 和解析出的执行顺序。
-3. 运行 delivery、tasks 和跨文件校验；需要的脚本不存在、不可执行、引用不完整或
-   涉及凭据正文时 fail closed。凭据只写 secret 名称，值由外部环境提供。
-4. 用户确认后才把配置设为启用。配置修改只影响下一次 delivery run；已确认或正在
-   执行的 run 使用开始时审阅的 commit/config revision 快照，不能借当前分支修改
-   扩大权限。
+读 [delivery.md](references/delivery.md)。测试环境写成 `{via: deployer, env: <env>}`；`.pouch/deployer/<env>` 未就绪则停止并加载 deployer「初始化」，不在 ACK 里复制 compose。发版写在同一份 `delivery.yaml`，不保存 shell。本地 `npm run dev` / `go run` 不算测试环境。旧项目首次启用只补文件指针与 `deliveryRuns: []`，保持 `enabled: false`，用户确认后才启用。进行中的 run 使用开始时的 commit/config 快照。
 
 ## 运行测试环境
 
-1. 读取 `.pouch/ack/delivery.yaml`、`references/delivery.md` 和 deployer skill 的
-   `SKILL.md`。
-2. `enabled` 不为 true，或 `intents.testEnvironment` 为 null：停止，请用户说明如何
-   部署测试环境，转入交付配置维护。不猜测编译或启动命令。
-3. `intents.testEnvironment` 必须是 `{via: deployer, env: <env>}`。若仍是旧的
-   profile ID 字符串：停止，展示迁移说明，转入交付配置维护。不要执行 ACK
-   delivery profile 来布测试环境。
-4. 不要求任务已 `verified`。按 deployer 的项目内环境布局操作
-   `.pouch/deployer/<env>`：list 确认服务，再按服务 sync + up（或用户要求的
-   recreate），并用 ps/logs/健康检查验证。不要复制 deployer 脚本，不要发明
-   第二套 compose 命令。
-5. 把访问地址交给用户或随后的 Test 黑盒。证据写入 `deliveryRuns`，
-   `intent: testEnvironment`，`profile` 记 `deployer-<env>`，`taskIds` 可为空。
-6. 派发 Test 前若该 intent 已启用，必须先完成本步骤。deployer 未安装、环境目录
-   不存在或 `check.py` 未通过：停止，加载 deployer skill 的「初始化」，报告
-   `userAction`，不把环境失败写成产品失败，也不要在 ACK 里发明 compose 命令。
-   健康检查失败同样 fail closed。
+读 `delivery.yaml` 与 [delivery.md](references/delivery.md)，并加载 deployer。`enabled` 非 true 或 intent 为 null：停止，转入交付配置维护。intent 必须是 `{via: deployer, env: <env>}`；旧 profile ID 字符串要先迁移。不要用 ACK delivery profile 布环境，不猜测启动命令。不要求任务已 `verified`。对 `.pouch/deployer/<env>` 按 deployer：list → 按服务 sync+up → 健康检查。证据写入 `deliveryRuns`（`intent: testEnvironment`，`profile: deployer-<env>`）。未安装、缺目录、`check.py` 失败或健康检查失败：fail closed，报告 `userAction`，不记产品失败。
 
 ## 运行回归
 
-1. 若 `.pouch/ack` 不存在，停止并建议先初始化。
-2. 若没有 `.pouch/ack/regression.yaml` 或 `project.regressionFile`：停止，用户授权后
-   从模板生成空文件并只补任务板指针与 `regressionRuns: []`。
-3. 用 `scripts/select_regression.py` 读取 active 用例（默认 `--suite smoke`；用户
-   指定 full 或 case id 时缩小范围）。没有命中用例时停止并说明先收获用例。
-   不要把完整 `regression.yaml` 注入上下文。细则见 `references/regression.md`。
-4. 先执行「运行测试环境」。
-5. 当前会话担任 Coordinator：按 Test profile 启动独立 Test worker，派发回归清单、
-   Base URL 和每条 case 的 surface/steps/expected。Coordinator 不亲自点浏览器或
-   打 API。
-6. Test 按 `surface` 执行：`browser` 必须走真实交互，不得改成只打 API。逐条对照
-   `expected` 回报。环境失败记环境事件，不记产品失败。
-7. Coordinator 终检后写入 `regressionRuns`。失败只报告，不自动派 Developer，不占
-   任务三轮预算。用户明确要求修复时再按修 bug 为每条失败开任务。
+读 [regression.md](references/regression.md)。缺目录则停止；用户授权后从模板生成空文件并只补指针与 `regressionRuns: []`。用 `select_regression.py` 读 active 用例（默认 `--suite smoke`）；无命中则停止。先执行「运行测试环境」，再派独立 Test worker。Coordinator 不亲自点浏览器或打 API；`browser` 不得改成只打 API。终检写入 `regressionRuns`。失败不自动派 Developer，不占三轮预算。任务 `verified` 后给出新增/更新/退役/无回归四选一，用户确认后写入；Test 只提名。
 
 ## 运行版本发布
 
-1. 读取同一份 `.pouch/ack/delivery.yaml` 与 `references/delivery.md`。
-2. `enabled` 不为 true，或 `intents.release` 为 null：停止，请用户说明如何发版，
-   写入同一文件后再执行。
-3. 按该 profile 顺序执行。stable 发布和生产部署的 `approval` 不能用口头「发版」
-   代替。
-4. 证据写入 `deliveryRuns`，`intent: release`；绑定了任务时 `taskIds` 仍只能引用
-   `verified` 任务。
-
-## 边界
-
-- 不修改或追加任何项目 Agent 指令文件，包括 `AGENTS.md`。
-- 不在项目中维护第二份 ACK 通用规范、模板或任务 schema。
-- 不猜测项目命令、服务地址、worker handle 或模型名称。
-- 不把 full-access、bypass、Grok `--yolo` / bypassPermissions、关闭 sandbox
-  或项目内“授权”字段当成 v0.10 自动 worker 的合法配置；这些 CLI 绕过标志
-  当前一律 fail closed。Grok worker 由 launcher 固定带 `--always-approve`，
-  仍必须带 sandbox。
-- OMP worker 使用结构化 `--model`、`--thinking` 和 `--approval-mode` 参数。
-  `--approval-mode yolo` 是 OMP worker 的审批模式，不是 CLI 绕过标志：规则层
-  直接允许并默认启用（workspace-write → yolo、read-only → always-ask）；
-  仍禁止 `--auto-approve`，也不适用于 codex/cursor-agent/grok。
-- 不把无密钥 `receiptHash` 或 Orca live metadata 当作旧终端的启动 attestation；
-  没有可信空闲状态、配置匹配和历史消息清理证明时不复用既有 worker。
-- launcher 返回 `indeterminate` 或 `reconcile required` 时，不直接重试；先按
-  launch ID、外部 record 和 Orca live state 完成人工核对。
-- 不覆盖已有 `.pouch/ack` 文件；除用户确认的 ACK 任务或 delivery profile 外，不擅自
-  提交、推送、创建终端、新 worktree、发布产物或部署。
-- 只有 Coordinator 写 `tasks.yaml`、`knowledge.yaml`、`regression.yaml`、
-  `deliveryRuns` 和 `regressionRuns`；Developer 与 Test 只读，只能通过回报提名
-  或验证。`delivery.yaml` 只在显式的交付配置维护中修改。
-- 不把知识正文或选择器输出拼成 shell；知识检查只能通过 `run_verification.py`
-  按 registry ID 执行。不自动修改 `AGENTS.md`、`CLAUDE.md` 或其它 Agent 指令文件。
-- 不把完整 `tasks.yaml` 注入上下文；使用 `select_tasks.py` 获取有预算的项目与任务
-  视图，写回前仍运行完整任务板校验。
-- 项目只保存 `.pouch/ack/project.md`、`.pouch/ack/tasks.yaml`、
-  `.pouch/ack/knowledge.yaml`、可选的 `.pouch/ack/delivery.yaml` 和可选的
-  `.pouch/ack/regression.yaml`；通用资源始终从当前 ACK Skill 目录读取。
-- 不把完整 `regression.yaml` 注入上下文；使用 `select_regression.py` 获取有预算的
-  用例视图，写回前仍运行完整校验。
+1. 读同一份 `delivery.yaml` 与 [delivery.md](references/delivery.md)。
+2. `enabled` 不为 true，或 `intents.release` 为 null：停止，先做交付配置维护。
+3. 按该 profile 顺序执行。stable 发布和生产部署的 `approval` 不能用口头「发版」代替。
+4. 证据写入 `deliveryRuns`，`intent: release`；绑定了任务时 `taskIds` 仍只能引用 `verified` 任务。