better-dsh 0.2.4-a → 0.2.4-b

package/docs/10_plans/self-scheme-and-monolog-draft.md

@@ -1,357 +0,0 @@
-# `self://` scheme + `monolog()` tool — 设计草案
-
-> 日期（UTC）：2026-09-15 · 状态：**DRAFT / 未裁决**（无实现、无 spec 落盘）
-> 定位：把 RLM（Recursive Language Model）范式里**尚未落地**的那条腿，接到 dashr 已有的
-> URL schemes + `llm_completion` + 持久 kernel 上。
-> 研究依据：arXiv:2512.24601《Recursive Language Models》(Zhang / Kraska / Khattab, Open MIND, 2025-12-31)
-> 全文缓存 `~/.hermes/cache/web/arxiv.org-f7ccb39fbc.md`(455 行)；本仓调研
-> `/home/u1/workspaces/agent-harness/21_CLI-Agent/04_prime-agent/03_prime-agent-rlm-analysis.md`。
-> 全部结论均有文件/行号/引文支撑；无支撑的判断一律标 `[推测]`。
-> ⚠️ **排序已被 `self-exo-cot-draft.md`（v2）修订**：v2 依据 GPT-6 Astra 双 harness 数据
-> （62.7% → 99.9% 的自变量是 harness 侧推理保留），主张**先做 `self()` 工具**，
-> `self://` 降级为其产物的读地址。v1 的缺口分析与 `monolog()` 仍然有效。
-
----
-
-## 0. 结论速览（TL;DR）
-
-| # | 问题 | 结论 |
-|---|---|---|
-| ① | RLM 论文在哪 | **Energy-Intel 里没有**（全仓 grep `RLM`/`recursive language model`/`2512.24601` 零命中）。真正的引用在姊妹仓 **`agent-harness`**（Energy-Intel `index.md` 已 ⇄ 交叉链接该仓）。见 §1.1 证据表 |
-| ② | dashr 还有 RLM 缺口吗 | **有，但只剩一条腿**。`eval`(持久 IPython) = REPL 腿 ✅；`ctx://` = 「上下文即环境」的**读**腿 ✅；`llm_completion` = 自调用原语 ✅——**但它只吃 `prompt`，无法对「不在上下文里的资源」发起子调用** ❌。这正是 RLM 论文的核心动作（prompt 放环境里，不放进神经网络） |
-| ③ | 该做成什么 | **`self://`（只读 scheme，自指状态面）+ `monolog()`（工具，对可寻址源做递归自发调用）**。二者一个是**地址**、一个是**动作**，合起来闭合 RLM 回路 |
-| ④ | 为什么不叫 `monolog://` | 把「读一个资源」和「跑一次计算」混进同一个 scheme 命名空间；`dvc://` 的「读=roster，写=执行」已经证明这条边界在 dashr 里是**刻意维护**的（catalog.ts 明写只有 `dvc://` 可写） |
-| ⑤ | 为什么不叫 `self()` | dashr 的主交互面是 **Python cell**（`eval` / 持久 kernel）。`self` 是 Python 实例方法的约定名，把 `self` 注册成 kernel 命名空间里的可调用对象是**主动制造混淆**（本仓 v0.1.5 以前 flat-global 绑定的历史包袱，见 §3.2）。`tool.monolog(...)` 无此问题 |
-| ⑥ | 最小可行切片 | **Phase 0 = 给 `llm_completion` 加一个 `source` 参数**（URL/path → 走既有 `UrlResolver` 解引用 → 用解引用文本当 payload）。改动面最小、无新 scheme、无新工具名，先拿到「越窗读+处理」能力，再决定要不要长成 `monolog()` |
-
----
-
-## 1. 研究依据
-
-### 1.1 任务 1 的检索结论：RLM 引用**不在** Energy-Intel
-
-对 `/home/u1/workspaces/Energy-Intel`（331 个 `.md` + 若干 csv/json/pdf）做了穷尽检索：
-
-| 检索式 | 命中 |
-|---|---|
-| `RLM`（全文件类型，含二进制裸串） | 仅 `30_AI/09_llm-evaluation-and-benchmarking/collected/01_reasoning-and-knowledge/simple_qa_test_set.csv` 的偶然子串；PDF `strings` 命中的 `:rlmKqB` 是 zlib 流噪声 |
-| `recursive language model` / `递归语言模型` | 0 |
-| `2512.24601` | 0 |
-| `Khattab` / `Kraska` | 0 |
-| 文件名 `*rlm*` / `*recursi*` | 仅 `10_Mathematics-&-Physics/06_recusive-quine/`（λ 不动点，与 RLM 无关）与 `50_Synthesis-&-Toward-AGI/02_agi-pathways/recursive-self-improvement*.md`（RSI，另一条线） |
-
-Energy-Intel 是**理论 vault**（FEP / 计算不可约 / 记忆 / AGI 路径），不是 agent 运行时工程仓；RLM 属于后者。
-
-**RLM 引用的真实落点**（均在 `/home/u1/workspaces/` 下）：
-
-| 位置 | 内容 |
-|---|---|
-| `agent-harness/21_CLI-Agent/04_prime-agent/03_prime-agent-rlm-analysis.md:136` | **作者归属裁决**：`arXiv:2512.24601` 作者 = Alex Zhang / Tim Kraska / Omar Khattab（Open MIND，2025-12-31 发布；Khattab = DSPy 作者）；并纠正了「论文出 Prime Intellect」的误记——prime-agent 是该论文的**工程化实现者**（论文引用其 release），非出品方 |
-| 同上 `:84` | 论文原句落地：*"long prompts should not be fed into the neural network directly, treated as part of the environment"* |
-| `agent-harness/21_CLI-Agent/04_prime-agent/01_prime-agent-research.md:8,43` | RLM 定义 + 论文链接（`arxiv.org/abs/2512.24601`）；同页另一条线 Continual Harness（arXiv:2605.09998） |
-| `agent-harness/21_CLI-Agent/01_hermes/rlm-plugin-research.md:25,89` | **RLM 开源生态 6 个独立实现**（openrlm / pyrlm-runtime / jsueling-rlm / exrlm / recursive-llm(TS) / Jbollenbacher-RLM）的横向对照；共性 = 「REPL/kernel + 大上下文存变量 + LLM 写代码 inspect + 递归 subcall」 |
-| `agent-harness/15_Memory/07_context-as-variables/context-as-variables-research.md:50,136` | 「context is a variable」谱系（CoALA → RLM），把它接到 Dash 的 iPython 统一界面维度 |
-| `base/40_Services/11_prime-agent-webui/packages/coding-agent/docs/rlm.md` | prime-agent 官方 RLM 文档（工程实现侧） |
-
-> Energy-Intel 侧唯一可用的桥：其 `index.md` 的「跨空间链接」把 `../agent-harness/` 标为「皮层（应用层）」——**RLM 引用就在那一层**。
-
-### 1.2 dashr 的 RLM 血统与今天的现状
-
-dashr **本来就是** RLM 插件，只是改了名、拆了骨架：
-
-| 时期 | 形态 | 证据 |
-|---|---|---|
-| v0.1.x | npm `dsh-rlm-mode`，定位「RLM Plugin for `dsh`」，产品名就叫 RLM | `docs/50_test-reports/v0.1.8-实测报告.md:38`；`docs/00_adr/0001-bridge-tool-layer-not-service-layer.md:3` |
-| v0.1.8 | `rlm` / `agent_list` / `rlm_workflow` / `rlm_ralph` 桥接族**整体删除**，递归改走 `tool.subagent` / `tool.subagent_fork` 直连 | `docs/50_test-reports/v0.1.8-improved-实测报告.md:29,85` |
-| 今天 | `CONTEXT.md` 把 **RLM 明确列为 retired product name**（"Delegation … _Avoid_: RLM (Recursive Language Model) — the retired v0.1.x product name"），保留的是 `eval` + `tool.subagent` + 后来的 `ctx://` | `CONTEXT.md`（root，DASHR 语言表） |
-
-也就是说：**RLM 这个「产品名」被退役了，但 RLM 那套「上下文即环境 + 递归自调用」的机制诉求一件都没消失**，只是散成了三条独立的腿。本草案的工作就是把这三条腿重新点清楚，补齐缺的那条。
-
-### 1.3 RLM 论文的可执行结论（→ 设计约束）
-
-论文 §RESULTS / §LIMITATIONS / Appendix A「negative results」里能直接翻成工程约束的条目：
-
-| 论文结论 | 对本设计的约束 |
-|---|---|
-| **Obs.1** 10M+ token 规模可用；相对 base LM 最高 2× 提升，成本同量级或更低 | 目标不是「更好的长上下文」，是「**越窗**处理」。dsh 侧 = 资源在 URL 里，不在 prompt 里 |
-| **Obs.2** REPL 是长输入的**必要**条件；**递归 sub-call 在信息密集任务上额外 +10%–59%** | 两条腿都要有：`eval`（已有）+ 递归子调用（**本草案**）。ablation 说明：只有 REPL 无 sub-call 也能越窗，但信息密集任务退化成关键词启发式 |
-| **Obs.3** 小输入区间 base LM 反而更好（存在**交叉点**） | 工具描述必须写明「短上下文别用」——否则是纯增本。dsh 的 wire description 是单源（`eval-description.md` 先例），可以承载这条纪律 |
-| **Obs.4** 成本方差大、长尾尖（中位数比 base 便宜，离群值显著更贵） | **硬上限**必须是参数：`maxChunks` / `maxSubcalls` / 输出 token 上限。不能靠 prompt 里写「别调太多」 |
-| **Obs.5** 模型无关，但不同模型的上下文管理策略差异巨大 | 默认参数要保守；行为差异写进测试而非 prompt |
-| **Limitation** 同步 sub-call 慢；最大递归深度取 **1** | 并发化 map 扇出；默认 `depth = 1`（sub-call 是 LM，不是 RLM） |
-| **Limitation** 未训练模型是低效的上下文决策者 | 把「分块/扇出/归约」这套低效决策**从模型手里拿走**，封进工具实现 |
-| **Neg.** `FINAL()` / `FINAL VAR()` 标签区分「思考」vs「终答」很脆（模型会把计划当答案交出去） | **dsh 的结构化工具返回天然解决这条**——`ToolDefinition.output.schema` 是类型化的，不需要字符串哨兵。这是 dsh 相对论文原型的真实优势，值得在草案里明确 |
-| **Neg.** 同一 system prompt 跨模型会致灾；Qwen3-Coder 对基础任务发**上千次** sub-call | 印证 Obs.4：硬上限是刚需，不是优化 |
-| **Neg.** 无充分编码能力的模型做不好 RLM；thinking 模型会耗尽输出 token | `monolog()` 把循环收进实现 → **降低能力门槛**（模型不再需要自己写对循环），这是相对论文原型的正向差异 |
-
----
-
-## 2. 缺口分析：RLM 原语 → dashr 现状
-
-论文的 RLM 原语 vs 本仓今天的可用面：
-
-| RLM 原语 | dashr 今天 | 缺口 |
-|---|---|---|
-| `P` 放进环境，不放进神经网络 | `ctx://session/...`（含被 compaction shadow 的原文）+ 持久 kernel 变量 | ✅ 读腿齐备 |
-| 写代码 peek / decompose / inspect | `eval`（持久 IPython，`tool.*` 桥接） | ✅ |
-| 观察执行副作用（stdout 回流） | kernel 的 stdout 投影 | ✅ |
-| **`llm_query()`：对环境中一个片段调自己** | `llm_completion({prompt})`（`src/llm-completion.ts:62`） | ❌ **只吃 `prompt` 字面量**——调用者必须**先**把内容搬进自己的上下文，正好抵消越窗收益。走 `subagent` 则是**重**方案：新 session、进 roster、带 tools/memory、生命周期可见 |
-| map 扇出 + reduce 归约 | 模型手写 Python 循环（`eval` 里 `asyncio.gather`） | ⚠️ 可行但**每次都要写对**，且无成本/并发护栏 |
-| 根 LM / 子 LM 分层路由 | `llm_completion` 固定路由到**调用者自己的** provider/model | ⚠️ 无便宜子档（本仓是刻意为之：judge call 只在同级才有意义） |
-| 深递归 | `subagent` 有 `maxDepth`（native 默认 3） | ⚠️ 但那是**新 agent**，不是 self-call |
-| **自指：我现在还剩多少上下文 / 我实际有哪些工具** | **无地址**。`ctx://` 是**历史日志**，`dsh://config` 是**全局 resolved config**，`agent://` 是**roster / 别的 agent** | ❌ 见 §2.1 |
-
-### 2.1 `self://` 缺口的具体证据
-
-`self://surface`（本 agent **实际生效**的工具面）不是锦上添花，它对应一个**已实测发生的漂移事故**：
-
-> 持久会话热升级插件后，本会话 system prompt 的 Tool Catalog **仍在声明 `rlm` / `agent_list` / `rlm_workflow` / `rlm_ralph` 可用**，而实测运行时已经 `unknown binding`。
-> —— `docs/50_test-reports/v0.1.8-improved-实测报告.md:134`
-
-即：**agent 对自己工具面的信念可以显著偏离运行时真相**，而当时没有任何 SSoT 地址可查。`self://surface` 读 `agent.ctx.tools.schemas(agent)` 的**可见投影**（这正是 wire mask 之后、catalog 渲染所读的同一份真值，见 `src/index.ts` 的 wireMask 段），就能给出 ground truth。
-
-同理，`self://budget`（是否逼近 compaction 压力）是 §1.3 Obs.3「何时该递归、何时别用」的**决策输入**——没有它，`monolog()` 的纪律只能靠模型自觉。
-
----
-
-## 3. 命名裁决
-
-候选与评估：
-
-| 候选 | 形态 | 语义契合 | 命名冲突 | 裁决 |
-|---|---|---|---|---|
-| `self://` | scheme（只读） | ✅ 自指状态面，与 `agent://`/`ctx://`/`dsh://`/`dvc://` 同属短名词寄存器 | 与 `ctx://` 易混（见下） | **✅ 采用**（明确划界：`ctx://` = 记录，`self://` = 运行时） |
-| `monolog://` | scheme | ❌ 「自言自语」是**动作**不是**资源**；做成 scheme 会诱导出 `monolog://...` 这种既非纯读也非 dvc 写执行的第四种形态 | — | ❌ 否决 |
-| `self` (tool) | 工具 | ⚠️ | 🔴 **Python kernel 命名空间冲突**：dashr 主交互面是 Python cell，`self` 是实例方法约定名 | ❌ 否决 |
-| `monolog` (tool) | 工具 | ✅ 恰好命名「对自己说话」这一次**计算** | 全仓 grep 零命中（唯二命中是 `upstream/oh-my-pi` 测试里的 "internal monologue" 注释） | **✅ 采用** |
-| 沿用 `llm_completion` 扩展 | 工具加参 | ✅ 改动最小 | — | **✅ Phase 0 采用**（见 §4.0） |
-
-### 3.1 为什么 `self://` 与 `ctx://` 不重复
-
-| | `ctx://` | `self://` |
-|---|---|---|
-| 读的是什么 | 已经**落盘**的 session 事件日志（历史） | **活**运行时状态（当下） |
-| 数据来源 | `sessionPersistence.open(id,'read')` | `exec.agent` 的内存态 + `agent.ctx.tools.schemas(agent)` + gates/policy |
-| 时间箭头 | 过去 | 现在 |
-| 典型问句 | 「三小时前被压缩掉的那段原文是什么？」 | 「我现在实际有哪些工具？我离 compaction 还有多远？我是谁派来的？」 |
-| 可写性 | 只读 | 只读（**必须**；写入通道继续只留给 `dvc://`） |
-
-### 3.2 为什么 `self()` 是硬伤而不是洁癖
-
-dashr 的 kernel 绑定历史就是教训：v0.1.5 以前工具是 **flat globals**，v0.1.8 才收敛到统一 `tool.*` 命名空间（`docs/50_test-reports/v0.1.8-实测报告.md:174`：`rlm(...)` 裸调用 → `NameError`，因为已不是裸全局）。`self` 作为裸标识符在 Python cell 里的语义负荷比 `rlm` 重得多——`self` 是**每个方法体的第一个参数**。任何「把 `self` 变成可调用对象」的设计，都会让读 cell 的人和写 cell 的模型同时误判作用域。`tool.monolog(...)` / `monolog(...)` 无此问题。
-
-> 若将来要做裸全局绑定，注册名只能是 `monolog`，**不能**是 `self`。
-
----
-
-## 4. 设计提案
-
-### 4.0 Phase 0（最小切片）：`llm_completion` 增 `source`
-
-**动机**：先验证「越窗读 + 处理」这条链本身，不引入新概念。
-
-```
-llm_completion({
-  prompt?: string,        // 既有：字面量 prompt
-  source?: string,        // 新增：scheme:// URL 或普通路径
-  system?: string,
-  maxTokens?: number,
-})
-```
-
-语义：
-- 二者**恰有其一**（都缺 → 结构化 error；都给 → 结构化 error，不做隐式拼接）。
-- `source` 走既有的 `UrlResolver`（`src/url-schemes/resolver.ts`），与 `read` tool 的 scheme branch **同一条解析路径**——六个 scheme 全部可用，零新解析器。
-- `source` 解引用的文本作为 payload；`prompt` 若同时作为**指令**则被禁止（避免「指令/数据」边界含糊）。
-- 默认 `maxSourceChars` 硬上限（建议 256 KiB，超出结构化报错并提示用 `:N-M` 分页）——**防止一次调用把巨型资源拉爆上下文**（Obs.4 长尾）。
-
-价值：`llm_completion({ source: 'ctx://session/compactions[221217]:raw', prompt: '提取时间线' })` —— 一行拿到「被压缩掉的原文」的摘要，**原文一秒都没进调用方上下文**。这就是论文的核心动作，且不新增任何 scheme/工具名。
-
-### 4.1 `self://` — 只读自指状态面（scheme）
-
-**唯一形态**：`self://<face>[:selector]`，只读；注册点与 `ctx://` 并列（`src/url-schemes/index.ts:287` 一带，`resolver.register('self', createSelfHandler({...}))`）；`selectorAware: true` 走 `ctx://` 同一套 canonical/prepared + `:raw`/`:N-M` 契约。
-
-**faces（建议集）**：
-
-| URL | prepared 面（bare） | canonical 面（`:raw`） |
-|---|---|---|
-| `self://` | roster（一行一个 face + 用途） | 同左 |
-| `self://identity` | 信息卡：agent id、status、origin、delegationDepth、agentPreset、cwd、provider/model/maxTokens | 同左（JSON） |
-| `self://surface` | **生效工具面**：name + 一行 description，来自 `agent.ctx.tools.schemas(agent)`（wire mask 后的可见投影） | 完整 schema JSON |
-| `self://lineage` | 委派链：自己 → 父 → 祖，每级 id/status/preset | 同左（JSON） |
-| `self://policy` | 生效策略：sandbox mode、approval policy、url-schemes/hashline gates | 同左（JSON） |
-| `self://budget` | 上下文压力：已用 token / 距 compaction 阈值 / 本 turn-step 计数 | 同左（JSON） |
-
-**硬约束**：
-- **只读**：任何 write → 结构化 `URL_READ_ONLY`（与 `ctx://` 同款契约，`docs/specs/ctx/spec.md` 已有先例）。
-- **不泄密**：`self://policy` 必须复用 `dsh://config` 的脱敏管线（`docs/specs/dsh/spec.md` 的 secret 剥离要求），schema `role('secret')` + 键名 denylist 递归施加。
-- **不做新真值源**：所有 face 必须从**既有**服务读，不得另建缓存/影子状态，否则又造一个会漂移的副本（正是 §2.1 事故的成因）。
-- **`self://budget` 可行性待勘**：host 的公开 `Agent` 类型极薄（`upstream/deepseek-harness/packages/core/agent/src/types.ts:13` 只有 `{id}`）；turn/step 边界可用 `TurnBoundaryProjection`，但**token 用量是否已持久化成事件未证实**。→ 标为**开放问题**（§8 Q3），实现前必须先勘。若不可得，`self://budget` 退化为「turn/step + 事件计数」的粗略代理，并如实标注。
-
-### 4.2 `monolog()` — 对可寻址源做递归自发调用（tool）
-
-**一句话**：把 RLM 论文的 `llm_query()` 循环封成一个类型化工具调用，输入是**地址**不是文本。
-
-```
-monolog({
-  source: string,                  // scheme:// URL 或路径（复用 UrlResolver）
-  question: string,                // 对这段内容要问什么
-  chunk?: { by: 'lines'|'bytes'|'regex', size: number, pattern?: string },
-  fanout?: { concurrency: number },// 默认 4；Obs."同步 sub-call 慢" 的直接对策
-  reduce?: 'concat' | 'synthesize',
-  maxChunks?: number,              // 默认 16；Obs.4 硬上限
-  maxDepth?: number,               // 默认 1（论文 setting）
-  maxTokens?: number,              // 单次子调用输出上限，默认 1024
-})
-```
-
-执行语义（map-reduce）：
-
-```
-source ──UrlResolver──▶ 全文（不进调用方上下文）
-   │
-   ├─ 无 chunk：单次 sub-call(question, text) ─────────────▶ 结果文本
-   │
-   └─ 有 chunk：切片 → bounded-concurrency map:
-                    sub-call(question, slice_i) → partial_i
-                 → reduce: 'concat'   = 逐段拼接（保序，带 provenance）
-                           'synthesize'= 再一次 sub-call 归约（消耗 1 次预算）
-   ▲
-   子调用 = 与调用者同 provider/model 的一次 bare LLM call（复用 llm-completion 的
-   `ctx.llm.stream` 路径与 finish-reason 处理）
-```
-
-与 RLM 论文的逐条对应：
-
-| 论文设定 | 本设计的落地 |
-|---|---|
-| prompt 在环境里 | `source` 通过 URL 解引用，**从不进调用方上下文**（只回最终 digest） |
-| 递归 sub-call | `ctx.llm.stream` 的 bare call，`maxDepth` 默认 1 |
-| 同步慢 | `fanout.concurrency` 并发扇出 |
-| 上千次 sub-call 失控 | `maxChunks` / `maxSubcalls`(=maxChunks + reduce) 硬上限，**不是 prompt 劝告** |
-| `FINAL()` / `FINAL VAR()` 脆 | 不存在：返回是 `ToolDefinition.output.schema`，类型化 `{ digest, chunks, subcalls, costHint }` 或 `{ error }` |
-| 无编码能力的模型做不了 | 模型不再需要写循环 |
-| 小输入反而更差 | wire description 明写「短上下文请直接用 `read`/`llm_completion`」 |
-
-**返回信封（建议）**：不只回文本，回**带 provenance 的结构**——
-`{ digest, source, chunks: n, subcalls: n, truncated: bool, partials?: [{range, text}] }`。
-理由：论文的失败轨迹里反复出现「模型建好了答案却把中间结果丢了 / 反复重做」（Appendix B 的 Qwen3-Coder 例）。provenance 让后续步骤可以**引用**而非**重算**。
-
-**失败模式**（全部结构化，不抛异常——沿用 `llm_completion` 的契约）：
-`no-route`（调用者无 provider/model）、`source-unresolvable`、`source-too-large`、`chunk-plan-empty`、`budget-exceeded`、`subcall-failed`。
-
-### 4.3 两者的耦合 = RLM 回路闭合
-
-```
-   ┌────────────────────────────────────────────────────────────┐
-   │ root LM（调用方，上下文有限）                                  │
-   └───────┬─────────────────────────────────▲──────────────────┘
-           │ ①读 self://budget / self://surface│ ⑤只拿到 digest
-           │   （我该不该递归？我有什么工具？）   │   （原文 never enters）
-           ▼                                  │
-   ┌───────────────────┐   ②source(URL)  ┌───┴──────────────┐
-   │ monolog() 工具     │ ───────────────▶│ UrlResolver      │
-   │  map/reduce/上限    │                 │ (ctx:// agent:// │
-   └─────────┬─────────┘                 │  skill:// dsh:// │
-             │ ③bare sub-call             │  dvc:// http://) │
-             ▼                            └──────────────────┘
-        ctx.llm.stream（同 provider/model，depth 1）
-             │ ④partials
-             └──────────▶ reduce ──▶ digest
-```
-
-`self://` 提供**决策输入**（该不该递归、还能容多少），`monolog()` 执行**递归动作**。缺 `self://`，纪律只能靠模型自觉；缺 `monolog()`，`self://` 只是一堆好看的只读 JSON。
-
-### 4.4 与既表面的边界（正交性）
-
-| 面 | 成本 | 生命周期 | 上下文代价 | 何时用 |
-|---|---|---|---|---|
-| `read <scheme>://` | 极低 | — | **全额进上下文** | 要看内容 |
-| `llm_completion({prompt})` | 低 | 无 | prompt 字面量进上下文 | 手头文本的 judge/extract |
-| **`llm_completion({source})`**（Phase 0） | 低 | 无 | **只进结果** | 单次越窗提取 |
-| **`monolog()`**（Phase 1） | 中（成本方差大） | 无 session、不进 roster | 只进 digest | 信息密集的越窗 map-reduce |
-| `subagent` / `subagent_fork` | 高 | **新 session + roster + 生命周期** | 独立上下文 | 需要独立能力集/长任务的委派 |
-| `workflow` / `ralph` | 最高 | 多 agent | — | 多 agent 编排 |
-| `eval` | 低 | 持久 kernel | 代码+stdout | 符号化操作（可组合上面任意一个） |
-
-**关键区分**：`monolog()` 是「**自己**在自己进程内、不留痕地问自己一遍」；`subagent` 是「**开一个新 agent**」。前者不进 roster、不产生会话事件（除一条 `tool/call`+`tool/result`），后者全部相反。dashr 今天**只有重的那一档**。
-
----
-
-## 5. 备选方案评估（为什么不直接把 `llm_completion` 长成全部）
-
-| 方案 | 改动面 | 优点 | 缺点 | 裁决 |
-|---|---|---|---|---|
-| **A. 只扩展 `llm_completion({source})`** | 最小（1 文件 + 参数） | 无新名、无新 scheme；立刻拿到越窗单次调用 | 无 map/reduce，信息密集任务要模型自己写循环 → 回到 Obs.4 的风险 | **Phase 0 采纳** |
-| **B. 独立 `monolog()` 工具** | 中（新工具 + 复用 resolver/llm） | 语义聚焦；上限/并发/深度都是一等参数；wire description 可独立写纪律 | 与 `llm_completion` 语义有重叠 → 需在 description 里划清（§4.4 表） | **Phase 1 采纳** |
-| **C. 只做 `self://`，递归仍走 eval 手写** | 小 | 不碰 LLM 调用面 | 纪律与护栏全靠模型自觉；Qwen3-Coder 式失控无解 | ❌ 否决为终态，可作并行 Phase 2 |
-| **D. 复活 v0.1.8 删掉的 `rlm()` 桥** | 大 | 历史资产 | 与「RT 退役决定」正面冲突、与 `subagent` 语义打架；且当年是**委派**语义，不是 self-call | ❌ 否决 |
-
----
-
-## 6. 风险与红线
-
-| 风险 | 说明 | 对策 |
-|---|---|---|
-| **成本失控** | Obs.4：中位数便宜但长尾尖；Obs.5 + Neg.：某些模型对基础任务发上千次 sub-call | `maxChunks` / `maxSubcalls` / `maxTokens` / `maxSourceChars` 全部**硬上限**，默认保守；错误里回显用量 |
-| **上下文遮蔽** | 「没进上下文」是优点也是缺点：模型无法目视验证 digest 的ground truth | 返回带 `partials[].range` provenance；`:N-M` 可复核（`ctx://` 的 `:raw:N-M ≡ :N-M` 契约先例） |
-| **`self://` 泄密** | 策略/配置面可能含凭据 | 复用 `dsh://config` 的脱敏管线（`docs/specs/dsh/spec.md`） |
-| **`self://` 造第二真值源** | 任何缓存/镜像都会重演 §2.1 漂移事故 | 强制「直读既有服务，零缓存」 |
-| **只读被绕过** | 新 scheme 是写攻击面 | 沿用 catalog 的不变式：**只有 `dvc://` 可写**；`self://` write → `URL_READ_ONLY` |
-| **命名混淆** | `self://` vs `ctx://`；`monolog` vs `monologue` | catalog 的 `purpose` 一句话必须写死边界（「record」vs「runtime」） |
-| **`self://budget` 数据不可得** | 公开 `Agent` 类型只暴露 `{id}` | 先勘（§8 Q3）；不可得就降级并如实标注，不伪造精度 |
-
-**流程红线**（AGENTS §〇，逐条适用）：本改动触及「运行时工具面」，验收必须是 **4999 第一人称实测**（真实会话里跑通 `self://surface` + `monolog` 越窗 map-reduce），落 `docs/50_test-reports/`，**user 明确确认后**才 `npm publish`。单测绿 / tsc 0 / boot graph 在位**不是**验收。
-
----
-
-## 7. 分期与验收
-
-| Phase | 内容 | 验收证据（须可复现） |
-|---|---|---|
-| **0** | `llm_completion` 增 `source`（+ `maxSourceChars`）；六个 scheme 全部可当 source | 单测：scheme 解引用复用、互斥校验、超限结构化错误；4999 实测：`source: 'ctx://session/compactions[<label>]:raw'` 拿到摘要且**原文未进上下文**（以 transcript 事件长度佐证） |
-| **1** | `monolog()`：chunk 规划 + 并发 map + reduce + 硬上限 + provenance 信封 | 单测：chunk 三种 by、并发上限、`maxChunks`/`maxSubcalls` 触发、depth=1、部分失败降级；4999 实测：一个 > 上下文窗的资源（如 `dsh://docs` 全量或长 `ctx://` 原文）map-reduce 出 digest |
-| **2** | `self://`（identity / surface / lineage / policy；budget 视勘误） | 单测：roster、face 结构、只读拒绝、脱敏；4999 实测：§2.1 漂移场景下 `self://surface` 报出**运行时真值**而非 catalog 文本 |
-| **横切** | catalog + `url-schemes-instruction.md` + wire description 单源更新（`SCHEME_CATALOGUE` 是唯一真值源，`src/url-schemes/catalog.ts:56`） | 单源渲染测试：新增 scheme 自动出现在 system prompt 表 + error message 列表 |
-
-> 顺序建议：**0 → 2 → 1**。`self://` 比 `monolog()` 便宜且立刻能验证 §2.1 那个已发生的 bug；`monolog()` 是重头戏，放在有了决策输入之后更稳。
-
----
-
-## 8. 开放问题（需 user 裁决）
-
-| # | 问题 | 选项 |
-|---|---|---|
-| **Q1** | 命名终局 | (a) `self://` + `monolog()`【本草案推荐】 (b) `self://` + `self_call()` (c) 只 `llm_completion` 扩展到底，不做新工具 |
-| **Q2** | `monolog()` 是否独立成工具，还是 `llm_completion` 的一个 `mode` | 独立（语义清晰、description 可写纪律） vs 合并（无重叠名、工具表更短） |
-| **Q3** | `self://budget` 的 token 用量从哪来 | (a) session log 里已有 usage 事件（**待勘**） (b) 需要 host 新服务 (c) 降级为 turn/step + 事件计数代理 |
-| **Q4** | `self://` 是否应该包含**可写**的 agent 自有 scratchpad（跨 compaction 备忘） | 本草案**否**（写入通道只留 `dvc://`，且 Corti memory 已覆盖持久记忆）；若 user 要，需单独立项 |
-| **Q5** | `fanout.concurrency` 默认值 4 是否合适 | 取决于上游 LLM adapter 的限流；需实测 |
-| **Q6** | `monolog()` 的子调用是否需要独立 model 档（便宜模型做 map） | 本仓 `llm_completion` 刻意锁同级（`src/llm-completion.ts` 注释：judge call 只在同级才有意义）。放开会破坏该决策，需 user 明确 |
-
----
-
-## 附录 A：证据锚点
-
-| 事实 | 锚点 |
-|---|---|
-| RLM 论文全文（含 authors / abstract / results / negative results） | `~/.hermes/cache/web/arxiv.org-f7ccb39fbc.md`（455 行，2026-08-15 直读缓存） |
-| RLM 作者归属裁决 | `agent-harness/21_CLI-Agent/04_prime-agent/03_prime-agent-rlm-analysis.md:136` |
-| 论文核心断言的落地解读 | 同上 `:84` |
-| RLM 开源实现横向对照（6 个） | `agent-harness/21_CLI-Agent/01_hermes/rlm-plugin-research.md:25,89` |
-| 「context as variable」谱系 | `agent-harness/15_Memory/07_context-as-variables/context-as-variables-research.md:28,50,136` |
-| Energy-Intel 与 agent-harness 的交叉链接 | `Energy-Intel/index.md`（「跨空间链接」段） |
-| RLM 产品名退役 | `dashr/CONTEXT.md`（DASHR 语言表 Delegation 条） |
-| `rlm` 桥接族删除 | `docs/50_test-reports/v0.1.8-improved-实测报告.md:29,85` |
-| flat-global → `tool.*` 迁移 | `docs/50_test-reports/v0.1.8-实测报告.md:174` |
-| **Tool Catalog 漂移事故** | `docs/50_test-reports/v0.1.8-improved-实测报告.md:134` |
-| `llm_completion` 工具定义 | `dashr/src/llm-completion.ts:62`（注册于 `dashr/src/index.ts:1144`） |
-| `llm_completion` 输出上限 | `dashr/src/llm-completion.ts:41`（`MAX_COMPLETION_TOKENS = 4096`） |
-| scheme 单源目录 | `dashr/src/url-schemes/catalog.ts:56`（`SCHEME_CATALOGUE`） |
-| `ctx://` 注册点 | `dashr/src/url-schemes/index.ts:287` |
-| `dvc://` 注册点 / 唯一可写 | `dashr/src/url-schemes/index.ts:284`；`catalog.ts` 的 `write: 'json-args'` |
-| resolver 契约（含 `selectorAware`） | `dashr/src/url-schemes/resolver.ts` |
-| `ctx://` 只读 + canonical/prepared 契约 | `docs/specs/ctx/spec.md` |
-| `dsh://config` 脱敏契约 | `docs/specs/dsh/spec.md`（「Config never leaks secrets」） |
-| 上游 `Agent` 公开类型极薄 | `upstream/deepseek-harness/packages/core/agent/src/types.ts:13`（`interface Agent { readonly id: SessionId }`） |
-| scheme 系统提示段单源加载 | `dashr/src/url-schemes/general-section.ts` + `dashr/url-schemes-instruction.md` |

package/docs/50_test-reports/2026-09-22-4988/345/217/214/345/271/263/351/235/242/345/220/257/345/212/250/344/277/256/345/244/215/345/256/236/346/265/213/346/212/245/345/221/212.md

@@ -1,76 +0,0 @@
-# 4988 双平面启动修复（首工具调用 'prepare' 崩溃 + 会话毒化）实测报告
-
-- 日期：2026-09-22
-- 环境：Dev/Test 1（upstream `dsh-v0.1.6-alpha.2` checkout + 内嵌 better-dsh 0.2.4 副本），实例 4988（unit `dsh-4988-test` + LAN socat 中继），`DSH_HOME=/home/u1/workspaces/dashr/.dsh-test`
-- 结论：**根因修复 + 第一人称实测通过**。崩溃与 better-dsh 无关（headless 无 better-dsh 一样崩；prod 3080 带 better-dsh 0.2.4 正常）；根因是 **tsx 源码启动的双平面模块分裂**。修复 = 产物面启动（`apps/cli/lib/bin.js` + 裸 node，与 prod 同构）。
-
-## 一、症状（user 报告，2026-09-21/22）
-
-每个新 session 的**第一个工具调用**必失败：
-
-```
-This turn failed  Cannot read properties of undefined (reading 'prepare')  UNKNOWN
-```
-
-其后同 session 任何后续轮次：
-
-```
-This turn failed  DeepSeek Messages tool calls need immediate results  INVALID_REQUEST
-```
-
-会话从此不可用。复现的失败工具：`bash`、`skill`；Llm `thinking` 流正常出字（LLM 请求/响应路径完好），崩溃点在工具调度。
-
-## 二、证据时间线（session log 全量扫描，88 个 zstd session）
-
-| 时间（HKT） | session | 工具调用数 | turn 错误 | 备注 |
-|---|---|---|---|---|
-| 09-12 ~ 09-15 01:09 | 数十个 | 1–289/个 | 0 | 同一 09-12 01:13 boot，read/write（dvc:// URI 走 better-dsh remask）全部成功 |
-| 09-15 01:26 | `…7842bf` | 1 | prepare + INVALID_REQUEST | **首例**；agent preset `cordis`；旧 0.1.5-rc.2 boot |
-| （无 session） | — | — | — | 09-15→09-22 间无任何真实 chat session 复测 |
-| 09-22 00:06 | `…8c2514ba` | 1 | prepare + INVALID_REQUEST | user 复测；默认组合 |
-| 09-22 00:12 | `…5ca418a1` | 1 | prepare | user 复测；preset cordis |
-
-关键事实：09-15 01:09（成功，13 调用）与 01:26（首败）在**同一 daemon 进程**上——非重启/重建引入；align 轮（09-21）之前已存在。
-
-## 三、根因链（每步有实证）
-
-1. **崩溃点**：`agent-loop/src/tool-calls.ts` `startCall` 的 `ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)`。栈经临时诊断打点捕获（已还原）。`tool/call` 事件先落（`appendToolCall`），prepare 抛 TypeError → turn 以 UNKNOWN 结束；**孤儿 tool/call 无结果** → 之后每轮 DeepSeek 序列化器拒绝（`llm-deepseek/src/protocols/messages/serialize.ts:117` 的 "tool calls need immediate results"）。
-2. **诊断打点实测**：`ctx.tools` 是 ToolRuntime 实例，ownSymbols 含 `Symbol(@deepseek-ai/dsh-tools.scheduler)`，但与 agent-loop 导入的 symbol **同 description 不同对象** = 同进程两份 `@deepseek-ai/dsh-tools`。
-3. **两份从哪来**：tsx 源码启动 = 双平面运行时——
-   - TS 文件（apps/cli、各包 src）经 `tsconfig.base.json` `paths`（`@deepseek-ai/dsh-*` → `packages/*/*/src/index.ts`）→ **src 副本**；
-   - plugin loader 把组合行模块名解析为构建 lib 的 file URL → **lib 副本**（且 vendor/cordis 的 lib bundle 陈旧——不含 `FiberState` 导出）。
-   - lib 侧 ToolRuntime 把 scheduler 挂在 lib 副本 symbol 下；src 侧 agent-loop 按 src 副本 symbol 查 → `undefined`。
-4. **为何 prepare 门不接住**：`prepareExecution` 的 try/catch 只包门内瀑布；`ctx.tools[SYMBOL]` 在 agent-loop 侧、门之前求值。
-5. **为何 paths-less 收敛不可行**：`vendor/cordis/src/fiber.ts` 的 `export const enum FiberState` 被 tsc 内联（bundle 无该运行时导出），tsx 只能保留 value import → 产物 lib 面 boot 必然 `SyntaxError: ... does not provide an export named 'FiberState'`。**源码启动本质上需要 src 面** → 唯一正解 = 产物面启动。
-
-## 四、better-dsh 判定：**无关（exonerated）**
-
-- headless 一次性任务（无 web profile、无 better-dsh、`--profile headless`）在 tsx 启动下**同栈同错**；
-- prod 3080（npm 0.1.6-alpha.2 + better-dsh 0.2.4，产物面运行）工具调用全部正常——本报告撰写会话即运行其上；
-- 九条运行期 import 的 better-dsh 嵌套链接审计：8 条本就指 workspace，1 条（`dsh-home-paths` → `.pnpm/@deepseek-ai+dsh-home-paths@0.1.2-rc.1`）为陈旧 registry 副本，**已改链**到 `packages/util/home-paths`（见 §六）。
-
-## 五、修复与验证
-
-**修复**（对 src 零改动——三个临时诊断打点已全部还原，`git status` 干净）：
-
-- `tests/start-4999.sh`：boot 行改为 `node apps/cli/lib/bin.js web --no-open --port $PORT`（产物面 + 裸 node，无 tsx），附根因注释与 lib/bin.js 存在性守卫；
-- `AGENTS.md` §二 启动块同步改写：新命令 + 红线（tsx 源码启动禁止用于回归验收）+ `pnpm run build` 前置条件；
-- 全量 `pnpm run build` 已跑（exit 0），产物面完整。
-
-**验证**：
-
-1. headless A/B（同 checkout 同 home）：tsx 启动 → 必现 `prepare` 崩溃；`node apps/cli/lib/bin.js` → 过（调度器查找命中）。
-2. **真 session 第一人称**（systemd-run 沙箱外一次性任务，真 LLM + 真 bwrap）：
-   - `bash`：`echo repro-marker-4988` → `repro-marker-4988`（exit 0）✅
-   - `skill`：调用返回**结构化结果**（"skill using-superpowers is unknown"——headless cwd 无该技能目录，属正常业务错误；关键在 tool result 落账，不再 UNKNOWN）✅
-3. 4988 web 实例（修复后重启，`LAN=1`）：shell HTTP 200、`__DSH_BOOT__` 在位、boot graph 含 `"id":"better-dsh"`；进程确认为 `node …/apps/cli/lib/bin.js web --no-open --port 4988`。
-4. agent-loop/tools lib 复查：无 `dashr-debug` 残留；两包 src 无本地改动。
-
-## 六、遗留与备注
-
-- better-dsh 副本嵌套树仍存在非运行期陈旧链（`dsh-agent-loop`、`dsh` → `.pnpm …@0.1.2-rc.1`；运行期不 import，无实害）。运行期九链已全 workspace 化。
-- `packages/subagent/tool-subagent-report/` 为**只含 lib/ 的异源残留**（无 package.json/src、git 未跟踪；疑另一 workstream 产物），未被任何 manifest 引用，无实害；处置待 user 裁决。
-- **旧中毒 session 无法复活**（孤儿 tool/call 已落账）：09-15 `7842bf` 与 09-22 两个 session 请弃用；新 session 正常。
-- prod 3080 无需任何动作（本就产物面运行）。
-- 09-15 `7842bf`（旧 0.1.5 树 + cordis preset）为同类双平面机制在旧树的另一形态；旧树已升级，不回溯归因。
-- 诊断过程临时文件：`.scratch/session-debug/`（session 解包与扫描脚本），留作证据。

package/docs/50_test-reports/2026-09-22-better-dsh/347/273/204/344/273/266/347/203/255/346/217/222/346/213/224/344/270/216/344/276/235/350/265/226/347/272/247/350/201/224/345/256/236/346/265/213/346/212/245/345/221/212.md

@@ -1,117 +0,0 @@
-# better-dsh 六组件热插拔（Cordis HMR）与行间依赖级联 实测报告
-
-- 日期：2026-09-22
-- 问题：better-dsh 是否可热插拔（cordis HMR）？六个组件行是否逐个可热插拔？若组件间存在依赖，关掉被依赖组件时，依赖方是自动关闭还是留在 active 里运行时出错？
-- 测试环境：Dev/Test 1 实例 **4988**（`DSH_HOME=/home/u1/workspaces/dashr/.dsh-test`，harness 0.1.6-alpha.2 + better-dsh 0.2.4，与 prod 3080 同版），systemd `dsh-4988-test.service`
-- 结论：**全部可热插拔（零重启）**；**六个组件行无一例外**；**行间不存在 inject 边，因此关闭任一组件不会级联关闭其他组件**（诊断见 §四）
-
----
-
-## 一、机制事实（源码锚点）
-
-### 1.1 行开关 = 写 profile 用户层 patch + 活体重算
-
-- `Plugins` 页的行开关落到 `PluginManager.setPluginEnabled`（`upstream/deepseek-harness/packages/boot/plugin-manager/src/index.ts:302`）：写 `{id, disabled}` 到 `profile.patchPath`，再 `reload()`。
-- `writePluginEnabled`（`packages/boot/plugin-manager/src/patch.ts:14`）用 yaml Document **原地改最后一个同 id 行**（有则改 `disabled`，无则追加），保留注释与其余字段；本实例对应文件 `.dsh-test/profiles/web/cordis.patch.yml`。
-- `reload()` → `reconcileProfilePatches`（`packages/boot/app-boot/src/index.ts:251`）：把完整 patch 列表`entry.update()` 进根 Include 行，然后 `ctx.loader.await()` 等激活收敛——**在同一个进程里 unmount/mount**。
-- `change()`（`plugin-manager/src/index.ts:557`）里 `application` 的取值由是否在场决定：`ctx.get('hmr') !== undefined ? 'applied' : 'restart-required'`。即**没有 hmr 服务的 profile，开关仍写盘，但要重启才生效**。
-- 反向兜底：`dsh-hmr` 也 watch profile patch 文件本身（`packages/boot/hmr/src/index.ts:215`，watch `profile.patchPath` + `$DSH_HOME/cordis.patch.yml` + profile `package.json`），所以**手改这些文件同样热生效**，不必点 UI。
-
-### 1.2 什么被 watch，什么不被 watch
-
-- `packages/bundle/base/cordis.patch.yml:28-32` 给 hmr 行配的是 **`root: []`**（注释原文 "Profile configuration reloads by default; module roots are opt-in."；`HmrConfig` JSDoc："an empty list leaves only explicit configuration watches"）。
-- 推论：**只有配置面热**。改 better-dsh 的 `lib/*.js` 不会触发 host 侧重载，必须重启（除非显式给 hmr 配非空 `root`）。
-- client 面：整套客户端是**一个 bundle**（`package.json` 的 `dsh.client`），不按组件拆；`client-hmr`（`packages/client/hmr/src/index.ts`）是 host 侧 500ms stat-poll 每个 graph 行的 client bundle + SSE 推 `rebuilt`，浏览器侧换模块——**行开关不碰 client bundle**，客户端靠"页面全局缺席即休眠"降级。
-
-### 1.3 组件行的定义
-
-页面上的"组件" = bundle patch 的 **insert 行**（`declaredRows()`，`plugin-manager/src/index.ts:447`）；非 insert 行只进 `overrides`，页面不列、不可单独开关。
-
-`better-dsh/cordis.patch.yml:19` 起共 **6 条 insert**：
-
-| 行 id | 模块 | 源码 inject |
-|---|---|---|
-| `dashr-repl` | `better-dsh` | `['tools']`（`better-dsh/src/index.ts:132`） |
-| `dashr-url-schemes` | `better-dsh/url-schemes` | `['tools','fs','skills','subagents','sessions','settings','agents','sessionPersistence']`（`better-dsh/src/url-schemes/index.ts:78`） |
-| `dashr-failover` | `better-dsh/failover` | `[]`（行内 `ctx.inject(['settings'])`，`better-dsh/src/failover/index.ts:43`） |
-| `dashr-compaction-tuning` | `better-dsh/compaction-tuning` | `[]`（行内 `ctx.inject(['settings'])`/`['compaction']`，`better-dsh/src/compaction/index.ts:56`） |
-| `dashr-web-trust` | `better-dsh/web-trust` | `[]`（行内 `ctx.inject(['webServer'])`，`better-dsh/src/web-trust.ts:180`） |
-| `dashr-mobile` | `better-dsh/mobile` | `[]`（行内 `ctx.inject(['webServer'])`，`better-dsh/src/mobile/plugin.ts:29`） |
-
-override 行 4 条：`compaction-basic` / `command-compact` / `tool-result-pruner`（再启用）+ `connection`（fence）——**不是组件**，页面无法开关。
-
----
-
-## 二、实测方法
-
-1. 备份 profile 用户层 patch：`.scratch/cordis.patch.yml.bak-hotplug-probe-1790010496`。
-2. 取本 boot token URL（`.scratch/.4988-url`），`curl -c jar -L` 拉 served HTML 作为 boot script 双腿探针（基线 `http=200 bytes=36031`；`__DASHR_MOBILE__ 2`、`__DSH_TRANSPORT__ 1`、`ios-zoom-font-floor 1`、`zoomGuard 2`）。
-3. 逐行 `plugin_manager set_plugin {enabled:false}` → 读 `list_plugins`（`enabled` / `fiberPhase`）→ 再 `{enabled:true}` → 复读。
-4. 全程以 `ChangeResult.application` 判定是否热生效；`restart-required` 与 `applied` 互斥可验。
-5. 收尾：从备份还原 patch 文件并复验 composed 状态与 served HTML。
-
----
-
-## 三、实测结果
-
-### 3.1 逐组件 off → on（全部 `{"changed":true,"application":"applied","warnings":[]}`）
-
-| 行 | off 后 `fiberPhase` | on 后 | 副作用探针 |
-|---|---|---|---|
-| `include:dashr-mobile` | `null`（enabled:false） | `active` | served HTML：`__DASHR_MOBILE__` 2→**0**→2、`zoomGuard` 2→**0**→2、`ios-zoom-font-floor` 1→**0**→1；`__DSH_TRANSPORT__` 恒 1（web-trust 腿不牵连） |
-| `include:dashr-web-trust` | `null` | `active` | `__DSH_TRANSPORT__` 1→**0**→1；mobile 腿恒 2（互不牵连） |
-| `include:dashr-failover` | `null` | `active` | — |
-| `include:dashr-compaction-tuning` | `null` | `active` | — |
-| `include:dashr-url-schemes` | `null` | `active` | off 期间 read/grep/edit 回落原生语义仍可用（`read`/`grep` 复验通过）；核心行全程 `active` |
-| `include:dashr-repl`（核心） | `null` | `active` | off 时同页 `list_plugins` 里**其余 5 行全部保持 enabled:true / active**；eval 工具随行卸载，重开后 `eval` 恢复（复验 cell 跑通，pad 命名空间由 turn-1 快照恢复） |
-
-- 用户层 patch 形态（以 mobile 为例）：`- id: dashr-mobile` + `disabled: true`（关闭）→ `disabled: false`（打开），原地改写、注释保留。
-- **零重启**：全程 `application:"applied"`，无 `restart-required`。
-
-### 3.2 收尾复原
-
-- `diff` 备份 vs 现文件：**逐字一致**（`cp` 还原 + `RESTORED IDENTICAL`）。
-- served HTML 回基线（2 / 1 / 1 / 2），`list_plugins` 六行全 `enabled:true / active`。
-- NOTE：`writePluginEnabled` 的语义是"改最后一次匹配行，否则追加"，所以 probe 期间会给 `dashr-web-trust`/`dashr-failover`/`dashr-compaction-tuning`/`dashr-url-schemes` 追加 `disabled: false` 覆盖行、并给 `dashr-repl` 行补 `disabled: false`；**这些都只是 probe 残留，已随备份还原清除**。正常 UI 使用中，用户关闭过的行会留下 `disabled: false` 覆盖行，这是该实现的设计行为（幂等、语义无变化）。
-
----
-
-## 四、行间依赖与级联：结论与通用语义
-
-### 4.1 better-dsh 六行之间：不存在依赖边，无级联
-
-- **实测**：关任一组件时其余五行保持 active（含关核心 `dashr-repl` 的那一刻）。
-- **静态**：六行 `inject` 只声明 host 服务；行内动态 `ctx.inject([...])` 也是 host 服务（`settings` / `webServer` / `compaction`）。全包 grep **无 `provide()`**；唯一被提供的服务 `replRuntime` 由核心行自己 `ctx.plugin(DashrRuntime)` 注册、并由**同一行**的 `ctx.inject(['replRuntime'])`（`better-dsh/src/index.ts:966`、`:997`）消费——是**行内边**，随行一起销毁/重建，不跨行。
-- **唯一跨组件耦合**是模块级单例 `native-capture`（`better-dsh/src/native-capture.ts`，capture-before-mask）：核心行的 wire mask 监听器第一步自己调 `captureAllTools`，url-schemes 行缺席也照常；反之 url-schemes 缺席时核心的 eval/委派桥正常。这是**共享 ESM chunk，不是 cordis 服务边**，因此不参与 fiber 依赖计算。
-- 组件行关闭后的降级形态是设计内且 fail-open 的（见 `docs/specs/plugins-page-components/spec.md` §五 / §Out of Scope）：url-schemes 关 → read/write/grep/glob 回落原生；failover / compaction-tuning 关 → 其 client 设置卡仍在但无消费者；mobile / web-trust 关 → 页面全局缺席，客户端惰性。
-
-### 4.2 若真存在 inject 边：消费方**自动挂起（PENDING）**，不是留在 active 里运行时崩
-
-Cordis fiber 的依赖语义（`upstream/deepseek-harness/vendor/cordis/src/fiber.ts`）：
-
-- `_refresh()`（`:611`）把消费方的 epoch 由"每个 inject 服务提供者 fiber 的 uid 串"决定；provider 消失（`reflect` 删 impl 后 `notify` → 各依赖 fiber `_refresh()`，`vendor/cordis/src/reflect.ts:277`/`:314`）→ epoch 变 `INACTIVE`。
-- `_setEpoch()`（`:625`）在 epoch active→INACTIVE 时调 **`_unload()`**（`:675`）：跑完该 fiber 全部 disposer、撤销其全部注册（工具、事件、slot…），状态落到 **`PENDING`**。
-- provider 回来 → epoch 变有效 → **`_reload()`**（`:646`）重跑 plugin `apply`。即 **自动关 + 自动开**。
-- 启动/重算期把这状态报成 `pending (waiting for service(s): X)`（`packages/boot/app-boot/src/index.ts:795`、`:826`）；preset 挂载审计里是 `... waiting for X`（`packages/preset/agent-presets/src/mount.ts:322`）。
-
-**重要副作用（本次新发现，源码推导，未做破坏性实测）**：`reconcileProfilePatches` 把重算后新出现的非 ACTIVE 条目判为 introduced failure 并 **throw**（`packages/boot/app-boot/src/index.ts:268`；`inactiveEntries` 遍历全部 loader 条目、非 ACTIVE 即计入，`:769`）。因此"关掉被依赖组件"这一次 toggle 的返回会是 **`application:"failed"` + diagnostic（点名 pending 的依赖方）**，而盘上的 `disabled:true` 已经写入且运行时确实已挂起依赖方——即用户看到的是**开关报错 + 依赖方变 pending**，而非静默坏掉或"留在 active 里崩"。
-
-**例外：用 `ctx.get()` 的消费方不参与依赖计算**，provider 消失时它**留在 active**、运行时自行降级或报错。本插件内就有这种形态：`better-dsh/src/compaction/index.ts:116`/`:151` 的 `ctx.get('llm')`/`ctx.get('compaction')`、以及 plugin-manager 自己 `ctx.get('hmr')`（缺 hmr 就退回 `restart-required`）。
-
----
-
-## 五、边界与未验证
-
-- **代码面不热**：`hmr` 行 `root: []`，改 `better-dsh/lib/*.js` 不触发热重载，需重启（本报告未实测"改代码"路径）。
-- **client 半不按组件拆**：行开关只影响 served HTML 注入腿；client bundle 需重建 + `client-hmr` stat-poll 才会换模块。
-- **§4.2 的级联失败路径为源码推导**：本 profile 内没有"两个都可开关、且其一 inject 另一个"的行对（六组件间无边；host 侧 provider 行多为 `management-required` 或动它会打断本 session），故未做破坏性 live 验证。若日后需要实证，最小实验是造一对测试行（provider + `inject:[...]` 消费方）在同一 bundle patch 里，关 provider 观察消费方 `fiberPhase` 与 `ChangeResult`。
-- 本次实测在 Dev/Test 1（4988）；prod 3080 未动。
-
----
-
-## 六、相关文档
-
-- 组件拆分设计：`docs/specs/plugins-page-components/spec.md`
-- 前序实测（拆分 + 真 UI 开关往返）：`docs/50_test-reports/2026-09-17-plugins页六组件拆分实测报告.md`
-- 插件机制速查：`docs/60_exploration-and-research/05-dashr-dev/plugin-development.md`
-- override 三条硬边界 / patch 层序：根 `AGENTS.md` §四

package/docs/80_upstream-docs-and-skills/dsh-dev-skill/pi-and-omp/.tools/MdxPage-CTY7atqe.js

@@ -1,11 +0,0 @@
-// Stub of the site's MdxPage module.
-export function n() { return {}; }   // default component map (base tags are string literals in content chunks)
-export function t(page, meta) {
-  const C = (props) => {
-    let tree = null;
-    try { tree = typeof page === 'function' ? page(props || {}) : null; } catch (e) { tree = null; }
-    return { kind: 'doc', meta: meta || {}, tree };
-  };
-  return C;
-}
-export default t;

package/docs/80_upstream-docs-and-skills/dsh-dev-skill/pi-and-omp/.tools/extract_omp.mjs

@@ -1,42 +0,0 @@
-import { writeFileSync } from "fs";
-
-const chunks = [
-  "start-Dj2bs0Kq",
-  "capabilities-Cqy7s-PF",
-  "customization-okh9xJ8M",
-  "models-DZr7pp6i",
-  "programmatic-D_fLU-fi",
-  "reference-BWFEeAhZ",
-];
-
-const all = {};
-for (const c of chunks) {
-  let mod;
-  try {
-    mod = await import("./chunk_" + c + ".js");
-  } catch (err) {
-    console.error("IMPORT FAIL", c, String(err));
-    continue;
-  }
-  for (const [k, v] of Object.entries(mod)) {
-    if (typeof v !== "function") continue;
-    let res;
-    try {
-      res = v({});
-    } catch (err) {
-      continue; // not a doc-page component
-    }
-    if (res && res.kind === "doc") {
-      const slug = (res.meta && res.meta.slug) || k;
-      all[slug] = {
-        group: (res.meta && res.meta.group) || "",
-        title: (res.meta && res.meta.title) || k,
-        lede: (res.meta && res.meta.lede) || "",
-        tree: res.tree,
-      };
-    }
-  }
-}
-writeFileSync(new URL("./omp_extracted.json", import.meta.url), JSON.stringify(all));
-console.log("pages extracted:", Object.keys(all).length);
-for (const s of Object.keys(all)) console.log(" ", s);