super-dsh 0.3.0-c → 0.3.0-e

package/node_modules/better-dsh/docs/50_test-reports/2026-10-07-better-dsh-welcome-self-contained-4999.md

@@ -1,52 +0,0 @@
-# 2026-10-07 Super Dash 自包含 Better Dash / 动态 welcome 验收
-
-本轮为本地 4999 消费者验收，不是 npm 发布或 dev3 放行。两仓物理独立，Better Dash 本地源码始终参与构建。
-
-## 交付物
-
-| 包 | 本地版本 | SHA256 |
-|---|---|---|
-| Super Dash | 0.1.12-e | `243951a2ed5bfbaa6139aa045bd4314ac96f91bf6420159b940c34b2da6ab52d` |
-| Better Dash | 0.2.5-h | `3ab52507f738e3c74fb1142cc41aae9544e1f78453e80d573baa686d0885af8d` |
-
-路径为Super Dash 仓 `.scratch/superd-pack/`；完整来源、绝对路径与时间见 `pair.json`。pack 从 `/home/u1/workspaces/dashr/better-dsh` 清理并构建 lib，统一普通 npm pack，再物理展开该 tarball 供 bundledDependencies 打包。不存在 registry Better Dash 回退。每次 pack 自动对独立与内嵌 Better Dash 的 **741 个文件逐字节核验**，缺失或陈旧内容不能写入成功记录。
-
-消费者 profile 直接依赖只有 Super Dash tarball 与开发附加 WebMCP；没有 Better Dash 直接依赖/bundle、没有 pnpm Better Dash override、没有 profile-root Better Dash。实际安装的 `super-dsh/node_modules/better-dsh` 与独立本地 tarball 逐文件一致。有序 patch 文件先读内嵌 Better Dash YAML，再读 Super Dash YAML；无组件清单复制。
-
-## 用户可见行为
-
-- WebTrust 与 WebServer/default bind、credential onboarding、welcome 均归 Better Dash。Super Dash 删除重复 WebTrust 源码、导出和行。dev WebMCP 移到兄弟仓 `dev-webmcp/`，不进入两包正式 tarball。
-- `dashr-welcome-notice` 从**实际运行宿主**的 WebApp → Models client 路径读当前版本；本次读到 `2026-09-28.1`，实际 settings/describe 的 General value 相同。没有在 profile patch 写死 welcome 值；组件用 Loader 的公共 internal/config/Entry.update 对原 namespace 做可逆投影。`disabled: true` 恢复原生确认行为。
-- 发现并修复真正的首次 HTTP 竞态：原生 Models 页面 settings mirror 的 unary HTTP 不受 WebSocket appReady 门约束。Better Dash 禁用原 webserver 行，插入 `dashr-webserver` 继承原生 Service，等待 welcome settle 后才执行原生 init/bind。延迟 General 激活的真实 Loader/HTTP fixture 先复现首读 null，修复后首个 200 快照含当前版本。禁用/重启组件恢复原值且不重建 General fiber；曾复现双挂载后已修复为只在 fiber 不存在时 init。
-- 普通版本 bump 自动适配下一次启动。私有常量重命名、布局变化或多匹配时明确报错；不承诺任意未来上游结构变化也无需维护。没有直接 Settings.update 等自身 root reconciliation、没有替换 Models UI、没有本地 localStorage 假确认。
-- 默认监听实际为 `0.0.0.0:4999`，由 Better Dash YAML 提供。测试 profile 只补共用 credentials 路径，端口走原生 CLI `--port 4999`。保留压缩与显式 loopback CLI override。
-- 真页面发现异步模块挂载能颠倒 FIFO 排序。Better Dash 的 ownership 脚本现 prepend 公共 injection table；实际认证后 HTML 中 trust 先于 fusion，credentialOnboarding 为 false。公开 client graph 的 67 个 id 无重复，Better Dash 与 Super Dash client 各一份。
-
-## 实际运行验收
-
-- `bash super-dsh/test/start-4999.sh` 完整双源码构建、tarball 安装、原生 CLI 启动 exit 0；`superd-4999-test` active。使用 Node26.10.0、npm12.2.0、pnpm12.9.1。安装期脚本保持禁用，没有 approve-builds。
-- 新客户端密码页 POST 登录303、cookie签发；认证后原生 app 与 API 正常。WAN 与 LAN 匿名首页为密码表单，受保护 API 均401。共用 seed 与测试用户会话保留；生产3080/3081和上游源码未修改。
-- roster = native、agy、claude、codex、hermes、omp、pi，**7个均 ready:true、failed:false**。本轮没有重跑六个未改动 foreign adapter 的真实模型会话，不把 roster 代称其 prompt 验收。
-- 最终产物新建 standard native 会话 `session-a601281b-2ce2-42bc-86c4-7e3753609b57`：DeepSeek真实模型看到并实际调用 Better Dash `eval`，v4日志 tool/call seq17、tool/result seq18 得到 `SELF-CONTAINED-EVAL-42: 42`，turn/end completed。没有用注入探针冒充模型工具调用。
-- 服务重启及最终新产物重启后，既有会话 `session-3f8564c9-e846-4506-ac54-95bb0599dd2e` 实际续接，读取上一轮工具输出并正确回复 `LOCAL-BETTER-FOREVER`，第三轮 turn/end completed；验证了持久会话 resume。
-- CUA inventory 为 apps[]/browsers[]，无法完成视觉/交互浏览器验收；首个 HTTP fixture、真实 settings 与 client graph 是已验证范围，用户视觉复核仍需访问下面 URL。dev3 未实施，本报告不作其通过声明。
-
-## 检查
-
-- Better Dash welcome/WebTrust/connection：19 tests通过；host/client typecheck通过。
-- Super Dash fusion-transport/fusion-flag/world-mount-patches：38 tests通过。
-- Super Dash composition/login/pack-contract：7 tests通过。
-- 实际 npm pack fixture与内嵌缺失/陈旧拒绝：2 tests通过。
-- 迁移 dev WebMCP build与script测试：2 tests通过。
-- 独立审查无 Important/Critical 遗留；修正了异步脚本顺序与文档旧结论。git diff --check、launcher shell syntax通过。
-- LSP：检查上游配置更新关系、定义/引用；最后针对 Better Dash trust builder 返回真实定义及引用。TypeScript AST确认唯一注入push调用后改为prepend；无假类型/上游修改。
-
-证据保留在 `.scratch/self-contained-install-proof.json`、`self-contained-live-proof.json`、`self-contained-session-proof.json`、`self-contained-roster-proof.json`、`self-contained-client-graph-proof.json` 与 `self-contained-launch-delivery.log`。不记录 cookie、密码签名密钥或 provider keys。
-
-## 留运行线
-
-- WAN: https://test.pc.randomhash.app/
-- LAN: http://192.168.31.130:4999/
-- local: http://127.0.0.1:4999/
-
-未 npm publish，未 commit/tag/push；4999 保持运行，供 user 实际页面复核。

package/node_modules/better-dsh/docs/50_test-reports/REPL-/345/267/245/345/205/267/350/260/203/347/224/250-/346/210/252/346/226/255/350/257/212/346/226/255.md

@@ -1,110 +0,0 @@
-# REPL 工具调用截断诊断（v0.2.1b 实测中发现，2026-09-01）
-
-## 结论先行
-
-**任何从 REPL（`eval` cell）内部发起的工具调用（`tool.<name>(...)`）都会让 dsh web daemon 进程崩溃并自动重启；会话日志在 `tool/code-dispatch-start` 处撕裂，恢复时 repair 机制合成「interrupted-tool-result」，模型看到的即「工具调用被截断、结果未知」。** 4 次探针 4 次复现，与 journald 守护进程崩溃记录逐条对应。
-
-这不是 REPL 同步/异步的问题，也不是 subagent 特有问题——是 dashr 子分派桥接层的结构性缺陷 + 部署运行态注册表视图缺 symbol 的直接原因叠加。
-
-## 一、复现矩阵（第一人称）
-
-| # | cell 内容 | 结果 |
-|---|---|---|
-| 1 | `await tool.subagent({… run_in_background: false })` | 截断（daemon 崩溃 17:39:17） |
-| 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） |
-
-对照：纯 Python cell（`dir(tool)`、顶层 `return` 判错、`await asyncio.sleep(0)`）全部正常。**凡含 `tool.*` RPC 的 cell 必崩，与工具、与 background 与否无关。**
-
-## 二、截断面定位（三层证据）
-
-### 1. 会话日志（`~/.dsh/sessions/…/session.jsonl.zstd`）
-4 次截断的共同指纹：`tool/call (eval)` → `tool/code-dispatch-start`（**已持久化**）→ 日志撕裂（无 `tool/code-dispatch`、无 `step/end`/`turn/end`）→ 重载时 `packages/core/session/src/repair.ts` 的 `interruptedTurnClosers` 合成 `interrupted-tool-result-<callId>-<seq>`（`TOOL_OUTCOME_UNKNOWN`）。会话内 **0 条 error 事件**——错误根本没走到会话层。
-
-### 2. 守护进程日志（`journalctl --user -u dsh.service`）——铁证
-```
-Sep 01 17:39:17 pnpm[414449]: dsh: fatal load failure: TypeError: Cannot read properties of undefined (reading 'prepare')
-    at Object.start (…/better-dsh/lib/index.js:11281:41)
-    at <anonymous> (…/lib/index.js:11191:21)
-    at drive (…/lib/index.js:11207:7)
-    at outcome (…/lib/index.js:11310:6)
-    at new Promise (<anonymous>)
-    at toolFunctions.<computed> (…/lib/index.js:11320:72)
-    at Proxy.dispatchHostRequest (…/lib/index.js:2180:21)
-Sep 01 17:39:19 systemd: dsh.service: Main process exited, code=exited, status=1/FAILURE
-Sep 01 17:39:23 systemd: dsh.service: Scheduled restart job, restart counter is at 1.
-```
-17:39:17 / 17:41:15 / 17:57:05 / 18:02:27 四次崩溃，栈完全一致。`scheduler.prepare` 中 `scheduler` 为 `undefined`——即 `registry[TOOL_RUNTIME_SCHEDULER]` 在部署运行态取不到值。
-
-### 3. 源码链（`dashr/src/index.ts`）
-- kernel 侧：`tool.<name>(...)` → `binding.call` RPC（`src/bootstrap.ts` `_dashr_callable`）。
-- host 侧：`dispatchHostRequest`（`src/runtime.ts:545`）→ `await fn(args)`（`src/index.ts` `binding()`）。
-- `binding()` 内部（`src/index.ts:666`）：`const scheduler = registry[TOOL_RUNTIME_SCHEDULER]` → 单驱动道 `drive()`（`src/index.ts:591-621`）→ `start()` 内 `await scheduler.prepare(input)`（`src/index.ts:712`）。
-- **结构性缺陷**：`drive()` 的 async IIFE 是 `try { … } finally { … }`，**没有 catch**；调用处是 `void drive()`。任何 `start()`/`commit()` 抛错（如 `scheduler.prepare` TypeError）都会变成 **unhandled rejection**——binding promise 既不 resolve 也不 reject，cell 永久挂起，错误外泄给进程。
-**完整链条**：cell 工具调用 → dispatch 启动（`code-dispatch-start` 已入日志）→ `registry[TOOL_RUNTIME_SCHEDULER]` 为 undefined → `scheduler.prepare` TypeError → driver 无 catch → unhandled rejection → `installFailLoud` 判定 fatal → daemon exit(1) → systemd 重启 → 会话重载 repair 合成「interrupted-tool-result」→ 模型收到截断消息。**截断面：binding 桥 → registry symbol 查询 → driver 的未处理拒绝。**
-
-## 三、命名澄清：REPL dispatch log 与 code-dispatch 是两个不同层（重要）
-
-容易混淆，先分清：
-
-| 名字 | 层级 | 是谁 | 本次 change 是否改名 |
-|---|---|---|---|
-| `tool/code-dispatch-start` / `tool/code-dispatch` | **会话持久日志事件**（durable log，`agent.session.append`） | dashr `src/index.ts:689,712`；harness `known-event-types.ts:63-64` 注册 | **否**——v0.1.x 就有，历史遗留名 |
-| `dashr/repl-dispatch-log` | **waterfall 扩展点**（内容整形监听事件） | dashr 自注册（`src/index.ts:458`） | **是**——v0.2.1 从上游 `tools/code-dispatch-log`/`tools/ptc-dispatch-log` 改名为「自己的 REPL dispatch log」 |
-| `tools/ptc-dispatch-log` | waterfall（上游 PTC 用） | harness `src/ptc.ts:282` + spill policy 监听（`spill-policy/src/index.ts:217`） | dashr 已不再 emit（仅注释提及） |
-
-**结论**：
-- 「自己的 REPL dispatch log」`dashr/repl-dispatch-log` **在代码里存在且自注册**——目标形态已就位。它之所以「没被触发」，是因为崩溃发生在它之前的 `scheduler.prepare`（它在 settle 之后才跑）——**是崩溃的结果，不是原因**。
-- 会话日志里我用作定位证据的 `tool/code-dispatch-start` 是**持久日志事件名**，与 waterfall 改名无关，只是「撕裂点之前最后一条已写入事件」的定位标记。
-- 改名引入了一个**真实但非崩溃的副作用**：harness 的 spill policy 仍监听上游 `tools/ptc-dispatch-log`，dashr 不再 emit → 溢出限幅（oversized 结果的 preview+locator 替换）对 eval 子调用日志**静默失效**。**已补（2026-09-01 晚，见六）**：dashr `shapeDispatchLog` 跑完 `dashr/repl-dispatch-log` 后，再把同一 dispatch（载荷结构与上游 `PtcDispatchLog` 完全一致）喂进 `tools/ptc-dispatch-log` 载体，spill 臂恢复生效。改动在 `dashr/src/index.ts`，lib 已重建（`f0febba7…`），**部署位同步 + daemon 重启待用户执行**。
-
-## 四、为什么 `registry[TOOL_RUNTIME_SCHEDULER]` 是 undefined（直接原因）
-
-
-- 已排除：dsh-tools 双副本 symbol 不一致（实测插件与 daemon 均解析到同一 realpath `/home/u1/workspaces/dsh-alpha/packages/core/tools`，symbol 严格相等）；dashr 分派代码改动（266d232/06e516a/HEAD 逐字节一致）；dsh-tools alpha.1 vs alpha.3 差异（仅 import 整理/ToolCallId brand 等外观差异）。
-- 关键观察：`classify()` 调用的 `registry.executionMode(input)` **正常**（`code-dispatch-start` 已写入日志，证明 `start()` 之前的分派逻辑跑通），而 `registry[TOOL_RUNTIME_SCHEDULER]` **取不到**。`executionMode` 是 ToolRuntime 类方法、`TOOL_RUNTIME_SCHEDULER` 是类实例 symbol 字段——即部署运行态 `runtimeCtx.tools` 返回的**不是原生 ToolRuntime 实例**，而是一个有方法、缺实例 symbol 字段的服务视图（cordis 作用域服务解析 / plugin tree 挂载路径差异）。
-- 测试为什么全绿：dashr 测试组合（`test/helpers.ts`）把 `ctx.tools` 解析到**根作用域的原生 ToolRuntime 实例**，symbol 在位；生产组合经 harness plugin tree / scope 层解析，拿到的是视图。
-- **何时坏的（重要修正）**：v0.1.8 实测报告（2026-08-24）实证 DASHR 自己的 `eval` 桥当时**正常工作**——同 cell 并发 `tool.read` + `tool.bash` 完成。2026-08-28 会话用的是 harness 自带 PTC `run_cell`（`tools.bash`，复数命名空间 = PTC SDK 形态；该 PTC 核心经 `@deepseek-ai/dsh-code-runtime-python` 执行 **Python**，非 TS），不能代表 dashr 桥状态。**崩溃由 2026-09-01 的 harness alpha（0.1.2-alpha.1）升级引入**——升级后 plugin tree 里 `runtimeCtx.tools` 变成缺实例 symbol 字段的服务视图；dashr v0.2.1 的 dispatch-log 改名不是崩溃原因。
-
-## 五、REPL 同步/异步问题的回答（顺带闭环）
-
-- 模型层：`eval` 是同步工具调用，模型等 cell 结果——这是设计使然，与缺陷无关。
-- cell 内：`tool.<name>(...)` 是 kernel→host 的 `binding.call` RPC，被 cell `await`；host 经与原生调用同一 registry 分派器执行。`run_in_background: true` 的工具实现**快速返回 id**（subagent `{kind:'continuable', subagentId}`、bash 返回 job id），background 语义本应保留、子任务与 cell 结束无关。
-- 但**当前运行时该路径整体坏掉**：任何子分派在 `scheduler.prepare` 即 TypeError，与 background 无关——所以「在 REPL 里 background 是否异步」目前是伪问题，路径不通；修好后 background 语义会按上述设计成立。
-
-## 六、修复方向（分层）
-
-1. **dashr 立即修（阻断 daemon 崩溃）**：`drive()` 加 catch / `start()`、`commit()` 失败必须 settle binding promise 为错误结果——cell 内工具调用失败应变成可见的 `ToolCallError`，**绝不允许以 unhandled rejection 外泄杀 daemon**。这是把「任何分派错误」放大成「整个运行时崩溃」的放大器，无论直接原因是什么都必须先修。
-2. **dashr 防御**：`registry[TOOL_RUNTIME_SCHEDULER]` 为 undefined 时抛带上下文的 loud 错误（cell 可见），而不是裸 `undefined.prepare` TypeError。
-3. **根因定位（harness 接线）**：在活体 daemon 上探针确认 plugin tree 中 `runtimeCtx.tools` 的实际对象（cordis 作用域服务视图 / 第二个 tools 实例），修正挂载使插件拿到原生 ToolRuntime（symbol 在位）。这一步需要 daemon 侧可写环境（本会话 bwrap 沙箱只读宿主，无法直接探查活体）。
-4. **测试补强（部分完成）**：已加「`tools/ptc-dispatch-log` 载体回喂」回归用例（`test/bridge.spec.ts`，全量 396 绿）。仍缺「生产形态」挂载测试——按 harness 的 plugin-tree/scope 方式挂载插件，断言 `ctx.tools[TOOL_RUNTIME_SCHEDULER]` 已定义 + 一个真实工具 RPC 从 cell 完成；防止此环境差异回归。
-5. **回归核验基线**：修复后重跑本文档第一节的 4 探针矩阵（4/4 应全部返回结果而非截断），并观察 `journalctl --user -u dsh.service` 无新崩溃。
-
-## 附：证据文件
-- 会话日志：`~/.dsh/sessions/--home-u1-workspaces-dashr--/session-ad9ac311-3400-4304-b501-e7303da850df/session.jsonl.zstd`
-- 守护进程日志：`journalctl --user -u dsh.service`（17:39:17 / 17:41:15 / 17:57:05 / 18:02:27 四条 fatal load failure）
-- 对照工作会话：`06ac8b2c-fb2e-458f-80d6-a0d28e50f193`（2026-08-28，9 对完整 code-dispatch，PTC run_cell 路径）
-
----
-
-## 七、v0.2.1c 修复执行记录（2026-09-01，change v0-2-1c-repl-tool-crash-fix）
-
-### 六.1 + 六.2 已实现（dashr 侧）
-
-- `drive()` async IIFE 补 `catch`：lane 级 backstop——任何逃逸 start()/commit() 自身包裹的错误（或 classify() 抛错）settle 所有 queued-but-unsettled 分派为可见错误、清空队列、复位 exclusive、记 warn，**绝不外泄 unhandled rejection**。
-- `PendingDispatch` 新增 `fail(error)`：把 binding promise settle 为 `{ isError: true, message }`（经 `settleError` → `settle`，kernel 转 `ToolCallError`）。
-- `start()` / `commit()` 各自 try/catch：prepare 失败、dispatch body rejection、finalize/finish 失败都 settle 自己的 binding，不再向 lane 抛。
-- `binding()` 内 `registry[TOOL_RUNTIME_SCHEDULER]` 判空：undefined 时抛带上下文的 loud 错误（点名 symbol、指向 harness 挂载接线），替代裸 `undefined.prepare` TypeError。
-- 回归测试 3 个（`test/bridge.spec.ts`，全量 399 绿含 3 新）：view 缺 symbol → cell 收到含 `TOOL_RUNTIME_SCHEDULER` 的 loud 错误；`scheduler.prepare` 抛错 → binding settle 为可见错误；classify 抛错 → lane backstop settle 且进程存活。
-
-### 六.3 根因探针（本轮结论，待活体 daemon 复核）
-
-- **根因已锁定并更正（2026-09-02 活体探针 + 受控实验；推翻本节 2026-09-01 的 shadow 分支推断）**：真实根因是**部署拓扑 dual-copy**——崩溃期（2026-09-01 17:39–18:02）部署位插件嵌套 `node_modules/@deepseek-ai/*` 的 17 条 symlink（已退役 dev 接线）指向 dsh-alpha 源码树，插件 import 的 `TOOL_RUNTIME_SCHEDULER` 来自 alpha 副本的 dsh-tools 模块实例；daemon 的 `ToolRuntime` 实例由 host vendored 副本构建，其 symbol 字段以 host 副本 symbol 为键。两 symbol 为不同 `Symbol()` 实例：跨副本读实例字段 → `undefined`（`executionMode` 等字符串键方法不受影响、照常工作——症状逐字吻合）。
-- 证据链（2026-09-02）：① 活体 4 探针（`tool.bash` fg/bg、`tool.read`、`tool.subagent` bg:false/bg:true）经 `eval` cell 路径 4/4 真实结果——现行生产形态 symbol 在位；② 部署位 `require.resolve('@deepseek-ai/dsh-tools')` = `/home/u1/.local/lib/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-tools/lib/index.js`（host vendored，③→④ 层）；③ 受控实验：host 与 z_dsh-alpha 两副本 `TOOL_RUNTIME_SCHEDULER` 严格不等，host 键实例经 alpha symbol 读 → `undefined`、经 host symbol 读 → object；④ 时间线闭环：改名 `dsh-alpha → z_dsh-alpha`（2026-09-01 22:29）→ symlink 悬空 → 2026-09-02 清理删除 → daemon 重启 → 自愈。
-- shadow 分支理论为何被否：它与症状吻合但从未被活体证实，且无法解释「拓扑清理 + 重启后自愈」；dual-copy 机制同时解释故障与恢复。v0.2.1c 报告引「symbol 严格相等」的排除测量与崩溃期拓扑矛盾（疑测同一副本两次或取于改名后），以直接证据为准。
-- cordis traceable proxy 本身无嫌疑（symbol 转发分支在位；现行活体 plain read 即返回带 symbol 原生实例）。
-- dashr 侧交付边界：六.1+六.2（不崩溃 + loud 错误）继续有效；dual-copy 已由部署拓扑收敛消除（部署纪律：插件 `node_modules/@deepseek-ai/` 只留 `schemastery`+`cosmokit`）；v0.2.1d 给 guard 错误附 dsh-tools 解析路径实现事件自诊断。
-### 六.4 生产形态挂载测试（说明）
-
-- 三个回归用例以「缺 symbol 视图」「prepare 抛错」「classify 抛错」三种形态驱动 `createRunCellTool`，覆盖六.1+六.2 全部防御面；测试组合（根作用域原生实例）本就 symbol 在位，断言 `runtimeCtx.tools[TOOL_RUNTIME_SCHEDULER]` 定义的用例属于测试组合自身形态（根挂载原生实例），无法复现生产 realm 差异——该差异须在活体 daemon 上复核（六.5）。

package/node_modules/better-dsh/docs/50_test-reports/kernel-provisioning.md

@@ -1,44 +0,0 @@
-# DASHR Kernel 供给（iKernel Provisioning）
-
-> One page（June R1.6 落实地）：dashr REPL 的 IPython kernel 由插件**全责供给**——位置、版本、触发时机、修复出路。对应 spec：`openspec/specs/kernel-provisioning/`（change `2026-09-02-kernel-provisioning-completeness`）。
-
-## 原则
-
-- **完全体**：不提供"只有 REPL 界面没有解析引擎"的形态。kernel 装好、能用是插件的责任。
-- **独占**：kernel 只活在插件自有 venv（`<packageRoot>/.venv-kernel`，prod 即 web profile 内插件领地；`kernelEnvDir` 可显式覆盖）。永不写用户全局 Python，probe 永不 import 用户 site 模块。
-- **不随包分发 venv**：npm 包只带 JS 产物；"随包"= 随包携带**供给能力**，供给结果在现场生成。
-- **fail-open**：任何一级供给失败只留提示（含修复出路），绝不阻断 npm 安装、daemon 启动或插件挂载。
-
-## 版本锁定（测试跑通值）
-
-| 组件 | 版本 | 出处 |
-|---|---|---|
-| CPython | 3.11（uv 拉取；无 uv 时宿主 python3 亦验证兼容——3.14.4 实测通过） | `DEFAULT_KERNEL_PYTHON_VERSION` |
-| ipykernel | 7.3.0 | `IPYKERNEL_VERSION` |
-| dill | 0.4.1 | `DILL_VERSION` |
-
-升级 = 显式 change + 回归跑通后再改常量。
-
-## 两级触发（全部幂等、全部 fail-open；v0.2.2-a 起 postinstall 已移除）
-
-1. **daemon spin-up（主路径）**：插件随宿主 daemon 在 host 平面启动即异步检查/补装。**agent session 永远不会在首用时才发现缺 kernel**。在就 pass（毫秒级 probe），缺才装（数十秒）。
-2. **首用 lazy（最后兜底）**：`kernelAutoInstall` 默认 true，覆盖 spin-up 失败/被跳过的残余场景。
-
-> **v0.2.2-a 设计变更（owner 裁决 2026-09-03）**：移除 postinstall 加速器，npm 包现为**零 lifecycle script**。原因：pnpm 10+ 供应链策略下，未经消费方 `allowBuilds` 白名单的 build script 是安装**硬错**——发布日新装的 friction 全部由此而来，而 spin-up 主路径本就覆盖其职责（fail-open、daemon 启动即检查、毫秒级 probe）。`npm run kernel:venv`（包内 `scripts/kernel-provision.mjs` 保留发布）作为手动预置入口不变。
-
-## 供给梯子与环境加固
-
-- 有 `uv`：`uv venv --python 3.11` + `uv pip install ipykernel==7.3.0 dill==0.4.1`，且 **`UV_CACHE_DIR`/`UV_PYTHON_INSTALL_DIR` 重定向到 `<packageRoot>/.uv-cache`**、`UV_LINK_MODE=copy`——只读 `~/.cache`/只读 home 的主机不再被阻断（2026-09-03 实测：HOME chmod 555 下供给成功）。
-- 无 `uv`：`python3 -m venv` + `pip install`（ensurepip，无 cache 依赖；3.14.4 实测通过）。
-
-## 各 profile 速查
-
-| Profile | venv 位置 | 验证 | 修复 |
-|---|---|---|---|
-| prod（web profile 插件） | `~/.dsh/profiles/web/node_modules/@pgmi-builds/better-dsh/.venv-kernel` | daemon 日志见 `kernel ready`；REPL 首 cell 即时响应 | 在包目录跑 `npm run kernel:venv`；或设 `python` 指向已备解释器 |
-| dev/test 4999（monorepo 副本） | `packages/better-dsh/better-dsh/.venv-kernel` | 同上（stdout 可见 provisioning→ready） | 同上；rsync 后照常（.venv-kernel 在排除清单，不被 --delete 清掉） |
-| 显式覆盖 | config `kernelEnvDir` | — | — |
-
-## 状态与错误
-
-供给各阶段有日志（provisioning / ready / degraded-dill / failed）；失败信息列三条出路：`npm run kernel:venv`（手动）、`kernelAutoInstall: true`（首用自动装）、config `python` 指向已备解释器。

package/node_modules/better-dsh/docs/50_test-reports/repl-kernel-provisioning-test-report.md

@@ -1,87 +0,0 @@
-# REPL Pad Kernel Provisioning — Test Report & Forward Requirement
-
-- Date: 2026-06-03
-- Scope: DSH Web GUI session — `eval` (dashr REPL pad) kernel lifecycle, `dvc://` device surface smoke check
-- Result: **FAIL on first-run → FIXED (manual provision) → PASS**; forward requirement recorded below for the next dev phase
-
----
-
-## 1. What was tested
-
-| # | Test | Outcome |
-|---|------|---------|
-| T1 | REPL pad first cell after a cold runtime (`eval "print(6*7)"`) | **FAIL** — kernel failed to start (`worker-exit`) |
-| T2 | Root-cause probes: filesystem writability, toolchain presence | PASS (diagnosed EROFS on `uv` cache) |
-| T3 | Managed kernel venv provisioned with redirected caches | PASS |
-| T4 | REPL pad retest after provision (`eval`, state persistence probe) | **PASS** — `pad alive: 42`, CPython `3.11.15` |
-| T5 | `dvc://` device surface (`read dvc://`, `read dvc://browser`) | PASS — roster serves `ast_edit`, `ast_grep`, `browser`, `lsp` |
-
-## 2. Environment facts (this host)
-
-| Item | Value |
-|------|-------|
-| Root filesystem | `/dev/sdc3 / ext4 ro` — **read-only** (container/image layout) |
-| Writable bind mount | `/dev/sdc3 /home/u1/workspaces/dashr ext4 rw` only |
-| `uv` cache home | `/home/u1/.cache/uv` — **on the read-only root → EROFS** |
-| `uv` | `0.11.15` (present; preferred by kernel-env provisioning) |
-| System Pythons | `3.14.4` (default `python3`), `3.11.15` (`/home/u1/.local/bin/python3.11`) |
-| Pad runtime package | `packages/better-dsh/better-dsh` (managed venv default `<package>/.venv-kernel`) |
-| Managed venv (provisioned) | CPython `3.11.15`, `ipykernel 7.3.0`, `dill 0.4.1` |
-
-## 3. Failure & root cause
-
-**Observed** (first `eval` after cold start):
-
-```
-Error: code run failed (worker-exit): kernel failed to start:
-Command failed: uv venv .../.venv-kernel --python 3.11
-error: Could not acquire lock
-  Caused by: Could not create temporary file
-  Caused by: Read-only file system (os error 30) at path "/home/u1/.cache/uv/.tmpmqu7oz"
-```
-
-**Root cause**: the dashr runtime owns a *managed* kernel venv and provisions it on first use via `uv` when no explicit interpreter is configured (`kernel-env.ts`: `createVenv`/`installDeps`, `python: python3` sentinel → managed). `uv` always stages a lock temp file under its cache dir (`~/.cache/uv`, overridable via `UV_CACHE_DIR`). On this host the root FS (and therefore `~/.cache`) is genuinely read-only, so provisioning cannot even start — an environment-portability defect, not a code bug in the provisioning logic itself.
-
-Supporting facts: provisioning is **retry-safe** (`runtime.ts` clears a rejected `kernelEnvPromise` in `.catch`, so the next `eval` retries) and **idempotent** (`ensureVenv` reuses a complete venv — `ipykernel && dill` present — without invoking `uv` again).
-
-## 4. Remediation applied (this session, host-local)
-
-1. Probed writability: `/tmp` ✅, `/home/u1/.cache` ❌ readonly (confirmed), dashr package dir ✅, repo-local cache dir ✅.
-2. Provisioned the managed venv **at the runtime's default location** so future `eval`s skip `uv` entirely:
-
-```bash
-REPO=/home/u1/workspaces/dashr/upstream/deepseek-harness
-PKG="$REPO/packages/better-dsh/better-dsh"
-export UV_CACHE_DIR="$REPO/.uv-cache" \
-       UV_PYTHON_INSTALL_DIR="$REPO/.uv-python" \
-       UV_LINK_MODE=copy
-cd "$PKG"
-uv venv .venv-kernel --python 3.11
-uv pip install --python .venv-kernel/bin/python ipykernel dill
-```
-
-3. Verified interpreter: `OK 3.11.15 ipykernel 7.3.0 dill 0.4.1`.
-4. Re-ran `eval` → PASS (see T4). The complete venv is reused on every later start; no further `uv` invocation.
-
-Artifacts left on disk (build state, not tracked source): `<package>/.venv-kernel`, sibling `$REPO/.uv-cache`, `$REPO/.uv-python`.
-
-## 5. Forward requirement — R1 (next dev phase)
-
-> **Proper kernel provisioning at installation time is a requirement, across all environments (prod / dev / test).**
-
-First-run lazy provisioning must **not** be the only path: an environment where the interpreter cannot be provisioned at runtime (read-only root, no writable home/cache, air-gapped, no `uv`) currently bricks the REPL pad entirely. The coming dev phase must make kernel setup an explicit, environment-aware installation step.
-
-Proposed acceptance criteria (to be confirmed/refined in the dev plan):
-
-- **R1.1 Install-time provision hook.** `npm run kernel:venv`-equivalent (already exists) is promoted to part of standard install; runtime lazy-provision remains only as a fallback for writable dev hosts.
-- **R1.2 Environment profiles.** prod / dev / test each declare kernel policy: explicit interpreter path vs. managed venv dir, auto-install on/off, version pin (`kernelPythonVersion`), and fail-fast behavior — surfaced as config, not code (`kernelEnvDir`, `kernelAutoInstall`, `kernelPythonVersion` already exist in the runtime config schema).
-- **R1.3 Writable-cache independence.** Provisioning must set/respect `UV_CACHE_DIR` / `UV_PYTHON_INSTALL_DIR` (or fall back to `python3 -m venv` + `ensurepip`) so read-only `~/.cache` or read-only root never blocks the pad.
-- **R1.4 Verification gate.** Install/CI runs a probe (`import ipykernel, dill`) and fails loudly with the actionable message already implemented in `kernel-env.ts` (`run 'npm run kernel:venv' … or set kernelAutoInstall: true`).
-- **R1.5 CI coverage.** dev/test CI exercises a cold start (no venv) and a pre-provisioned start; prod smoke test asserts the pad boots on first `eval` (or fails fast at deploy).
-- **R1.6 Docs.** One page: how each profile's kernel is provisioned, verified, and repaired — this report's §4 command becomes the canonical snippet.
-
-## 6. Open items
-
-- Host `python3` default is 3.14 while the managed venv pins 3.11 — confirm the intended matrix (the runtime already probes/pins independently of PATH default).
-- Decide whether the GUI should surface kernel provisioning status/errors (today failures surface only through the `eval` error).
-- `/tmp` is writable here but tmpfs-reaped on reboot — prefer repo/home-adjacent venv dirs (current default already avoids `/tmp` by design; keep it).

package/node_modules/better-dsh/docs/50_test-reports/upstream-dsh-0.1.2-alpha.5-local-test-report.md

@@ -1,81 +0,0 @@
-# 上游 dsh 0.1.2-alpha.5 本地实测报告（Dev/Test 1 源码级 4999 实例）
-
-- 实测日期：2026-09-02
-- 范围：upstream checkout 升级 alpha.3 → alpha.5、本地构建、4999 隔离实例启动、工具面冒烟、agent 侧功能实测（user 驱动）、session storage 热升级观察、web UI 手工核查（user）
-- 结论：**PASS —— 无破坏性更新，整体可跑起来；dashr 工具与界面介入 functionality 衔接正常，无大适配性问题**。3 项 UI/功能瑕疵记录在案，作为下一波 alignment 的 change 输入（§4）。
-
-前置调研见 `upstream-dsh-0.1.2-alpha.5-report.md`（alpha.3 → alpha.5 差异分析）。
-
----
-
-## 1. 实测范围与结果
-
-| # | 测试 | 结果 |
-|---|---|---|
-| T1 | checkout `dsh-v0.1.2-alpha.5` + 本地 patch 重放（stash → checkout → stash pop） | ✅ patch 载体文件（`pnpm-workspace.yaml`/`tsdown.client.ts`）tag 间零改动，干净重放；备份 `.scratch/alpha3-local-patches-backup.patch` |
-| T2 | `pnpm install`（268 workspace projects，store 重定向 `.scratch/pnpm-store`） | ✅ EXIT=0（修两坑后，见 §2 备注） |
-| T3 | `pnpm run build` + better-dsh tsdown | ✅ tsc + tsdown host/client + vite web（220 client artifacts）+ 插件产物 |
-| T4 | 4999 实例启动（`DSH_HOME=.dsh-test`，与 prod 3080 完全隔离） | ✅ `dsh-root@0.1.2-alpha.5` 监听 127.0.0.1:4999，token URL 正常签发 |
-| T5 | 工具面冒烟（dump-config） | ✅ `dashr-repl` 工具行在、`DASHR_KERNEL_PYTHON` 注入正常；`tool-web` 为 `fetchProvider: http`，`web-fetch-http` 服务挂载——alpha.5 的 **web_fetch 默认开放**在本实例得到确认（base 层行为，含无审批匿名公网抓取，见调研报告专题二） |
-| T6 | web shell 冒烟（cookie jar + 303 认证链） | ✅ 根页 200（title: DSH Local Build）+ 新构建 asset（`/assets/index-*.js`）200 |
-| T7 | **session storage 热升级观察**（重点，见 §3） | ✅ 结构变更就地完成，全程无崩溃 |
-| T8 | agent 侧功能实测（user 在实例上驱动运行中的 agent） | ✅ dashr 工具与界面介入 functionality 均能衔接，整体无大适配性问题 |
-| T9 | web UI 手工核查（user） | ⚠️ 3 项瑕疵，见 §4（1 项为 dashr 计划特色未实现；2 项为 user 私人 patch 未适配） |
-
-## 2. 环境事实
-
-| 项 | 值 |
-|---|---|
-| Harness checkout | `./upstream/deepseek-harness`，detached at `dsh-v0.1.2-alpha.5`（db6bdc3576） |
-| 本地 patch（3 个，全部重放成功） | ① `tsdown.client.ts` REPOSITORY_ROOT 推导（本机 Node 22.22.1 无 native TS loader，必需）；② `pnpm-workspace.yaml` storeDir 重定向 + `verifyDepsBeforeRun: false`；③ 根 `package.json` 补 `unrun` devDep |
-| dashr 副本 | `packages/better-dsh/better-dsh/`（workspace 成员，npm-range peerDeps 靠 `linkWorkspacePackages` 解析） |
-| 用户数据 | `DSH_HOME=/home/u1/workspaces/dashr/.dsh-test`（**携 alpha.3 时代存量数据直接升级**，这正是 T7 的观察对象） |
-| 实例 | `npm run dsh -- web --no-open --port 4999`；prod `~/.dsh` 全程未动 |
-
-本轮融资到的两个坑（已修，并已固化进 AGENTS.md）：
-
-1. **stale peerDep 复发**：rsync 从 canonical 带回 `@deepseek-ai/dsh-client-runtime` peerDep；alpha.5 workspace 已无此包、npm 亦无匹配 range 的版本 → `ERR_PNPM_NO_MATCHING_VERSION`。修法：副本 package.json 删该 peerDep + `peerDependenciesMeta` 条目（每次 rsync 后须重删）。
-2. **zeromq build 审批**：pnpm 11.7 插入的 `set this to true or false` 占位符在 strictDepBuilds 下为硬错误。修法：`allowBuilds` 显式 `zeromq: true`（zeromq 是 better-dsh 自己的 kernel IPC 依赖，必须放行）。
-
-另：`pnpm install | tail` 会吞退出码（本次正是靠 `pipefail` 抓到第一坑），流程里一律 `set -o pipefail`。
-
-## 3. 重点观察：session storage 结构性更新与热升级自愈（T7）
-
-**这是本轮实测最重要的一条记录：上游 alpha.5 自带的 session storage 热升级在真实测试实体上可观察地完成了——结构变了，系统没有崩溃。**
-
-背景（上游笔记 `.agents/notes/implemented/architecture/2026-09-02-projcache-cross-version-read-compat.zh.md`）：`session_projcache` 域磁盘结构三代演进——v3（0.1.1-rc.2，单文件）→ v4（0.1.2-alpha.3，per-record `sessions/<sessionId>.json`）→ v5（0.1.2-alpha.4/5，同布局，identity 新增 `isSeeded`/`inheritedEventCount` lineage 字段）。alpha.5 的热修以声明式读兼容实现自愈：域声明 `version: 5, compatibleVersions: [3, 4]`，旧版本戳记录直接读入，**读到旧记录后的下一次 checkpoint 自然把它重写为当前版本**；schema 兜底 `backup-and-skip`（改名 `.bak.<ts>` 留档跳过），取代此前"整域拒开/列表丢标题"的故障模式。
-
-本实例的磁盘证据（`.dsh-test/storages/`，时间线）：
-
-| 观察 | 事实 | 解读 |
-|---|---|---|
-| 存量保留 | `session_projcache/` 目录 mtime 停在 16:44（alpha.3 建域时刻）原地保留 | 升级未清场、未迁移重摆 |
-| **热升级写回** | `sessions/session-2547aab1….json`（createdAt ≈ 16:44，**与 alpha.3 建域精确吻合的旧会话**）mtime 21:48（alpha.5 运行期），内容已是 `"version": 5` 且带 `isSeeded`/`inheritedEventCount` | v4 旧记录被读兼容接受后，checkpoint 重写为 v5——**"自愈"的直接物证** |
-| 新写会话 | 23:31 起新会话文档 `version: 5` 正常写入（新 id 无 `session-` 前缀） | 新版本戳写入路径正常 |
-| 混版本共存 | 23:36/23:48 仍有 `version: 4` 新文档落盘（cwd=`.scratch/acp-playground`；**已确认（user）：另一 agent 的 dsh ACP 测试共享 `.dsh-test` profile**——隔离分区、共享测试 profile，属预期形态），与 v5 文档同域共存、SessionList 照常服务 | 读兼容不仅容忍存量，也容忍**并发旧版本写入**（新老实例并发共享一个 home 的额外压力证据） |
-| 无崩溃 | 整个测试窗口（含 user 交互实测至 23:49）实例持续服务 | "没有发生破坏性崩溃"——虽然结构变了，升级对使用侧透明 |
-
-结论：对将来的 prod 升级（目前 prod 仍为 alpha.3 = v4 home）而言，本轮等于在隔离实体上预演了同一条升级路径（v4 home → alpha.5），**存储侧无阻断性风险**。
-
-## 4. 发现的瑕疵（下一波 alignment 的 change 输入）
-
-| # | 现象 | 定性 | 去向 |
-|---|---|---|---|
-| P1 | Settings > General 未见 **Model Failover** 功能 | dashr 计划中的特色功能，尚未实现——非 alpha.5 回归 | 排入 dashr 下一波开发 |
-| P2 | **Loopback Auth Patch** 未生效：Settings > Models 显示 "loading the provider directory failed"，模型清单不出 | user 私人 patch（不随 dashr ship）；alpha.4/5 对 provider directory 相关代码有改动，patch 触点漂移 | alignment change：为 patch 重定位触点 |
-| P3 | **Mobile Responsiveness UI Patch** 未生效：移动端右侧栏未隐藏（宽度不为 0），手指左右滑动交互失效 | user 私人 patch（不随 dashr ship）；布局逻辑向 CSS 迁移（调研报告专题一）后原 JS 侧挂点失效 | alignment change：改走 CSS/语义属性路线重做 |
-
-dashr 本体（工具注册、REPL pad、界面介入）：无适配性问题（T5/T8）。
-
-## 5. 流程化产出（本轮已落地）
-
-1. **`.agents/skills/upstream-alignment/SKILL.md`**：把"上游插件项目的版本对齐"固化为可复用技能——checkout 最新上游 → wire 最新插件 → 验证运行 → 发现的不足作为下一波 change。本轮 alpha.5 实测即其首次全流程演练。
-2. **AGENTS.md 部署规范**：新增"user, just another user"生产部署原则（registry 同源安装：npm 主体 + npm/plugin-market 插件），与 dev/test 源码路径（第二、三节）正式分离。
-
-## 6. Open items
-
-- ~~确认 §3 混版本共存中 v4 新文档的确切写入方~~ **已确认（user 2026-09-02）**：另一 agent 的 dsh ACP 测试共享 `.dsh-test` profile（隔离分区、共享 profile），v4 新文档即其写入，属预期测试形态。
-- P2/P3 两个 user 私人 patch 在 alpha.5 下的重适配（触点重定位 / CSS 路线重做）。
-- P1 Model Failover 的设计与排期。
-- dashr web UI 卡片半边（`build-client`）在 monorepo 内仍未跑（沿用既有记载，需要时再补）。
-- prod（3080）升级决策：本轮存储侧与插件侧均无阻断项；升级时按调研报告专题二复核工具面（base 默认多出无审批 `web_fetch`）。

package/node_modules/better-dsh/docs/50_test-reports/upstream-dsh-0.1.2-alpha.5-report.md

@@ -1,93 +0,0 @@
-# 上游 dsh 0.1.2-alpha.3 → 0.1.2-alpha.5 改进调研报告
-
-- 调研日期：2026-09-02
-- 方法：npm tarball diff（伞包仅版本号与 vendored 树增删变化）+ upstream git tag diff（`dsh-v0.1.2-alpha.3..alpha.5`，2391 文件 +30k/−21k）+ 仓内 `.agents/notes/implemented/` 设计笔记（上游每个决策都有 as-built 笔记，本报告的结论均有笔记或 diff 直接佐证）
-- 版本事实：alpha.4（09-01）为大批量发布（~8.5k agent 生成的 commit，重测试/文档）；alpha.5（09-02）为 4-commit 存储安全热修。`latest` dist-tag 仍为 0.1.1-rc.2，本线仅在 alpha 通道。
-
----
-
-## 专题一：前端布局逻辑迁移到 CSS
-
-### 1.1 动机：不是"React 太重"，而是"JS 驱动的布局测量太贵"
-
-React 本身没有被替换——组件、store、渲染管线全部保留。被替换的是**用 JS 读 DOM 几何、再写回样式**的那类"布局反应性"代码。三个典型案例（均有 commit diff 实证）：
-
-**案例 A — ReasoningRow（`perf(ui-chat): move reasoning tail alignment to CSS`，203e2440ac）**
-- 之前：组件持有一个 40 行的 `use-throttled-visual-update` hook，每次流式文本更新后同步读 `scrollWidth`/`clientWidth` 再写 `scrollLeft`，把"推理摘要跟随末尾"对齐。这是教科书式的 forced synchronous layout（读-写-读交替触发反复强制布局），且发生在**每个流式 token 到达时**。
-- 之后：hook 整个删除；对齐改为 `data-follow-end` 属性 + CSS `display:flex; justify-content:flex-end; min-width:100%`，浏览器原生完成尾部跟随，零 JS。
-
-**案例 B — MessageIconActions（`derive user action reveal in CSS`，f808112ec8）**
-- 之前：每个用户消息组件订阅 conversation store，倒序遍历节点序列计算"我是不是最新用户行"，决定操作按钮常显/悬停显——转写一变就可能触发一批组件重渲染。
-- 之后：store 订阅与 `reveal` prop 全部删除；CSS 用 `:has(~ :is([data-chat-flow-kind='user'],…))` 兄弟选择器从 DOM 结构直接推导"后面还有没有更新的用户行"。
-
-**案例 C — ProducedFiles（`move overflow sizing to CSS`，e5bbee893b + 笔记 `2026-09-01-css-produced-file-layout`）**
-- 之前：产出文件行在隐藏探针树里**复制每个候选 chip**，layout effect 同步读 computed style 与元素几何，行或探针 resize 时反复重测——只为算"一行放得下几个文件名"。
-- 之后：探针树、resize observer、布局 state、几何读取全部删除；改为 inline-size 容器查询 + 预设宽度档位（`@container (max-width: 687/583/479/375px)` 四档，每档预算 = 96px/chip + 8px gap + 64px 剩余标签），flex 收缩 + ellipsis 兜底。
-
-**判断依据是逐案取舍，不是教条**：同一波里 `aad1ce0c68 perf(ui-chat): retain the stats resize observer` 明确保留了 StatsLine 的 resize observer——CSS 表达不了的真实内容测量仍留在 JS。配套的流式性能潮（每 2–3 帧发布一次流式更新、滚动几何采样节流）说明整体背景：流式会话让主线程每秒都在跑布局相关代码，把能下沉到 CSS 的布局反应性下沉，是性价比最高的削减。
-
-结论：**转变的动因是性能（layout thrashing / per-frame observer 与 state churn），而非框架更换或 React 本身太重**。
-
-### 1.2 解耦与维护维度：CSS 是静态资产，store 驱动的 DOM 自适应
-
-先回答核心疑问：**CSS 不随 store 动态增加或减少。它就是你猜的第二种——构建期静态资产，所有可能形态预定义在样式表（甚至预渲染在 DOM）里，React 产生的模块去自适应。**
-
-机制拆解（对照"基础组件 → 中间层转译 → 统一 store → 渲染层"的既有心智模型）：
-
-1. **store → 转译/slot → React 的管线完全没动**。变化只在渲染产物这一段：从"JS state 驱动布局"改为"语义属性 + 静态 CSS"。
-2. **CSS 载体是 CSS Modules**（`*.module.css`，与组件同目录，构建期编译打包）。alpha.3 → alpha.5 ui-chat 包内 `.module.css` 数量不变（16 → 16），不存在运行时生成/注入 CSS 的通道。
-3. **耦合面是一张有界的语义属性词表**：`data-chat-flow-kind={routedNode.kind}`、`data-follow-end`、`data-shown='N'`、`data-pending-steering`……全部是渲染时从节点数据**一次性落下的静态标注**。store 变化 → React 重渲染 → 属性/内容更新 → CSS 选择器（container query、`:has()`、media query）自动反应。CSS 侧永远不感知 store 结构。
-4. **"所有变体预渲染 + CSS 挑选"**：ProducedFiles 每行至多渲染 6 个 chip 加一组预渲染的本地化 `+ N files` span，CSS 档位只让其中 0 或 1 个可见——所有分支都在 DOM 里，由 `@container` 决定显隐，不做运行时测量。
-
-**是否多了一个维护维度？是，但有界、且被上游显式文档化并测试锁定**：
-
-- 代价 1：变体必须预渲染，DOM 略胖（每行多几个短 span）。
-- 代价 2：档位断点与布局预算强耦合——改 chip 最大宽/间距要同步改四档断点（预算以局部 CSS 自定义属性 `--produced-file-chip-max`/`--produced-file-gap` 为准，笔记里写明了换算）。
-- 代价 3：语义属性词表成为 React 侧与 CSS 侧的契约，两侧需同步演进；行为由 client spec + e2e 锁定（单行、无横向溢出、响应式省略、无悬停设备回退）。
-- 代价 4：**精度换确定性**——固定档位忽略实际文本宽度与本地化标签宽度，可能比精确测量多/少显示一个 chip。上游在笔记里明确接受了这一近似（`+ N files` 计数始终准确）。
-
-对比维护成本：删掉的是每组件一份的 observer + layout effect + 布局 state + 几何读取（每处 40–140 行 JS），换来的是一份静态样式表里的几十行声明式规则。上游把这类改动归档在 `simplification/`（简化）而非 `architecture/`（架构）目录——他们将其定性为**净删减复杂度**。
-
----
-
-## 专题二：web_fetch 默认开放的含义
-
-**是什么**：共享基础 bundle `dsh-base` 的 `tool-web` 配置从 `fetch: false` 改为 `fetch: true`（`packages/bundle/base/cordis.patch.yml`）。即 `web_fetch` 从"各产品层各自 opt-in"变为 **base 层默认挂载的模型工具**。
-
-**之前（alpha.3 及更早，笔记 `2026-07-31-web-default-search`）**：base 只默认暴露 `web_search`；`web_fetch` 需要产品层逐个 override 开启（Web 的 cordis/ptc/standard presets、headless、full SDK 开了），ACP 被漏掉，新建 base-only profile 默认没有 fetch，快照头也因此按产品分裂。
-
-**之后（笔记 `2026-09-01-shared-base-web-fetch-default`）**：所有已交付完整产品对匿名公共抓取的策略已收敛一致，重复 override 不再编码任何产品差异，于是上收到 base：
-
-- headless / full SDK / **ACP** / 自定义 base-only profile 全部直接继承 `web_search` + `web_fetch`，零应用层 override；
-- Web app 改为禁用 base 的 tool-web 行、按 agent preset 组合同样一对工具（行为不变，配置位置变化）；
-- `sdk-minimal` 不经过 base，不受影响。
-
-**安全边界（笔记原文要点）**：
-
-- 匿名 `http:`/`https:` 请求，且**仅允许校验过的公共目的地**（public-destination validation，即防 SSRF 打内网/环回）；
-- 抓取在 shell/文件沙箱与审批预设**之外**执行，**无需逐调用审批**；
-- 笔记明说"public-destination validation does not prevent public data egress"——只限目的地是公网，不限制公网数据外发；
-- 需要不同网络策略的产品/部署，必须在更晚的 bundle 或 profile patch 里**显式覆盖整个 tool-web 配置**。
-
-**对本机的含义**：全局 dsh 若从 alpha.3 升级，所有 base-backed 面（含 Dash Agent 本体与 ACP）的默认模型工具面会多出无审批的 `web_fetch`。omp-web 因禁用了原生 agent-loop/llm routes，其 OMP-backed agent 不直接受影响，但共享同一 host 工具注册面，升级时值得在 4999 测例里过一眼工具清单。
-
----
-
-## 其余要点（回顾，详见前次会话总结）
-
-- **新包 `dsh-experimental-code-runtime-python`**：`ctx.codeRuntime` 能力缝的 CPython 子进程实现（fd 3 JSON-lines 协议、RLIMIT/墙钟/SIGKILL 约束），即 `run_code`/"Code Mode" 底层；vendored 树同时移除 `dsh-tool-subagent-report`。
-- **内部破坏性重构**：session 事件 seq 与 log offset 分离（笔记 `2026-08-31-session-sequence-and-log-offset-brands`）。
-- **alpha.5 存储热修**：per-record 单元跨版本读兼容 + backup-and-skip 抢救；升级后的 session-projection 缓存保持可读（笔记 `2026-09-02-projcache-cross-version-read-compat`）——升级 prod 前必读。
-- **视觉刷新**：超椭圆圆角 + 发丝线阴影描边（两份 09-01 笔记）。
-
-## 参考索引
-
-| 主题 | 证据 |
-|---|---|
-| CSS 布局档位笔记 | `.agents/notes/implemented/simplification/2026-09-01-css-produced-file-layout.md`（中英双语） |
-| 尾部对齐 CSS 化 | commit `203e2440ac`（删 `use-throttled-visual-update.ts`） |
-| 悬停显隐 CSS 化 | commit `f808112ec8`（`:has(~ …)` 替代 store 订阅） |
-| 溢出测量 CSS 化 | commit `e5bbee893b` + `ProducedFiles.module.css` 宽度档位 |
-| 保留 observer 的反例 | commit `aad1ce0c68` |
-| web_fetch 默认开放 | 笔记 `feature/2026-09-01-shared-base-web-fetch-default.md`；`bundle/base/cordis.patch.yml` `fetch: false→true` |
-| 被取代的旧决策 | 笔记 `feature/2026-07-31-web-default-search.md`（fetch opt-in 段落被标注 superseded） |

package/node_modules/better-dsh/docs/50_test-reports/upstream-dsh-0.1.3-alpha.2-local-test-report.md

@@ -1,44 +0,0 @@
-# 上游 dsh 0.1.3-alpha.2 对齐轮本地实测报告（dashr 测试线）
-
-- 实测日期：2026-09-08
-- 范围：**仅 dashr（better-dsh 插件）** 自身对齐（omp-web 不在内）；OpenSpec change `openspec/changes/2026-09-08-upstream-0-1-3-alpha-2-alignment/`（G1 S1–S7 + G2 小修，v0.2.3）
-- 环境事实：checkout `upstream/deepseek-harness` @ `dsh-v0.1.3-alpha.2`（`82a5fd61a7`，release merge PR #3685）；Node v22.22.1（unrun 路径）；pnpm 11.7.0（store 重定向 `.scratch/pnpm-store`）；better-dsh 副本 = canonical `0.2.3`（rsync 双向已收敛，src/test 字节一致）；`DSH_HOME=.dsh-test`（prod `~/.dsh` 未动）；web `127.0.0.1:4999`
-- 上游版本判定（S0 报告 `docs/50_test-reports/upstream-dsh-0.1.3-alpha.2-report.md`）：rc.1 = 纯发布（代码零差）；目标 = alpha.2（npm `alpha` dist-tag）
-
-## 实测结果表
-
-| 步骤 | 结果 | 备注 |
-|---|---|---|
-| S1 侦察 | ✅ | 三 tag 本机拉齐；patch 载体 tag 间 diff 复核（tsdown.client.ts ±1 / pnpm-workspace.yaml +8−1；`resolveRepositoryRoot` 上游未吸收，仍需本地） |
-| S2 切换与重放 | ✅ | alpha.5 脏 overlay 全量归档 `.scratch/alpha5-dashr-local-overlay.patch`（2527 行）→ stash → checkout alpha.2 → 三必需 patch 手工重放（unrun devDep / storeDir+verifyDepsBeforeRun+zeromq / tsdown `resolveRepositoryRoot`）。**overlay 定性**：其余 17 文件全部为 bun --compile 可移植补丁（注释自证；Node 下惰性/同行为），未重引（4999 走 Node），归档留存 bun 实验用 |
-| S3 副本地化 | ✅ | 副本无 stale `dsh-client-runtime` peerDep；peer 范围含 alpha.2（0.1.3-alpha.2 ∈ `>=0.1.2-alpha.1 <0.2.0-0`）；bundle 名 `@deepseek-ai/dsh-base`/`dsh-web-app` 不变 |
-| S4/S5 安装与构建 | ✅ | `pnpm install`（**pnpm 11.7 自动插 `allowBuilds` 占位符 `set this to true or false` → 硬错，改显式布尔**，AGENTS.md 已知坑再现）；`pnpm run build` 全绿 ×2（tsc host + tsdown + vite web + 224 client artifacts），better-dsh lib+client 在位 |
-| S6 启动 4999 | ✅ | systemd-run `dsh-4999-test`；root 200；dump-config：`dashr-repl` 行 + `DASHR_KERNEL_PYTHON` 注入 ✓；**注**：stop 后立即 start 有 EADDRINUSE 竞态（旧实例端口未释放），需间隔 ~2s 或独立 unit 先验证 |
-| S7.1 工具面 | ✅ | `tool-web` 在位；`str_replace_editor` **缺席（0）**（base/web-app 默认下架生效） |
-| S7.2 client 卡片 | ✅ | boot 图含 `"id":"better-dsh"`；合并 loader bundle 200（5.2MB/224 模块），better-dsh 段与 `lib/client/index.js` **字节一致**（除 sourceMappingURL 尾行）；单入口 `/plugins/??better-dsh/client.js` 404（alpha.2 只服务聚合 `??` 请求——探针改聚合提取法） |
-| S7.3 行形状查表 | ✅（预查收敛） | ① connection 行形状未漂移（persona 行改 prefix/suffix 与 dashr 无交集）；② `__DSH_TRANSPORT__` 读法不变（新增可选 `__DSH_CONNECTION_RECOVERY__`，缺省无害）；③④⑤ 零改动 |
-| S7.4 fence/isLoopback | ✅ 静态 | 页面含 `__DASHR_MOBILE__` boot script（web-trust 腿在位）；`__DSH_TRANSPORT__` 0（空 authorities 惰性=设计）；env 探针（`DSH_TRUSTED_HOSTS` 401/403）留手测 |
-| S7.5 zoomGuard | ✅ 静态 | ④⑤ 零改动 → reconcile 路径不变；CDP 双形态留手测 |
-| S7.6 telemetry | ⏳ 手测 | feedback 面已 revert（上游 13daefe073）；`DSH_TELEMETRY_DISABLED=1` 立场 prod 验证 |
-| S7.7 老会话读兼容 | ⏳ 手测 | `.dsh-test` 无 v1 历史会话可自动验证；建议 GUI 用旧会话验证（上游 released migration 兜底） |
-| file-tool 升级矩阵 | ⏳ 手测 | 事件报告建议 3 回归项；本地链路 09-06 已过，本实例留 user GUI 复测 |
-
-## 发现与修复（本批次代码改动，vitest 全量 481/481 绿）
-
-1. **session 事件面 API 漂移（真实对齐点）**：registry 解析的 `@deepseek-ai/dsh-session@0.1.2-rc.1` 为 **format-v2 会话**（`SESSION_FORMAT_VERSION=0`；header 必填 `isSeeded:boolean`；无 `.events` 属性，改 `snapshotEvents()`/`ownEvents()`）→ dashr `url-schema/handlers/agent.ts` roster 的 `live.events` 属性读失效。修复：`live.snapshotEvents()`；测试 fixture 补 `isSeeded:false`（自包含 seed，非 fork）。见 diff。
-2. **pi-natives loader 锚点穿透**：`findPackageDir` 的 `createRequire.resolve` 快路径会经进程 globalPaths（含 pnpm `.pnpm/node_modules` hoist 根）从**任意锚点**命中已安装 addon，违反"锚点限定"契约（degradation 测试抓出）。修复：去掉 resolve 快路径，仅用自锚点向上的确定性 node_modules walk。见 diff。
-3. **escalation-guidance 附 A 定稿回填 canonical**（drift 修正）：monorepo 副本已实装定稿（deniable/denied · per-call），canonical `src/index.ts` 仍旧句 → 回填；`presentation.spec.ts` 断言同步（定稿 token + 无 'retried once' 断言）。
-4. **附 C 矛盾子句结案（不暴露）**：render 证据（`renderReplBridgeInstructions` signature-only，description 散文不进模型可见面）→ 不做 dashr 侧订正；上游 schema 文本缺陷记上游面 Open item。S7 实证项（grep 装配产物 0 命中）未单独执行——本轮运行实例装配面即证（签名行、零散文）。
-
-## 环境注记 / Open items
-
-- **peer 双副本分裂**：better-dsh 的 peer `@deepseek-ai/*` 经 pnpm autoInstallPeers 从 registry 装入 `.pnpm`（dsh-llm/dsh-session@0.1.2-rc.1），而部分依赖链解析到 workspace 副本 → **包级 `tsc -p tsconfig.json` 出现双身份类型分裂（69 错，dsh-llm branded 字段、SessionSeq 品牌）**；权威类型门 = 根 `tsc -b tsconfig.host.json`（`pnpm run build`，**全绿 0 错**）。vitest 全量（36 文件/481 用例）绿。非代码回归，记录待解（历史 dev-loop 在 alpha.5 未现，系本次 registry 解析到 rc.1/alpha.2 后拓扑变化）。
-- **registry 发布物与 tag 疑点（上游面）**：npm `@deepseek-ai/dsh-session@0.1.2-rc.1` 实为 format-v2 API，而 git rc.1 tag（== alpha.5）按版本号-only 判定应无此改动 → 疑似 session 包独立发布线带 0.1.3-alpha 代码却标 rc.1。记录，prod 升级前需以 npm 发布物为准复验。
-- 手测/用户项：老会话读兼容、fence env 探针（401/403）、zoomGuard/mobile CDP 双形态、file-tool 升级矩阵、prod 3080 复测（write 事件回归）。
-- 版本：canonical `dashr/package.json` → **0.2.3**（本地 commit+tag `v0.2.3`；npm 发布按 AGENTS.md 红线另行）。
-
-## 产出
-
-- S0 差异报告：`docs/50_test-reports/upstream-dsh-0.1.3-alpha.2-report.md`（2026-09-08 已落）
-- 本报告 + OpenSpec change `2026-09-08-upstream-0-1-3-alpha-2-alignment/`（proposal/design/tasks/specs delta）
-- overlay 归档：`.scratch/alpha5-dashr-local-overlay.patch` + 逐文件分片 `.scratch/overlay-triage/`