来源、父级与授权链

本 Issue 由 2026-08-15 的 clean-slate 迁仓，从冻结的老仓 Eridanus117/agent-control#31（摩擦：Orca 高层启动与低层 Dispatch） 迁入。

原 Issue 的全部评论、决定回执与证据链继续在老仓可读，本仓不复制。授权与父级沿用原 Issue，未扩大。老仓自迁仓日起 archive（只读），不再写入。

范围

见下方「原正文（逐字迁入）」。迁入时未修改范围；正文中对老仓的引用一律为完整 URL。

验收条件

见下方原正文。原正文未显式列出验收条件时，以老仓原 Issue 的成功条件为准（链接见上）。

原正文（逐字迁入）

摩擦模式：Orca 高层 Worker 与低层 Dispatch 生命周期断裂

Parent 与模式键

• Parent：agent-control#27。
• 历史证据：agent-control 摩擦：所有 Agent 共用一个 GitHub 账号，授权链无法辨认发言者 #21、方案：P0-2 生命周期可重入收口（待三方审阅） #25、调研：规则与 Skill 体系复杂度收敛 #26 及其交付评论。
• 模式键：高层 worker-start 无法解析已登记 repo／worktree，低层 agent-first worktree + dispatch --inject 可以运行；但高层 worker-show／worker-read／worker-release、低层 heartbeat／worker_done 与资源生命周期不能稳定识别同一 Dispatch。

累计证据

该模式已经跨多个 Run 和 Orca 版本重复：

• 高层 worker-start 至少 4 个运行批次返回 selector_not_found，目前均在创建资源前安全失败；同仓和跨仓都已复现。
• 低层 worktree／terminal／Dispatch 能交付，但 worker-show、worker-read、worker-release 多次返回 dispatch_not_found。
• 调研：规则与 Skill 体系复杂度收敛 #26 父目标复核中，dispatch-show 可见 capability hash，普通 status／Delivery 可用；同一终端的 heartbeat 和 worker_done 却被拒绝为 dispatch_capability_invalid（capability missing）。被拒绝的 worker_done 正文仍进入 Delivery，但 Task／Dispatch 不能正常 settle。
• 一次 dispatch --inject 返回成功后，Claude 终端仍停在等待提示；协调者追加同范围唤醒才真正开始执行。

精确历史总次数未重新全量复算；当前事实足以说明这是稳定模式而不是一次故障。

已交付行为与剩余缺陷

orchestrated-collaboration 0.1.5 已三端安装，交付的是后端中立的安全人工收口规则：高层优先；低层完成不等于生命周期结束；先读标准释放回执；有恢复动作必须照做；没有恢复动作时只有远端持久化、干净工作树、精确身份和连带影响四项证明齐全，才精确关闭整个 tab／删除 worktree；缺证明时保留，禁止 force。

这减少资源泄漏与误删风险，但没有修复 Orca 底层 selector、capability 或高低层对象发现。不能把“人工绕过可用”写成“生命周期缺陷已解决”。

当前稳定运行方式

1. 高层 Worker 路径只尝试一次；无副作用 selector_not_found 后不枚举同类 selector。
2. 降级时用精确 repo 建 agent-first worktree，等待 TUI 可接受输入，再建立 Task／Dispatch；dispatch --inject 后必须从终端行为或 heartbeat 确认任务真的开始，不能只信返回码。
3. 监督优先使用 task-list、dispatch-show、check --wait 与有界 terminal read；完整 Delivery 处理后立即 ack，避免旧批次重放遮蔽新结果。
4. 结果先持久化到 GitHub；heartbeat／worker_done 被拒绝时保留拒绝回执与 Delivery 正文，不伪造 settled。
5. 标准 worker-release 失败后，严格按 0.1.5 的恢复动作与四项证明处理资源；精确关闭、无 force、删除后重读列表。

影响与优化边界

影响：中到高。当前没有数据丢失，但每个 Worker 增加路径选择、唤醒、监督、Delivery 确认和资源收口成本，降低并发净收益并增加中心 Session 依赖。

该模式已达到优化比较门。后续可比较：向 Orca 上游提交带版本与最小复现的 Issue；在现有 Skill 中继续维护窄适配；若上游长期不能修复且自然成本继续放大，再比较 Fork、薄适配器或替换后端。当前不自动公开上游 Issue、不 Fork Orca、不建设新调度器或自有 UI；这些仍需要负责人产品决定。

后续事件与关闭条件

评论记录 Run／Task／Dispatch、Orca App 与 CLI 版本、selector、失败副作用、低层路径、heartbeat／worker_done、读取／释放结果、遗留资源和人工恢复成本。上游或本地方案交付后，在 3 次真实 Dispatch 中不再需要双路径人工恢复，且终端／worktree 可按合同自动或单步收口，再请求关闭。产品采用和长期依赖仍单独决定。

合同压缩：2026-08-11；由当前正文、全部事件和 orchestrated-collaboration 0.1.5 当前交付事实生成。评论保留为审计轨迹。