fix(local-runtime) + feat(webui): migration lease recovery + M3-B10 model/permission facade

docs/webui.md

@@ -324,6 +324,12 @@ An error rather than a synthetic "cancelled" result says plainly that this clien
 
 The seam for a real surface is the `clientRequest` constructor option: `(method, params) => result | Promise<result>`. Its resolved value becomes the JSON-RPC `result`; a throw or rejection becomes an error response carrying the thrown `message` and, when it has one, its `code` (otherwise `-32603`). Nothing in the webui installs a handler yet — routing a decision through to the browser is separate work, and the honest current state is that the webui has no interactive surface to offer.
 
+### Engine stderr in the crash alert
+
+The engine announces its own failures on stderr and then dies; the crash alert is raised by the webui, not by the engine. `McodeAcpClient` therefore keeps a bounded tail of that stream — the last 2KB and the last 20 lines, cleared at every `start()` so one process's crash text can never be blamed on the next — and the `[mcode-acp.start]` and `[mcode-acp.stream]` error alerts carry it as `data.stderrTail`, prefixed with `[acp stderr truncated, showing the tail]` when anything was dropped. An exit code is not a diagnosis: `mcode acp exited (code=1)` cannot separate a lock the engine could not take from a configuration it refused to parse, while the engine's own line (`agent_name_conflict_migration_failed:lock`) says which.
+
+`stderrTail` is additive and optional. A silent engine leaves `data` byte-identical to what it was before the field existed, so no consumer of the alert contract has to learn a new required key. The `debug` constructor option keeps its old job — mirroring the stream live to the server's own stderr as it arrives — but all three construction sites in the shipped server pass `debug: false`, so in a running webui the alert's tail is the only channel that stderr has.
+
 ### What this does and does not buy
 
 `plan: {}` turns on a **notification**, not a question. A plan review carries a single `approve` option and the Runtime pins `allowOther: true` on every step, so the engine settles it fail-closed through the questionnaire path rather than turning it into a permission request — which is why advertising `plan` is safe for a client that cannot answer anything. The permission-request path is a separate switch the webui never turns on.

docs/webui.zh-CN.md

@@ -324,6 +324,12 @@ ACP 握手是双向的，两个方向都由同一份 `initialize` 载荷决定
 
 留给真实交互界面的接缝是构造函数选项 `clientRequest`：`(method, params) => result | Promise<result>`。它的 resolved 值成为 JSON-RPC 的 `result`；抛错或 reject 变成错误响应，携带抛出的 `message` 与（若有）`code`，否则为 `-32603`。webui 目前没有安装任何处理器——把一次决定真正送到浏览器是另一件事，诚实的现状是 webui 没有可提供的交互界面。
 
+### 崩溃告警里的引擎 stderr
+
+引擎把自己的失败写在 stderr 上然后死掉，而崩溃告警是 webui 发的，不是引擎发的。所以 `McodeAcpClient` 会留住这段输出的一个**有界尾部**——最后 2KB 且最后 20 行，并且在每次 `start()` 时清空，免得一个进程的崩溃信息被算到下一个进程头上——`[mcode-acp.start]` 与 `[mcode-acp.stream]` 这两条错误告警把它作为 `data.stderrTail` 带出去；若确实丢掉了内容，前面会加上 `[acp stderr truncated, showing the tail]`。退出码不是诊断：`mcode acp exited (code=1)` 分不清是引擎拿不到锁，还是配置被它拒绝解析；引擎自己那一行（`agent_name_conflict_migration_failed:lock`）才能说明是哪一种。
+
+`stderrTail` 是新增的可选字段。引擎若什么都没写，`data` 与这个字段出现之前逐字节相同，所以告警契约的任何消费方都不必学到一个新的必填键。`debug` 构造选项保留它原来的职责——把这段流实时镜像到服务端自己的 stderr——但要清楚：已发布服务端的三个构造点全部传 `debug: false`，因此在一个真正跑起来的 webui 里，告警里的尾部是 stderr 唯一的出口。
+
 ### 这次拿到了什么、没拿到什么
 
 `plan: {}` 打开的是**通知**，不是提问。计划评审只有一个 `approve` 选项，而运行时把 `allowOther: true` 固定在每一步上，所以引擎会走问卷通道 fail-closed 地了结它，而不会把它变成一次权限请求——这正是「声明 `plan`」对一个什么都答不了的客户端仍然安全的原因。权限请求通道是另一个开关，webui 从不打开它。

packages/webui/acp.mjs

@@ -34,6 +34,20 @@ const DEFAULT_CWD = process.cwd()
 const JSON_RPC_METHOD_NOT_FOUND = -32601
 const JSON_RPC_INTERNAL_ERROR = -32603
 
+// Bounded tail of the engine subprocess's stderr.
+//
+// The engine reports its OWN failures on stderr — a failed migration, a
+// lock it could not take, a config it refused to parse — and the crash
+// alert is raised by the webui, not by the engine. Without a tail the
+// whole diagnostic dies with the pipe: the operator sees only
+// `mcode acp exited (code=1)` and cannot tell a lock contention from a
+// missing binary. Both bounds are needed: bytes alone let one long
+// stack trace push the real message out of the window, and lines alone
+// let one pathological line carry megabytes.
+const STDERR_TAIL_MAX_BYTES = 2048
+const STDERR_TAIL_MAX_LINES = 20
+const STDERR_TRUNCATION_MARKER = '[acp stderr truncated, showing the tail]'
+
 /**
  * The capabilities this client advertises in `initialize`.
  *
@@ -96,12 +110,31 @@ export class McodeAcpClient extends EventEmitter {
     // singleton (the previous PR's bug: `_mcodeAcpSingleton.alive` always
     // undefined) is now actually detected and replaced on the next call.
     this._alive = false
+    // Bounded stderr tail (see STDERR_TAIL_MAX_BYTES). Reset per
+    // `start()` because each start is a different subprocess.
+    this._stderrTail = ''
+    this._stderrTruncated = false
   }
 
   get alive() {
     return this._alive && this.child !== null && this.started === true
   }
 
+  /**
+   * The engine subprocess's stderr, bounded to the last ~2KB / ~20 lines,
+   * prefixed with a truncation marker when anything was dropped.
+   *
+   * `''` when the engine wrote nothing to stderr — a caller reporting a
+   * crash omits the field rather than attaching an empty string, so the
+   * alert it builds keeps the shape it had before this existed.
+   */
+  get stderrTail() {
+    if (!this._stderrTail) return ''
+    const lines = this._stderrTail.split('\n')
+    const kept = lines.slice(-STDERR_TAIL_MAX_LINES).join('\n')
+    return this._stderrTruncated ? STDERR_TRUNCATION_MARKER + '\n' + kept : kept
+  }
+
   async start() {
     if (this.started) return this.capabilities
     // Windows .cmd shim handling: Node 22+ rejects `spawn('mcode.cmd', { shell:false })`
@@ -111,6 +144,10 @@ export class McodeAcpClient extends EventEmitter {
     // On Linux/macOS, plain `spawn('mcode')` walks PATH. .js/.mjs entries run under
     // process.execPath on every platform.
     const resolved = resolveMcodeCmd()
+    // A new subprocess gets a new tail: a stale line from a previous
+    // process would misattribute its failure to this one.
+    this._stderrTail = ''
+    this._stderrTruncated = false
     let cmd, args
     if (/\.(js|mjs)$/i.test(resolved)) {
       cmd = process.execPath
@@ -156,9 +193,7 @@ export class McodeAcpClient extends EventEmitter {
     this.child.stdout.setEncoding('utf8')
     this.child.stdout.on('data', (chunk) => this._onData(chunk))
     this.child.stderr.setEncoding('utf8')
-    this.child.stderr.on('data', (c) => {
-      if (this.debug) process.stderr.write('[acp stderr] ' + c)
-    })
+    this.child.stderr.on('data', (c) => this._onStderr(c))
     this.capabilities = await this.request('initialize', {
       protocolVersion: 1,
       clientInfo: { name: 'mcode-webui', version: '0.1.0' },
@@ -183,6 +218,22 @@ export class McodeAcpClient extends EventEmitter {
     this.pending.clear()
   }
 
+  // Record the engine's stderr for the crash alert, and mirror it live
+  // in debug mode (the dev-loop behavior this handler had before the
+  // tail existed — unchanged). The tail is kept regardless of `debug`:
+  // in production nobody is reading the server's own stderr, which is
+  // precisely why the engine's message has to travel inside the alert.
+  _onStderr(chunk) {
+    if (this.debug) process.stderr.write('[acp stderr] ' + chunk)
+    const next = this._stderrTail + chunk
+    if (next.length > STDERR_TAIL_MAX_BYTES) {
+      this._stderrTail = next.slice(-STDERR_TAIL_MAX_BYTES)
+      this._stderrTruncated = true
+    } else {
+      this._stderrTail = next
+    }
+  }
+
   _onData(chunk) {
     this.buf += chunk
     let nl

packages/webui/server/lib/mcode-acp.js

@@ -272,6 +272,26 @@ function matchesModelId(recorded, engineCurrent, modelOption) {
  * `resolveModelId` covers this case before the name-match runs.
  */
 
+/**
+ * The engine's stderr tail, shaped for an alert's `data`.
+ *
+ * The engine announces its own failures on stderr and dies; the webui is
+ * the one that raises the crash alert. Without carrying the tail across,
+ * every engine failure collapses to `mcode acp exited (code=1)` — an
+ * operator cannot act on an exit code, only on the engine's line
+ * (`agent_name_conflict_migration_failed:lock`, a config parse error, a
+ * missing binary). The client already bounds and truncates it; see
+ * `McodeAcpClient#stderrTail` in packages/webui/acp.mjs.
+ *
+ * Returns `{}` — not `{ stderrTail: "" }` — when the engine said nothing,
+ * so a silent failure produces byte-identical alert data to what it
+ * produced before this helper existed.
+ */
+function acpStderrData(client) {
+  const tail = client && typeof client.stderrTail === "string" ? client.stderrTail : "";
+  return tail ? { stderrTail: tail } : {};
+}
+
 // Exported for unit tests (test/lib/mcode-acp-note.test.js extends to
 // cover applyRecordedModel's resolution logic). The pre-session model
 // apply needs to handle three input forms without regressing, so the
@@ -431,7 +451,7 @@ export async function runMcodeAcp(content, opts = {}) {
       src: "mcode-acp",
       cid: cid || null,
       sessionId: sid || null,
-      data: { phase: "start-or-load" },
+      data: { phase: "start-or-load", ...acpStderrData(client) },
     });
     return {
       status: "failed",
@@ -1330,7 +1350,7 @@ function streamAcpPrompt(
           src: "mcode-acp",
           cid: cid || null,
           sessionId: sid || null,
-          data: { phase: "promise-catch" },
+          data: { phase: "promise-catch", ...acpStderrData(client) },
         });
         finalize();
       });