/multi-agent-orchestration

Orca-first Worker Backend

配合 SKILL.md §4 阅读。版本：v2.28.0（2026-09-24）。

目录

1. 先加载版本匹配指南
2. 双层能力模型
3. Runtime 与 CLI 检测
4. 启动与共享 Run
5. Supervised 生命周期
6. PM 实时感知
7. UI 与状态来源
8. 四后端与自定义 argv
9. 失败与恢复
10. METADATA 契约

1. 先加载版本匹配指南

Orca CLI 与 orchestration contract 会随 runtime 更新。每个新会话先运行：

orca skills get orca-cli
orca skills get orchestration   # 仅监督/等待/DAG/ask-reply 场景
orca status --json

若 ORCA_CLI_COMMAND 已设置就使用其值；开发版用 orca-dev；Linux 的非 Orca terminal 用 orca-ide；其他平台用 orca。脚本通过 scripts/orca-runtime.sh 固化这一选择。

2. 双层能力模型

不要把 terminal-managed 描述成 supervised。terminal create 成功只证明终端存在；task-list + dispatch-show 才证明编排来源。

3. Runtime 与 CLI 检测

旧版用 TERM_PROGRAM=Orca + ORCA_WORKTREE_ID 判断，会在真实 Orca 会话未注入这些变量时误回落，甚至在 set -u 下崩溃。v2.3 改为：

1. 从 PROJECT_DIR 求 git toplevel。
2. 在该目录执行 orca worktree current --json。
3. 比较 .result.worktree.path 与项目 toplevel。
4. 验证 status 含 terminal.multiplex.v1；supervised 另验 orchestration.contract.v1。

--no-orca-mode 显式改走 tmux；跨 repo 不误触发 Orca；Orca 模式不把 tmux 当硬依赖。

仓库自动注册与授权边界（v2.10.3，2026-09-01 实测事故）

事故形态：仓库是有效 Git 仓、Orca runtime 健康，但 repo 未注册进 Orca——worktree current --json 只返回 {ok:false,error:{code:"selector_not_found"}}，Orca 模式被静默降级为 tmux；手工 orca repo add --path <canonical 路径> --json 注册后 worktree current 立即返回精确主 worktree，Orca worker 派发恢复可用。

当前行为（orca-runtime.sh + detect_orca_mode）：

1. orca_runtime_current_project 失败时把原因暴露为 ORCA_WORKTREE_CURRENT_ERROR：selector_not_found（未注册）、path_mismatch（命中别的仓/路径）、空（runtime 不可达 / 非 Git / 输出不可解析）。
2. 仅当错误码精确等于 selector_not_found 时，调用 orca-register-project.py：在 Git common-dir 的 mao-orca-register.lock 普通文件上有界互斥，并在锁内重新读取 worktree current；其他 helper 已注册则复用。只有锁内仍明确未注册、canonical Git toplevel 可证明且 orca status --json 可达时，才执行一次 repo add。要求明确 ok:true/repo.id，再在同一锁内复验精确路径和 repo 身份，才继续 Orca 模式（版本/capability 预检照常）。
3. 默认锁等待 5 秒、每次 CLI 调用 10 秒；使用 Python 标准库，不另安装系统 flock。锁文件必须是当前用户的私有普通文件；symlink、FIFO、hardlink、未知/损坏内容均拒绝，不删除重建所谓陈旧锁。
4. mutation 前写入并 fsync pending。请求超时、回执丢失或复验失败不证明服务端没执行：保留 pending，后续没有精确身份则返回 registration_prior_outcome_unknown，不再 add。已有 acknowledged repo.id 时还必须一致。初始只读 probe 可复用精确身份但不清标记；注册 helper 在锁内证明身份后才清空标记内容，锁文件保留。PM 对未知结果先只读调查，不通过删锁或清标记“重试修复”。
5. 注册失败或身份不符 → 诊断并回退既有 tmux 检测路径，绝不假装 Orca 管理成功；不因此跳过其他启动门禁。全部检查发生在 branch/worktree/provider 副作用之前。--dry-run 只打印计划，不创建注册/锁文件。

授权边界：调用 Orca-first worker 路径（spawn-worker.sh 自动检测、未传 --no-orca-mode）即授权把「当前这一个 Git 仓库」注册进 Orca；不授权移动/克隆/删除仓库、不授权改动其他 Orca 项目或全局配置。repo 已注册、--no-orca-mode、非 Git、runtime 不可达、其他错误码（含 path_mismatch）一律不注册。互斥只协调本机采用此 helper 的同一 Git common-dir，不约束 UI、其他客户端或独立 clone，也不自动治理既有重复注册。回归见 scripts/test-orca-auto-register.sh 与 scripts/test_orca_registration_concurrency.py；后者使用真实进程/锁与 fake CLI，不代表真实 Orca mutation 已验证。

4. 启动与共享 Run

先把同一 Wave 写成 manifest，并在任何 worker 启动前创建/绑定一个 Run、预建全部 Task：

cat > /tmp/wave.json <<'JSON'
{"objective":"完成 Wave 1 的两个独立任务","tasks":[
  {"key":"a","title":"worker-a","spec":"任务 A 的范围、验证与完成条件"},
  {"key":"b","title":"worker-b","spec":"任务 B 的范围、验证与完成条件"}
]}
JSON
bash scripts/orca-wave-prepare.sh --manifest /tmp/wave.json --receipt /tmp/wave-receipt.json
WAVE_RUNTIME_ID=$(jq -er '._meta.runtimeId' /tmp/wave-receipt.json)

receipt 成功后才可并行启动；每个 supervised worker 传同一个 Run/coordinator 和自己的 Task：

bash scripts/spawn-worker.sh \
  --project "$PROJECT" \
  --branch feat/worker-a \
  --session worker-a \
  --command "$AGENT_COMMAND" \
  --worker-backend claude-code \
  --orca-supervised \
  --orca-run-id "$RUN_ID" \
  --orca-coordinator-handle "$COORDINATOR_HANDLE" \
  --orca-runtime-id "$WAVE_RUNTIME_ID" \
  --orca-task-id "$TASK_A_ID"

orca-wave-prepare.sh 给每个 Task spec 的第一段前置强制完成协议，并把 run_id/coordinator_handle/task_id 写入 receipt。spawn-worker.sh 使用 worktree create --setup skip：repo Setup 会早于 Session Context、安装门禁和 scope hook，因此不能继承或强制执行。显式 --orca-setup-mode inherit|run 会在任何 worktree/provider/terminal/Dispatch 副作用前以 ORCA_SETUP_REQUIRES_PRELAUNCH_AUTH_CONTRACT 拒绝；即使同时提供 --allow-install-command 也不放行，因为后者只约束门禁已就位后的 worker 阶段。之后再写入 Session Context 与机械门禁，用 terminal create 启动 Agent 并等待 TUI ready，随后让 orca-supervised-register.sh 直接执行 worker-start --terminal。预建 Task 路径不再调用 run-use/task-create，因此可安全并行启动；supervised 路径也不发送普通 prompt，避免同一任务被执行两次。

terminal wait 的退出码0不保证就绪。启动 helper 要求单个 JSON 回执的顶层 ok=true，以及布尔型 result.wait.satisfied=true；回执出现的 handle/condition 必须匹配本轮终端及 tui-idle。先捕获退出码再解析：退出0允许有效布尔回执，原生退出1仅允许 ok=true / satisfied=false；退出1却返回true或退出码大于1均拒绝。首次等待30s返回 false 时（退出0或合法退出1），仅在同一 handle 再等待60s；畸形/失败回执立即停止，两次仍未就绪则非0退出，不投递、不宣布启动完成，保留终端与工作树并打印精确身份。恢复或清理前先只读核查该终端，不能因 metadata 尚未写入 handle 推断终端未创建。经已有 terminal 注册的 supervised 也必须通过此门禁后才能执行唯一的 worker-start。显式 ZCode native 路径不先创建 terminal：全部 MAO 门禁通过后直接由 worker-start --agent zcode 创建并等待首次 composer，然后注入唯一 Task；版本、可信环境桥和回执核对见 原生 ZCode Orca。

当前不采用 worktree create --agent。该命令会在原子创建时立即启动 Agent，早于本 Skill 写入机械门禁，形成未受保护的启动窗口。只有 Orca 支持预置文件或延迟 Agent 启动后，才能安全切换 agent-first；这项取舍优先保证权限顺序，而不是仅减少 fallback terminal。

Run receipt 中的 coordinator handle 是 consumer fencing 身份，不等同于 Run ID。Wave prepare 使用 --from <本轮PM终端>；没有显式 sender、也没有 session 绑定的新 Run 才可把宿主 ORCA_TERMINAL_HANDLE 作为待核 selector。统一 helper 核对 status、terminal show 与 run-current 的同一 runtime、精确 handle/Run/coordinator，以及终端 connected/writable/非 orphaned/无 exitCause。环境值和 runtime 相同都不是活性证明，不从当前焦点选择别人终端。

Wave helper 将冻结 handle 作为 --from 传给全部 task-create；worker helper 复用它传给 worker-start。单 worker 在 quota/mem 通过后、provider lease/worktree/session/terminal 创建前准备 Run；有 Run/Task 的 Wave 只读验证，不重绑或重复创建 Task。失败可能已经建立或重绑 Run，必须先只读核查现有结果，不盲试；零 Worker 资源不等于零 Run 记录。

receipt 同时冻结 _meta.runtimeId，新 Wave 按上例传入 --orca-runtime-id；手工 register 使用 --runtime-id。prepare 前后、spawn 早期、terminal 创建前及每次 worker-start 前检查可观察到的身份漂移；metadata 另存 .session.orca.runtime_id。旧上下文缺 runtime 时，统一 helper 只能从当前 status/terminal/Run 三方正向核验后冻结，并声明历史连续性 NOT_VERIFIED；已有非空 runtime 漂移即拒绝，显式 --from 也不绕过。consumer fencing 仍作最终判断；该前置核验不扩展为直接独立 register legacy 入口已全面迁移。回归见 scripts/test_pm_sender_binding.py 与既有 runtime 身份测试；真实重启期间派发未由其证明。

若不传 --orca-run-id，helper 为单 worker 新建 Run，适合独立监督；多 worker Wave 不应各建一个 Run。

5. Supervised 生命周期

固定顺序：

PM create/bind Run
  → 在任何 worker 启动前创建全部 Task
  → worker-start（注入 live preamble + TASK；不同 worker 可并行）
  → worker 工作；必要时 ask/heartbeat
  → worker 从自己的 terminal 发送且只发送一次 worker_done
  → PM check --wait 收到完整 Delivery
  → PM 处理每条消息并决定 reuse / release / retain
  → PM ack Delivery

硬边界：

• Worker 必须使用 preamble 注入的 task/dispatch ID；不得猜 ID。
• spawn-worker.sh 自动向 register 传 PM 冻结的 --authority-receipt；直接调用 orca-supervised-register.sh 时该参数现在必填，且须使用该次启动真实生成的 authority receipt，不可从可写 METADATA 临时换一个路径。缺失或非法时在 worker-start 前拒绝。内部 --metadata-file 只供 pm-orchestrate reauthorize 在已核对原始 receipt、runtime、session、worktree、branch 与目标文件无软链后轮换既有 registration；它不是普通手动 register 的替代入口。显式 --agent zcode 新建路径另外使用 --metadata-file 定位尚无 terminal 的本次 Session Context，并绑定可信请求与原生 created 回执；不能借此放宽既有 replacement 的身份校验。
• recover-unconfigured-worker.sh 从真实 Git common-dir 和已校验 session 推导该次既有 receipt，核对身份后才允许注入/重绑；缺失、软链、metadata 改址或身份错配时要求人工处理，不新建 receipt 冒充旧启动授权。
• worker-start 后的 completion receipt 位于相同 agent-authority 目录，绑定 authority 路径与 SHA-256、task/dispatch/terminal/run/runtime、process incarnation 及 capability SHA-256，不保存 capability 明文。发送时以启动快照读取 receipt，并通过只读 dispatch-show 复核当前身份；元数据不能成为新权威，精确 Shell allowlist 也不能覆盖完成校验失败。reauthorize 轮换既有 receipt 时先保留私有回滚副本，只有 METADATA 原子写回成功才提交替换；写回失败必须恢复旧 receipt，让仍存活的旧 Worker 保持原完成权限。这是 hook 权限边界，不是同一 OS 用户之间的安全沙箱，最终 mutation 仍由 Orca 验证。
• preamble 中反斜杠续行的 worker_done 是合法命令形态，应原样执行。首次 ORCA_COMPLETION_AUTHORITY_INVALID 后停止并报告协议阻塞，不换引号、编码、子进程或 wrapper/helper 重试；PM 按精确 Dispatch 检查，不根据 STATUS 强行结算。
• Worker 的 Shell 门禁只对严格语义白名单放行 Orca 自报告协议：send 仅允许 worker_done/heartbeat/escalation，并校验真实 task/dispatch、subject/body/outcome；ask 必须在新问题与原 message ID resume 中二选一且 bounded timeout，resume 不得带新 options；check 只允许已绑定 Worker handle 的 consuming default、bounded wait，或对同一 Worker inbox 已处理 Delivery 的 ack，不允许 peek/all/unread 冒充处理，也不能指定 coordinator handle。reply、coordinator Delivery ack、task-update、worker-stop、群发目标、缺 outcome 或 shell chaining 一律拒绝，最终仍由 Orca runtime 验证 live Dispatch。
• STATUS.json=done 只唤醒 PM，不结算 Task/Dispatch。
• Sentinel 不得因 STATUS、timeout、idle、heartbeat、question 或 escalation 执行 worker-stop / worker-release / terminal close。
• PM 只对 accepted、settled 的 worker 执行 release；要保留排障就显式 retain；有立即后续任务可复用同一 terminal。
• check --wait 返回一个 Delivery；处理全部消息再 ack，并继续等到全部预期 Dispatch settle。
• PM 的 mutation/wait/accounting 命令会先 run-use --id 把调用终端重新绑定为 coordinator，并刷新 METADATA 中的 handle；后续 check 消费当前绑定 Run，不再传陈旧 --run。
• pm-run-bind.sh 将 handle probe/run-use 畸形响应视为失败（exit 1），run-current 不可验证或身份不匹配返回 exit 2；绑定未知时先检查原始响应，不盲目重试。远端分支清理绑定预期 OID 做原子比较删除，较新 tip 不会被删除；远端失败可能发生在本地资源已回收之后，须保留并处理 remote-pending 结果，不能声称整组资源均已保留或清空。

5.1 Worker 问答与跟进收件

阻塞问题必须从 live preamble 复制 Orca executable、worker handle 与 Dispatch capability：

orca orchestration ask --from "$WORKER_HANDLE" --dispatch-capability "$CAPABILITY" \
  --question "需要 PM 回答的问题" --options "A,B" --timeout-ms 600000 --json

# timeout/cancel/断线后只恢复原 message ID；不再创建新 question
orca orchestration ask --from "$WORKER_HANDLE" --dispatch-capability "$CAPABILITY" \
  --resume "$MESSAGE_ID" --timeout-ms 600000 --json

ask 是 Worker 与 PM 的阻塞问答，不是 coordinator-owned Task DAG decision gate。超时或断线不会取消原问题；只有 resume 返回成功 answer receipt 才证明已收到答复，仍不证明后续动作已经执行。

PM 的 send --to dispatch:<id> 只保证 durable enqueue，且不会自动打断 Worker。Worker 必须在开始下一个文件前、每次 scoped test 后和 worker_done 前执行：

orca orchestration check --terminal "$WORKER_HANDLE" --json

这是 Worker inbox 的 consuming check；禁止用 --peek/--all/--unread 代替。先处理返回 Delivery 的全部消息，再用输出的 delivery ID 推进同一 Worker inbox：

orca orchestration check --terminal "$WORKER_HANDLE" --ack "$WORKER_DELIVERY_ID" --json

ack 调用可能直接返回下一批；继续处理、ack，直到 count=0。这个权限由 Shell 门禁绑定 Worker 自己的 handle，不可改用 coordinator handle，因此不是 coordinator Delivery ack。没有 non-peek Delivery 及其处理/ack 回执，只能说消息已入队或可见，不能声称 Worker 已处理。返回 consumer_fenced（consumer generation/进程身份被替换）或 dispatch_inactive（原 Dispatch 已 settled、stopped 或不再 active）时立即停止，不发 worker_done、不重试 check；其他 guidance 仍受原任务与权限边界约束。发出 worker_done 后停止收件和新工作。

6. PM 实时感知

统一用 pm-orchestrate.sh：

# 精确会话读取：优先 Agent transcript，无法证明时 Orca 返回 terminal fallbackReason
bash scripts/pm-orchestrate.sh read --worktree "$WT" --session worker-a --lines 80

# alternate-screen TUI 首读完整历史，之后保存返回的 nextCursor 增量读取
bash scripts/pm-orchestrate.sh read --worktree "$WT" --session worker-a \
  --lines 5000 --cursor 0

# Dispatch/Task/terminal 状态
bash scripts/pm-orchestrate.sh show --worktree "$WT" --session worker-a

# 结构化纠偏，不向 TUI 重复注入任务
bash scripts/pm-orchestrate.sh send --worktree "$WT" --session worker-a --text "只修复测试失败，不扩大范围"

# 等 worker_done / escalation / question；timeout 只是 checkpoint
bash scripts/pm-orchestrate.sh wait --worktree "$WT" --session worker-a --timeout 900

# 回答问题
bash scripts/pm-orchestrate.sh reply --worktree "$WT" --session worker-a \
  --message-id "$MESSAGE_ID" --text "按方案 A"

# 结算 terminal 后再 ack Delivery
bash scripts/pm-orchestrate.sh release --worktree "$WT" --session worker-a
bash scripts/pm-orchestrate.sh ack --worktree "$WT" --session worker-a --delivery-id "$DELIVERY_ID"

这比轮询 tmux pane 更适合 PM：worker-read 可读取 Orca hook 证明的 Agent transcript，check --wait 只在结构化事件到来时唤醒，UI 同时展示 worktree/branch/terminal。

terminal-managed 的 terminal wait --for tui-idle 只是 liveness/readiness 信号。实测 CodeBuddy 在界面仍显示等待模型时也可返回 idle；Qoder 的默认 tail 只见 spinner，而 --cursor 0 能读到完整历史。因此不得用 idle 或空 tail 判断完成。

7. UI 与状态来源

supervised 的 STATUS done 只把 workspace 标为 in-review；PM 验收并结算后再把 UI 状态改为 completed。

8. 四后端与自定义 argv

Orca terminal 对 --command 是开放的，但 spawn-worker.sh 只允许 Claude Code、Codex、CodeBuddy、QoderWork CN 四种 backend。Claude 第三方 provider wrapper 与 Codex 自定义参数属于这四种 backend 的 argv 变体，不构成新的 backend。

原生 orchestration 的 worker-start --terminal 只接受 Orca 能证明的 Agent session。若某 CLI 未被识别：

1. 保留 terminal-managed 模式，不回落到 tmux。
2. PM 仍可 terminal read/send/wait，并在 UI 看 worktree/branch。
3. 不创建虚假的 Dispatch，不要求 worker 发送 worker_done。
4. 若用户必须要原生 Task/Dispatch，改用 Orca 支持的 Agent launcher，或等待 Orca 增加该 Agent 识别。

实测边界：CodeBuddy 可以在 terminal read 中看到完整响应；Qoder 可启动、通过 cursor history 读取，但当前 Orca 1.4.180 未把它识别为 agent。OpenCode/custom 等旧实验资料不在当前派发白名单内，不得据此调用 spawn-worker.sh。

9. 失败与恢复

• worker-start 非零或结果未知：保留原始 receipt 的 requestId/failedStage/stage/effects/residualResources/recovery/runtimeId，以及精确 Run、Task、Dispatch、terminal/incarnation/worktree。空 title、timeout、TUI idle 和心跳不能证明孤儿或业务完成。
• 先只读 request-show --request <id>、dispatch-show --task <task>、worker-show --dispatch <dispatch> 与具名 worker-list --run <run>。request completed 读取原结果；pending 先确认原命令是否仍在飞，再依同一 request 的恢复指令处理；absent 不是零副作用证明，先核现场。不得换新 Run/Task 盲重试，也不双发已被终端接受但提交未确认的输入。
• 原生 worker-start 在 agent ready 前失败仍可能拥有已创建 terminal，按 receipt/fleet 的精确 reclaimable 资源调用 worker-release，不手工 terminal close。release_pending/release_unknown 依精确 recovery 继续；exit 0 不是回收完成证明。已接受 worker_done 后先验收，reuse/retain/release 后再 ack。
• 只有已证明 failed/stopped 的重试才使用原 Task、--retry-of 和显式 placement；遵守重试熔断，不靠复位 ready 或新 Run 绕过。2026-08-30 曾有慢冷启动失败与复用终端重试成功的现场记录，不作为所有版本的通用恢复命令。当前合同以 orca skills get orchestration --reference references/recovery-and-cleanup.md 与对应 --help 为准；旧 host 缺字段时不猜。
• terminal handle stale：只读重新定位后，还须证明 owner、同一资源及 incarnation/状态，不能仅取列表中的新 handle 接管。未知/活跃/不匹配资源保留并上报。
• check --wait timeout / count=0：这是 rolling wait checkpoint，不是 worker failed。
• active/unknown Dispatch 的文件清理：clean-worktree.sh --execute fail-closed；不要用 worktree rm 代替生命周期处理。清理器必须从 METADATA.session.orca.supervised.run_id 取得权威 Run，以 worker-list --run <run> --limit 100 遍历全部 opaque cursor，并且只接受在同一 Run 中唯一出现的目标 Dispatch。前置查询出现缺页、空/循环游标、scope/run 漂移、读取失败、目标缺失或重复时，在 worker-release、terminal close、worktree rm 和分支删除前停止；不得回退到无 --run 的默认 fleet 页。reclaimable release 后的同一查询若失败，只能说明 release 可能已发生，仍必须停止 terminal、worktree 和分支后续 mutation。只读 worker-show/dispatch-show 与 diff/tests 只能用于观察/业务验收，不能结算 Dispatch。
• Dispatch 死锁兜底（Task-047R，settle）：若 worker 进程已死但未发 worker_done，用 pm-orchestrate settle --worktree <WT> --session <S> --reason "..." [--force] [--destroy]：
  1. 校验 METADATA.project 与 worker 的 Git common dir 一致，并先把 reason 写入 common-dir NDJSON 审计；不可写则拒绝 mutation。
  2. 只有 observation.status=exited|missing 且 worker.state=succeeded|failed|stopped 通过；缺字段、active 与未知未来值默认拒绝。
  3. 调 worker-stop --dispatch <D> 原子 fence+stop。失败时仅尝试一次 worker-abandon 作非破坏性 fence 兜底，然后返回 2 并保留 worktree；不得继续 destroy。
  4. 默认不删文件。显式 --destroy 只在 stop 成功后释放 lease、执行 Orca worktree rm，再用完整路径匹配 Git registration 做 fallback；任何失败都 fail-loud。
  5. 审计在 <git-common-dir>/orchestration/settle-audit.ndjson，删除 Session Context 后仍存在。--force 只覆盖 liveness 不确定性，不覆盖身份、审计、stop、lease 或删除失败。
  • 验证脚本：test-settle-liveness.sh（字段矩阵）与 test-settle-command.sh（真实命令顺序和资源保留）。
• provider/custom argv 由 spawn-worker.sh 预创建的 terminal 会被 Orca 标记为 external。完整分页预检已经证明目标唯一且 settled 后，retained/external_terminal 是所有权结果，不是失败；只有 METADATA 与 worker resource 的句柄精确一致时，创建者才可关闭。reclaimable 先按目标 Dispatch release，再用同一 Run 完整重读；后置结果不可证时不继续直接关闭 terminal 或删除文件。任何 active/unknown/mismatch 都拒绝清理。

外部终端关闭还须核对 incarnation、已 settled 且未被用户接管；精确关闭后读回复验 disconnected，再结算 lease。不得把 terminal close 用作 release_pending/release_unknown 的替代。上述 legacy settle 参数不是未知现场的新授权；证据不足时即使有 --force 也不执行，优先按当前官方 recovery 合同处理。

Claude 信任/MCP/外部导入弹窗：用受支持的 worker-read/agentWait 有界证据确认实际等待内容，交有权限的人或明确授权流程处理；不自动改全局 ~/.claude.json、接受全部 MCP 或导入外部配置。未响应不等于死进程，不因此强杀/重派。terminal read 偶发错误尚无稳定复现，保存 runtime、时间、精确 handle 与退出码，不伪称已修复。

心跳正常但缺文件、commit 或测试产物时，只能说明协议活性。PM 按任务阶段与最近业务产物判断停滞，向原 worker 给一条窄纠偏：先完成已列第一项并做定向验证。不自动换模型、改 effort、杀进程或领取额外任务；长期无进展按任务门禁升级。

10. METADATA 契约

{
  "session": {
    "orca": {
      "mode": "auto",
      "setup_mode": "skip",
      "worktree_id": "<repoId>::<path>",
      "worktree_path": "/abs/path",
      "terminal_handle": "term_xxx",
      "app_version": "1.4.180",
      "runtime_id": "<validated-runtime-id>",
      "capabilities": ["terminal.multiplex.v1", "orchestration.contract.v1"],
      "supervised": {
        "run_id": "run_xxx",
        "coordinator_handle": "term_pm_xxx",
        "task_id": "task_xxx",
        "dispatch_id": "ctx_xxx",
        "dispatch_bind": "ok",
        "contract": "orca.orchestration.contract.v1",
        "completion_authority": "worker_done",
        "terminal_ownership": "external"
      }
    }
  }
}

无 supervised 子块就只能按 terminal-managed 处理。dispatch_bind（Task-076）记录 spawn 收尾自检结果：ok 或 manual-required（自动补绑未完成，dispatch_id 可为空——空时 pm-orchestrate 按 terminal-managed 路由，run/task id 是 PM 手动三步补绑的输入）。Handle 是 runtime-scoped；Run/Task/Dispatch 是结构化协调身份，不要互相替代。