super-dsh 0.1.12-a → 0.3.0

package/node_modules/better-dsh/docs/50_test-reports/v0.1.9a-/345/256/236/346/265/213/346/212/245/345/221/212.md

@@ -0,0 +1,168 @@
+# v0.1.9-a 实测报告（native-tools）
+
+- 部署：commit `266d232`，版本 `0.1.9-a`，profile web，dsh-web PID 3340234（127.0.0.1:3080）
+- 套件：30 文件 / 365 tests 全绿；typecheck 零错
+- 前置：surface-and-devices 已归档（2026-08-28），本 change 的 tool-surface delta 叠其上
+- 实测人：被测 Dash Agent 运行时本体（第一人称），2026-08-28，会话 `session-59618b74-4aa4-4d94-b0b9-2b45cdc6c1ef`，路由 zai-plan / glm-5.3
+
+## 部署核验（实测前置）
+
+- 源码版本 `0.1.9-a`（dashr/package.json），工作树 HEAD `e3d29fb`（报告骨架）之上即 `266d232`（本 change）。
+- 部署位 `~/.dsh/profiles/web/node_modules/@pgmi-builds/dashr`，`lib/index.js` 构建于 2026-08-28 12:12，与工作区 `dashr/lib/index.js` **md5 逐字节一致**（`39ce52edb15027b91f12254d5732e85d`）。
+- 部署 lib 含 `llm_completion` 14 处、`AGENT_BRIDGE_SCHEMAS` 0 处（退役干净，源码中仅剩 index.ts:1018 一条解释性注释）。
+- 运行时级新鲜度由实测本身坐实：本会话 wire 面已出现 `agent` / `agent_message` / `agent_workflow` / `llm_completion` 四个工具（v0.1.8 及以前三桥不在此面）。
+
+## 本轮结构变化（对实测口径的影响）
+
+1. **三桥成为真工具**：`agent` / `agent_message` / `agent_workflow` 现在是 registry 注册（与 `eval` 同宿主层）。模型**直调**（不经 cell）应当工作，且走完整 dispatch 管道（审计事件/presentation）。REPL 侧 `tool.agent(...)` 不变（auto-bridge 自动拾取）。手写 `AGENT_BRIDGE_SCHEMAS` 路径已删除——目录渲染单源。
+2. **新增 `llm_completion`**：one-shot 无工具无历史 LLM 调用。参数 `{prompt, system?, maxTokens?}`，返回**纯文本**（string 根）或 `{error}`。路由 = 调用方 agent 的 provider/model。
+3. **write 反馈环**：lsp server 在位的语言，write 结果带 `diagnostics` 摘要字段（计数+首条）；格式化在写前完成（单次写、单次审计）。无 server 语言零变化。
+
+## 实测点（新会话）
+
+### §1 三桥 wire 直调（不变式验收）
+```
+# 直调（不经 eval cell），各应返回与 REPL 相同的 shape：
+agent({ "description": "probe", "prompt": "Reply exactly PROBE-OK", "run_in_background": false })
+agent_message({ "receiver": "child", ... })      # 沿用 v0.1.8f 口径
+agent_workflow({ "mode": "rfc", "objective": "..." })
+```
+- [x] wire 直调三桥基本盘全通：`agent` one-shot 直调返回 `{kind:"foreground", runId, output:[…]}`，子代理回 `WIRE-PROBE-OK`（v0.1.8f §11 的结构性缺口关闭）；`agent_message` child 下行投递成功、子代理回 `DOWNLINK-OK`；`agent_message` parent 自根 agent 调用返回结构化 UNAUTHORIZED 错误（不抛）；`agent_message` interrupt 成功停止 sleep-90 子代理（`accepted:true`，子代理 "stopped before it finished"）。
+- [x] wire 工具数组中出现 `agent` / `agent_message` / `agent_workflow` / `llm_completion`（本会话 wire 声明即证）。
+- [x] **三面逐名相等（例外恰为 `eval`）**：REPL 真实绑定集 = `__dashr_injected__["tool"]["functions"]` 枚举 25 名（agent、agent_message、agent_workflow、llm_completion、read/write/edit/grep/glob、bash、job_*、memory_*、web_search、ask_user_question、read_image、todo_write、get/update/create_goal、exit_plan_mode；初版误记 26，0.1.9-b 复测时以集合差分复核定正），与 wire 平面（26 平面名 = 同 25 名 + `eval`，另 5 个非平面 `mcp__cordis-a2a__*`）逐名相等；`eval` 只在 wire 面、不在绑定集也不在目录（符合 self-call 防护例外）；mask 九名（skill/send_message/report/list_agents/subagent/subagent_fork/interrupt_agent/workflow/ralph）在 wire 与绑定集均零出现。
+- [x] dispatch 管道审计（D1 白捡收益）：wire 直调 `agent` 在会话日志落 `tool/call`（seq 8994，全参数）；cell 内桥/completion 调用落 `tool/code-dispatch-start` + `tool/code-dispatch` 成对事件（本会话 19 对，含结构化错误场景，`isError:false` + `{error:...}` 内容）。v0.1.8f「cell 闭包直调绕过审计」关闭。
+- [ ] **`agent_workflow` rfc 模式真正跑通** — wire 直调 rfc 模式 ✅：`maxRounds:1`，返回 `{runId, agentsStarted:1, result:{status:"complete", roundsStarted:1, report:{summary:"RFC-OK-019A"}}}`，v3 引擎 realm 修复（`0a56da4`）+ 注册化叠加端到端成立。但 **script 模式 wire 不可用**，见缺陷 F1。
+
+### §2 llm_completion
+```
+llm_completion({ "prompt": "Reply with exactly one word: PONG" })
+```
+- [x] 返回纯文本 `PONG`（string 根，非 {text} 包装）。
+- [x] cell 内：`await tool.llm_completion({"prompt":"…"})` 返回裸 str `CELL-PONG`（auto-bridge 拾取，零 spawn——judge 场景成立）。
+- [x] system 生效：强制尾缀 SYST-OK 的 system prompt 下，回复以 `SYST-OK` 结尾。
+- [x] 参数校验为结构化 error：`maxTokens:0` 与 `maxTokens:5000`（>4096 上限）均返回 `{error:"…must be a positive safe integer no greater than 4096"}`，不抛。
+- [~] 降级 finish → 结构化 error：**本路由不可触发**。`maxTokens:1` / `maxTokens:3` 实际返回了完整长输出（见缺陷 F8），说明 maxTokens 未端到端生效，"hits maxTokens → {error}" 场景在此 provider 上无法到达；abort 路径未做第一人称触发。
+- [~] 无路由场景：结构化 error 为**源码级核验**（llm-completion.ts:93-96：无 provider/model 即 `{error:"requires a model route"}`），根会话第一人称不可达（exec.agent 恒在）。注意该行为与设计文档的 default-model 回落说法不一致，见缺陷 F5。
+
+### §3 write 反馈环（lsp = rust-analyzer，本机唯一在装 server）
+- [x] 写带类型错误的 .rs → write 结果含 `diagnostics` 字段：`"1 error(s), 1 hint(s) — first: mismatched types\nexpected 'u32', found '&str'"`（E0308，计数+首条明细，与 spec 一致）。
+- [x] 写正确 .rs → 无 `diagnostics` 字段（"no diagnostics 不附加" 成立；新文件干净控制组 clean.rs 同样无字段）。
+- [x] 写 .txt（无 server）→ 结果键集 `{path, operation, before, after}`，与旧版完全一致（无新字段、无格式化、无错误）。
+- [ ] 格式化：**未生效**——写风格混乱的 .rs（`pub fn   messy(x:i32)->i32{…}`）盘上字节不变；直查设备返回 `{changed:false, reason:"server declares no formatting capability"}`，而 rustfmt 在装、rust-analyzer 实际声明该能力。根因是**能力键名读错**（`formattingProvider` vs LSP 规范字段 `documentFormattingProvider`），见缺陷 F3。测试计划的 .ts 前提亦不成立：本机无 typescript-language-server（defaults.json 注册 56 个 server，仅 rust-analyzer 二进制在位）。
+- [ ] **非 stale（D2 正确性关键点）不成立**：lib.rs 先写坏（1 error），改写正确内容后连续多次 write 及直查设备**仍报旧 E0308**，且错误 span（line 2, ch 5-23）对应旧内容、hint span 对应新内容——publish 里混着 stale flycheck 诊断，见缺陷 F2。
+- [~] wire 面（模型直调 write）**看不到 diagnostics**：render 只输出 `Created/Updated <path>`，diagnostics 只存在于 JSON 值里；同一调用经 cell（原始 JSON）可见。反馈环在直调面对模型不可见，见缺陷 F4。
+
+### §4 回归
+- [x] v0.1.8f §11 agents 面不回归：one-shot `WIRE-PROBE-OK` / continuable subagentId（cca40744…）/ 下行 `DOWNLINK-OK` / interrupt 生效，全套通过。
+- [x] mask 九名仍全链路消失（wire、绑定集双面核验）；`eval` 仍不在绑定集/目录。
+- [x] URL 面回归：`skill://grilling` 全文输出；`ctx://` 精确三键 session/model/cwd；未注册 scheme 报错列 7 个注册 scheme（agent, ctx, dsh, dvc, http, https, skill）；`dvc://` 列四设备（ast_edit / ast_grep / browser / lsp），lsp 设备 diagnostics/definition/references/hover/format 动作真实可执行。
+- [x] control-prompt.md `kernel` 措辞 0 处（v0.1.8e D5 欠账已清）；v0.1.8e 的 `dir(tool)` 空目录缺陷**仍在**（28 个 dunder、零绑定名，真实绑定集仍只在未文档化的 `__dashr_injected__`），本轮 scope 未含此项，沿用为已知欠账。
+
+## 结果
+
+**总体判定：v0.1.9-a 已真实生效，主体目标（A.1 不变式恢复、桥审计、completion、write 反馈环骨架）达成；存在 2 个 P1 缺陷（script 模式 wire 不可调、write 诊断 stale）与 1 个 P2 死代码（format-on-write 能力键名错误），均不破坏既有面，可热修。**
+
+### 通过项
+| # | 项 | 证据 |
+|---|---|---|
+| P1 | 三面逐名相等（例外恰 eval） | 绑定集 26 名枚举 ≡ wire 平面名 ≡ 目录；mask 九名双面零出现 |
+| P2 | 桥 wire 直调 | `agent` one-shot/background、`agent_message` child/parent/interrupt 全通过，日志 `tool/call` 全参数 |
+| P3 | dispatch 审计 | wire `tool/call`+`tool/result`；cell `code-dispatch` 19 对（v0.1.8f 审计缺口关闭） |
+| P4 | workflow rfc 端到端 | `RFC-OK-019A`，1 round / 1 agent，realm 修复叠加注册化成立 |
+| P5 | llm_completion 主链路 | 裸 string 根、system 生效、cell 零 spawn、结构化校验错误（0/5000 边界） |
+| P6 | write 诊断（cell 面） | 计数+首条摘要附结果；干净/serverless 零附加（byte-identical 键集） |
+| P7 | 手写 schema 路径退役 | `AGENT_BRIDGE_SCHEMAS`/`createAgentBridgeBindings` 源码+部署 lib 双零；目录单源 |
+| P8 | 回归面 | skill:///ctx:///dvc:///错误词汇/kernel 措辞/agents 面全部不回归 |
+
+### 缺陷清单
+| # | 级 | 缺陷 | 证据与定位 |
+|---|---|---|---|
+| F1 | P1 | **`agent_workflow` script 模式 wire 不可调用**：`meta`/`args`（`type:'json'` 平铺字段）在 wire 路径以 JSON **字符串**到达（会话日志 seq 15232/22071 两种编码均然），而桥的 execute 要求 `typeof meta === 'object'`（bridges/index.ts:367）→ 恒报 `requires {"meta": {...}}`。对照：数组型参数（todo_write 的 todos）wire 正常到达为容器——疑为 wire 层只按声明类型做字符串→值还原、typeless(json) 字段保持字符串。cell 路径（py dict→JS object）正常（`SCRIPT-CELL-OK`，runId ca63c30a）。**A.1 的「wire ≡ REPL」在此一工具上破约**。修法：桥侧对 meta/args 做 `typeof === 'string'` 时 `JSON.parse`（一行），或参数 schema 改声明 object 形状 | 双编码 wire 调用 + 日志 arguments + cell 对照 |
+| F2 | P1 | **write 诊断 stale**：修复后的内容连续多次写入仍报旧错（E0308），错误 span 指向旧内容、hint span 指向新内容；直查 `dvc://lsp`（带 content override）同样 stale。机制：rustc 源（flycheck）诊断不随 didChange 刷新，版本门限等待放行了合并 publish。违反 dvc spec「EXACT content just written (never a stale earlier version)」场景。修法：write-feedback 路径过滤 `source==='rustc'`，或主动触发 flycheck（`rust-analyzer/runFlycheck`） | lib.rs 坏→好×3 次 + 设备直查，span 错位实锤 |
+| F3 | P2 | **format-on-write 死代码**：lsp-device.ts:423 读 `serverCapabilities?.formattingProvider`，LSP 规范字段为 `documentFormattingProvider`（client 直接存 `initResult.capabilities`，无键名改写）→ 永远 `changed:false, "server declares no formatting capability"`，与 rustfmt 在装、RA 实有格式化能力的事实矛盾。一行修复 | 设备直查 reason + 两文件键名对照 |
+| F4 | P2 | **wire 面 write 结果不呈现 diagnostics**：render 仅输出 `Created/Updated <path>`（write.ts output.render），diagnostics 只在 JSON 值中；模型直调 write 永远看不到反馈，反馈环仅在 cell 面可用。D2 的目的（edit 完立即知道写对了没有）对直调面落空 | 同一写入 wire 面（只见一行）vs cell 面（JSON 含 diagnostics）对照 |
+| F5 | P3 | 文档漂移：design D3/spec 说无路由时回落 host default model，实现返回结构化 error（llm-completion.ts 源码注释自述「answers a structured error rather than guessing」）。实现取舍可辩护，文档应改 | design.md D3 vs llm-completion.ts:93-96 |
+| F6 | P3 | 文档漂移：design/tasks 说 `purpose:'completion'` 审计，实现不传 purpose（host `GenerateOptions.purpose` 为封闭枚举 'compaction'/'session-title'），归因仅靠 sessionId + tool 级审计。spec「audit purpose distinct from agent turns」未满足 | llm-completion.ts 头注 + 会话日志（无独立 request/header） |
+| F7 | P3 | 文档漂移：design D2 说诊断走「`xd://lsp` 设备通道」，实际 scheme 为 `dvc://lsp`（`xd://` 未注册，错误词汇列 7 scheme 无它） | `xd://lsp` 报 URL_UNREGISTERED_SCHEME |
+| F8 | P3 | `maxTokens` 未端到端强制（zai/pi-ai 路由）：`maxTokens:1/3` 返回完整长输出；上限校验（≤4096）正常。dashr 侧转发链已核（GenerateOptions.maxTokens → pi-ai `streamSimple(...{maxTokens})`），丢失点在 dashr 边界之下（pi-natives 方言或端点）。后果：「降级 finish → {error}」场景在此路由不可达 | 两次小 maxTokens 长输出 + 源链核验 |
+| F9 | P4 | 沿用欠账：`dir(tool)` 仍无绑定名（28 dunder），真实绑定集在未文档化 `__dashr_injected__["tool"]["functions"]` | pad 枚举 |
+| F10 | P4 | wire 层在校验时静默丢弃未知键（带 `bogus_param` 的 agent 调用正常 spawn），桥内 `rejectUnknownKeys` 仅 cell 面可见——两面错误词汇不对称 | wire bogus 键 spawn 成功 vs cell `{error:"unexpected key(s)"}` |
+
+### 建议
+1. **热修三件**（合计约五行改动）：桥侧 JSON.parse json 型字符串字段（F1）；lsp 能力键名改 `documentFormattingProvider`（F3）；write render 附 diagnostics 摘要行（F4）。
+2. F2 需小设计决策（过滤 rustc 源 vs 触发 flycheck vs 延迟双拉），建议单开 change 或并入下轮。
+3. 文档同步：design.md D3 的路由回落与 purpose 表述、D2 的 `xd://lsp` 措辞，按实现实况改写（F5/F6/F7）。
+4. 测试计划模板（本文件 §3）的 .ts 前提与主机 server 现实脱节，建议模板改为「按 defaults.json ∩ 已安装二进制选择探测语言」。
+5. F8 建议在 pi-natives/zai 路由上单独立案追 maxTokens 丢失点；dashr 侧已无可修。
+6. 归档前跑一次 `registry.schemas(scope)` 与绑定集的程序化逐名断言进 vitest（tasks 1.4 已列，保持）。
+
+
+## §5 热修轮（0.1.9-b，commit 见下）
+
+针对 §1–§3 缺陷清单的第一轮热修（deployed，dsh-web PID 3416099，30 文件 / 371 tests 绿，+6 新测试）：
+
+### 已修
+- **F1** ✅：`agent_workflow` 桥侧 `coerceJsonField`——`meta`/`args` 以 JSON 字符串到达时先 parse 再校验（字符串先于校验规整，两面同语义）；不可解析字符串仍走结构化 error。回归测试 ×2（wire-form 字符串 coerce / 不可解析仍报错）。**A.1「wire ≡ REPL」在此工具恢复。**
+- **F3** ✅：能力键名改 `documentFormattingProvider`（LSP 规范字段，短别名保留为容错回退）。fake-lsp-server 声明该能力 + 实现 `textDocument/formatting`（确定性空格折叠编辑）+ didOpen/didChange 全量文本追踪；设备测试 ×3（spec 键格式化 / 已格式化 changed:false / content override 的诊断同步）。
+- **F4** ✅：write 的 `output.render` 在有 `diagnostics` 时附第二行摘要——wire 直调面模型可见反馈环（此前仅 cell JSON 可见）。
+- **F5/F6/F7** ✅（文档同步）：design D3 路由改为「无路由=结构化 error，不猜默认」；purpose 表述改为「宿主封闭枚举，归因靠 sessionId + 工具级审计」；D2 的 `xd://lsp` 改 `dvc://lsp`。spec delta 同步。
+
+### 复测点（下轮）→ 已于 0.1.9-b 复测（2026-08-28，同一第一人称会话续跑，新 PID 3416099）
+- [x] `agent_workflow` script 模式 **wire 直调** ✅：wire 面对象参数直调返回 `{runId:575a5a42…, agentsStarted:0, result:{token:"SCRIPT-WIRE-OK", hookAgent:"function"}}`（脚本内可见 agent 钩子）；cell 面 `SCRIPT-CELL-OK-B`。**F1 关闭，wire ≡ REPL 恢复**。
+- [x] write 格式化生效 ✅（update 路径）/ ⚠️（create 路径见新缺陷 F11）：对**已存在**的 messy.rs 重写混乱风格 → 盘上内容为 rustfmt 归整版（`pub fn messy3(x: i32) -> i32 {\n    let y = x * 2;…`），设备直查 format 返回 `changed:true` + 规整文本；但对**新建**文件（messy.rs/messy2.rs 首写）盘上保持原文——`preWriteFormat` 先于落盘执行，而设备入口有 `existsSync` 门（lsp-device.ts 文件不存在即抛 LSP_BAD_ARGS，钩子吞掉静默跳过）。
+- [x] write wire 直调面 ✅：坏内容 .rs 的直调 write 结果为两行文本（`Created <path>` + `1 error(s), 1 hint(s) — first: mismatched types\nexpected 'u32', found '&str'`）——反馈环对模型可见。**F4 关闭**。
+
+### 复测结果（0.1.9-b）
+- **部署核验**：源码/部署 lib 版本 `0.1.9-b`（commit `92d5908`），构建于 2026-08-28 13:12，md5 与工作区一致（`b9598bd0…`），371 tests 绿（commit 自述）。
+- **回归**：绑定集 25 名与 0.1.9-a 完全一致（集合差分零差；初版计数 26 为笔误，已定正）；mask 九名零出现；`eval` 例外不变；`agent` one-shot 直调 `REGRESS-OK-B`；`llm_completion` 正常。
+- **F2 复核：仍在**（立案跟踪一致）——main.rs 坏→好覆写后，wire 直调 write 仍报 stale `1 error(s) … mismatched types`（旧内容诊断）。
+- **F8 复核：仍在**（立案跟踪一致）——`maxTokens:1` 仍返回完整五十词计数+收尾语。
+- **文档同步核验**（F5/F6/F7）：design/spec delta 措辞已按实现改写（无默认路由回落、封闭枚举无 purpose、`dvc://lsp`）。小疵：spec.md 新文本将「attributed … through the normal tool-call audit」子句写了**两遍**（同段重复句），建议顺手去重。
+
+### 新增缺陷（复测发现）
+| # | 级 | 缺陷 | 证据与定位 |
+|---|---|---|---|
+| F11 | P3 | **format-on-write 对新建文件失效**：`preWriteFormat` 在落盘前调设备，而设备 `execute` 入口的 `existsSync` 门拒绝尚不存在的文件（抛 LSP_BAD_ARGS，钩子静默吞掉）→ create 场景永不格式化，update 场景正常。修法：设备对带 `content` override 的调用放宽存在性门（或钩子侧传临时 URI） | messy.rs create 未格式化 vs update 格式化；lsp-device.ts existsSync 门 |
+
+
+### 热修轮 0.1.9-c（F11 + 小疵，commit 见 git log）
+- **F11** ✅：设备 `existsSync` 门改为仅守 disk-backed 调用——带 `content` override（pre-write format 的形态）时跳过存在性检查，create 场景可格式化；回归测试 ×2（不存在文件 + content 可格式化 / 无 content 的不存在文件仍报 `file not found`——门只对 content 放宽）。
+- **spec 重复句** ✅：llm_completion requirement 里 duplicated 的 attribution 子句已去重。
+- 部署：30 文件 / **373 tests** 绿，版本 `0.1.9-c`，md5 一致，dsh-web PID **3461003**。
+- 复测点：新建混乱风格 .rs 一笔写入 → 盘上即 rustfmt 归整版（create 路径格式化首次生效）。
+
+### 复测结果（0.1.9-c，2026-08-28，commit `7ed1fc2`，md5 `d2f95874…` 一致，PID 3461003）
+- [x] **F11 关闭**：wire 直调一笔新建 `fresh.rs`（混乱风格 `pub fn   fresh_messy(x:i32)->i32{…}`）→ 盘上直接落 rustfmt 归整版（`pub fn fresh_messy(x: i32) -> i32 {\n    let y = x * 3;…`）——create 路径格式化首次端到端生效；设备侧 content-override 放宽门与 disk-backed `file not found` 保留（diff 核验）。
+- [x] **F4 保持**：坏内容 main.rs 直调 write 仍输出两行（`Created …` + `1 error(s), 1 hint(s) — first: mismatched types…`）。
+- [x] **F1 保持**：wire script-mode 回归 `SCRIPT-WIRE-OK-C`；绑定集 25 名不变、`eval` 例外不变；`agent` one-shot `REGRESS-OK-C`；spec 重复子句已去重（diff 核验）。
+- **F2 复核：仍在**（立案跟踪一致）——本轮以**真 cargo target** 干净复现：src/main.rs 坏写报 E0308 → 覆写正确内容（`let x: u32 = 2026;`）后仍报旧错。附带方法论修正：**非 target 的游离文件（无 main.rs/lib.rs 的包内文件）完全不产 flycheck 诊断**（设备直查 `no diagnostics`）——上一轮 v019b 的 messy.rs 之所以"有行为"是同 root 下有 main.rs；今后 stale/诊断类探针必须落在 target 文件上。
+- **F8 复核：仍在**（立案跟踪一致）——`maxTokens:1` 仍返回完整十行输出。
+
+### 立案跟踪（未在本轮修）
+| 缺陷 | 处置 |
+|---|---|
+| F2 write 诊断 stale（flycheck 不随 didChange 刷新） | 需设计决策（过滤 rustc 源 / 触发 `rust-analyzer/runFlycheck` / 延迟双拉），单开 change |
+| F8 maxTokens 端到端丢失（zai/pi-ai 路由，dashr 边界之下） | 在 pi-natives/zai 侧单独立案 |
+| F9 `dir(tool)` 空目录 | 沿用欠账（真实绑定集在 `__dashr_injected__`） |
+| F10 wire 层静默丢未知键（两面错误词汇不对称） | 宿主 dispatch 行为，dashr 侧不可修，记录在案 |
+
+
+---
+
+# v0.2.0 系列实测报告
+
+## v0.2.0a（honest-feedback，commit `5142d8c`，tag 已打）
+- F2 两段式 didSave 新鲜度管线 + 超时丢 rustc 降级 + span 兜底（378 tests 绿）
+- F9 `dir(tool)` 返回排序绑定名（真 kernel 验证）
+- **已复测（v0.2.0b 轮，2026-08-28，详见 `docs/v0.2.0b-实测报告.md`）**：F2 关闭（target 坏→好不再报旧错，超时丢 rustc 实测两态）、F9 关闭（`dir(tool)` 26 排序绑定名）、回归面全绿
+
+## v0.2.0b（hashline-edit，PID 3611429，379 tests 绿）
+- **hashline edit 家族首次接线**（v0.1.8c vendor 的树，躺了三个版本）：`edit`（hash 锚定，own-layer shadow 内建）+ `undo_last_edit` + write preview hook + guidance sections（agentPresets fast path）
+- **lsp 反馈环覆盖 edit**：post-execute hook 读落盘内容 → 诊断摘要附结果文本（write 走 wrapper 钩子不双拉）
+- housekeeping：pi-natives 核对**已登记**（欠账记录未同步，本轮更正）；package-lock 完整 re-resolve 三次卡死（registry 不通）→ 降级为身份字段对齐，完整同步挂 Open Question
+- **复测点**（已测，详证见 `docs/v0.2.0b-实测报告.md` §3）：
+  - [x] `read` 一个文件 → 行锚仍在（hashline read 原有面不回归）
+  - [x] `edit` 用锚元组改文件 → 落盘生效（结果为 hashline diffstat 形态；auto-read preview 属 write hook，edit 面不附——如实记录）；`undo_last_edit` 回退且恢复行锚 hash 与原锚一致
+  - [x] edit 引入类型错误（.rs target 文件）→ 结果文本附诊断摘要（F2 契约，post-execute 钩子）
+  - [x] 内建 edit 不可达（shadow 生效，行为证：锚元组/E_STALE_ANCHOR/undo 配对语义）；guidance sections 覆盖内建 tool guidance（会话 system prompt 携 hashline 指引全文）
+  - [x] write 结果 preview + 诊断双附加共存（create 路径再加格式化，三附加共存）

package/node_modules/better-dsh/docs/50_test-reports/v0.2.0b-/345/256/236/346/265/213/346/212/245/345/221/212.md

@@ -0,0 +1,123 @@
+# v0.2.0b 实测报告（honest-feedback + hashline-edit）
+
+- 部署：commit `b2d69ea`（tag `v0.2.0b`），版本 `0.2.0-b`，profile web
+- 套件：commit 自述 30 文件 / 379 tests 绿
+- 被测内容：v0.2.0a（honest-feedback：F2 两段式 didSave 新鲜度 + span 兜底；F9 `dir(tool)` 真目录）+ v0.2.0b（hashline-edit：vendored 编辑家族首次接线，lsp 反馈环挂 edit）
+- 实测人：被测 Dash Agent 运行时本体（第一人称），2026-08-28，路由 zai-plan / glm-5.3
+- 探针工件：`docs/v0.2.0b_artifacts/`（f2probe / slowprobe 两个 cargo 工程 + hashline-probe.md；target 目录已清，源码留档）
+
+## 部署核验（实测前置）
+
+- 源码版本 `0.2.0-b`（dashr/package.json），工作树 HEAD `b2d69ea`，tag `v0.2.0a` / `v0.2.0b` 均在。
+- 部署位 `~/.dsh/profiles/web/node_modules/@pgmi-builds/dashr`，`lib/index.js` 构建于 2026-08-28 15:29:37，与工作区 `dashr/lib/index.js` **md5 逐字节一致**（`f69d4912f6e697d613e87cb50aa18c4b`）。
+- 部署 lib 含新符号：`notifyDidSave`×2、`timeout-dropped-rustc`×2、`registerEditTool`/`registerUndoTool`/`registerWriteHook`/`installAgentTools`/`composeSections` 各 2，`__dir__` 在位。
+- 源码级核验：两段式等待 + rustc 丢弃 + `check` 字段在 `lsp-device.ts`（diagnostics action，`saved:true` 分支）；span 行级过滤在 `url-schema/index.ts:104-105`（`record.line <= content.split('\n').length`）；hashline 接线（edit/undo/write-hook + guidance）与 edit 的 `tools/post-execute` 诊断钩子（跳过 `write` 名）在 `url-schema/index.ts` installAgentTools。
+- dsh-web PID：commit 自述 3611429；本实测 shell 处于 bwrap（`--unshare-pid`）沙箱，宿主 PID 不可独立复核——**运行时新鲜度改由会话面本身坐实**：本会话绑定集含 `undo_last_edit`（v0.1.9 的 25 名之外的新名）、edit 呈 hashline 锚定语义、didSave 管线行为可见（下述）。
+- control-prompt.md：`kernel` 措辞 0 处（md5 `6ec2ec00…`）。
+
+## §1 F9 — `dir(tool)` 真目录（honest-feedback D3）
+
+- [x] `dir(tool)` 返回 **26 个排序绑定名、零 dunder**（v0.1.9 为 28 dunder / 0 绑定名）：agent、agent_message、agent_workflow、ask_user_question、bash、create_goal、edit、exit_plan_mode、get_goal、glob、grep、job_kill、job_list、job_output、llm_completion、memory_add、memory_flush、memory_list、memory_search、read、read_image、todo_write、**undo_last_edit**（新）、update_goal、web_search、write。
+- [x] `__dashr_injected__["tool"]["functions"]` 形态不变（list，26 名），与 `dir(tool)` **逐名相等**（集合断言 True）——兼容面未动，符合「仅加不改」。
+- [x] 三面不变式保持：`dir(tool)` ≡ `__dashr_injected__` ≡ wire 面 − {`eval`}；`eval` 例外恰好成立；mask 九名（skill/send_message/report/list_agents/subagent/subagent_fork/interrupt_agent/workflow/ralph）双面零出现。
+
+**F9 关闭。**
+
+## §2 F2 — write 诊断新鲜度（honest-feedback D1/D2）
+
+探针：`f2probe`（真 cargo target `src/main.rs`，遵守 v0.1.9-c 方法论教训——游离文件不产 flycheck 诊断）；`slowprobe`（`build.rs` 睡 6s，`cargo check` 实测 6.4s，用于确定性超时）。
+
+### 核心场景（坏→好→坏，wire 直调面）
+- [x] 写坏（`let x: u32 = "oops"`）→ 结果附 `1 error(s), 1 hint(s) — first: mismatched types\nexpected \`u32\`, found \`&str\``（新鲜 E0308）。
+- [x] **改写正确内容（`let x: u32 = 2026`）→ 旧错不再出现**：结果只有 `Updated <path>` + preview，无诊断行；cell 面 JSON 同样**无 `diagnostics` 键**（v0.1.9 三轮在此处必报旧 E0308）。**「A fixed error stops being reported」场景通过——F2 主验收成立。**
+- [x] 再写坏 → 错误回归（管线活着，非静默哑掉）。同行位新旧内容（坏/好均在 line 2）也如此——didSave 主干确实覆盖「同行 stale」漏检区（span 兜底管不到的区域）。
+
+### 超时降级（诚实策略）
+- [x] 设备面（`dvc://lsp` 直调，`{action:'diagnostics', file, content, saved:true}`）返回体带 **`check` 字段**，两态均第一人称捕获：
+  - `check: "completed"` — 新鲜 rustc 记录在场（error+hint，span 对准 override 内容的 line 6）；
+  - `check: "timeout-dropped-rustc"` — **内容明明是坏的，`diagnostics: []`、`summary: "no diagnostics"`**：rustc 源被丢、不误报（发生在 slowprobe 检查进行中的争用窗口）。「Slow checks degrade honestly」场景通过。
+- [x] 确定性慢路径：`touch build.rs` 后 wire 写坏内容 → 结果**无诊断行**（flycheck 6s > 3s 预算）；缓存转热后同内容写/查 → 错误正常出现。降级与恢复均如设计。
+- [x] 超时窗口内 write 面是「诚实的沉默」：宁少报不误报（设计明示取舍，见观察 O4）。
+
+### span 兜底（D2）
+- [x] 行为面：13 行坏内容（错在 line 7）→ 立即覆写 2 行正确内容 → **无任何越界旧错泄漏**（本次由超时丢弃覆盖；两保护层在此场景下输出一致）。
+- [~] **guard 单独触发未第一人称分离**（两保护层输出同形）：以源码核验补证（index.ts:104-105 过滤 + summary 按 retained 重算），单元测试覆盖（tasks 1.4）。如实记录。
+
+**F2 关闭**（write 面契约级；残余仅「guard 独立触发未单独目击」，已有源码+测试双证）。
+
+## §3 hashline-edit（v0.2.0b 主体）
+
+- [x] **read 锚面不回归**：全程 `HASH│content` 行锚（本报告所有探针读写均经此面）。
+- [x] **edit 锚元组落盘**：`{path, edits:[[hash,hash,text]]}` 一击替换成功，响应为 hashline diffstat 形态（`Successfully edited 1 file(s) — 1 of 1 edit(s) applied. Added 1 line(s), removed 1 line(s).`），未触碰行锚点稳定不变（s33/AuN/nyO/DBc 跨编辑保持）。
+- [x] **drift 校验**：复用已失效锚（`zlr`）→ `[E_BATCH_ABORT]` + `[E_STALE_ANCHOR] "zlr"` 硬拒，**整批原子、零写入**。
+- [x] **undo_last_edit 回退**：`Removed 1 line(s) … restored 1 line(s)`，diff 展示回退；被恢复行的锚 hash 与原锚完全一致（**hash 确定性**：同内容同锚，双向稳定）。
+- [x] **edit 引入类型错误 → 结果文本附诊断摘要**（spec 关键场景）：main.rs 好态下锚编辑 `let x: u32 = "edit-introduced"` → edit 结果第二行即 `1 error(s), 1 hint(s) — first: mismatched types…`。post-execute 钩子端到端成立；edit 无 format（D3 取舍符合）。
+- [x] **shadow 生效（行为证）**：edit 呈 hashline 语义（锚元组/E_STALE_ANCHOR/diffstat/undo 配对）——与宿主原生 old_string/new_string 形态完全不同；mask 名单无 `edit`（九名不变）；绑定集 edit/undo_last_edit 在位。**guidance sections 在场**：本会话 system prompt 携带 hashline 编辑指引全文（bare 3-char HASH anchor 用法、undo_last_edit 说明、`HASH│content` 行格式、`[E_RANGE_STALE]`/`[E_RANGE_UNSERVED]` 词汇表）——compiled defaults 对内建 tool guidance 的同层 shadow 第一人称可见。
+- [x] **write preview + 诊断 + 格式化三附加共存**：一笔 create 写入混乱风格坏内容（`src/bin/messy.rs`，真 cargo target）→ 单一结果同时含 ① `Created <path>` ② 诊断行（针对**落盘后**内容）③ Auto-read preview 展示 **rustfmt 归整版**（盘上字节核验一致：`pub fn messy_v020b(x: i32) -> i32 {` 多行展开）。F11（create 路径格式化）与 preview/诊断叠加态不互斥。
+
+## §4 回归面
+
+- [x] `agent` one-shot wire 直调：`REGRESS-OK-D`（顺带 F10 复核：附 `bogus_param` 仍正常 spawn——wire 层静默丢未知键，行为不变，立案口径不变）。
+- [x] `agent_workflow` script 模式 wire 直调：`SCRIPT-WIRE-OK-D`（F1 保持关闭）；**新观察**：`meta` 现在强制 `description` 非空（仅 `{name}` 得结构化错误 `meta.description must be a non-empty string`），见 O2。
+- [x] `llm_completion`：`PONG`（裸 string 根）。
+- [x] **F8 复核：仍在**（立案跟踪一致）：`maxTokens:1` 返回完整五十词计数 + `DONE`（dashr 边界之下，pi-natives/zai 侧）。
+- [x] URL 面：`ctx://model` 三键（zai-plan / glm-5.3）；`dvc://` 四设备 roster（ast_edit/ast_grep/browser/lsp）；未注册 scheme 报错列 7 scheme；`skill://grilling` 全文可读（1842 字节）。
+- [x] mask 九名零出现；`eval` 三面例外恰成；control-prompt `kernel` 0 处。
+
+## 结果
+
+**总体判定：v0.2.0b 全部验收点通过。F2 关闭（write 反馈环不再报旧错，超时诚实降级）、F9 关闭（`dir(tool)` 真目录）；hashline 编辑家族（read 锚 → edit → drift → undo → 诊断随 edit）端到端成立，write 面 preview/诊断/格式化三附加共存。无新增 P1/P2 缺陷。**
+
+### 通过项
+| # | 项 | 证据 |
+|---|---|---|
+| P1 | F9 `dir(tool)` 真目录 | 26 排序绑定名（原 28 dunder/0 名）；≡ `__dashr_injected__`（形态不变）≡ wire − {eval}；mask 九名零出现 |
+| P2 | F2 坏→好→坏 | 好内容写后旧 E0308 消失（wire 无行 / cell 无键），再坏回归；同行位新旧亦然 |
+| P3 | F2 超时降级 | 设备面 `check` 两态实捕：`completed`（新鲜 rustc）/ `timeout-dropped-rustc`（坏内容 → `[]`，不误报）；build.rs 睡 6s 确定性复现 |
+| P4 | span 兜底 | 13 行坏（line 7 错）→ 2 行好覆写零泄漏；源码+单测补证（两保护层输出同形，未单独目击，如实记录） |
+| P5 | hashline edit 家族 | 锚元组落盘 + 未触行锚稳定 + `E_STALE_ANCHOR` 原子硬拒 + undo 回退（hash 确定性）|
+| P6 | lsp 反馈挂 edit | 锚编辑引入 E0308 → edit 结果文本即附诊断摘要（post-execute 钩子，spec 场景逐字成立） |
+| P7 | shadow + guidance | edit 呈 hashline 语义（行为证）；system prompt 携 hashline 指引全文（compiled defaults 同层 shadow） |
+| P8 | write 三附加共存 | create 写混乱坏 .rs：`Created` + 诊断行 + rustfmt 归整 preview（盘上字节一致） |
+| P9 | 回归面 | REGRESS-OK-D / SCRIPT-WIRE-OK-D / PONG / URL 四 scheme / kernel 0 / mask 不变 |
+
+### 观察与欠账（无缺陷定级）
+| # | 级 | 观察 |
+|---|---|---|
+| O1 | 观察 | 本会话**首笔**带诊断的 wire write 结果缺 `Updated <path>` 操作行（其余 9 笔均在，含同场景重放）——一次性、疑与 RA 冷启动相邻，未复现；监控即可 |
+| O2 | P3 | `agent_workflow` 的 `meta` 校验收紧：强制 `description` 非空（v0.1.9 轮次 `{name}` 可用）。行为合理，属 schema 演进——工具声明/design 文档宜同步一句 |
+| O3 | 记录 | `check` 字段只在设备面（`dvc://lsp` 返回体）；write 面折叠为摘要字符串。与 design「设备返回值带 check」一致，非缺陷——两面语义边界记录在案 |
+| O4 | 记录 | 超时窗口内 write 面是「诚实的沉默」：坏内容在 flycheck 未完成时**完全不报**——「无消息」在模型侧可读作「好消息」。设计明示取舍（宁少报不误报）；若未来要消歧，可在 write render 附 `check: timeout` 提示行（一行改动，非本轮 scope） |
+| F8 | 立案 | maxTokens 端到端丢失（zai/pi-ai 路由，dashr 边界之下）——复核仍在，处置不变（pi-natives/zai 侧单独立案） |
+| F10 | 立案 | wire 层静默丢未知键（宿主 dispatch 行为）——复核仍在，dashr 侧不可修，记录在案 |
+
+### 建议
+1. O2 的 `meta.description` 必填写进 agent_workflow 工具声明文案（一句），免得下轮实测再撞。
+2. O4 若要做，是 write render 的一行增量（`check==='timeout-dropped-rustc'` 时附提示行）；独立小 change，优先级随真实误判案例再定。
+3. O1 保持观察：若再现实锤（冷启动 + 诊断 + 操作行丢失三连），去 write render 的组合路径查竞态。
+4. 探针工件留在 `docs/v0.2.0b_artifacts/`（target 已清，源码留档可复跑）。
+
+## §5 附：与 v0.1.9 开局状态的对照
+
+| 面 | v0.1.9-c | v0.2.0b（本轮） |
+|---|---|---|
+| `dir(tool)` | 28 dunder、0 绑定名（F9） | 26 排序绑定名，≡ 注入集 ≡ wire−{eval} |
+| write 诊断 | 坏→好后仍报旧 E0308（F2） | 好内容即静默；坏回归；超时丢 rustc 不误报 |
+| edit 形态 | 宿主原生 old/new（vendored 树躺着） | hashline 锚元组 + drift 硬拒 + undo + 指引 shadow |
+| edit 反馈 | 无（edit 不入反馈环） | 落盘即附诊断摘要 |
+| write 结果 | Created/Updated（+诊断行，0.1.9-b 起） | + Auto-read preview（hashline write-hook） |
+
+
+---
+
+## §6 后续：依赖面重组根治 lock 欠账（v0.2.0-c）
+
+**背景更正**：v0.2.0-b 报告「registry 网络不通」为**误判**——registry 完全通（ping PONG 251ms、curl 200、102 请求全 200 零重试）。真因两层：
+1. `npm install --package-lock-only` 会把 node_modules 实树里「已存在」的 optional peers（196 个手动落盘的 @deepseek-ai 包）纳入解析，传递树全展开 → 706 包级解析；
+2. npm arborist 在该树上内核态自旋（18 分钟 stime=1110s / utime=0）。
+
+**根治（用户方案）**：dashr 是插件非自足发行版，宿主（dsh）必带 @deepseek-ai 全家 → 39 个 devDependencies 的 @deepseek-ai 包全部挪 `peerDependencies`（+peerDependenciesMeta optional，共 43 peers），devDependencies 只留 5 个构建/测试工具（@types/node、node-addon-require-builtin、tsdown、typescript、vitest）。
+
+**lock 重建**：stash node_modules（同盘 rename）后纯声明解析 **7.7 秒**完成（vs 18 分钟自旋），lock 从 706 包瘦身到 **182 包**，version 0.2.0-c。node_modules 恢复后 typecheck/vitest 全绿（379）、build 正常（途中修复了 npm 清空的 .bin 链接——重建 tsdown/vitest/tsc 三个符号链接）。
+
+**运维注意**：重建 node_modules 仍靠手动拷贝/从 dsh 单体复制（peer 不自动装）；.bin 若再被 npm 清空，按 `ln -s ../<pkg>/<bin> node_modules/.bin/<name>` 重建。

package/node_modules/better-dsh/docs/50_test-reports/v0.2.1-/345/256/236/346/265/213/346/212/245/345/221/212.md

@@ -0,0 +1,110 @@
+# v0.2.1 实测报告（挂载核验：工具面 + REPL + MCP 桥接）
+
+- 部署：commit `06e516a`（describe `v0.2.0c-3-g06e516a`），版本 `0.2.1`，profile web
+- 部署位 `~/.dsh/profiles/web/node_modules/@pgmi-builds/better-dsh/lib/index.js` 与工作区 `dashr/lib/index.js` **md5 逐字节一致**（`a5490f0b635f6dfc9109b3ed026d2298`，构建于 Sep 1 00:50）——运行态与工作区 lib 同步，非陈旧部署
+- 被测内容：本轮为「挂载核验」而非功能特性验收——REPL 挂载态、工具面 mask 不变式、MCP 桥接 best-effort 语义、control/catalog prompt 的 hint 到位情况
+- 实测人：被测 Dash Agent 运行时本体（第一人称），第一人称 `eval` 探针直接读 `dir(tool)`
+
+## 部署核验（实测前置）
+
+- 源码版本 `0.2.1`（dashr/package.json），工作树 HEAD `06e516a`；`git describe` = `v0.2.0c-3-g06e516a`。
+- 工作树有未提交改动（`dashr/src/fallbacks/*` 删除、package.json/build-client 修改等，与 v0.2.1 fallbacks vendoring Path B 对齐）；但 `dashr/lib/index.js` 已构建且与部署位 md5 一致，**lib 面代表运行态**。
+- mask 名单在 lib 内（`MASKED_TOOL_NAMES` / `WIRE_MASKED_NAMES`，`src/index.ts:166`）：`skill`、`send_message`、`report`、`list_agents`、`subagent`、`subagent_fork`、`interrupt_agent`、`workflow`、`ralph` 九名。
+
+## §1 REPL 挂载（✅ 正确）
+
+- [x] `eval` 传输工具在位，跑在真实 IPython kernel（`sys.version` = **3.14.4**；README 文档的 managed venv 默认 CPython 3.11 未命中——当前用宿主 python 或显式 `DASHR_KERNEL_PYTHON`，非缺陷，见 O1）。
+- [x] 会话持久化（state codification）成立：一笔 cell 赋的 dict 探针在下一笔 cell 原样读回。
+- [x] `tool` 命名空间类型 `_DashrBindingHolder`；`__dashr_injected__` 在位（兼容面未动）。
+- [x] `dir(tool)` 返回 **24 个排序绑定名、零 dunder**（introspection 契约 F9 成立）。
+- [x] `eval` 自排除成立：`'eval' in dir(tool)` = `False`（self-call prevention，spec 唯一例外）。
+
+## §2 工具面 mask 不变式（⚠️ 一处回归）
+
+- [x] 三桥在位：`agent`、`agent_message`、`agent_workflow`（registry 工具，非手写桥 schema）。
+- [x] `llm_completion` 在位。
+- [x] hashline 编辑家族 `edit`/`undo_last_edit` 在位；URL 包装 `read`/`write`/`grep`/`glob` 在位。
+- [x] mask 九名中 **8 名双面零出现**：`skill`、`send_message`、`report`、`list_agents`、`subagent_fork`、`interrupt_agent`、`workflow`、`ralph`。
+- [x] **回归**：`subagent` 双面泄漏——wire 工具声明在列（签名 `{description, prompt, run_in_background?}`，无 `mode`，即**宿主原生 subagent**，非 dashr `agent` 桥），且 `'subagent' in dir(tool)` = `True`。
+  - v0.2.0b 报告明确记录「mask 九名双面零出现」，本轮 `subagent` 回潮，属 **v0.2.0c→v0.2.1 区间引入的回归**。
+  - 部署 lib 与工作区同步（md5 一致），排除「陈旧部署」解释——是运行期 mask 未生效，非名单缺项。
+  - 最可能机制：mask 接线（`src/index.ts:1036-1039`）对整表 `restrict({deny})` 抛错后逐名降级，`subagent` 单名 `restrict` 抛「non-restrictable layer」被 catch 静默跳过（唯一静默跳过路径）。**宿主层根因待确认**（见建议 1）。
+
+## §3 MCP 桥接 best-effort + 非平坦定义（✅ 语义正确）
+
+- [x] wire 面 14 个 MCP 工具（3 server：`orch-a2a` / `web-reader` / `zai-vision`），**0 个进 REPL 绑定**——自动桥接按 `isFlatBindableName` 机械跳过，符合 spec「Non-flat names SHALL be skipped」。
+- [x] best-effort 的「能力不丢」成立：这 14 个 MCP 工具仍以**直接工具调用**形式可达（wire 声明在列），只是不能在 cell 内 `tool.<name>` 命中。
+
+### 「非平坦」的精确口径（纠正常见误读）
+
+`isFlatBindableName`（`src/py-sdk.ts:447`）四条件**同时**满足才叫「平坦（flat-bindable）」：
+
+1. 匹配 `^[A-Za-z_][A-Za-z0-9_]*$`（纯 ASCII 标识符）；
+2. 不以 `_` 开头；
+3. 非保留字（ECMAScript ∪ Python 并集）；
+4. 非 5 个保留绑定全局（`console`/`__dsh_main__`/`__builtins__`/`__name__`/`__debug__`）。
+
+**`__` 中缀本身不构成非平坦**——`__` 是合法 Python 标识符字符。实测：
+
+- `'mcp__server__tool'.isidentifier()` = `True`（纯 `__` 中缀、无连字符 → 合法，可平坦绑定）；
+- 真实 MCP 名 `mcp__orch-a2a__a2a_agents` 的 `isidentifier()` = `False`。
+
+**真正的元凶是连字符 `-`**（server 段 `orch-a2a`/`web-reader`/`zai-vision`），不是 `__`。所以「包含 `__` 就叫非平坦」是常见但不精确的 shorthand：`__` 是 MCP 命名约定的**作用域分隔符**，而让它非法的是名字里混进的 `-`（及任何非 `[A-Za-z0-9_]` 字符）。
+
+## §4 prompt hint 到位情况（✅ 已说明，属事实局限，非 defect）
+
+用户的判定标尺：hint 缺失 → defect/discrepancy；hint 已在而运行期确实做不到 → 事实局限。**结论落在后者**。
+
+- [x] **hint 在位**。system prompt 的「Calling tools from the scripting pad」段（=`dashr:tool-catalog` 节的 `REPL_BRIDGE_INSTRUCTIONS`，`src/py-sdk.ts:616`）逐字给出：
+  > Tool names that are not plain identifiers (for example MCP names with hyphens or `__` infixes) have no `tool.<name>` member — call those as direct tool calls.
+- [x] 运行期确实如此（§3 已证：14 MCP 工具 0 绑定，仅直接调用可达）。**文档与实现一致，是已声明的边界，不是缺说明的 defect。**
+- [~] 次要观察 O2：hint 只在 **catalog 段**（`dashr:tool-catalog`）给出；**control 段**（`dashr/control-prompt.md`，「Tools inside a cell」写的是「every native tool is a member of the `tool` object」）**未提**非平坦例外。二者同在 system prompt、且 control 段的「native tool」措辞与 MCP 工具不在同一范畴，故不算自相矛盾；但若未来 control 段独立渲染（脱离 catalog 段），hint 会随 catalog 段一起消失——记录为提示性观察。
+
+## §5 eval 工具描述与行为不一致（❌ discrepancy）
+
+- **现象**：`eval` 的 model-facing 描述承诺「top-level `await` and `return` work」——`EVAL_DESCRIPTION`/`EVAL_CELL_PARAM_DESCRIPTION`（`src/index.ts:205-217`），control 段 `control-prompt.md:8` 同文。运行期顶层 `return` 是 SyntaxError。
+- **复现（本会话第一人称）**：cell `x = 41; print(...); return "cell finished"` → `SyntaxError: 'return' outside function`（`_DashrTopLevelReturnChecker` 于 AST 访问期抛出，`src/bootstrap.ts:231-250`）；去掉 return 即正常。行为有测试固化：`test/runtime.spec.ts:92`「rejects a top-level 'return' as a SyntaxError, like a native IPython cell」。
+- **机制**：kernel 按纯 IPython REPL 语义运行 cell——module scope（globals=locals）、`PyCF_ALLOW_TOP_LEVEL_AWAIT` 编译 + `eval`/`await` 执行模块协程（`src/bootstrap.ts:255-280`）；顶层 `return`/`yield` 由 checker 显式判 SyntaxError，嵌套函数/类/λ 内 return 语义保留（与原生 Python 一致）。
+- **根因**：描述文本是旧设计残留——blueprint（`docs/plans/dashr-blueprint.md:499`「top-level return = rewriter 改写为 `_DashrReturn`（BaseException）」）在 08-19 原生语义重构后**未随实现同步更新**；实现侧注释（`src/python.ts:6`、`src/bootstrap.ts:257-260`）写的是正确语义。**contract 对模型撒谎：承诺了 kernel 刻意拒绝的特性。**
+- **影响**：模型按描述在 cell 内写顶层 `return`（本会话即发生），白费一轮往返。
+- **await 条款核实（非 discrepancy）**：描述中「top-level `await` works」行为为真——kernel 确以 `PyCF_ALLOW_TOP_LEVEL_AWAIT` 编译并运行模块协程；且该能力是环境特性而非纯 Python（实测见会话讨论），故保留该条款必要且准确，仅 `return` 条款需修正。
+
+## 结果
+
+**总体判定：REPL 正确挂载；工具面存在 1 处回归（`subagent` 泄漏）+ 1 处描述不一致（eval 顶层 `return` 承诺与行为相悖，await 条款属实）；MCP 桥接 best-effort 有文档说明、属事实局限而非缺陷。**
+
+### 通过项
+
+| # | 项 | 证据 |
+|---|---|---|
+| P1 | REPL 挂载 | eval 传输在位、IPython 3.14.4、dict 探针跨 cell 持久、`dir(tool)` 24 名零 dunder |
+| P2 | 三面例外不变式 | `eval` 自排除（`'eval' in dir(tool)`=False） |
+| P3 | 桥接家族 | `agent`/`agent_message`/`agent_workflow` + `llm_completion` + hashline `edit`/`undo_last_edit` + URL 包装四件套在位 |
+| P4 | MCP best-effort | wire 14 MCP 工具 → 0 REPL 绑定；能力经直接调用保留 |
+| P5 | 非平坦语义 | `isFlatBindableName` 机械跳过；`__` 中缀合法（实测 `isidentifier()=True`）、连字符是元凶（实测 `False`） |
+| P6 | hint 到位 | catalog 段逐字声明非平坦例外，与运行期一致 |
+
+### 观察与欠账
+
+| # | 级 | 观察 |
+|---|---|---|
+| D1 | **P2（回归）** | `subagent` 双面泄漏（wire + REPL），v0.2.0b「mask 九名零出现」→ 本轮回潮；部署 lib 同步排除陈旧部署；疑 `restrict` 单名降级静默跳过，宿主层根因待确认 |
+| O1 | 记录 | kernel Python 3.14.4，README managed venv 默认 3.11 未命中（宿主 python 或显式 `DASHR_KERNEL_PYTHON`）；非挂载缺陷 |
+| O2 | 提示 | 非平坦 hint 只在 catalog 段（`dashr:tool-catalog`）；control 段（`control-prompt.md`）措辞「every native tool」未提例外。当前二者同屏无矛盾；若 control 段未来独立渲染则 hint 可能失陪 |
+| O3 | 提示 | hint 原文「hyphens or `__` infixes」并列举例略宽：`__` 中缀单独是合法标识符，真正非法的是 `-`。措辞方向正确（真实 MCP 名两者兼有），不算错误，但可收紧为「non-identifier characters such as hyphens」 |
+| D2 | **描述不一致** | eval 描述承诺「top-level `return` work」，运行期为 SyntaxError（`_DashrTopLevelReturnChecker` 显式判错，`test/runtime.spec.ts:92` 固化）；旧 rewriter 设计残留文本未随 08-19 原生语义重构更新（`src/index.ts:205-217`、`control-prompt.md:8`）。await 条款实测为真，不属此 discrepancy |
+
+### 建议
+
+1. **D1 回归定位**：在宿主层复核 `tools.restrict({deny:['subagent']})` 为何抛错/被跳过——确认 `subagent` 是否落在 non-restrictable 层（对比 v0.2.0b 到 v0.2.1 的 fallbacks vendoring 是否改变了该工具注册层）。修复优先级高于本轮其它项。
+2. O3 的一行措辞收紧：把 bridge instructions 里的 `hyphens or \`__\` infixes` 改为 `non-identifier characters (e.g. hyphens)`，避免模型把 `__` 误读为禁用符。
+3. O2 若在意，可在 `control-prompt.md` 的「Tools inside a cell」补半句非平坦例外，与 catalog 段互为印证。
+4. **D2 契约修正**：`EVAL_DESCRIPTION`/`EVAL_CELL_PARAM_DESCRIPTION`（`src/index.ts:205-217`）与 `control-prompt.md:8` 的「top-level `await` and `return` work」改为「top-level `await` works（kernel 以 `PyCF_ALLOW_TOP_LEVEL_AWAIT` 编译并运行模块协程，同 IPython cell）；顶层 `return` 是 SyntaxError——cell 以 module scope 运行」。await 条款保留（行为为真，且该能力非纯 Python，正需向模型声明）。
+
+## D1 后续处理（2026-09-01，v0.2.1b）
+
+**根因已确认（源码核实 + 会话日志实证）**：standard preset（`dsh-agent-presets/presets/standard/agent.cordis.yml`）的 `tool-subagent` 行配置 `modelSelectionSettings: true` → dsh-tool-subagent 的 `agent/created` 监听走 `candidate.ctx.inject([...])`，把 subagent 工具注册到**该 agent 自己的层**（own layer）；registry `restrict` 只过滤 inherited 名（global + ancestors），own-layer 名永远可见、不可 restrict（dsh-tools `view()` 对 own.tools 无条件 visible）→ `restrict({deny:['subagent']})` 抛「unknown global tool」→ DASHR mask catch 静默跳过 → 全表面泄漏。其余八名（subagent_fork / workflow / ralph 等）无 modelSelectionSettings → composition 层 → 可 restrict → 正常。**v0.2.1 报告的 fallbacks 假设不成立**（06e516a 全为 LLM failover 机制）。
+
+**v0.2.1b 决策（用户拍板，临时方案）**：接受暴露，不做 mask/覆盖——`subagent` 从 `MASKED_TOOL_NAMES` 移除（九名 → 八名）；在 `control-prompt.md` 自由文本注解 `subagent` 为 `agent`（统一 agent-spawn 入口）的 alias、两者经同一 runtime 委托，保持模型面逻辑自洽。彻底方案（部署配置 modelSelectionSettings: false / DASHR own-layer 防线 / 上游修复）另行 change。
+
+**实现状态**：v0.2.1b change（`openspec/changes/v0-2-1-fixes-and-escalation-guidance/`）内 D1/D2/O2/O3/escalation-guidance 全部落地，测试与部署核验见该 change 任务清单。

package/node_modules/better-dsh/docs/50_test-reports/v0.2.1b-/345/256/236/346/265/213/346/212/245/345/221/212.md

@@ -0,0 +1,86 @@
+# v0.2.1b 实测报告（v0-2-1-fixes-and-escalation-guidance 第一人称复核）
+
+- 部署：commit `247326a`（`v0.2.1a`），版本 `0.2.1-b`（package.json），profile web，宿主已重启、本会话运行于更新后的运行时
+- 被测内容：**仅本 change**（`openspec/changes/v0-2-1-fixes-and-escalation-guidance/`）的四个面——D1 subagent 接受暴露 + alias 注解、D2 eval 描述契约、O2/O3 非平坦措辞、escalation-guidance 注入。不复核既往 feature/change
+- 实测人：被测 Dash Agent 运行时本体（第一人称）；注入探针直接读自身 system prompt 的 runtime-context 快照，工具面探针经 `dir(tool)` 与 wire 声明
+- 对应任务清单：tasks.md 5.3「宿主重启新会话后复核」——本报告即该复核的记录
+
+## 部署核验（实测前置）
+
+- 工作树 HEAD `247326a`（describe `v0.2.1a`）；本 change 源码改动（`src/index.ts` / `src/py-sdk.ts` / `control-prompt.md` / 测试）为未提交工作树改动，但 `dashr/lib` 已重建且与部署位逐字节一致，**lib 面代表运行态**。
+- md5 核验（工作区 `dashr/lib` ↔ 部署位 `~/.dsh/profiles/web/node_modules/@pgmi-builds/better-dsh/lib`）：
+
+| 文件 | 工作区 | 部署位 | 一致 |
+|---|---|---|---|
+| index.js | `284722a77b1f7fc310a24d0e22d69bb0` | 同左 | ✅ |
+| py-sdk.js | `85691cac2d669fef46f257281f63a44d` | 同左 | ✅ |
+| py-sdk-CbgYiX8O.js（实际实现 chunk） | `8410d97db290eceb1b3ba69cdc8edb86` | 同左 | ✅ |
+
+- lib 产物内容抽查：`MASKED_TOOL_NAMES = new Set([skill, send_message, report, list_agents, subagent_fork, interrupt_agent, workflow, ralph])`（index.js:10894-10903，**八名、无 subagent**）；escalation 注入句出现 1 次；`!sandboxPolicy` fail-closed 分支在位；eval 描述含「top-level `return` is a SyntaxError」；py-sdk chunk 措辞为「non-identifier characters, e.g. hyphens」且全文 0 处 `infixes`。
+
+## §1 D1：subagent 接受暴露 + control prompt alias 注解（✅）
+
+- **源码**：`MASKED_TOOL_NAMES`（`src/index.ts:166`）已移除 `subagent`（九名 → 八名），注释记录 v0.2.1b 决策——standard preset 的 `modelSelectionSettings: true` 使 subagent 注册到 agent own 层、registry restriction 不可达，故接受暴露并以 control prompt 注解替代 mask。
+- **control-prompt.md** 自由文本含 alias 注解（逐字）：
+  > Delegation: `agent` is the unified agent-spawn entry; `subagent` is its native alias — both delegate through the same runtime, so call either.
+- **wire 面（本会话 system prompt 工具声明）**：`subagent` 在列且签名 `{description, prompt, run_in_background?}`（无 `mode`，宿主原生 subagent，与 v0.2.1 判定一致）；`agent` 在列且带 `mode`（dashr 桥）；其余八名（skill / send_message / report / list_agents / subagent_fork / interrupt_agent / workflow / ralph）**双面零出现**。
+- **REPL 绑定（第一人称 `dir(tool)` 探针）**：
+  - `'subagent' in dir(tool)` = **True**（有意保留）｜`'agent' in dir(tool)` = True
+  - 八名泄漏 = **[]**（全部按预期 mask）
+  - `eval` 自排除 True、0 dunder、`_DashrBindingHolder` / `__dashr_injected__` 在位、共 28 个平坦绑定
+- **功能冒烟（alias 注解推荐的直接调用面）**：`subagent` 实际委托成功——`fc86211b-3253-459b-8ed5-e0a8ec35a76c` 创建并结算，返回 `SUBAGENT-ALIAS-OK`。接受暴露不是摆设，委托链路真实可用。
+
+## §2 D2：eval 描述契约与运行期语义一致（✅）
+
+- **描述文本**（`EVAL_DESCRIPTION` `src/index.ts` ~212 与 `control-prompt.md:8` 同一句式，本会话 system prompt 渲染逐字）：
+  > `eval` takes two required arguments: `cell` (one Python program; top-level `await` works; top-level `return` is a SyntaxError — the cell runs in module scope; …)
+- **无 return 承诺**：全文本不再出现「top-level `return` work」；await 条款保留（行为为真）。
+- **行为实证（第一人称）**：提交含顶层 `return` 的 cell → 运行期抛 `SyntaxError: 'return' outside function`，traceback 定位 `_dashr_run_program` → `_DashrTopLevelReturnChecker().visit(parsed)` → `visit_Return` 显式判错（`src/bootstrap.ts:231-280` 路径）。**描述与行为一致，D2 契约修正成立**。
+- **await 条款实证**：cell 内 `await asyncio.sleep(0)` → `await-ok`；await-in-comprehension `[0, 1, 2]`。kernel 以顶层 await 运行模块协程，描述属实。
+- `test/runtime.spec.ts:92`「rejects a top-level 'return' as a SyntaxError」在套件全绿之列。
+
+## §3 O2/O3：非平坦措辞精确化（✅）
+
+- **catalog 段**（`REPL_BRIDGE_INSTRUCTIONS`，`src/py-sdk.ts:616`）已改为（部署 chunk 逐字核验，且全文 **0 处 `infixes`**）：
+  > Tool names that are not plain identifiers (non-identifier characters, e.g. hyphens) have no `tool.<name>` member — call those as direct tool calls.
+- **control 段**（`control-prompt.md`「Tools inside a cell」）已补非平坦例外句，与 catalog 同义（见 §1 引用段）——v0.2.1 报告 O2 的「hint 只在 catalog 段」已闭合。
+- **行为不变式**：MCP 非平坦名仍 0 绑定（本会话 0 个 `mcp*` 进 REPL），能力经直接调用保留；`'mcp__cordis-a2a__a2a_agents'.isidentifier()` = False、`'mcp__server__tool'.isidentifier()` = True——元凶确为连字符而非 `__`，措辞收紧方向与实现一致。
+
+## §4 escalation-guidance 注入（✅，第一人称最强证据）
+
+- **源码**（`src/index.ts:1099-1118`）：`ctx.systemPrompt.context({ name: 'dashr:escalation-guidance', order: ESCALATION_GUIDANCE_ORDER = 116, text })`；text 为 use-time 求值——`sandboxPolicy?.resolve({ session: context.agent?.session })`，`mode === 'workspace-write'` 返回注入文本，否则空串；service 缺失 / 无 agent 时 fail-closed（空串）。注册处注释注明依赖 upstream CONTEXT_ORDERS（110/115/120）。
+- **模式矩阵测试**（`test/presentation.spec.ts:208-281`，v0.2.1b model-surface contracts）：order 116 在位 / workspace-write 注入 / read-only、danger-full-access 空 / 无 sandboxPolicy service 空——套件全绿。
+- **本会话 runtime-context 快照（第一人称实测）**——当前为 workspace-write 模式，快照逐行：
+
+  ```
+  Current DSH file policy: workspace-write. Any available operation enforced by the
+  DSH file sandbox may modify files under the session workspace: "/home/u1/workspaces/dashr". …
+
+  Approval policy: ask. Operations that require approval may ask through the configured
+  answerers; without an available answerer, the request fails closed.
+
+  Restricted operations may be retried once with sandbox_permissions for single-call
+  escalation, pending user approval.
+  ```
+
+  注入句**精确等于** D3 披露文本（`Restricted operations may be retried once with sandbox_permissions for single-call escalation, pending user approval.`），且**紧贴 `approval:policy`（115）之后、`subagent:delegation`（120）之前**——order 116 位置成立，渲染在 policy 段落同一快照内。
+
+## §5 测试套件
+
+- `npx vitest run`：**31 files，392 passed | 3 skipped（395），exit 0**（109.89s）——与 tasks 2.3 / 4.3 预期（395 全绿、presentation.spec 19/19）一致。
+
+## 观察（非缺陷）
+
+| # | 级 | 观察 |
+|---|---|---|
+| O-1 | 记录 | 部署位残留陈旧 chunk `py-sdk-DRmSaN8R.js`（md5 `77cd3ed0…`，内容寻址 chunk，未被引用、无加载风险）——清理可选 |
+| O-2 | 记录 | 本会话 kernel python = 部署 `.venv-kernel` 的 **3.11.15**（traceback 实证 `.venv-kernel/lib/python3.11`）——v0.2.1 报告 O1「managed venv 3.11 未命中、用宿主 3.14.4」在本次重启后已命中 managed venv；环境事实 |
+| O-3 | **已修正为缺陷** | REPL 内工具调用截断的**真实原因**：非阻塞问题，而是任何 `tool.*` RPC 都触发 `registry[TOOL_RUNTIME_SCHEDULER]` 为 undefined → `scheduler.prepare` TypeError → driver 无 catch 的 unhandled rejection → harness `installFailLoud` 判定 fatal → **daemon 崩溃重启** → repair 合成「interrupted」。4/4 复现（17:39/17:41/17:57/18:02），journald 铁证。详见 `docs/REPL-工具调用-截断诊断.md`；修复后需重跑探针矩阵 |
+
+## 结果
+
+**总体判定：v0.2.1b 四项目标（D1 接受暴露 + alias 注解、D2 eval 描述契约、O2/O3 非平坦措辞、escalation-guidance order-116 注入）在新会话运行态下全部成立，无回归、无 discrepancy。**
+
+- v0.2.1 报告的两处问题均已按本 change 落地闭合：D1 回归 → 转为有意暴露 + 注解（功能冒烟通过）；D2 描述不一致 → 描述与运行期语义一致（顶层 return 实测 SyntaxError）。
+- 注入矩阵在 workspace-write（本会话实际模式）下第一人称可见，read-only / danger-full-access 不注入由单测矩阵覆盖。
+- tasks.md 5.3（宿主重启新会话复核）完成：control 段 alias 注解 ✓、eval 描述无 return 承诺 ✓、escalation 注入文本位于 `approval:policy` 之后 ✓。

package/node_modules/better-dsh/docs/50_test-reports/v0.2.1c-/345/256/236/346/265/213/346/212/245/345/221/212.md

@@ -0,0 +1,66 @@
+# v0.2.1c 实测报告（v0-2-1c-repl-tool-crash-fix 第一人称实测）
+
+- 部署：版本 `0.2.1-c`（package.json，工作区与部署位一致），profile web；用户已执行部署同步 + daemon 重启（19:23:19），本会话运行于更新后的运行时
+- 被测内容：**本 change**（`openspec/changes/v0-2-1c-repl-tool-crash-fix/`）的六.1（drive 加 catch）+ 六.2（scheduler 防御）在活体 daemon 上的回归核验基线（六.5）；六.3 根因归属复核
+- 实测人：被测 Dash Agent 运行时本体（第一人称）；探针经 `eval` cell 内 `tool.<name>(...)` 直接调用 REPL 子分派桥——与 v0.2.1b 崩溃复现矩阵完全同路径
+- 对应任务清单：tasks.md 6.1 / 6.2 / 6.3（以及 3.2 活体复核）——本报告即该核验的记录
+
+## 部署核验（实测前置）
+
+- 版本：`dashr/package.json` 与部署位 `~/.dsh/profiles/web/node_modules/@pgmi-builds/better-dsh/package.json` 均为 `0.2.1-c` ✅
+- md5 核验（工作区 `dashr/lib` ↔ 部署位 lib）：
+
+| 文件 | 工作区 | 部署位 | 一致 |
+|---|---|---|---|
+| index.js | `861fb9d3fb108015fb1d665d00d789b2` | 同左 | ✅ |
+| client/index.js | `8b1548613b5d68ef4606f4729b0af312` | 同左 | ✅ |
+
+- `diff -rq lib/` 两侧 **LIB DIRS IDENTICAL**（含删除陈旧 chunk 后的完整目录对比）✅
+- lib 产物内容抽查：六.2 loud 错误文本（`the tools service resolved by this composition lacks the TOOL_RUNTIME_SCHEDULER symbol …`）在 index.js 中出现；六.1 lane backstop（`settling queued dispatches as errors`）在源码 `src/index.ts:642-652` 在位 ✅
+- daemon 重启：journal 显示 19:23:19 旧进程（pid 443984）SIGTERM 优雅停止 → 同一秒新进程（pid 532389→532407→532567）启动；自重启至今 **0 条 fatal / TypeError / FAILURE / restart** ✅
+
+## §1 4 探针矩阵（六.5 回归核验，第一人称）
+
+对照 v0.2.1b 诊断矩阵（`docs/REPL-工具调用-截断诊断.md` §一），同 cell 内容在**本会话（v0.2.1c 运行态）**重跑：
+
+| # | cell 内容 | v0.2.1b 结果 | v0.2.1c 实测结果 | 判定 |
+|---|---|---|---|---|
+| 1 | `await tool.subagent({… run_in_background: false })` | 截断（daemon 崩溃 17:39:17） | cell 收到 `ToolCallError`，消息点名 `TOOL_RUNTIME_SCHEDULER` symbol + scope/service view 上下文 | ✅ 返回结果非截断 |
+| 2 | `await tool.subagent({… run_in_background: true })` | 截断（daemon 崩溃 17:41:15） | 同上 | ✅ 返回结果非截断 |
+| 3 | `await tool.bash({… run_in_background: true })` | 截断（daemon 崩溃 17:57:05） | 同上 | ✅ 返回结果非截断 |
+| 4 | `await tool.read({path: "dashr/package.json"})` | 截断（daemon 崩溃 18:02:27） | 同上 | ✅ 返回结果非截断 |
+
+- **4/4 全部返回可见结果**（loud `ToolCallError`，含完整上下文消息），**零截断、零 daemon 崩溃**。每次探针后 daemon 继续存活、后续 cell 正常执行——与 v0.2.1b 的「探针即杀进程」形成对照。
+- 探针实际收到的错误消息（4/4 逐字一致）：
+  > `eval: the tools service resolved by this composition lacks the TOOL_RUNTIME_SCHEDULER symbol (a scope/service view instead of the native ToolRuntime instance) — REPL sub-dispatch cannot run; check the harness mount wiring (packages/core/tools) resolving the plugin's tools service`
+- **对照结论**：v0.2.1b 同路径的「裸 `undefined.prepare` TypeError → driver 无 catch → unhandled rejection → installFailLoud fatal → daemon exit(1) → repair 合成 interrupted-tool-result」链条已被六.1+六.2 打断。错误现在**在 cell 内可见**，binding promise 正常 settle，进程零外泄。
+
+## §2 journald 守护进程日志（六.5 铁证）
+
+- 自重启时刻 19:23:19 起：`journalctl --user -u dsh.service --since "19:23:19"` grep `fatal|TypeError|FAILURE|restart|crashed|exit` → **0 条匹配**；journal 尾部仅启动 INFO（MCP 注册、dsh web URL）。
+- 对照：v0.2.1b 的 17:39:17 / 17:41:15 / 17:57:05 / 18:02:27 四条 fatal load failure（`Cannot read properties of undefined (reading 'prepare')`）**不再出现**。
+- 会话日志侧：本会话（`session-6c013361…`）**0 条 `interrupted-tool-result`** repair 事件——无截断指纹。且因六.2 guard 在 `binding()` 内、`start()` 之前抛错（`src/index.ts:695-697` 先于 `tool/code-dispatch-start` append），本次探针连半程 dispatch 日志都没有留下——错误在最早点被拒绝，不产生部分状态。✅
+
+## §3 根因归属与交付边界（六.3 活体复核）
+
+- 活体探针结论：**生产组合仍把 `runtimeCtx.tools` 解析为缺 `TOOL_RUNTIME_SCHEDULER` 实例 symbol 的 scope/service 视图**——4/4 探针的 loud 错误本身就是活体证据（错误消息由 guard 在 symbol 判空时抛出，证明运行态确实取不到 symbol）。
+- 与诊断文档 §四/§七的推演一致：测试组合（根作用域原生实例，symbol 在位）全绿，生产组合（preset realm / plugin tree 发布路径带 shadow 标记 → `getTraceable` 返回原型而非实例）缺 symbol——**差异在 harness 侧（dsh-alpha），作为外部依赖记录**。
+- **本 change 的 dashr 交付边界 = 「不崩溃 + loud 错误」——已达成**（§1+§2 实证）。「调度器真正可用、REPL 子分派真实执行」取决于 harness 挂载修正（dsh-alpha），不在本 change 交付物内。
+
+## §4 测试套件
+
+- `npx vitest run`（本轮实测重跑）：**31 files、396 passed | 3 skipped = 399 绿、exit 0**（109.41s）——与 tasks.md 记录的 399 全绿一致，含 3 个 v0.2.1c 韧性回归用例（缺 symbol 视图 → loud 错误；`scheduler.prepare` 抛错 → binding settle 可见错误；classify 抛错 → lane backstop settle 且进程存活）。本轮实测的活体行为与这三个用例的断言一一对应。
+
+## 观察（非缺陷）
+
+| # | 级 | 观察 |
+|---|---|---|
+| O-1 | 记录 | REPL 内 `tool.*` 子分派目前**不可用**（调度器 symbol 缺失，loud 错误可见）——这是 harness 侧外部依赖，非本 change 回归；dashr 侧防御保证了「不可用」以可见错误呈现而非进程崩溃 |
+| O-2 | 记录 | 本次守护进程重启（19:23:19）由用户执行，重启后本会话续跑于新 lib（部署位 md5 与工作区一致）；journal 无旧崩溃残留以外的任何异常 |
+
+## 结果
+
+**总体判定：v0.2.1c 的目标在活体 daemon 上全部成立——六.1（drive 加 catch）阻断 unhandled rejection 外泄、六.2（scheduler 防御）把裸 TypeError 转为 cell 可见 loud 错误；4 探针矩阵 4/4 返回结果而非截断，journald 自重启后 0 条崩溃，会话日志 0 条 interrupted-tool-result 修复事件。**
+
+- tasks.md 6.1（4 探针矩阵 4/4 非截断）✅、6.2（journal 无新崩溃）✅、6.3（本报告）✅、3.2（活体复核：根因确认在 harness，dashr 可及范围防御已实施，harness 侧记录为外部依赖修复）✅。
+- 交付边界已按设计执行：dashr 侧「不崩溃 + loud 错误」；「调度器真正可用」依赖 dsh-alpha 挂载修正，需在 harness 侧 change 中跟进。