@@ -6,6 +6,7 @@ import type {
 } from '@mavis/local-runtime';
 import type { LocalBrowserAdapter, LocalBrowserToolExposure } from '@mavis/agent-tools/desktop';
 import type { RuntimeApplications } from '../application/initialize.js';
+import type { RuntimeServices } from '../services.js';
 import type {
   MiniAppPresenter,
   LocalRuntimeApplication,
@@ -80,6 +81,21 @@ interface CreatedLocalRuntimeHost extends V1CreatedLocalRuntimeHost {
    */
   applications?: RuntimeApplications;
   cliService?: import('./cli-service.js').CliService;
+  /**
+   * The composed V2 service owners (`managedWorktrees`, `pinService`,
+   * `agent`, `mcp`, `skill`, `modelSystem`, …), handed to the embedder
+   * as-is. Distinct from `application` / `applications`: those two are
+   * the PRODUCT use cases, this is the OWNER graph behind them, so a
+   * consumer that finds no use case it can call (`agent` has none on
+   * the process-local facade) still has a real path to the capability.
+   *
+   * Optional because a host without the V2 compatibility slice
+   * (`compatibility === undefined`) has no service owners at all — the
+   * member is absent rather than an empty object, so "no owner" and
+   * "owner with no members" cannot be confused. Every member is
+   * `readonly`; lifecycle stays with the host's `close()`.
+   */
+  services?: RuntimeServices;
 }
 
 export type {
 
@@ -439,6 +439,13 @@ function createStartedHost(
       ? {
           application: ownerRuntime.services.application,
           applications: ownerRuntime.services.applications,
+          // The owner graph itself, for embedders whose product facade
+          // carries no use case for a capability the services do own
+          // (the process-local facade declares no `agent` member, while
+          // `services.agent` is a full AgentApplication). Same object,
+          // same lifetime: `services.close()` stays reached only through
+          // the host's own shutdown path.
+          services: ownerRuntime.services,
         }
       : {}),
     ...(cliService ? { cliService } : {}),
 
@@ -2697,8 +2697,17 @@ There is no manual `?v=N` cache-bust any more — every chunk URL under
 Read-only, declaration-backed: which of the 14 engine capability keys a
 provider supports, plus the `unavailable` summary the capability-driven
 UI renders from. Boots no host and runs no probe. `?provider=` defaults
-to `local-runtime-v2`; the other registered surface is
-`tui-runtime-adapter`.
+to `local-runtime-v2` — unchanged since B1, so every existing caller keeps the
+declaration it had. The other three registered providers are
+`tui-runtime-adapter` (the in-process adapter surface), `acp` (the
+`mcode acp` subprocess protocol) and `exec` (the one-shot `mcode exec`
+subprocess).
+
+Registering a provider is not routing it. Both `acp` and `exec` are
+registered and unreachable: no capability gate resolves to either of
+them, so a server running on either transport still evaluates every
+gate against no provider at all. `?provider=exec` is answerable today;
+a gate that consults the exec declaration is M4-3's work.
 
 **Response 200**
 ```json
@@ -2716,9 +2725,36 @@ to `local-runtime-v2`; the other registered surface is
 ```
 (`capabilities` carries all 14 keys; three are shown.)
 
+A `none` entry may carry an extra `servedBy: "<providerId>"` alongside its
+`reason`. It does not change the level or the `unavailable` roll-up — the
+provider really has none of that capability. It records that webui still
+serves the endpoint, from another provider's in-process host. Both
+transport providers use it for exactly two keys (`turnDiff`, `plugins`):
+neither the acp protocol nor the exec CLI has a diff method or a plugin
+method, yet those thirteen endpoints work on either transport because
+they project the in-process local-runtime-v2 host and gate on no
+transport at all. That is why the field is a per-key declaration field
+rather than an acp special case: the exception belongs to the two
+routes, so every transport inherits it. A client that wants to know who
+answers a request should treat `servedBy` as "not a degradation" — and
+must not read it as the capability being present.
+
+The `exec` declaration is the one worth reading before writing a client
+against it, because its shape follows from the transport having **no
+request channel**: `mcode exec` takes a prompt on stdin and writes a
+`stream-json` event stream to stdout, so there are no methods to call
+and nothing to declare `full` except sending. It is `full` on
+`streamingSend`, `partial` on `sessionCrud` (it can re-enter or resume an
+existing session but cannot list, load, close or delete one), `partial`
+on `toolSkillInvocation`, `mcp` and `usageStats`, and `none` on the other
+six — including `interrupt` and `authCredentials`, which the acp provider
+answers `partial`. Each `reason` names the file and line it was taken
+from, and the level is a statement about the transport's interface, not
+about which endpoints currently respond under it.
+
 **Errors** — `404 {"ok":false,"code":"unknown_engine_provider","knownProviders":[…]}` for an unknown `?provider=` (caller confusion — never 501). Any future route gated on an undeclared capability answers `501 {"ok":false,"code":"engine_capability_not_supported","capability","provider","missing"?,"reason"?}` — expected degradation, not a server fault; treat it as "hide the entry point", not as an error toast.
 
-Contract details (the 14-key table, both providers' levels, the
+Contract details (the 14-key table, every provider's levels, the
 migration state) live in [`docs/webui.md`](../../../docs/webui.md)
 under "Engine capability declaration".
 
 
@@ -2487,8 +2487,15 @@ chunk URL 都做内容寻址，rebuild 时自动失效。
 
 只读、声明直出：返回某个 provider 在 14 个引擎能力键上的支持档位，
 附前端能力驱动渲染所用的 `unavailable` 汇总。不起 host、不探测。
-`?provider=` 缺省为 `local-runtime-v2`；另一个已注册面是
-`tui-runtime-adapter`。
+`?provider=` 缺省为 `local-runtime-v2`（自 B1 起未变）；另外三个已注册的
+provider 是 `tui-runtime-adapter`（进程内 adapter 面）、`acp`
+（`mcode acp` 子进程协议，传输面）与 `exec`（一次性 `mcode exec`
+子进程，传输面）。
+
+注册 provider 不等于把它接进路由。`acp` 与 `exec` 都已注册但不可达：
+没有任何能力门控会解析到它们，因此跑在这两条传输上的 server 对每道门控
+仍然按「没有 provider」来评估。`?provider=exec` 今天就能作答；会去查
+exec 声明的门控属于 M4-3 的活。
 
 **Response 200**
 ```json
@@ -2506,9 +2513,28 @@ chunk URL 都做内容寻址，rebuild 时自动失效。
 ```
 （`capabilities` 实际含全部 14 键；此处示例 3 个。）
 
+`none` 条目除 `reason` 外还可带一个 `servedBy: "<providerId>"`。它**不改变**
+档位，也不改变 `unavailable` 汇总——该 provider 确实没有这个能力。它记录的是
+webui 仍从另一个 provider 的进程内 host 服务该端点。两个传输 provider 都只对
+两个键用它（`turnDiff`、`plugins`）：acp 协议与 exec CLI 既无 diff 方法也无
+插件方法，但那十三个端点在任一条传输上都可用，因为它们投影的是进程内
+local-runtime-v2 host 且完全不按传输门控。这正是该字段是「逐键声明字段」而
+不是 acp 特例的原因：这个例外属于那两个路由，所以每条传输都继承它。客户端若
+想知道「由谁应答」，应把 `servedBy` 读作「这不是降级」——但绝不可读作该能力
+可用。
+
+写客户端之前值得先读 `exec` 那份声明，因为它的形状源自这条传输
+**没有请求通道**：`mcode exec` 从 stdin 取 prompt、向 stdout 写
+`stream-json` 事件流，因此没有方法可调，除了「发送」之外没有哪一项能声明成
+`full`。它是 `streamingSend` 为 `full`，`sessionCrud`（能重新进入或续接已有
+会话，但列举不了、加载不了、关不掉、删不掉）、`toolSkillInvocation`、`mcp`、
+`usageStats` 为 `partial`，其余六键为 `none`——其中包含 acp provider 答成
+`partial` 的 `interrupt` 与 `authCredentials`。每条 `reason` 都写明取证的文件
+与行号，且档位是关于这条传输的**接口面**的陈述，而不是关于当前哪些端点会应答。
+
 **错误** —— `?provider=` 写错答 `404 {"ok":false,"code":"unknown_engine_provider","knownProviders":[…]}`（调用方的错，绝不会是 501）。未来任何按能力门控的路由，调到未声明能力答 `501 {"ok":false,"code":"engine_capability_not_supported","capability","provider","missing"?,"reason"?}`——这是预期降级、不是服务端故障；按「隐藏入口」处理，不弹错误提示。
 
-契约细节（14 键总表、两个 provider 的档位、迁移状态）见
+契约细节（14 键总表、各 provider 的档位、迁移状态）见
 [`docs/webui.zh-CN.md`](../../../docs/webui.zh-CN.md) 的
 「引擎能力声明」一节。