super-dsh 0.3.0-c → 0.3.0-e

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

@@ -1,127 +0,0 @@
-# DASHR v0.1.8c 实测报告（URL Schema 第一人称实测）
-
-> 状态：URL schema 已部署到运行时，但**部分生效**——本报告为实测记录 + 待修缺口清单，只做实测/记录，不动代码。
-> 日期：2026-08-26
-> 变更对象：`openspec/changes/url-schema/`（proposal + design + specs + impl-contract）
-> 发布包：`@pgmi-builds/dashr@0.1.10`（`package.json` 已升 0.1.10；本 openspec change 沿用 v0.1.8c 标签）
-
----
-
-## 0. 结论摘要
-
-| 验收面 | 结果 | 一句话 |
-|---|---|---|
-| URL resolver + read 路由 | ✅ 生效 | `read` 能把 `scheme://` 分流到 handler |
-| `skill://` | 🔴 坏 | `ctx.skills` 注册表空，与 prompt 里的 skill 目录不同源 |
-| `agent://`（名册 / 输出 / transcript / child） | ✅ 生效 | 四形态返回真实内容；但名册字段与 spec 不符 |
-| `history://` 并入 `agent://` | ✅ 生效 | 返回「已并入」提示 |
-| `dsh://config` | ✅ 生效 | 返回 resolved settings，无 secret 泄漏 |
-| `dsh://docs` | 🔴 坏 | `docs/` 没打进发布包，`resolveDocsDir` 从安装路径向上找不到 |
-| `ctx://` 读 | 🔴 坏 | URL 分支传空 env，落到 `AGENTLESS_KEY` 空内核 |
-| `ctx://` 写 | 🔴 未接线 | `writeCtxVar` 是死代码，`defaultSchemeWrite` 直接抛不支持 |
-| `xd://` 读 + 写 | ✅ 生效 | 空占位行为与 spec 一致 |
-| selector 语法（`:N-M` / `:raw` / …） | ✅ 生效 | `dsh://config:1-3` 正确按行截断 |
-| 未注册 scheme 报错 | ✅ 生效 | 结构化报错并列出 `registered: agent, ctx, dsh, skill, xd` |
-| mask `skill` 工具（D5） | 🔴 未生效 | 只挡 REPL 的 `tool.*` 面，host 层原生 `skill` + `<available_skills>` 仍在 |
-| **`write` 普通路径（透传）** | 🔴 **回归** | **`write` 工具对工作区任意路径一律拒绝，只放行 `/tmp`；`read`/`edit`/bash 均正常** |
-
-**净结果：6 个 scheme 里 3 个半生效（agent / dsh:config / xd + selector/history），2 个半坏（skill / ctx 读），1 个彻底坏（ctx 写），1 个配套改造（dsh:docs）坏，1 个 BREAKING（mask skill）未生效；另有 1 处**非 URL 路径 `write` 的回归**（破坏「普通路径透传」spec）。**
-
----
-
-## 1. 部署状态确认（不是 stale host）
-
-上一轮 v0.1.8c 实测结论是「stale host + BetterEdit shadow 冲突」。本轮复核**推翻该结论**：
-
-- 运行时实际加载的 DASHR 包 = `~/.dsh/profiles/web/node_modules/@pgmi-builds/dashr`，`package.json` version `0.1.10`。
-- 部署 `lib/index.js`（2026-08-26 04:22 构建，210482 字节）与工作区 `dashr/lib/index.js`（04:21）**逐字节一致**——是最新构建，非旧代码。
-- `dashr/src/url-schema/` 源码完整（resolver / selector / handlers×5 / tools×4 / vendored hashline）。
-- 5 个 handler **都已注册**（未注册 scheme 报错里列得全：`agent, ctx, dsh, skill, xd`）。
-
-所以剩余问题**不是代码没跑起来，是部署接线/打包缺口 + 一处 write 回归**。
-
----
-
-## 2. 逐项实测记录
-
-> 以下均为本人（Dash Agent 运行时）直接调用自身 `read`/`write`/`grep`/`glob` 工具得到的第一人称结果。
-
-| scheme / 面 | 调用 | 实际返回 |
-|---|---|---|
-| skill:// 存在名 | `read skill://markitdown` | `skill "markitdown" is unknown or no longer available`（markitdown 在 `<available_skills>` 里真实存在） |
-| skill:// 不存在名 | `read skill://__nonexistent__` | 同上结构化报错 |
-| agent:// 裸 | `read agent://` | 名册表 `id / origin / depth / cwd`（4 条 session） |
-| agent://<id> | `read agent://<session-id>` | 返回该 agent 最后一条非空 assistant 输出文本 |
-| agent://<id>/transcript | `read agent://<id>/transcript` | 返回完整 transcript（role-headed） |
-| history:// | `read history://` | `history:// 已并入 agent://：…` |
-| dsh://config | `read dsh://config` | 6296 字节 resolved settings JSON；`api` 命中全为端点 URL（`api.z.ai` 等），无 key/token/secret |
-| dsh://docs | `read dsh://docs` | `dsh://docs: no docs directory found (provide docsDir to createDshHandler)` |
-| ctx:// 裸 | `read ctx://` | 空串（空命名空间） |
-| ctx://<var> | `read ctx://probe_marker` | `ctx://probe_marker: no such variable in the kernel namespace`（该变量在 eval 内核里真实存在） |
-| ctx:// 写 | `write ctx://test_var` | `write to ctx:// is not supported (read-only scheme, or its write channel is not wired yet)` |
-| xd:// 裸 | `read xd://` | `no devices mounted` |
-| xd://<device> | `read xd://lsp` | `unknown device: lsp` |
-| xd:// 写 | `write xd://lsp` | `xd:// write dispatch: no devices mounted to route the write to` |
-| 未注册 scheme | `read http://example.com/x` | `no handler registered for scheme "http" (registered: agent, ctx, dsh, skill, xd)` |
-| selector | `read dsh://config:1-3` | 按 1–3 行截断返回 |
-| grep/glob scheme | `grep skill://markitdown`、`glob skill://markitdown/**` | 均因 skill 未知而报错（路由生效，handler 上游失败） |
-| read 普通文件 | `read docs/.__editprobe.md` | 正常返回 `HASH│content` 锚点 |
-| edit 普通文件 | `edit`（先 read 后 edit） | 正常改写，锚点随内容更新 |
-| **write 普通文件** | `write /home/u1/workspaces/dashr/docs/test-ascii.md` | `cannot write "…": file access denied under workspace-write mode` |
-| **write 工作区根** | `write /home/u1/workspaces/dashr/test-root.md` | 同上被拒 |
-| **write /tmp** | `write /tmp/dashr-test.md` | 成功 `{operation: 'create'}` |
-| **bash 写工作区** | `printf … > docs/.__probe.md` | 成功（OS/bash 层不受影响） |
-
----
-
-## 3. 失效点根因（已定位到源码）
-
-1. **`skill://`** —— `dashr/src/url-schema/handlers/skill.ts` 查 `ctx.skills.get(name)`（`@deepseek-ai/dsh-skill` 的 `SkillRegistry`），但该注册表**为空**，与注入 prompt 的 harness session skill 目录（`<available_skills>`）不是同一来源。skill handler 本身逻辑正确（错误分支、`/path` 资源寻址、路径逃逸守卫都在），只是上游 `ctx.skills` 没被喂进实际可用的 skill。
-
-2. **`dsh://docs`** —— `dashr/src/url-schema/index.ts` 的 `resolveDocsDir()` 从 `import.meta.url` 向上找 `docs/`。发布包 `@pgmi-builds/dashr` 里**没有 `docs/`**（`docs/` 在仓库根 `/home/u1/workspaces/dashr/docs`，位于包根 `dashr/` 之外，未进 npm 包）。运行时从 `~/.dsh/profiles/web/node_modules/...` 加载，向上走到 `/` 也够不着仓库里的 docs。dev 布局（`dashr/lib/index.js` 向上能到 `/home/u1/workspaces/dashr/docs`）能跑通，装进 node_modules 就断——纯打包缺口。
-
-3. **`ctx://` 读** —— `dashr/src/url-schema/tools/read.ts` 的 URL 分支调 `resolver.resolve({}, rawPath)`，传**空 env**；`handlers/ctx.ts` 随之 `queryVar(name)` 不传 `principal`，`runtime.ts:393` 落到 `AGENTLESS_KEY`（共享默认内核）——而 eval cell 跑在**会话 principal 键**的内核上。所以永远读一个没人用的空内核，真实存在的变量也报 missing。对比：文件分支正确用了 `execSessionKey(exec)`，URL 分支没传。
-
-4. **`ctx://` 写** —— `dashr/src/url-schema/tools/write.ts` 的 `defaultSchemeWrite` 对除 `xd` 外一律抛 `URL_WRITE_UNSUPPORTED`；`handlers/ctx.ts` 里已写好的 `writeCtxVar` 是**死代码**（`index.ts` 装 write 工具只传 `{ nativeWrite }`，没传 `writeScheme` 把 `ctx://` 路由到 `writeCtxVar`）。
-
-5. **mask `skill`（D5）** —— `dashr/src/index.ts:154` 的 `MASKED_TOOL_NAMES` 确实含 `'skill'`，但它只作用于 REPL 自己的 `tool.*` 绑定面（`index.ts:761`）+ Tool Catalog（`index.ts:901`），所以 eval cell 里 `tool.skill` 确实没了；但**挡不住 host 层注入的原生 `skill` 工具 + `<available_skills>` 目录**，模型从原生工具面照样能看见并调用 `skill`。验收项「工具目录不含 skill」未达成。
-
-6. **`write` 普通路径回归（新增）** —— 设计 D2 明确「不替换 write（write 保留原生，只挂 write-hook 装饰结果）」，但 v0.1.10 实际用 `tools/write.ts` 的 `createWriteTool` 以 `name: 'write'` **shadow 了原生 write**，其 `nativeWrite` 直接 `ctx.fs.resolve(...)` + `ctx.fs.writeText(...)`，**没走原生 write 工具的 write-intent 政策门**，于是对工作区路径被 sandbox 拒绝（`file access denied under workspace-write mode`），只放行 `/tmp`。对比：`read`/`edit` 走 vendored hashline 的 fs-bridge（含 `fs/write-intent` + `fs/observed` 政策门），工作区读写正常；bash 也正常。**这直接违反 spec「普通路径透传」——非 scheme 的 `write` 行为与引入 URL schema 之前不一致。**
-
----
-
-## 4. 一处 spec 偏差（非阻断）
-
-`agent://` 名册 schema 与 spec 不符：
-
-- `specs/agent/spec.md` 要求：`id / status / kind / parent / last activity`
-- `handlers/agent.ts` 的 `renderRoster` 实际：`id / origin / depth / cwd`
-
-字段语义对不上（`origin`≠`kind`、`depth`≠`parent`、缺 `status`/`last activity`、多了 `cwd`）。
-
----
-
-## 5. 最小修复清单
-
-| # | 缺口 | 落点 | 类型 |
-|---|---|---|---|
-| 1 | URL 分支透传会话 `principal`（复用 `execSessionKey(exec)`）给 `queryVar`/`setVar` | `tools/read.ts`、`handlers/ctx.ts`、resolver env | 代码 |
-| 2 | write 工具接上 `writeScheme`，把 `ctx://` 路由到 `writeCtxVar` | `tools/write.ts`、`index.ts` `installAgentTools` | 代码 |
-| 3 | `ctx.skills` 注册表与 harness session skill 目录同源（或 skill handler 改读 `<available_skills>` 来源） | `handlers/skill.ts`、`index.ts` 接线 | 代码 |
-| 4 | `docs/` 收进发布包（`package.json` files / 或 `docsDir` 指向随包路径） | `index.ts` `resolveDocsDir`、打包配置 | 打包 |
-| 5 | mask `skill` 到 host 注入层（非只 REPL `tool.*` 面） | host 层 / `index.ts` mask 机制 | 代码 |
-| 6 | `agent://` 名册字段对齐 spec（id/status/kind/parent/last activity） | `handlers/agent.ts` `renderRoster` | 代码/文档 |
-| 7 | **修复 `write` 普通路径回归**：native 分支走原生 write-intent 政策门（或直接委托上游原生 write），而非裸 `ctx.fs.writeText` | `tools/write.ts` `nativeWrite`、`index.ts` | 代码 |
-
----
-
-## 6. 复测计划（修复后执行）
-
-1. `read skill://<真实 skill 名>` 返回正文；`skill://<name>/<path>` 返回内部资源；未注册名结构化报错。
-2. 原生工具面不再出现 `skill`（且 `<available_skills>` 保留为发现层）。
-3. `read dsh://docs` 返回文档清单，`dsh://docs/<doc>` 返回正文。
-4. eval 里 `x = 1` 后 `read ctx://x` 返回 `1`；`write ctx://y` 后 `read ctx://y` 返回新值。
-5. `read ctx://` 列出命名空间（含刚写的 y）。
-6. `agent://` 名册含 status/kind/parent/last activity。
-7. **`write <工作区普通路径>` 成功（回归修复）**。
-8. 回归：`read`/`write`/`grep`/`glob` 普通路径 + hashline 锚点无回归；`npm test` 全绿。

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

@@ -1,150 +0,0 @@
-# DASHR URL Schema v0.1.8d 第一人称实测报告
-
-- **日期**: 2026-08-27
-- **测试者**: Dash Agent 运行时自身(pc-deepseek-default,session `session-6fb5ad2a-1b62-471c-8db3-edbf1152360f`)
-- **被测对象**: 部署在本运行时上的 `@pgmi-builds/dashr` `0.1.8-d`(lib 构建于 08-27 02:33,profile 中 `dsh-better-edit` 已移除)
-- **方法**: 全部通过被测运行时自身的工具面(`read`/`write`/`grep`/`glob` 直调 + `eval` 内 `tool.*` 调用)发起,无旁路。
-- **版本**: v2 活文档。初版 = url-schema 实测;v2 并入工具面四层矩阵(L0/L1A/L1B/L2)、L1B 原生面探针修正、上游呈现层(dsh-tools)源码考据。后续讨论如有更新,一并并入本报告。
-
-## 结论
-
-**v0.1.8d 已真实生效。** 上一轮(08-25,v0.1.8c)的两个根因——宿主进程陈旧、BetterEdit 外挂未移除——均已消除。7 个 scheme、统一选择器、错误词汇、grep/glob 双翻译路径全部按设计工作。另发现 **2 处设计文档滞后(实际行为优于文档)** 和 **1 处未文档化的行为边界**。
-
-**v2 修正(重要)**:初版关于被掩工具"不可调"的判断被原生面探针**证伪**——被掩的 `skill` 以模型直调形式完整执行(§6.3)。这不是缺陷:ADR-0001/0002 本就设计为 "registered, executable, and dispatchable",presentation-only 在 API 层字面成立。
-
-## 1. 部署状态(对照上轮失败根因)
-
-| 检查项 | 结果 |
-|---|---|
-| 安装版本 | `0.1.8-d` ✓ |
-| `dsh-better-edit` 残留 | package.json 与 node_modules 均无(仅剩无关的 `dsh-better-sidebar`)✓ |
-| URL 路由 | 所有 scheme 真实路由,不再坍缩成 `skill:/grilling` 文件路径 ✓ |
-
-## 2. Scheme 路由(全过)
-
-| 探测 | 结果 |
-|---|---|
-| `skill://grilling` | 完整技能正文(path 根 `/home/u1/.agents/skills/grilling/SKILL.md`)|
-| `agent://` | 五列 roster(id/status/kind/parent/last activity),本会话 `running` 态可见 |
-| `agent://<id>` | 最后一条非空 assistant 输出 |
-| `agent://<id>/transcript:1-15` | transcript + 行选择器组合 |
-| `dsh://docs` | 27 项文档清单 |
-| `dsh://docs/adr/0002-….md:1-12` | 深层路径 + 选择器 |
-| `ctx://` | 精确三键 `session` / `model` / `cwd` |
-| `ctx://session` | `{id, status, delegationDepth:0}`,undefined 字段(如 maxTokens)按设计省略 |
-| `ctx://model` | `{provider: deepseek-official, model: deepseek-v4-flash}` |
-| `ctx://cwd` | 裸字符串 `/home/u1/workspaces/dashr` |
-| `dvc://` | `no devices mounted` 占位符 |
-| `http(s)://` | 见 §4 |
-
-## 3. 选择器与错误词汇(全过)
-
-- `:1-5` 区间、`:3-3` 单行、`:raw` 全文、`?q=frontier` 行过滤、`:999-1002` 越界优雅返回空 —— 全部符合统一选择器语义。
-- `foo://bar` / `history://x` / `xd://screen` → 统一 `no handler registered for scheme … (registered: agent, ctx, dsh, dvc, http, https, skill)`。**D11 确认**:`history://` 无特例、`xd://` 改名彻底、错误信息自带注册表。
-- `ctx://bogus` → `unknown snapshot key (known: session, model, cwd)`。
-- `dvc://nonexistent-device` → `unknown device: …` 占位文本(非错误,符合 D3)。
-- URL 写拒绝:`write skill://…` → 只读 scheme 拒绝;`write dvc://…` → `no devices mounted to route the write to`。
-
-## 4. http(s) handler(D9,全过)
-
-| 探测 | 结果 |
-|---|---|
-| `https://example.com` | 首行 disclaimer 逐字符合设计,空行 + 正文 |
-| 404 | `HTTP GET … returned 404 Not Found`(URL_HTTP_STATUS)|
-| PNG | 媒体白名单拒绝,错误文案含白名单明细(URL_HTTP_UNSUPPORTED_MEDIA)|
-| 10MB `.dat` | `body … is 10485760 bytes, over the 2097152-byte (2 MiB) text limit`(URL_HTTP_TOO_LARGE,报告真实字节数;且优先级正确:尺寸预检先于媒体检查)|
-| DNS 失败 | `URL_HTTP_FETCH_FAILED`,嵌套原因消息保留 |
-| 429 | 结构化状态错误 |
-
-未覆盖:20 s 超时预算(无可靠慢端点,不烧时间)。
-
-## 5. grep/glob over URL(D10,全过)
-
-- **path-backed**:`grep skill://grilling frontier` → 原生 ripgrep 直打 `/home/u1/.agents/skills/grilling/SKILL.md`(4 matches,真实路径);`glob skill://grilling` → 真实磁盘路径。
-- **content-backed**:`grep ctx:// session` → 物化到 `/tmp/dashr-url-*/content.txt` 后搜索;`grep agent:// running` → roster 命中本会话行;`glob agent://` → 解析文本本身即清单(非空行直出,无原生调用)。临时目录清理验证:`/tmp` 中 `dashr-url-*` 残留为 0。
-
-## 6. skill 掩码(D5)——四层矩阵与 "presentation-only" 的精确边界
-
-**v2 修正**:本节初版曾把被掩工具标为 L1B 不可调。经原生面探针证伪:以**原生函数调用**直接调 `skill({"name":"grilling"})`,调用完整执行,返回完整 `<skill_content>` 块(与用户直呼技能名的 host 注入同格式)。掩码摘掉的是广告,不是执行通路。
-
-### 6.1 分层定义
-
-| 层 | 含义 | 控制者 |
-|---|---|---|
-| **L0** 注册表 | 运行时可达,分发在此解析 | dsh 宿主;掩码与遮蔽均不触碰 |
-| **L1A** 目录可见 | 出现在呈现给 LLM 的目录/SDK 声明文本 | DASHR 投影(`collectSdkSchemas` → `dashr:tool-catalog` section) |
-| **L1B** 原生可调 | 模型经 API 函数调用面直接发起并执行 | 上游呈现层(`wireSchemas`/`resolveExecution`) |
-| **L2** REPL 可调 | `eval` 内作为 `tool.*` 成员调用 | DASHR REPL 绑定 allowlist(`_dashr_install_bindings`) |
-
-### 6.2 实测矩阵(v2,每格有本会话实证或源码考据)
-
-| 工具 | L0 | L1A 目录 | L1B 原生调 | L2 REPL |
-|---|:--:|:--:|:--:|:--:|
-| `subagent`(delegation 组) | ✓ | ✓ | ✓ | ✓ |
-| `skill`(上游) | ✓ | ✗ 掩码 | **✓ 探针执行** | ✗ `unknown binding` |
-| `report`(上游) | ✓(child scope) | ✗ 掩码 | 未探¹ | ✗ |
-| `send_message`(上游) | ✓ 被遮蔽 | ✗ 掩码 | 按名不可达² | 按名不可达² |
-| `send_message`(DASHR 桥) | ✓ 独立注册 | ✓ | ✓ | ✓ |
-| `mcp__cordis-a2a__*` | ✓ | ✓ | ✓ 实测 `a2a_agents` | ✗ 非平坦名 |
-| native `read`(dsh-tool-fs) | ✓ 被遮蔽 | ✗ | ✗ 按名解析到 dash read | ✗ |
-| dash `read`(URL 路由+hashline) | ✓ 最近层胜出 | ✓ 唯一可见 | ✓ 全部 URL 实测 | ✓ 实测路由 `ctx://model` |
-
-¹ `report` 只在 child scope 注册,root 探出 `UNKNOWN_TOOL` 无法区分"掩码拦截"与"未注册",探针无诊断力,故不探。
-² 同名遮蔽:调 `send_message` 按名解析到最近的 DASHR 桥(plan Q25,receiver='child' 桥接工具下行、'parent' 桥接 reportFrom 上行),上游定义按名不可达——这是遮蔽语义,不是掩码语义。
-
-### 6.3 为什么 L1B 放行(源码级因果链)
-
-1. `view(scope)`(dsh-tools):`visible` = 全局层+祖先层中每层 `admits` 全票通过的名字,加上本 scope 自有层无条件注册的名字。掩码**不注册任何可见性过滤**(dashr/src/index.ts:144:"The registry itself is never touched (no `restrict()` …)"),`skill` 恒在 `visible`。
-2. `wireSchemas(scope)`:`native`/`both` 模式全量 `visible` 上 wire;仅 `code` 模式坍缩到只剩 `run_code`。
-3. `resolveExecution(name, scope, nested)` 的拒绝条件 `collapses()` 全式:`!nested && mode==="code" && name!=="run_code"`。本会话为 `both` 模式(原生调用与 eval 并存),模型直调任何 visible 工具都放行。
-4. `UNKNOWN_TOOL` 只属于:不在 `visible`、或 code 模式下非 `run_code` 的模型直调——两者都不适用于被掩工具。
-
-ADR-0002 Consequences 原文:"The masked tools remain in the registry and are reachable via nested sub-dispatch with a parent token";ADR-0001:"must stay registered and executable even though the model never sees their names"。本探针表明 `both` 模式下比 ADR 表述更强:**模型直调**即可达,无需 parent token。
-
-### 6.4 L2 才是掩码的硬门
-
-REPL 绑定是显式 allowlist(`_dashr_install_bindings` 注入 28 个函数名,不含 `skill`/`report`):`await tool.skill({"name":"grilling"})` → `ToolCallError: unknown binding "tool.skill"`,调度层硬拒绝。allowlist 含全部 delegation 工具(`subagent`/`subagent_fork`/`list_agents`/`interrupt_agent`/`workflow`/`ralph`)与 `send_message` 桥,印证 ADR-0002 v0.1.9"delegation 直通、不重包装"。
-假象排除:`getattr(tool,'skill')` 与 `getattr(tool,'definitely_not_a_tool_xyz')` 都返回 function——惰性代理对任意名字都给可调用对象,`hasattr` 不能作掩码探针;门禁在调用时的绑定校验。
-
-### 6.5 两个易混机制
-
-- **掩码 vs 遮蔽**:掩码 = 投影点过滤(`MASKED_TOOL_NAMES = {send_message, report, skill}`,dashr/src/index.ts:154,打在 `collectSdkSchemas` 与 REPL `toolFunctions` 两点),注册表不动;遮蔽 = 同名最近层胜出(dash read 注册在 agent 自有层,native read 按名解析永远到达 dash read;上游 send_message 被桥遮蔽)。两者都表现为 L0✓/L1A✗,但 L1B 命运相反:**被掩的仍可执行,被遮的按名不可达**。
-- **L2 的两道过滤**:MASKED 之外另有 `isFlatBindableName`(连字符名不可作成员)——MCP 工具 L1A✓/L1B✓/L2✗,证明 REPL 投影与目录投影独立分叉。
-
-## 7. 非 URL 委托保真(D2-restore/D7)
-
-普通 `write`/`grep`/`glob` 行为原生:scratch 文件正常创建与删除、`grep dashr/src URL_UNREGISTERED_SCHEME` 命中源码 3 处、`glob openspec/changes/url-schema *.md` 正常返回。capture-before-register 委托在本会话无回归表现。
-
-## 8. 与设计文档的偏差
-
-### 8.1 文档滞后(实际行为优于文档,建议更新 design.md)
-
-1. **D9 已知限制":port 端到端失败"已不成立**:`https://example.com:443/` 成功取回;`https://example.com:80/` 报 TLS `wrong version number`(端口真实抵达 fetch 层)。http 解析豁免看起来已完整实现,但 D9 及 Open Questions 仍标 OPEN/deferred。
-2. **D9 "`?…` 被吃成 query 选择器导致结果二次过滤"已不成立**:`https://example.com/?x=1` 返回完整正文,无双重过滤。
-
-### 8.2 未文档化的行为边界(建议二选一:补文档或修)
-
-- `agent://<parent>/<child>` 对**已完成([ready] 态)的一次性子代理**返回 `child agent … is not live in the session store`。路由与结构化错误正确(短 id → `unknown child agent`,全 UUID → `not live`),但 D3 表承诺 "nested output" 未注明活性约束;一次性 subagent 的收尾输出(`NESTED-FORM-PROBE-OK`)在完成后经 URL 不可取回。
-- 关联观察:roster 表从未列出子代理行(parent 列全为 `-`)——一次性 subagent 会话似不进 `ctx.sessions`。
-
-## 9. 建议
-
-1. 更新 design.md D9 与 Open Questions:`:port` 与 `?query` 豁免已实现,关闭该 open question。
-2. 在 D3 表为 `<id>/<child>` 注明活性约束,或让 handler 回退到 `ctx.subagents` 的存档输出。
-3. 无需任何回滚动作;本轮未发现阻断性缺陷。
-4. design.md D5 / ADR-0002 补记实测结论:catalog 掩码在 `both` 模式下**不移除原生面可执行性**(模型直调可达,§6.3 探针)。若未来需要真正的 L1B 拒绝,机制是可见性层 restrict 或模式坍缩——ADR-0002 已因 ordering hazards 明确拒绝前者。应作为有意识的安全边界记录在案。
-
-## 10. 附:上游呈现层考据——原生 dsh 本就有 catalog 机制,DASHR 是同槽位本地化重实现
-
-**结论先行**:原生 dsh 必然也向 LLM 呈现工具目录(否则模型无从得知工具面),机制在 `@deepseek-ai/dsh-tools` 包;DASHR 的 `dashr:tool-catalog` section **顶替上游同名 slot**(dashr/src/index.ts:1010 注释自证:"the same scope-aware shape as upstream's sdkSection",pre-0.1.5 名为 `tools:dashr-sdk`)。"机制层面抄上游再本地化"成立;逐行同源与否在编译产物层面不可证。
-
-上游机制(编译产物 lib/index.js 可读):
-
-- `tools` 服务构造时注册**两条呈现通道**:
-  - `ctx.systemPrompt.tools((context) => this.wireSchemas(context.scope))` —— **wire 通道**:API 请求的 tools 声明数组,按调用 scope 的 `view.visible` 渲染;
-  - `sdkSection()`(name `tools:sdk`,order 150)—— **SDK 文本通道**:`code`/`both` 模式下把工具面渲染为语言对应 SDK 声明(`SDK_RENDERERS[runtime.language]`),`native` scope 渲染为空。DASHR 的 section 使用同一 order(SDK_SECTION_ORDER)顶替。
-- **呈现模式三态** `native`/`code`/`both`:最近 scope 层胜出(`presentAs()` 按 scope 声明,进程级默认走 `mode` 配置)。`code` 模式配 `collapseSection`(`tools:code-only`)向模型声明"只可调 run_code"——上游注释明言:缺了它,模型会对着 SDK 目录发原生调用、收 `UNKNOWN_TOOL`,进而"concludes the deployment is inconsistent"。
-- **分发门** `resolveExecution` → `collapses`:`!nested && mode==="code" && name!=="run_code"` 才拒;嵌套子分发(parent token,SDK 内调绑定工具)永可调任何 visible 工具。`UNKNOWN_TOOL` 支持带 `reachableFrom` 提示("unknown tool X: 从哪个 scope 可达")。
-- **`view(scope)` 解析**:inherited = 全局层+祖先层、每层 `admits` 全票;own 层无条件加入;`knownNames` 收录全部已知名(供错误提示)。上游注释自述设计哲学:"Restrictions do not make known tools invalid, but a mode collapse does"——上游自己把 restrict(可见性过滤)与 collapse(模式坍缩)区分为两种强度,ADR-0002 拒绝的正是前者,选择的 presentation-only 排除与 collapse 语义同构。
-
-对本会话的落点:wire 数组与 SDK 目录文本是**两件产物**;本会话声明文本带 REPL 词汇(如 MCP 工具"not callable from cells"注记),说明可见文本至少部分出自 DASHR 渲染器;而 wire 数组在 `both` 模式含全量 visible——这解释了 §6.3 中被掩工具为何原生直调可达。

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

@@ -1,224 +0,0 @@
-# DASHR surface-and-devices v0.1.8e 第一人称实测报告
-
-- **日期**: 2026-08-28
-- **测试者**: Dash Agent 运行时自身(pc-deepseek-default,session `session-c526cef2-c056-4b58-a15d-fb44edc9548a`)
-- **被测对象**: 部署在本运行时上的 `@pgmi-builds/dashr` `0.1.8-e`(git HEAD `0f9e84e` "v0.1.8e: wire masking, auto REPL bindings, dvc devices",profile `web`,lib 构建于 08-28 00:11)
-- **被测改动**: `openspec/changes/surface-and-devices/`(design.md D1–D8:注册表掩码 / REPL 自动映射 / 目录改名 / roster family tree / RAM 物化 / dvc 设备)
-- **方法**: 全部通过被测运行时自身的工具面(`read`/`write`/`grep`/`glob` 直调 + `eval` 内 `tool.*` 调用)发起,无旁路。第一人称——我自己就是被 deny 掩码作用的那张模型表面。
-- **会话环境**: cwd `/home/u1/workspaces/dashr`,preset `standard`,delegationDepth 0,sandbox `workspace-write`,approval `ask`;`/dev/shm` = tmpfs 6.6G。
-
-## 结论
-
-**v0.1.8e 已真实生效,且修复了 v0.1.8d 的核心结构矛盾。** 上一轮(v0.1.8d §6.3)的结论是「目录掩码 presentation-only,被掩的 `skill` 在 `both` 模式下模型直调照样执行」;本轮 D1 改用 registry 级 `restrict({deny})`,把掩码从「摘广告」升级为「摘通路」——**被掩名对 LLM 全链路消失**(wire 直调面 + 目录 + REPL 绑定 + 按名 dispatch 五面一致)。这条链在本会话每一格都实证成立。
-
-8 项决策的落地结果:**D1/D2/D3/D4/D6/D7 全过,D5 部分达成,D8 三设备两通一断**。另发现 **3 处设计文档/实现漂移** 和 **1 处部署缺陷**(browser 设备缺 `@puppeteer/browsers` 依赖,运行时拉不起来)。
-
-## 1. 部署状态
-
-| 检查项 | 结果 |
-|---|---|
-| 安装版本 | `0.1.8-e` ✓ |
-| git HEAD | `0f9e84e`(wire masking + auto REPL + dvc devices)✓ |
-| 运行 profile | `web`(`/home/u1/.dsh/profiles/web/node_modules/@pgmi-builds/dashr`)✓ |
-| `/dev/shm` | tmpfs 6.6G,可写 ✓ |
-| 系统 Chrome | `/usr/bin/google-chrome-stable` 存在 ✓ |
-
-## 2. D1 注册表掩码(核心,全过)
-
-deny 名单 9 名:`skill` / `send_message`(上游)/ `report` / `list_agents` / `subagent` / `subagent_fork` / `interrupt_agent` / `workflow` / `ralph`。
-
-**2.1 REPL 绑定面(硬门)**:8 个非桥名全部 `ToolCallError: unknown binding "tool.<name>"`:
-
-```
-skill / report / list_agents / subagent / subagent_fork /
-interrupt_agent / workflow / ralph
-  → ToolCallError: unknown binding "tool.<name>"
-```
-
-**2.2 wire 直调面**:我的直调函数集(22 个平坦名 + `eval` + 5 个 MCP 名)中,上述 9 名**一个都不在**。与 v0.1.8d 对照——上一轮 `skill` 还在 wire 上、模型直调可达(L1B 放行);本轮 `skill` 从 wire 消失。这是本次改动对 v0.1.8d 结构矛盾的正向修复,直接实证。
-
-**2.3 能力保留靠桥,不靠 registry 豁免**:`read skill://grilling` 正常返回技能正文(skill 能力经 URL 桥保留);own 层 wrapper(`read`/`write`/`grep`/`glob`)全程不受 deny 影响(§6/§7 的每一步都靠它们完成)。
-
-## 3. D2/D3 桥 + REPL 自动映射(全过,含 1 处命名漂移)
-
-**3.1 `send_message` 桥(单向实测全过)**:桥以 `send_message` 为名,`receiver: 'child' | 'parent'`:
-
-- `receiver='parent'`(root 无父)→ 结构化 `{error: '...only a live continuable child agent can report to its parent (a root agent has none) — agent "session-…" is no…'}`(服务层 `authorizeReporter` 的 UNAUTHORIZED 被桥如实转译,不崩溃)。
-- `receiver='child'` 缺 `subagent_id` → 结构化 `{error: 'send_message() receiver "child" requires {"subagent_id": "..."}'}`。
-- `receiver='sideways'` → 结构化 `{error: 'unknown receiver "sideways"'}`。
-
-**3.2 REPL 绑定单态自动映射**:绑定集 = restrict **之后** `registry.schemas(agent)` 的平坦可见名全集。实测 22 名(与 wire 平坦名一一对应,无名单、无二态):
-
-```
-memory_search, memory_add, memory_list, memory_flush, bash, glob, grep,
-job_output, job_list, job_kill, ask_user_question, web_search, read, write,
-edit, read_image, todo_write, get_goal, create_goal, update_goal,
-exit_plan_mode, send_message
-```
-
-被掩名随投影消失自然不绑(§2.1);MCP 非平坦名 `mcp__cordis-a2a__*` → `unknown binding`(如实跳过)。
-
-**3.3 命名漂移(design vs 实现)**:design D1/D2 与 proposal 都把桥命名为 **`agent_message`**;实现与部署的桥名是 **`send_message`**(复用上游同名,`receiver` 参数区分方向)。功能语义与设计一致(child 下行/parent 上行、root 无父结构化拒绝),但**桥名与文档不符**——要么改名实现,要么回写文档。
-
-## 4. D4 目录段 = REPL bridge instructions(全过)
-
-部署形态 = **选项 B(signatures)**:`REPL_BRIDGE_CATALOG_MODE = 'signatures'`。我看到的目录段就是「`tool.<name>(args: {…}) -> <output>` 每工具一行」的 omp 式紧凑签名,保留输出契约,无逐工具参数 interface 块,无 REPL 可调清单。
-
-## 5. D5 run_code = REPL scripting pad(部分达成,含 "kernel" 泄漏)
-
-- `eval` 工具描述:"Execute one Python cell on a session-persistent **scripting pad**…" ✓ 无 kernel。
-- 桥说明段(目录):"session-persistent **scripting pad** (Python today…)" ✓ 无 kernel。
-- **但 `dashr:control-prompt` 段(order 100)仍 3 次使用 "kernel"**,且逐字渲染给我:
-
-```
-"one `eval` call runs one Python program on a persistent IPython kernel"
-"everything else stays in the kernel"
-"they live in the kernel subprocess: keep durable state in files"
-```
-
-设计 D5 的原话是「LLM 可见文案**不用 kernel 一词**」。目录段做到了,`control-prompt.md`(另一个 LLM 可见段)没做到。另:旧渲染器 `renderToolsSdkPy`/`SDK_INSTRUCTIONS` 在 `py-sdk.ts` 里仍满篇 "kernel",但它是**死代码**(index.ts 只 import `renderReplBridgeInstructions`),不达模型,风险为零。
-
-## 6. D6 agent:// = caller 的 family tree(全过)
-
-| 探测 | 结果 |
-|---|---|
-| `agent://`(裸名册)| `no agents`(本会话无子,空名册,与 native 同型)|
-| `agent://<self>` | 我的最后一条非空 assistant 输出 ✓ |
-| `agent://<self>/transcript` | 逐条 role-headed(`## user`/`## assistant`…)✓ |
-| `agent://<陌生 id>` | `unknown agent "…" — addressing is scoped to your family tree (self and descendants)`(family 收窄,非全局超集)|
-| `agent://<self>/<bogus-child>` | `unknown child agent "…" of "…"` |
-
-v0.1.8d 的「五列全局 roster」已移除;错误措辞明说 family 边界——与 design D6 一致。
-
-## 7. D7 RAM 物化 = /dev/shm(全过,路径直接实证)
-
-content-backed 搜索的物化根目录从 `/tmp` 切到 `/dev/shm`,并 `finally` 清理。**grep 返回的真实路径直接落在 tmpfs**:
-
-```
-grep ctx://model  → 匹配路径 /dev/shm/dashr-url-ZILDQp/content.txt
-grep agent://     → 匹配路径 /dev/shm/dashr-url-5w99JR/content.txt
-```
-
-调用后 `/dev/shm` 与 `/tmp` 均无 `dashr-url-*` 残留(清理零泄漏)。这是全链路里最硬的实证——不是读源码推断,而是 ripgrep 自己回吐了 `/dev/shm/` 前缀路径。
-
-## 8. D8 dvc 设备(三设备两通一断)
-
-**8.1 名册**:裸 `dvc://` 返回 4 设备(不再是 `no devices mounted` 占位):
-
-```
-ast_edit  AST-aware structural rewrite: {ops: [{pat, out}], paths: string[], dryRun?: boolean}
-ast_grep  AST pattern search: {patterns: string[], path?, offset?, limit?, includeMeta?}
-browser   headless Chrome via puppeteer-core — open {url} / run {code|goto,type,click} / close
-lsp       LSP queries over stdio language servers — diagnostics / definition / references / hover
-```
-
-`dvc://<device>` 返回一行摘要 + `usage: write dvc://<device> …`;`dvc://nonexistent` → `unknown device: …`。
-
-**8.2 ast_edit / ast_grep(通)**:`@oh-my-pi/pi-natives` npm 包装的直 dlopen 在本机 linux-x64 成功。
-
-- `write dvc://ast_grep {"patterns":["add($A,$B)"],"path":…}` → 结构化 matches(命中 `add(1, 2)` @ line 4,带 byteStart/startLine/startColumn)。
-- `write dvc://ast_edit {ops:[{pat,out}], paths:[…]}`(dryRun 默认 true)→ 结构化 changes 预览,`applied: false`,文件内容原样未动。
-
-**8.3 lsp(优雅降级,符合预期)**:`diagnostics` 请求 → 结构化 `language server binary "typescript-language-server" not found — npm install -g …`。二进制缺失时如实报缺、不崩溃,符合 D8 spec。
-
-**8.4 browser(断,部署缺陷)**:`open` → 结构化 `dvc:// device "browser" execute failed: puppeteer-core is not installed … Cannot find package '@puppeteer/browsers' imported from …/puppeteer-core/lib/puppeteer/node/ChromeLauncher.js`。定位:**`puppeteer-core@25.3.0` 已装,但其传递依赖 `@puppeteer/browsers@3.0.6` 缺失**(profile `web` 的 node_modules 顶层与嵌套均无)。系统 Chrome 在,`run`/`close` 的「无页可跑/无可关」状态机也正确——**唯一断点是依赖未装全**,与 omp patch 无关(design S6 已裁决无 patch 可冒烟)。属部署收尾遗漏,非代码缺陷。
-
-## 9. 与设计文档的偏差汇总
-
-1. **桥名漂移(D1/D2/proposal)**:文档 `agent_message` vs 实现 `send_message`。语义一致,名称不符。
-2. **D5 "不用 kernel" 未全达成**:`control-prompt.md` 3 处 "kernel" 逐字渲染给模型;`renderToolsSdkPy` 旧渲染器仍含 "kernel"(但为死代码,不达模型)。
-3. **D3 "`dir(tool)` 自查" 承诺落空**:桥说明段写「read the live member set at run time with `dir(tool)`」,但 `dir(tool)` 返回**空**(惰性 `__getattr__` holder 无 `__dir__` 覆写,`hasattr` 对任意名恒真)。真实绑定集只能靠未文档化的内部 `__dashr_injected__`(bootstrap 写入的 spec,`functions` 为 22 名列表)或 wire/目录声明得知。要么给 holder 加 `__dir__`,要么改说明措辞。
-4. **host 静态 prose 与掩码面残留不一致**:host 基础提示里仍有「Use the workflow tool ONLY when…」「Use the ralph tool ONLY when…」等措辞,而 `workflow`/`ralph`/`subagent` 已被 deny 掩码从可调面摘除。这是 registry 掩码无法触达的宿主静态文案(design Risks 的「restrict 名单漂移」同源),非 DASHR 缺陷,但模型会读到「用某工具」却调不到它。
-
-## 10. 建议
-
-1. **browser 收尾**:在 profile 安装 `@puppeteer/browsers@3.0.6`(或让 puppeteer-core 走完整 `npm install`),重新冒烟 `open`/`run`/`close`;否则 D8 的 browser 设备形同虚设。
-2. **桥名二选一**:把实现桥名改成 `agent_message`,或回写 design/proposal 的 D1/D2 为 `send_message`。当前文档与部署名不一致,会让后续 reader 误解。
-3. **D5 收尾**:`control-prompt.md` 的 3 处 "kernel" 改成 "scripting pad"(或 "pad"),并顺手清理 `renderToolsSdkPy` 死代码里的 "kernel" 措辞,避免误当仍在用。
-4. **D3 收尾**:给 `_DashrBindingHolder` 实现 `__dir__`(返回 `functions` 键集),或把桥说明里的 `dir(tool)` 提示改为「绑定集见上方 Tool declarations / wire 声明」。
-5. 无需回滚。本轮无阻断性缺陷;deny 掩码是 v0.1.8d 结构矛盾的正确解法,已实证生效。
-
-## 11. v0.1.8f 复测补记(2026-08-28 01:50,commit `3fdd3dd`)
-
-本报告提交后,上游随即发布 v0.1.8f("delegation bridges close the spawn/interrupt/workflow gap"),逐条回应 §9/§10 的发现。同一会话复测(kernel 已重启,pad 全新):
-
-**已修复(4 项)**
-
-1. **桥名漂移 → 修复**:桥由 `send_message` 改名 **`agent_message`**,与 design D1/D2 命名一致。实测 `tool.send_message` 现为 `unknown binding`(旧名彻底退场),9 个被掩名的掩码在改名下原样保持。
-2. **D5 "kernel" 泄漏 → 修复**:`control-prompt.md` 重写,3 处 "kernel" 全部替换(`persistent IPython kernel` → `session-persistent scripting pad`;`stays in the kernel` → `stays in the scripting pad`;`kernel subprocess` → `the pad's process`)。工作区与 profile 两份 md5 一致(`6ec2ec0…`),"kernel" 零残留,重启后已实际渲染。
-3. **`dir(tool)` 承诺 → 撤回**:桥说明中「read the live member set at run time with `dir(tool)`」一句已删除(py-sdk −4 行),不再承诺 holder 从未兑现的自查机制。
-4. **delegation 断面 → 补桥**:新增 `src/bridges/index.ts`(490 行),三个平坦名桥关闭 v0.1.8e 掩码后 spawn/interrupt/workflow 无模型入口的能力回归:
-   - `agent` → `ctx.subagents.start/startContinuable`(spawn / fork,`run_in_background` 可选);
-   - `agent_message` → followup/reportFrom/**interrupt**(三向:child 下行 / parent 上行 / **interrupt 停子代理当前轮**,`target_session_id`——interrupt 是新增能力,补上被掩 `interrupt_agent` 的缺);
-   - `agent_workflow` → `ctx.workflowEngine.start`(script / ralph rfc 两模式)。
-
-   实测绑定集 22 → **24**(三桥进入,`send_message` 退出):`agent` 空参 → 结构化缺 `description`;`agent_message` parent 上行(root)→ 结构化 UNAUTHORIZED;interrupt 缺 `target_session_id` → 结构化报错;未知 receiver → 三向枚举报错。桥为 REPL 绑定 + 目录声明(插件内仅 `eval` 走 `tools.register`),delegation 经 cell 内 `tool.agent(...)` 触达。
-
-**仍未解决(2 项)**
-
-- **browser 设备仍断**:`@puppeteer/browsers` 传递依赖在 profile `web` 仍缺失,`open` 报错与 §8.4 逐字相同。
-- **agent_workflow 有桥无服务**:桥已绑且可达,但本组合返回结构化 `agent_workflow() is unavailable: no ctx.workflowEngine service is mounted in this composition`——workflow 能力在**服务层**仍缺席,该缺口只在桥层关闭,此部署里实际不可用。
-
-**复测不变项(继续成立)**:9 被掩名全链路消失;`dvc://` 名册 4 设备;/dev/shm 物化(新证:`/dev/shm/dashr-url-EZlvAV/content.txt`);`read skill://` 桥保留。
-
-### 第二轮复测(2026-08-28 02:10,commit `2ba147b` + 依赖补装)
-
-`2ba147b`(纯改名:`rlm-runtime.ts`→`repl-runtime.ts`、`rlm.spec.ts`→`delegation.spec.ts`,去 RLM 品牌,无功能变更)后 profile 补装 `@puppeteer/browsers@3.0.6`,lib 02:04 重建并重启。复测结果:
-
-- **browser 设备 → 通**:`open`(data: URL)→ `{"ok":true,"title":"dvc-probe"}`;`run` evaluate → `"dvc-probe|hello"`(DOM 读取成功);`close` → `{"ok":true}`。全周期冒烟通过,§8.4 的断点(缺传递依赖)解除,D8 四设备至此全部落地。
-- **agent_workflow → 仍无服务**:同一结构化报错逐字复现。这是 host 组合层未挂 `ctx.workflowEngine`,不是 DASHR 插件缺陷(桥按 optional-service 模式解析);要么 host 挂服务,要么从 deny 名单/桥中移除 workflow 面。
-- 掩码面无回归:绑定集 24(三桥在、`send_message` 出)、9 被掩名全缺席;`control-prompt.md` 两份 md5 仍一致(`6ec2ec0…`)、"kernel" 零残留。
-
-### 第三轮复测(2026-08-28 02:30,commit `db6d84b`:agent_workflow 改走捕获定义)
-
-提交把 `agent_workflow` 从「解析 `ctx.workflowEngine` 服务」改为「透传 session-start 捕获的原生 `workflow`/`ralph` 定义」——根因诊断正确且重要:**`workflowEngine` 在 standard preset 的 delegation 组里 entry-local(`isolate: workflowEngine: true`),组外任何 ctx 都不可见,服务层路由构造上就不可能成功**;捕获定义的 execute 闭包在 realm 内运行,是唯一可通路径。`agent`/`agent_message` 留在服务层(`ctx.subagents` 是进程级单例,处处可见)。
-
-**桥本身实测正确**:`{}` → shape 错误(缺 `script`),rfc 缺 `objective` → shape 错误 —— 校验先于可用性,与姊妹桥一致(该轮提交同步修正了校验顺序)。
-
-**但捕获路由仍不可用,且暴露新事实**:
-
-- script 模式 shape 合法时 → `agent_workflow() is unavailable: the native workflow tool is not registered in this composition` —— 捕获映射里**没有** `workflow` 定义。
-- 捕获是 pre-mask 快照(native-capture 在掩码监听器之前运行),所以这不是掩码吃掉了它:**本 session-start 时 `workflow` 就不在 root 可见面里**。绑定集(per-eval 实时枚举 visible)同样没有 `workflow`/`ralph`,而 deny 是 session-start 时按当时可见集计算的 —— 若工具后来才挂上,它会以未掩状态进绑定集;没有 → 本 boot 里它从未注册。
-- **对照 v0.1.8d**:同一 profile 的 wire 全量快照(functions.json,25 工具)当时**包含** `workflow`/`ralph`/`subagent` 全家 —— 即这个环境它们曾经正常挂载。
-- 排除项:`dsh-tool-workflow`/`dsh-tool-ralph`/`dsh-workflow-worker-thread` 包都在 host node_modules;standard preset 的 `tool-workflow`/`tool-ralph` 行启用(无 `disabled`);DASHR bundle patch 不碰 delegation 组;host 包自 08-23 未变。
-- 归因(边界内):delegation 组里依赖 realm-local `workflowEngine` 的行(`tool-workflow`/`tool-ralph`,inject 三个键含 `workflowEngine`)在本次 boot 疑似未完成挂载(worker-thread provider 未在 realm 内就绪 → inject 等待悬置)。沙箱内 ps/journal 均不可见,无法从 agent 侧看 host 的 preset activation audit —— 需在 host 侧核对 `delegation` 组三行的挂载状态。
-- 连带修正 §2.1 的表述:在**当前部署**里,deny 名单中 `workflow`/`ralph` 两项实为 no-op(计算 deny 时它们本就不可见);「9 名全链路消失」的结论不变,但其中 7 名是掩码所致,这两名是未挂载所致。
-
-**净结果**:`agent_workflow` 依然实际不可用,但报错从误导性的「no service mounted」变成了准确的「native tool not registered」。收尾动作在 host 侧:查 delegation 组挂载,或按 preset 注释补装对应 Bundle 后重启。
-
-### 第四轮复测(2026-08-28 02:45,commit `8eb7b27`:agent() 对齐原生 continuable 语义)
-
-提交把 `agent()` 的 `run_in_background` 默认从 false 翻转为 **true**(对齐部署的原生 `subagent` 工具 `backgroundMode: continuable` 的模型契约;显式 `false` 才是一次性等待语义)。本轮做了**真实端到端 delegation 全链路实测**(此前只探过 shape 错误路径):
-
-| 步骤 | 实测结果 |
-|---|---|
-| 一次性 spawn(`run_in_background: false`)| ✅ 等待并返回完整结果:`{"kind":"foreground","runId":"5f0c8fc0…","output":[…,{"text":"CHILD-OK"}]}` |
-| continuable spawn(默认)| ✅ 立即返回持久 id:`{"kind":"continuable","subagentId":"39d22093…"}` |
-| roster `agent://` | ✅ 一行:`bg probe child`(label 作 id 列)· `ready` · parent=本会话 · last activity;**一次性子正确不列**(D6)|
-| 下行 `agent_message(receiver='child')` | ✅ 返回 `{"messageId":"c3d9b351…"}`;子代理把 follow-up 当下一轮处理,结算回执恰为要求的 `DOWNLINK-OK` |
-| 子输出读取 | ✅ `agent://<raw id>` 与 **label 寻址** `agent://bg probe child` 双路命中同一输出(D6 label 寻址落地)|
-| `receiver='interrupt'`(已结算子)| ✅ `{"accepted":true}` —— 与原生「interrupt 已结束的 agent 是接受的 no-op」语义一致 |
-
-**两个观察(非阻断)**:
-
-1. **roster status 粒度**:continuable 子首个回合进行中时 roster 显示 `ready` 而非 `running`(`ctx.agents` 注册表查无该子 → 按回落渲染 `ready`)。native `list_agents` 的三态在此场景同样依赖 live registry,属上游同源的粒度限制,但值得记录。
-2. **输出 artifact 含 reasoning 且无分隔**:`agent://<child>` 返回 `…nothing else.DOWNLINK-OK` —— 子的 reasoning 块与 text 块直接拼接(无换行)。对照原生:一次性任务的父面最终文本 `finalText` **只取 text 块**(`blocks.filter(type==="text")`,`reasoning` 被滤除)。DASHR 的 URL artifact 按 spec「rendered content of last non-empty assistant message」渲染全部块,spec 字面成立,但(a)把子的思维链暴露进可读 URL 面、(b)块间无分隔符,是两处可打磨点。
-
-**workflows 面:与第三轮完全相同** —— `agent_workflow` 仍返回 `the native workflow tool is not registered in this composition`(本次 boot 原生 `workflow` 工具仍未挂载;`8eb7b27` 未触及 host 侧)。阻塞点不变:需 host 侧核对 delegation 组 `tool-workflow`/`tool-ralph`/`workflow-worker-thread` 三行的 activation audit。
-
-### 第五轮复测(2026-08-28 03:05,commit `0a56da4`:serviceForAgent 读址)—— **workflow/ralph 全通**
-
-三连修的第三方案:**`serviceForAgent(ctx, agent, 'workflowEngine')`** —— host preset 框架对「已持有 agent 的调用方读 realm-local 服务」的官方通道(api-proxy 同款机制),外加 root-realm `ctx.get` 回退;Ralph 的固定编排脚本/meta 常量从 `dsh-tool-ralph` 原样内联,script/rfc 透传 `engine.start`。提交信息同时确认了第三轮的诊断:原生 workflow/ralph 工具从不进入 agent 可见投影(v0.1.8 直暴时代早于 dsh 的 delegation 面 preset 化;掩码的「跳过未注册名」行为让这个缺席不可见)——捕获定义方案构造上不可能成功。
-
-**路由证明(先于真实运行)**:script 模式传入非法 meta → 错误来自**引擎内部**的 meta 校验(`meta.objective is not a recognized field (name/description/whenToUse/phases)…`)——不再是桥本地的 unavailable,`engine.start` 已真实抵达。
-
-**真实最小运行(双模式全过)**:
-
-| 模式 | 输入 | 结果 |
-|---|---|---|
-| script | 1 个 `agent()` hook 的平凡脚本 + 合法 meta | ✅ `{"runId":"533d956f…","agentsStarted":1,"result":{"token":"WF-AGENT-OK"}}` —— 引擎执行脚本、起 1 子、子按令牌回复、`return` 值回流 |
-| rfc(Ralph)| 平凡 objective + `maxRounds:1` | ✅ `{"runId":"9db99bd8…","agentsStarted":1,"result":{"status":"complete","roundsStarted":1,"report":{"status":"complete","summary":"RALPH-OK","evidence":[…],"nextSteps":[],"blocker":""}}}` —— 内联 Ralph 编排在 1 轮内由 fresh child 完成目标、结构化 report 回流、循环干净收尾 |
-
-**roster 一致性**:两次运行起的 one-shot 子(workflow 的 `agent()` 子、Ralph round-1 子)在事后的 `agent://` 名册中**正确缺席**(仍只列 continuable 的 `bg probe child`)——与 D6「one-shot 不列但可寻址」一致。
-
-**至此 §9/§10 的全部发现与遗留闭环**:四项漂移已修、browser 已修、delegation 三桥端到端全通、workflow/ralph 双模式真实运行通过。掩码面(24 绑定、9 名消失)、`control-prompt`(零 kernel)、四设备均无回归。v0.1.8f 的 surface-and-devices 交付完整落地。