SSH 执行边界¶

Orca 如何在你的机器与 SSH 主机之间划分工作、断连后哪些内容会保留，以及如何将 unverifiable 与 exited 区分开来。此前 docs/ 下没有任何文档说明这一点；agent 和人类都在从错误字符串中推断，并且经常推断错误。

规则¶

执行主机拥有所有与执行相关的内容 —— 工具、凭据、身份、环境、进程和产物。客户端拥有 UI、传输和 Orca 控制平面状态，但不是执行状态的权威来源。

两个推论，均不可妥协：

1. 禁止静默替换。 对远程 repoPath 的操作绝不能回退到在客户端上运行。缺少 SSH provider 并不构成在本地作答的许可 —— 本地运行可能会针对_错误的仓库_作答。
2. 禁止断言你无法观察到的内容。 失去联系不是 exited 的证据。应报告 unverifiable，绝不能报告 exited。

术语是固定的：live / unverifiable / exited，取自现有的 UnstoppedPtyVerdict。不要引入同义词，也绝不能将 unverifiable 归并到任一相邻状态。exited 需要来自拥有该进程的主机的明确缺席证据；传输故障永远只能产生 unverifiable。

规则 1 在 src/main/source-control/repo-default-branch.ts:76-78、src/main/repo-worktrees.ts:45-48、src/main/runtime/orca-runtime.ts 中的 OrcaRuntimeService.probeWorktreeDrift，以及 src/renderer/src/lib/connection-context.ts:22-24 中有所说明。它由 src/main/runtime/runtime-git-command-target.ts 中的 requireRuntimeGitProvider 在 src/main/runtime/orca-runtime-git.ts 中全程强制执行，并由 src/main/runtime/runtime-file-command-target.ts 中的 requireRuntimeFileProvider 在运行时文件系统命令中全程强制执行。两者都根据目标解析后的 executionHostId 进行路由，而不是根据仓库行的 connectionId：当 SSH 主机没有已注册的 provider 时，它们会抛出 provider 不可用消息；对于本进程不执行的 runtime: 主机，抛出 ExecutionHostNotDispatchableError；只有 local 才返回 null。请 grep 这些名称以查找当前调用点，而不是相信某个计数。

src/main/runtime/unstopped-pty-verification.ts:12-16 是规则 2 的参考实现：它将 live / unverifiable / exited 保持为三个不同的判定，并将“我们无法询问”视为其自身的答案。

在哪里执行¶

存活：断连_不会_做什么¶

默认情况下，远程工作会在你的机器离开后继续存活。relay 是一个分离的守护进程（`nohup …