@huseynsnmz/pi-board 0.15.3 → 0.16.0

package/docs/superpowers/specs/2026-09-07-issue-11-attach-runtime-desync-heal-design.md

@@ -1,130 +0,0 @@
-# Spec: attach 运行期失同步检测 + 限速 heal 兜底（issue #11）
-
-- 日期：2026-09-07
-- 状态：approved（2026-09-08 用户批准；review v2 修订：检测改定时器入口、CJK 验证点、A4 可行性标注）
-- 范围校准：attach 期失同步已由 shrink-and-hold 协议（#25 + #42 G6）覆盖；本 spec 只做**运行期**（attach settle 后、会话进行中）的失同步检测与限速补救。
-
-## 1. 背景
-
-issue #2 的修复建议 #2（失同步检测）在 #10 复盘中被证明必要：jiggle 链耗尽后系统再无自愈手段，脏画面（双光标+残留帧）一直挂着直到用户 detach/reattach。#25/#42 之后 attach 期已收敛，但运行期失同步（重放垃圾残留、子端渲染异常、未知失败模式）仍无兜底——本 spec 补上这道最后防线。
-
-## 2. 失同步信号原理
-
-**正常态**：子端 pi-tui 每帧把 PTY 硬件光标定位到编辑器 marker 处，而 marker 处的编辑器假光标 cell 是反色的（`ESC[7m`）。因此**光标 cell 本身就是反色 cell**。
-
-**失同步态**：本地 headless xterm 的光标记账与 buffer 内容不一致（典型：光标停在差分写结束处、footer 段末尾），光标 cell 非反色，假光标留在编辑器行。
-
-**streaming 例外**：输出进行中光标落在输出行（非反色）是正常的。用「距上次 socket 输出 > DESYNC_QUIET_MS」区分——输出停止后子端最后一帧会把光标定位回编辑器。
-
-## 3. 设计
-
-### 3.1 失同步判定纯函数 `detectCursorDesync(buf, cursor)`
-
-位置：`src/core/pty-attach-render.mjs`（纯函数、零依赖，随既有模块）。输入：xterm buffer（`getLine`/`getCell`/`isInverse` 最小接口）+ `projectPtyCursor()` 的返回值。返回三态：
-
-- `"aligned"`：cursor 非空且光标 cell 反色（含光标列越界但行末 cell 反色的等价形态）——正常；
-- `"misaligned"`：cursor 非空（光标在投影视口内）但光标 cell 非反色（cell 不存在、宽度 0、非反色均算）——候选失同步，等待时间门确认；
-- `"unknown"`：cursor 为 null（光标在视口外，如用户滚动历史）——不判定。
-
-主判定 O(1)（只查光标 cell）；仅在光标列越界需回看行末 cell 时退化 O(cols)。
-
-### 3.2 controller 新增 `heal(cols, rows)`
-
-位置：`src/core/pty-attach-jiggle-controller.mjs`。运行期补救入口，复用 shrink-and-hold 协议：
-
-1. healBudget 检查：已达上限（`HEAL_MAX_PER_LIFETIME = 5`）→ return，不再补救；通过检查即消耗一次额度（含后续因极小终端放弃的情况——防反复尝试）；
-2. 清 timer；若有旧 hold（held）先 restore（幂等）；
-3. 重置检测状态（`state = createJiggleRetryState()`、carry 清空）；
-4. **保留 `tuiFrameSeen = true`**（运行期子端必然渲染过——这是与 `start()` 的关键区别，跳过 G1 无帧守卫与首帧 re-arm 分支）；
-5. 重新 shrink 并 hold（`holdSize = resizeJiggleSize(cols, rows)`；极小终端无 holdSize → 直接放弃本次 heal）；
-6. `scheduleNextRetry()` 复用现有退避表（G2 预算耗尽自动 restore）。
-
-清屏检测复用 `feed()`：见 `\x1b[2J` → restore + 停链（现有逻辑）。守卫交互：
-
-- **G3**：`restoreAndStop()` 照常清 heal 的 hold；
-- **G4**：`notifyExternalResize()` 清 hold 与 timer，heal 自动取消（现有逻辑不动）；
-- **G5**：`start()`（重连）先恢复旧 hold——heal 的 hold 同样被恢复，重连后协议重新走 attach 期自愈；
-- **预算**：healBudget 在 controller 实例生命周期内累计（`start()`/`restoreAndStop()` 均不重置），防断连循环骚扰。
-
-### 3.3 组件接线（`src/ui/pty-attach.ts`）
-
-- `pushOutput()` **同步**收到数据时记录 `lastOutputAt`（不在 `term.write` 异步回调里记）；
-- `attachSettled` 即现有 `!this.attaching` 字段（不新造计时器），settle 后才开始检测；
-- **检测入口是独立 `checkDesync()` 组件方法 + 低频定时器，不挂 render 路径**——render 是事件驱动的（socket 输出/keypress/resize），而失同步恰恰发生在输出停止后，挂在 render 路径上会让空闲态失同步永远没有检测机会。定时器在 attach settle 后启动（周期 `DESYNC_PROBE_INTERVAL_MS = 2000`），unref 不阻止进程退出，`close()` 时清理；
-- `checkDesync()` 内部用与 `project()` 相同的视口计算（start/height）调 `projectPtyCursor` + `detectCursorDesync`，7 个门全部通过才 heal：
-  1. `attachSettled === true`；
-  2. controller `tuiFrameSeen === true`（子端是 pi，shell/vim 不检测）；
-  3. `detectCursorDesync(...) === "misaligned"`；
-  4. `Date.now() - lastOutputAt > DESYNC_QUIET_MS`（1500ms）；
-  5. 链不活跃：`getState()` 满足 `state.stopped && !held`（heal/attach 链进行中不重复触发）；
-  6. 距上次 heal > `HEAL_RATELIMIT_MS`（10000ms）；
-  7. socket 连接存活（`this.connected`）。
-- 门 1-7 通过 → `jiggleRetry.heal(this.cols, this.rows)`，记录 `lastHealAt`。healBudget 上限不是组件层门：由 `heal()` 内部强制（预算耗尽直接拒绝），组件层无需重复检查。
-
-### 3.4 数据流
-
-```
-socket 输出 → pushOutput（记 lastOutputAt）→ term.write 异步解析
-                                        ↘（输出停止后 render 不再触发）
-settle 后定时器（2s 周期）→ checkDesync()（自算视口 + projectPtyCursor）
-  → detectCursorDesync → 7 门判定 → heal()
-  → sendResize(shrink) → 子端 fullRender(true) 全清
-  → feed() 检测 \x1b[2J → restore 原尺寸 → 自愈完成
-```
-
-## 4. 误报场景与防护
-
-| 场景 | 防护 |
-|------|------|
-| streaming 中光标在输出行 | 门 4 时间条件（1.5s 无输出才判） |
-| 全清重绘中间态 | 重绘=大量输出 → lastOutputAt 持续刷新 → 门 4 挡住 |
-| 非 pi 子进程（shell/vim，光标行永无反色） | 门 2 tuiFrameSeen |
-| attach settle 前（重放中间态/banner 遮挡） | 门 1 |
-| 用户滚动历史（光标在视口外） | detectCursorDesync 返回 unknown |
-| pi 静默等待外部输入（密码 prompt 等） | 无法完全防（真误报）→ healBudget=5 上限封顶，闪烁有限次后停止 |
-| heal 进行中重复检测 | 门 5 链活跃检查 |
-
-**已知漏报（接受）**：光标 cell 恰好反色但 buffer 其他处有残影——检测不到。兜底不追求完美。
-
-**假设**：子端 buffer 的反色 cell 主要来源是编辑器假光标（detach gate `findLastInverseCellLine` 已依赖同一假设）。若存在其他反色源，只影响漏报（把失同步误判为 aligned），不产生误报。
-
-**实现时验证点**：CJK 宽字符的 continuation cell（width 0）在 xterm 中是否继承首格的反色属性——若光标停在中文 continuation cell 上被判为非反色，会造成中文输入场景误报。实现时用真实 @xterm/headless 验证，并在 A1 补对应用例（若确实误判，检测逻辑需回看首格）。
-
-## 5. 非目标
-
-- attach 期失同步检测（已由 shrink-and-hold 覆盖）；
-- 连续补救失败后隐藏光标块 + 状态行提示（原 issue 可选兜底 3，以 healBudget 上限替代）；
-- 残留帧特征检测（内容重复行等，成本高收益低）；
-- Windows 实机行为（无实机，标 pending）。
-
-## 6. 参数表
-
-| 参数 | 默认值 | 说明 |
-|------|--------|------|
-| DESYNC_QUIET_MS | 1500 | 判定失同步所需的输出静默窗口 |
-| DESYNC_PROBE_INTERVAL_MS | 2000 | settle 后定时检测周期 |
-| HEAL_RATELIMIT_MS | 10000 | 两次 heal 最小间隔 |
-| HEAL_MAX_PER_LIFETIME | 5 | controller 实例生命周期内 heal 总上限（进入 heal() 即消耗一次，含极小终端放弃的情况） |
-
-## 7. 验收矩阵
-
-| ID | 功能点 | 验收方式 | 具体验证 | 通过标准 |
-|----|--------|----------|----------|----------|
-| A1 | detectCursorDesync 三态判定 | 自动化（unit） | `node --test test/pty-attach-render.test.mjs` | aligned/misaligned/unknown 各场景断言正确（反色 cell、非反色、cell 越界、宽度 0、cursor null） |
-| A2 | heal() 协议行为 | 自动化（unit） | `node --test test/pty-attach-jiggle-controller.test.mjs` | shrink→feed clear→restore；budget 耗尽拒绝；G4 取消 heal；G5 恢复 heal hold；tuiFrameSeen 保留；极小终端放弃 |
-| A3 | 组件接线 + 7 门 + 自愈闭环 | 自动化（integration） | 新增 test-support TS 脚本（`--experimental-transform-types`，仿 detach-gate-smoke 模式）+ `node --test` 包装 | 伪造 buffer/输出流驱动真实组件：misaligned+静默→触发一次 heal resize；10s 内不重复；链活跃/settle 前/视口外/无帧均不触发；模拟子端全清输出后自愈停止；时间相关断言优先时间注入，其次真实等待 |
-| A4 | 健康 session 无误触发 | 自动化（E2E） | 复用 cold-start E2E harness 模式，真实 runner+pi 冷启动 attach 后稳定运行窗口内监控 heal 计数/resize 序列 | 正常会话全流程 heal 触发次数为 0。**可行性依赖**：现有 E2E harness 绕过组件胶水层（advisory 30-3），plan 阶段先核实组件级 harness 能力；不可行则降级为「A3 强化门控回归 + U1 观察」 |
-| U1 | 日常使用观察 | 用户实测 | 日常使用若干天：观察无误触发闪烁；（若偶遇真失同步）观察限速周期内自愈 | 无每 10s 频闪类骚扰性重绘；U1 为观察性验收，允许 pending，不阻塞合并 |
-
-## 8. 可测性拆分设计
-
-- **detectCursorDesync(buf, cursor)**：纯函数，输入最小 buffer 接口（伪造 `getLine→getCell→isInverse` 对象，test/pty-attach-render.test.mjs 已有 BufferLineLike 伪造模式）。测试边界：只测函数本身的三态映射，不涉及时间/限速（属组件层）。
-- **heal()**：注入式 controller（fake `sendResize`/`setTimeoutFn`/`clearTimeoutFn`，既有模式）。测试边界：协议时序与守卫交互，不涉及检测信号。
-- **接线门控**：真实组件（TS）+ 伪造 tui/socket 数据流，test-support 脚本模式。测试边界：门的组合逻辑与端到端自愈闭环，不依赖真实子进程。
-- **A4 E2E**：真实 runner+pi，只断言「健康流无误触发」这一回归性质，不构造失同步（构造失同步属于 A3 的伪造层职责）。
-
-## 9. 风险
-
-- pi 静默等待场景（密码 prompt/长工具无 spinner 帧）真误报 → 一次闪烁 + budget 封顶，无无限循环；
-- 子端其他反色源（若存在）→ 只漏报不误报；
-- 参数（1.5s/10s/5 次）为工程估值，A3/A4 验证后可调。

package/docs/superpowers/specs/2026-09-08-attach-ctrl-left-detach-design.md

@@ -1,58 +0,0 @@
-# issue #89 spec：attach 界面 Ctrl+← detach 和弦
-
-日期：2026-09-08 · 状态：已授权全自动推进（用户 2026-09-08 决策）
-
-## 背景与问题
-
-attach 界面里编辑器非空时 `←` 被判为光标左移转发给 child（#66/#68/#69 门禁链的有意行为），用户不知道要先清空输入才能 `←` 退出，被困后只能 Ctrl+C/D 强退（连带 shutdown child Pi——实录一次事故导致 host 反复冷启动 7 次）。需要一个不与编辑冲突、始终可用的退出和弦。
-
-## 核心设计（issue 已定稿，本 spec 为落地细化）
-
-### D1：Ctrl+← 无条件 detach
-`src/ui/pty-attach.ts` `handleInput`：在 `Key.left` 分支**之前**新增：
-```ts
-if (matchesKey(data, Key.ctrl("left"))) {
-	// Explicit detach chord (issue #89): single ← is gated on editor state
-	// (it doubles as cursor-left in a non-empty draft), so a user with a draft
-	// had no way out. Ctrl+← is unambiguous intent — detach unconditionally,
-	// regardless of editor state or socket liveness (same guarantee as the
-	// disconnected-← escape, issue #48).
-	this.detach();
-	return;
-}
-```
-- 放 Key.left 分支前：确保组合键不被单键分支截获（matchesKey 语义上两者不相交，但顺序防御更稳）；
-- 无条件：和弦语义 = "我要退出"，不需要门禁（门禁防的是误触，组合键无误触）；
-- pi-tui Key 支持现成：keys.js L845-846 legacy（`\x1b[1;5D`）+ kitty 序列均映射 ctrl+left。
-
-### D2：header 提示更新
-- L282：`← detach` → `←/Ctrl+← detach`
-- L298（renderLoading 中心提示）：`← to detach` → `←/Ctrl+← to detach`
-
-### 否决项（issue 已论证，记录防重提）
-- Esc：child 可能跑 vim/nvim，Esc 必须透传；
-- 双击 ←：编辑时连按 ← 移动光标是高频操作，必误触。
-
-## 非目标
-- 不改 ← 单键门禁链任何行为（#66/#68/#69 的判定逻辑保持原样）；
-- 不改其他键位；不改 detach() 本身语义。
-
-## 可测性拆分设计
-
-| 单元 | 性质 | 测法 |
-|---|---|---|
-| Ctrl+← 分支 | 组件 handleInput | 扩建现有 `test-support/detach-gate-smoke.ts` harness（fake tui + send spy + didDetach，#42/#48/#66 同款）：注入 `\x1b[1;5D` 序列 |
-| 文案 | render 输出 | harness 内 render(width) 断言含 "Ctrl+←" |
-
-## 验收矩阵
-
-| ID | 功能点 | 验收方式 | 具体验证 | 通过标准 |
-|----|--------|----------|----------|----------|
-| A1 | Ctrl+← 编辑器非空（draft）时 detach | 自动化（冒烟） | `node --test test/pty-attach-detach-gate.test.mjs` | didDetach() === true（editor_state draft 场景） |
-| A2 | Ctrl+← 编辑器空时 detach | 自动化（冒烟） | 同上 | didDetach() === true |
-| A3 | 单次 ← 门禁链回归 | 自动化（冒烟） | 同上 | 现有 15+ 断言全绿 |
-| A4 | header 文案 | 自动化（冒烟） | 同上 render 输出断言 | 含 "Ctrl+←" |
-| A5 | 全量回归 | 自动化（static/build） | `npm test` + `npm run typecheck` | 618+ 全绿 |
-| U1 | 真实场景 | 用户实测 | 合并后重启 pi：attach 活跃 session，输入几个字 → Ctrl+← | 立即 detach 回 dashboard，child 不受影响 |
-
-U1 需重启 pi，合并后用户执行。

package/docs/superpowers/specs/2026-09-08-dashboard-shrink-repaint-design.md

@@ -1,52 +0,0 @@
-# issue #88 spec：dashboard 花屏修复（首帧全清 + 收缩自愈帧）
-
-日期：2026-09-08 · 状态：已授权全自动推进（用户 2026-09-08 决策）
-
-## 背景与问题
-
-dashboard（pi-tui 全屏 overlay）花屏：行重复、folder 计数错位。根因：pi-tui 差分渲染在 overlay 激活时禁用 clearOnShrink（tui-main-screen.js L315 `!hasOverlayEntries`），且首帧不清屏（"assumes clean screen"）——脏底/收缩残留无任何自愈通道。拖窗口（widthChanged → fullRender(true)）可恢复，证明全清是有效兜底。973d492（v0.3.0）起存在的存量问题。
-
-## 核心设计（单文件：src/ui/dashboard.ts）
-
-### D1：mount 首帧全清
-组件新增 `needsFullClear = true`；首帧 render 时 `this.tui.requestRender(true)`（nextTick 异步，无递归）——下一帧全量重绘，给干净底。
-
-### D2：内容收缩自愈帧
-- `fitToHeight` 记录 pad 前内容行数到实例字段（pad 后行数恒满屏，检测无效——必须用 pad 前值）；
-- `render(width)` 改为包装方法：调原逻辑（改名 `renderLines`）拿 lines → 若 `needsFullClear` 或内容行数较上帧**减少** → `requestRender(true)` → 更新记录 → 返回 lines；
-- 只响应**减少**（增长/同行数由差分正确处理），避免无意义全清。
-
-### 为什么这样安全
-- `requestRender(true)` 经 nextTick 异步执行（tui.js L612-628），render() 内调用不递归；
-- 全清帧被 DECSET 2026 同步输出包裹，支持终端无闪烁；dashboard-render.mjs 注释警告的是"每帧 true"，本设计仅首帧+收缩帧低频触发；
-- 不动 pi-tui 上游、不动差分语义、不动 dashboard-render.mjs。
-
-## 非目标
-- pi-tui 上游修复（node_modules 不可控；且 overlay 禁 clearOnShrink 是有意设计）；
-- 每帧全清（闪烁，明确放弃）；
-- attach 视图（PtyAttachComponent）的渲染问题（不同组件，不在本 issue）。
-
-## 可测性拆分设计
-
-| 单元 | 性质 | 测法 |
-|---|---|---|
-| 首帧/收缩触发逻辑 | 组件 render 包装（.ts） | 子进程冒烟：`test-support/dashboard-shrink-render.ts` 用 --experimental-transform-types 加载组件，fake tui spy + fake deps，render 三帧（首帧/增行/减行）输出 requestRender 调用序列 JSON |
-| 既有差分语义 | dashboard-render.mjs | 现有测试 "dashboard repaint preserves Pi TUI differential render state" 不动（requestDashboardRender 不改成 force） |
-
-冒烟脚本 deps 构造照搬 `test-support/dashboard-refs-render.ts`（同组件既有范式）。
-
-## 验收矩阵
-
-| ID | 功能点 | 验收方式 | 具体验证 | 通过标准 |
-|----|--------|----------|----------|----------|
-| A1 | mount 首帧全清 | 自动化（integration/冒烟） | `node --test test/dashboard-render.test.mjs` | 首帧 render 后 requestRender 收到 [true] |
-| A2 | 收缩帧自愈 | 自动化（integration/冒烟） | 同上 | 减行帧触发 [true]；增行/不变帧不触发 |
-| A3 | 修复在 .ts 层（jiti 可重载） | 自动化（static） | diff 审查 | 运行时代码改动仅在 dashboard.ts（.mjs 无运行时行为变更） |
-| A4 | 全量回归 | 自动化（static/build） | `npm test` + `npm run typecheck` | 617+ 全绿 |
-| U1 | 真实花屏场景 | 用户实测 | 合并后重启 pi：密集创建/删除若干 session（可配合 host 崩溃场景），观察 dashboard | 无行重复/计数错位残留；无需拖窗口恢复 |
-
-U1 需重启 pi（git 包不热重载），合并后用户执行。
-
-## 风险与降级
-- 老终端无同步输出支持时全清帧可见一闪——低频可接受；
-- 若 U1 发现仍有残留场景（如运行期外部写屏非首帧非收缩），后续可加"定时低频全清"兜底，本 spec 不做。

package/docs/superpowers/specs/2026-09-08-legacy-stale-host-recovery-design.md

@@ -1,87 +0,0 @@
-# issue #87 spec：legacy 死 host 安全回收（resolver 自愈）
-
-日期：2026-09-08 · 状态：待用户确认
-
-## 背景与问题
-
-v0.5.x 时代（无 instanceId 协议）的 legacy PTY host，当 runner 进程被异常杀死（SIGKILL / 承载终端关闭）时 host.json 永远停在 `state: "alive"`（或 `"starting"`）。v0.6.0 的 attach resolver 对 legacy host 执行「never recovered」（spec §10.1 保守决策），probe 失败直接 pending，同时 `hostActive`（纯磁盘状态）让 ensureHost 拒绝重新 claim——三层叠加成死锁，attach 永久失败。本机实录 6 个 view 处于该状态。
-
-## 设计目标
-
-resolver 对「pid 可验证已死 + endpoint 不可达」的 legacy host 自动 finalize 为 `exited` 并走正常 ensure/claim 自愈，消除死锁；不满足安全条件时保持现有 pending 行为（不推翻 spec 的保守原意）。
-
-## 核心设计
-
-### D1：纯决策函数 `canFinalizeLegacyHost`（host-coordination.mjs）
-
-```js
-/**
- * @param {{ host: HostStatus|null, hostPid: number|null, hostPidAlive: boolean,
- *           probeClassification: string }} input
- * @returns {boolean}
- */
-```
-
-返回 true 当且仅当四条件同时成立：
-1. `host.instanceId == null`（legacy）
-2. `host.state ∈ {"starting", "alive"}`（stopping 由既有恢复路径 L907-933 覆盖，不重复处理）
-3. `hostPid != null && hostPidAlive === false` —— pid 已死是核心安全证据；pid 复用只会让 isAlive=true → 走保守分支，方向安全
-4. `probeClassification ∈ {"missing", "stale"}` —— missing=ENOENT（socket/pipe 不存在）；stale=ECONNREFUSED+isSocket（进程死、socket 文件残留）。`unknown`/`occupied`/`starting` 一律不回收
-
-纯函数、零副作用、零注入，真值表可全枚举测试。
-
-### D2：resolver legacy 分支改造（service.mjs `resolveAttachTargetInner`）
-
-- pid 解析复用 loadRow 同款 fallback：`Object.hasOwn(host, "runnerPid") ? host.runnerPid : readHostPid(root, viewId)`（legacy 的 pid 在 host-pid.json 镜像）
-- 现 L963 `else if (legacy) return pending(...)` 改为：
-  - `canFinalizeLegacyHost(...)` 为 true → finalize（见 D3）→ `continue`（下一轮 row 重载 hostActive=false → 走正常 ensure/claim）
-  - 否则保持原 pending（行为不变）
-- `state === "starting"` 的 legacy（L936 `withinGrace` 恒 true 的等死分支）：在 grace 等待分支内同样先查 `canFinalizeLegacyHost`（该分支 probe 已执行，classification 可得），满足即 finalize + continue，不再等 grace 到期
-
-### D3：finalize 动作（service.mjs 内联，写路径唯一）
-
-`writeHost(root, viewId, { ...host, state: "exited", endedAt: now, lastSeenAt: now, error: "legacy host finalized: runner pid dead" })` + `appendDiagnostic({ source: "service", level: "info", code: "legacy_host_finalized", ... })`。
-
-- legacy 无 instanceId，不存在并发 owner，无需 fencing（与新协议 updateOwnedHost 路径区分）；竞态窗口由 host-start lease 串行化兜底（claim 走全新 instanceId，与 exited 记录不冲突）。
-- 选 `exited` 而非 `failed`：进程是正常死亡语义（被外部杀死），failed 在现有代码里语义是"spawn/启动失败"（#86 场景），exited 与 v0.5.x runner 自然退出时写的状态一致，下游（canReplaceHost/ensure）对两者处理相同。
-
-### D4：平台兼容性
-
-不引入任何文件存在性检查（Windows 命名管道 existsSync 不可用，#45）；证据只来自 probe classification（connect+hello 是唯一权威，spec §7.1）+ isAlive（kill(pid,0) 跨平台）。不碰 prewarm keypress 路径（2s TTL 纪律）。
-
-## 非目标（明确排除）
-
-- **升级迁移扫描**（issue 建议 2）：resolver 自愈后功能冗余（下次 attach 自然恢复）；若后续要 dashboard 行状态立刻正确可单开 issue。
-- **UI 兜底提示**（issue 建议 3）：永久 pending 状态被消除后无存在意义。
-- **stopping 状态 legacy**：已有恢复路径覆盖（L907-933 对 instanceId != null 生效；legacy stopping 的 `staleStop` 判定要求 instanceId != null——属现存另一个小缺口，本次不扩范围，记为遗留观察项）。
-
-## 可测性拆分设计
-
-| 单元 | 位置 | 性质 | 测法 |
-|---|---|---|---|
-| `canFinalizeLegacyHost` | host-coordination.mjs 新增导出 | 纯函数 | 真值表单测：4 条件 × 关键组合（全满足/缺 pid/pid 活/unknown/stopping/新协议 host） |
-| pid fallback 解析 | service.mjs resolver 内联（复用 store.readHostPid） | 副作用隔离 | 集成测试造 legacy host.json（无 runnerPid 属性）+ host-pid.json |
-| finalize + 自愈闭环 | service.mjs resolver | 集成 | 注入 scriptProbe(missing) + 死 pid → 断言 host.json 落 exited、diagnostic 写入、resolver 继续 claim 新 host |
-| 保守分支 | 同上 | 集成 | pid 活（用 process.pid）→ 断言 pending 且不写盘 |
-
-测试基建现成：`resolverService` + `scriptProbe` + `aliveHost` fixtures + `instantSleep`（test/host-resolver.test.mjs 模式）。`aliveHost` fixture 需支持造 legacy host（无 instanceId、无 runnerPid 属性 + host-pid.json 镜像），必要时加 `legacyHost` fixture helper。
-
-## 验收矩阵
-
-| ID | 功能点 | 验收方式 | 具体验证 | 通过标准 |
-|----|--------|----------|----------|----------|
-| A1 | canFinalizeLegacyHost 决策正确性 | 自动化（unit） | `node --test test/host-coordination.test.mjs` | 真值表全组合通过 |
-| A2 | legacy alive + pid 死 + missing → 自愈闭环 | 自动化（integration） | `node --test test/host-resolver.test.mjs` | host.json 落 exited、diagnostic 有 legacy_host_finalized、resolver 成功 claim 新 instance |
-| A3 | legacy alive + pid 活 → 不回收 | 自动化（integration） | 同上 | pending 返回、host.json 未被改写 |
-| A4 | legacy starting + pid 死 → 不等 grace 即回收 | 自动化（integration） | 同上 | 不 sleep 到 deadline 即完成回收 + claim |
-| A5 | probe unknown → 不回收 | 自动化（integration） | 同上 | pending、不写盘 |
-| A6 | 全量回归 | 自动化（static/build） | `npm test` + `npm run typecheck` | 568+ 全绿、无新类型错误 |
-| U1 | 本机 6 个真实卡死 legacy view 实测 | 用户实测 | 运行副本 checkout PR 分支 → 重启 pi → board 对卡死 view 按 enter | 全部自动拉起新 host 可正常 attach，无 manual restart 提示 |
-
-U1 必须用户执行（重启 pi 会断开实现 session）。执行时机：PR 合并前。
-
-## 风险与降级
-
-- pid 复用误判方向恒为保守（不回收），不会误杀；
-- finalize 后若 claim 失败（如 PTY 不可用），行为与现有 ensure 失败路径一致（pending + 原因），无新增失败模式；
-- Windows 无 legacy named-pipe 实测环境（U2 类）——设计只依赖平台无关的 probe/isAlive，风险评估为低，最终报告标注未实测。

package/docs/superpowers/specs/2026-09-08-spawn-async-error-swallow-design.md

@@ -1,56 +0,0 @@
-# issue #86 spec：spawn 异步 error 兜底（spawnDetached 统一封装）
-
-日期：2026-09-08 · 状态：已授权全自动推进（用户 2026-09-08 决策）
-
-## 背景与问题
-
-`launch.mjs` 4 个启动函数与 `pty-attach.ts openExternalTarget()` 的 spawn 均为 `spawn(...)` + `unref()` 无 `'error'` listener。spawn 启动失败走异步 `'error'` 事件，EventEmitter 无 listener 的 error 直接 throw → uncaughtException → 整个 pi 宿主进程退出。实录：WSL2 上一次 node 二进制瞬时 ENOENT 直接带崩 pi（host.json 已正确落 failed，但进程没活下来走重试）。
-
-## 核心设计
-
-### D1：launch.mjs 新增内部 helper `spawnDetached`
-
-```js
-function spawnDetached(command, args, cwd) {
-    const child = spawn(command, args, { cwd, detached: true, stdio: "ignore", env: process.env, windowsHide: true });
-    child.on("error", () => {});   // 接住异步启动失败；调用方按 pid==null 记 failed，宿主不崩
-    child.unref();
-    return child;
-}
-```
-
-`launchRun` / `launchHost` / `launchTitle` / `launchAutoState` 四处收敛到该 helper。helper 不导出（模块内部实现细节，测试通过公开入口行为验证）。
-
-### D2：openExternalTarget 三分支补 error listener
-
-darwin/win32/其他三分支统一为 `const child = spawn(...); child.on("error", () => {}); child.unref();`。fire-and-forget 语义与返回值不变（打开链接是 best-effort，失败静默）。参照同文件 L847-848 xclip 既有正确模式。
-
-## 非目标
-
-- runner/*.mjs 内的 spawn（跑在分离 runner 进程里，崩了不拖垮 pi，issue 已明确排除）；
-- 顶层 `process.on("uncaughtException")` 兜底（会掩盖未知错误，不引入）；
-- 改变任何返回值/状态机语义。
-
-## 可测性拆分设计
-
-| 单元 | 性质 | 测法 |
-|---|---|---|
-| spawnDetached 异步 error 兜底 | 副作用隔离（仅 child_process） | integration：注入不存在 node 路径，断言返回 pid:null 且进程存活（uncaughtException listener 不触发；node:test 进程崩=测试天然失败） |
-| 4 个公开入口行为不变 | 公开 API | 复用现有 4 测试 + 新增 ENOENT 用例覆盖 launchRun/launchHost/launchTitle/launchAutoState |
-| openExternalTarget | UI 层（c8 阈值外，惯例冒烟保护） | 静态验证 error listener 存在；不单加测试 |
-
-## 验收矩阵
-
-| ID | 功能点 | 验收方式 | 具体验证 | 通过标准 |
-|----|--------|----------|----------|----------|
-| A1 | spawn 失败不带崩进程（4 入口） | 自动化（integration） | `node --test test/launch.test.mjs` | 注入 `/nonexistent/node-ENOENT-test` 后各入口正常返回 pid:null，进程存活 |
-| A2 | 既有行为回归 | 自动化（integration） | `node --test test/launch.test.mjs` | 原 4 测试全绿 |
-| A3 | openExternalTarget error 兜底 | 自动化（static） | 代码审查 + grep 断言 | 三分支均有 error listener |
-| A4 | 全量回归 | 自动化（static/build） | `npm test` + `npm run typecheck` | 568+ 全绿、无类型错误 |
-| U1 | issue 复现脚本对照 | 自动化替代（A1 等价） | issue 自带复现脚本逻辑已并入 A1 | 见 A1 |
-
-U1 说明：issue 的复现脚本本质是"注入坏 node 路径 + uncaughtException 监听"，A1 测试完全等价覆盖，故不需要独立用户实测。无 U 类纯人工项。
-
-## 风险
-
-极低：纯增量兜底，不改成功路径任何行为；失败路径从"进程崩"变为"走既有 pid==null 记 failed 重试路径"。

package/docs/superpowers/specs/2026-09-08-stale-model-attach-guard-design.md

@@ -1,79 +0,0 @@
-# issue #90 spec：defaultModel 失效防护（launch 前校验 + child exit 归因）
-
-日期：2026-09-08 · 状态：已授权全自动推进（用户 2026-09-08 决策）
-
-## 背景与问题
-
-session 创建时记录的 `meta.defaultModel` 失效后（provider 前缀改名/移除），attach 走「launchHost → child --model 失效 → exit 1 → host exited → 再 attach 再 launch」死循环（实录单 view 数百次 launch_host）。且 runner child exit 不写 error 字段（pty-runner.mjs L217），host.json 只有 exitCode:1 无任何归因线索。
-
-## 核心设计
-
-### D1：launch 前模型校验（断死循环）
-
-1. **core 导出匹配函数**（`src/core/launch-options.mjs`）：
-```js
-/**
- * Whether a stored model reference resolves to a currently-available model.
- * Same rule as the dashboard launch picker: case-insensitive exact "provider/id".
- * @param {string|null|undefined} modelRef
- * @param {Array<{provider: string, id: string}>|undefined|null} availableModels
- * @returns {boolean} true when modelRef is empty/null (no constraint) or matched.
- */
-export function modelRefAvailable(modelRef, availableModels)
-```
-`modelRef` 空 → true（无校验对象）；`availableModels` 空/undefined → true（调用方无法判断时保守放行，不制造新阻塞）。
-
-2. **service 注入**：`createService` 新增 `opts.availableModels`（`() => Array<{provider,id}>`，每次调用实时取值；默认 undefined → 跳过校验）。`src/index.ts` serviceFor 与 `src/commands/agent-board.ts` flag 路径注入 `() => ctx.modelRegistry.getAvailable()`（try/catch → undefined，对齐 agent-board.ts L75-79 现有防御模式）。
-
-3. **统一校验 helper**（service.mjs 模块内）：`validateViewModelMeta(meta) → null | string`（null=通过；string=错误消息）。错误消息明确可行动：`Model "X" configured for this session is no longer available — update the view's model or clear defaultModel, then retry attach.`
-
-4. **两个校验点**（service.mjs 仅有的 host spawn 路径）：
-   - `startHostUnderLease`：在 claim 之前校验（首选；若代码结构上 claim 已发生，则落 failed 清理后返回）→ `{ ok: false, error }`；
-   - `adoptClaimedHost`：claim 是既有废弃记录 → 校验失败时 `updateOwnedHost` 落 failed（error 带模型消息）+ 返回 pending。
-   - resolver 链路无需改动：ensureHostImpl 的 `{ ok:false, error }` 走现有 `pending(sessionFile, res.error)` → attach-flow notify 展示（渠道现成）。
-
-5. **dashboard.ts L1738 `findLaunchModelByRef` 改为复用 core 导出**（单一事实源；LaunchModel 结构类型 JSDoc 化）。
-
-### D2：child exit 错误归因（补线索）
-
-1. **纯函数**（`src/core/heuristics.mjs` 新增导出）：`lastVisibleLogLine(text, maxLen = 200)`——strip ANSI（CSI `\x1b\[[0-9;?]*[ -/]*[@-~]` + OSC `\x1b\][^\x07\x1b]*(?:\x07|\x1b\\)` + 杂项转义），按行切分，返回最后一个非空可见行（`\r` 处理：取每行最后一个 `\r` 段），截断 maxLen。空输入/全空 → null。
-2. **runner 接线**（`runner/pty-runner.mjs` child exit 回调 L213-223）：`exitCode != null && exitCode !== 0` 时 best-effort（try/catch 包裹，绝不影响 exit 路径）读 screen.log 尾部 ~8KB（openSync/readSync seek 尾部，不整文件读）→ `lastVisibleLogLine` → 非 null 则 `update({ ..., error })`。exitCode=0 不改 error。
-
-## 非目标
-
-- **失败退避**（issue 建议 2）：D1 已断 spawn 死循环；通用退避需跨 claim 持久计数，复杂度/收益不划算，未来场景再单开；
-- **run 路径模型校验**（launchRun 的 model）：detach run 失败是一次性的，不循环——观察项；
-- **UI 改动**：notify 渠道现成；
-- 自动 fallback 到其他模型：静默换模型会让用户不知 session 行为已变，fail-fast + 明确提示更安全（issue 建议 1 的两个选项中选 fail-fast）。
-
-## 可测性拆分设计
-
-| 单元 | 位置 | 性质 | 测法 |
-|---|---|---|---|
-| `modelRefAvailable` | launch-options.mjs | 纯函数 | 真值表：大小写/null/空列表/部分匹配不匹配 |
-| `validateViewModelMeta` + ensure 路径 | service.mjs | 副作用隔离（注入 availableModels + launchHost spy） | integration：失效模型 → ok:false + launchHost 零调用 + 无 starting claim 残留；有效/null/未注入三对照 |
-| adopt 路径校验 | service.mjs | 同上 | integration：废弃 claim + 失效模型 → 落 failed + 不 spawn |
-| `lastVisibleLogLine` | heuristics.mjs | 纯函数 | 单测：ANSI/OSC/`\r`/空行/截断/空输入 |
-| runner exit 归因 | pty-runner.mjs | 集成 | pty-runner.integration.test.mjs 模式：fake child exit 1 + 预置 screen.log → host.json.error 含错误行；exit 0 → error 不变 |
-
-## 验收矩阵
-
-| ID | 功能点 | 验收方式 | 具体验证 | 通过标准 |
-|----|--------|----------|----------|----------|
-| A1 | modelRefAvailable 匹配规则 | 自动化（unit） | `node --test test/launch-options.test.mjs`（或既有对应文件） | 真值表全过 |
-| A2 | 失效模型 attach 不再 spawn | 自动化（integration） | `node --test test/host-resolver.test.mjs` / service 测试 | ok:false、launchHost spy 零调用、无 starting claim 残留、error 消息含模型名 |
-| A3 | 有效模型/null 模型回归 | 自动化（integration） | 同上 | 正常 launch（claim → spawn） |
-| A4 | 未注入 availableModels 向后兼容 | 自动化（integration） | 同上 | 跳过校验正常 launch |
-| A5 | adopt 路径失效模型 | 自动化（integration） | 同上 | 落 failed + 不 spawn |
-| A6 | lastVisibleLogLine 提取 | 自动化（unit） | heuristics 测试 | ANSI/截断/空行用例全过 |
-| A7 | runner exit≠0 归因 | 自动化（integration） | runner 测试 | host.json.error 含 screen.log 尾部错误行；exit 0 不写 |
-| A8 | 全量回归 | 自动化（static/build） | `npm test` + `npm run typecheck` | 608+ 全绿 |
-| U1 | 真实失效 view 实测 | 用户实测 | 合并后：view_539a5e9e20 恢复失效 defaultModel=glm/glm-5.3 → attach → 观察 notify 与 diagnostics | notify 明确提示模型失效；diagnostics 不再累积 launch_host；改回有效模型后 attach 成功 |
-
-U1 需重启 pi（git 包不热重载），合并后由用户执行并回 issue 记录。
-
-## 风险与降级
-
-- availableModels 为空数组时保守放行（不制造新阻塞）——校验仅在能确定"失效"时拦截；
-- 校验失败路径每次 attach 仅一次文件级操作，无进程开销；
-- D2 全 try/catch best-effort，exit 路径行为不变。

package/docs/superpowers/specs/2026-09-09-claimpid-blocks-replace-design.md

@@ -1,147 +0,0 @@
-# Spec: exited host 的 claimPid 存活导致 attach 永久 pending（issue #99）
-
-## 背景
-
-dashboard 里对已退出的 session 点 attach，永远连不上：attach 一直转圈，最终超时提示 `host start timed out`。实测对象 `view_2472d82627`（host 已正常退出 `state: "exited"`，`exitCode: 0`），同机另有 `view_4b667ad75d`、`view_c038badb30` 两个 view 处于相同状态（exited + claimPid 存活），全部无法 attach。
-
-## 根因
-
-### 触发链条
-
-1. 用户从 dashboard（进程 P）attach session → `claimHost`（`src/core/store.mjs:172`）把 `claimPid` 记为 **dashboard 进程的 pid**（`claimPid: provisionalHost.claimPid ?? null`，即 service 进程 pid）
-2. pi 子进程正常退出（`pty-runner.mjs:262` `child.onExit` → `state: "exited"`）→ **退出路径不清除 claimPid**
-3. dashboard 进程 P 继续存活（用户一直开着 dashboard）
-4. 再次 attach → `startHostUnderLease`（`service.mjs:243`）替换 terminal host 前调 `canReplaceHost(observeHostForReplace(existing))`
-5. `observeHostForReplace`（`service.mjs:2006`）对 claim 角色用 `conservativeObservation(host.claimPid)`：**pid 活着 → `"unknown"`**
-6. `canReplaceHost`（`src/core/host-coordination.mjs:72`）要求 runner / child / claim 三角色都 `SAFE_TO_RELEASE`（`not_started | dead | foreign`），claim 为 `"unknown"` → **返回 false**
-7. → `pendingLaunchResult` → attach 循环等待直到 deadline → `pending(sessionFile, "host start timed out")`
-
-实机验证（node 直接调用 `canReplaceHost`）：
-
-```
-host.state: exited
-runnerPid 1004724 → dead
-childPid null → dead
-claimPid 1003423 → unknown   ← 阻塞点
-canReplaceHost → false
-```
-
-### claimPid 的语义（代码注释 + 测试确认）
-
-- **非 null = "launcher 可能还在 claim 和 spawn 之间"**：保护 mid-transaction，让 ensureHost/adopt 等 grace 窗口（`service.mjs:976` `withinGrace` 判定依赖 `claimPid != null`）
-- **recovery claim 用 `claimPid: null`**（`service.mjs:723-736`）：recovery 事务在 claim 落盘时已完成，spawning 是 adopter 的活；`host-recovery.test.mjs:317` 断言 `recovery claim must not carry a live claimPid`
-- **spawn 失败路径清除 claimPid**（`service.mjs:832, 869`）：failed fenced
-- **正常退出路径不清除** ← 缺口：host 进入 `exited` 后 claimPid 残留，而 claim 保护语义（launcher mid-transaction）在 host 已 terminal 时**不可能成立**（runner 都跑完退出了）
-
-### 为什么是 bug
-
-`canReplaceHost` 的 claim 角色检查在 host 已 terminal 的场景下过度保守。claim 保护只对 `starting` 状态有意义；host 为 `exited/failed` 时，claim 进程不可能还在启动它（启动要么成功——runner 跑过并退出，要么失败——failed fenced 已清 claimPid）。触发条件常见：**dashboard 进程存活 + host exited → 任何从 dashboard 启动又退出的 session 都无法再次 attach**。
-
-## 修复方案（选定：放宽 canReplaceHost 的 claim 角色判定）
-
-### 方案对比
-
-| 方案 | 改动 | 对存量坏记录 | 评价 |
-|------|------|-------------|------|
-| **A. canReplaceHost 放宽 claim 判定** | 纯函数（`host-coordination.mjs`）+ 调用方（`service.mjs`） | **立即生效**（下次 attach 即可替换） | ✅ 选定 |
-| B. terminal 时清除 claimPid | 改 pty-runner 退出路径多处 + recoverHost finalize | 无效（已存在的坏记录不会自动修复，需额外迁移机制） | 改动面大、覆盖不全 |
-| C. conservativeObservation 增加 host 状态感知 | 改观测函数签名（传入 host 状态） | 立即生效 | 污染通用观测函数语义：`conservativeObservation` 的职责是"保守判断单个 pid 是否活着"，让它感知 host 状态会把生命周期决策混进观测层，违背 service.mjs 里观测与决策分离的既有结构 |
-
-### 设计
-
-**1. `canReplaceHost`（`src/core/host-coordination.mjs:72`）判定改为**：host 已 terminal（exited/failed）+ runner/child 均 provably gone + 无 launch lease → 可替换，claim 角色不参与判定。
-
-```js
-export function canReplaceHost({ host, runnerObservation, childObservation, launchLeaseActive }) {
-	if (!host || (host.state !== "exited" && host.state !== "failed")) return false;
-	if (launchLeaseActive) return false;
-	// claim 角色不参与判定：claim 保护语义（launcher mid-transaction）只在 host
-	// 处于 starting 时有意义；host 已 terminal 时 claim 进程不可能还在启动它
-	// （启动要么成功——runner 跑过并退出，要么失败——failed fenced 已清 claimPid）。
-	return (
-		SAFE_TO_RELEASE.has(runnerObservation) &&
-		SAFE_TO_RELEASE.has(childObservation)
-	);
-}
-```
-
-**2. 同步移除 `claimObservation` 参数**（而非保留 unused 参数）：
-
-- `canReplaceHost` 签名从 `{host, runnerObservation, childObservation, claimObservation, launchLeaseActive}` 改为 `{host, runnerObservation, childObservation, launchLeaseActive}`
-- `observeHostForReplace`（`service.mjs:2006`，内部函数不导出）返回值移除 `claimObservation` 字段——少一次 `process.kill(pid, 0)` 系统调用
-- 既有测试用例同步移除 `claimObservation` 参数
-
-**取舍论证**（为什么移除而非保留 unused）：
-
-- `observeHostForReplace` 只有**一个**调用方（`service.mjs:243` 传给 `canReplaceHost`），且该函数是 service.mjs 内部函数不导出——无外部兼容性问题
-- 保留一个不参与判定的参数会让测试产生误导（传 `claimObservation: "unknown"` 的用例看起来期望 false，实际被忽略）
-- 移除后观测层少一次无用的 `isAlive` 系统调用
-
-### 改动文件
-
-| 文件 | 改动 |
-|------|------|
-| `src/core/host-coordination.mjs` | `canReplaceHost` 判定放宽 + 签名移除 `claimObservation` + JSDoc 更新 |
-| `src/runtime/service.mjs` | `observeHostForReplace` 返回值移除 `claimObservation` 字段 |
-| `test/host-coordination.test.mjs` | 既有 3 用例移除 `claimObservation` 参数；新增 A1-A5 用例 |
-| `test/host-resolver.test.mjs` | 新增 A6 集成测试 |
-
-### 安全性论证
-
-| 场景 | 分析 | 结论 |
-|------|------|------|
-| exited + claimPid 活着 | 只可能来自 runner 跑完退出（claim 事务早已完成） | 安全，**修复目标** |
-| failed + claimPid 活着 | runner 崩溃 / child spawn 失败（claim 事务已完成或 failed fenced 已清）；child 存活时 childObservation 仍阻塞 | 安全 |
-| runner 活着 | runnerObservation = "unknown" → 仍阻塞（不受影响） | 保守性保留 |
-| child 活着 | childObservation = "unknown" → 仍阻塞（不受影响） | 保守性保留 |
-| alive/starting host + claimPid 存活 | attach 直接到现有 host（probe ready → 返回 pty），**不经过 canReplaceHost** | 不受影响 |
-| recoverHost 并发 | recoverHost 与 startHostUnderLease 都在 host-start lease 内执行，互斥 | 无竞争 |
-| starting 状态 | canReplaceHost 对非 terminal 直接返回 false（不进入新判定） | 不受影响 |
-
-### 非目标
-
-- 不改 pty-runner 退出路径（方案 B 不做）
-- 不做存量 host.json 迁移/清理（方案 A 对存量记录天然生效）
-- 不改 `conservativeObservation`（其保守语义在 starting 场景仍需要）
-- 不改 dashboard UI、不改 host.json 结构（不加新字段）
-
-## 验收矩阵
-
-| ID | 功能点 | 验收方式 | 具体验证 | 通过标准 |
-|----|--------|----------|----------|----------|
-| A1 | canReplaceHost：exited/failed + runner/child dead + **claimPid 存活** → 可替换（修复点） | 自动化验证（unit） | `node --test test/host-coordination.test.mjs` | 新增用例通过：`{host:{state:"exited"}, runner:"dead", child:"dead", lease:false}` → `true`；`{host:{state:"failed"}, ...}` 同 → `true` |
-| A2 | canReplaceHost：runner/child 任一 unknown 仍阻塞（保守性不破坏） | 自动化验证（unit） | 同上 | `runnerObservation:"unknown"` 或 `childObservation:"unknown"` 时返回 `false` |
-| A3 | canReplaceHost：launchLeaseActive 仍阻塞 | 自动化验证（unit） | 同上 | `launchLeaseActive: true` 时返回 `false`（既有用例回归） |
-| A4 | canReplaceHost：非 terminal host（starting/alive/stopping）仍拒绝 | 自动化验证（unit） | 同上 | 三个状态均返回 `false`（新增断言） |
-| A5 | canReplaceHost：SAFE_TO_RELEASE 边界回归——foreign/not_started → 可替换；host null → false | 自动化验证（unit） | 同上 | `runnerObservation:"foreign"` 或 `childObservation:"not_started"` 时返回 `true`；`host: null` 返回 `false` |
-| A6 | resolver 集成：exited host + 存活 claimPid → attach 启动新 host | 自动化验证（integration） | `node --test test/host-resolver.test.mjs` | 新增用例：构造 exited host 记录（`claimPid: process.pid`，存活），`resolveAttachTarget` 返回 `{kind:"pty"}` 且 spawn 恰好 1 次 |
-| U1 | 真实 dashboard 场景：attach 已退出 session（dashboard 进程存活） | 用户实测 | 见下方步骤 | attach 成功进入 session，历史消息正常显示，无超时提示 |
-
-**U1 实测步骤**：
-
-1. **重启 dashboard 进程**（加载新代码——方案 A 对存量坏记录的"立即生效"以重启为前提）
-2. 打开 dashboard，找到已知坏记录 `view_2472d82627`（issue-225 session，host `state: "exited"` + claimPid 存活）
-3. 点 attach → 观察：成功进入 session、历史消息正常显示、无 `host start timed out` 提示
-4. 退出 session，再 attach，确认可重复
-5. 同法验证 `view_4b667ad75d` / `view_c038badb30`（另两个 exited + claimPid 存活的 view）
-
-## 可测性拆分设计
-
-修复集中在 `canReplaceHost` 一个纯函数（`src/core/host-coordination.mjs`），无副作用、无 I/O，天然可单测：
-
-- **纯函数边界**：`canReplaceHost({host, runnerObservation, childObservation, launchLeaseActive})` → boolean。输入为纯数据快照，输出只依赖输入，不触碰 fs/进程/socket。
-- **观测与决策分离**：`observeHostForReplace`（`service.mjs:2006`）负责进程观测（`conservativeObservation`），`canReplaceHost` 负责决策。修复只动决策层；观测层移除 `claimObservation` 字段是配套清理（少一次无用的 `isAlive` 调用），不改变观测语义。
-- **测试边界**：
-  - `test/host-coordination.test.mjs`：A1-A5 全部在纯函数层覆盖（现有 `canReplaceHost refuses unknown observations` 用例扩展 + 新增用例）
-  - `test/host-resolver.test.mjs`：A6 走现有 `resolverService` + `healServiceOverrides` 基建（真实 ensureHostImpl claim + scripted probe），验证 attach 全链路（resolver → ensureHost → startHostUnderLease → canReplaceHost → spawn）
-
-## 风险与降级
-
-- **行为变化面**：仅放宽"exited/failed host 的替换判定"一个点；starting/alive/stopping 的 host 不经过 `canReplaceHost`；runner/child 存活的 host 仍阻塞。
-- **回归风险**：低。改动为纯函数内一个条件的放宽 + 配套签名清理，A2-A5 保证保守性不破坏。
-- **降级路径**：若 U1 实测发现异常，**revert 本 issue 的 commit 恢复原判定**（claim 角色重新参与判定）。
-
-## 环境
-
-- Linux x64，node v24.13.0，pi-agent-board main（0.6.1）
-- 2026-09-09 实机排查，`view_2472d82627` 现场取证（host.json / diagnostics.jsonl / ps 进程树）