Third-party bundle plugins are silently disabled ~3s after boot (insert objects mutated by fiber disposal, HMR recompose persists it)

[LunaRime]

提交目标：https://github.com/deepseek-ai/deepseek-harness/issues/new

Title

Third-party bundle plugins are silently disabled ~3s after boot — HMR recompose picks up disabled=true written onto the shared bundle insert objects

Environment

• dsh version: 0.1.0-rc.7 (also reproduced on 0.1.0-rc.6)
• Platform: Windows 10, Node v23.11.0
• Profile: ~/.dsh/profiles/web, plugins installed via dsh plugin add and manual dsh.profile.bundles entries

Symptom

Any third-party bundle plugin (a package declaring "dsh": { "bundle": { "patch": "./cordis.patch.yml" } } whose patch inserts its own row via - insert: [{ id, name }]) activates at boot, then ~3 seconds later is silently disabled:

• entry.options.disabled becomes true (raw value), entry.fiber is destroyed — verified via injected probe in the live process.
• The settings → plugin list shows 配置状态: 已停用 with no Cordis status column (no fiber).
• The plugin's host services and client half both stop working (e.g. /api/usageStats/query returns 404 for dsh-spend).
• dsh --dump-config shows the entry without any disabled field — configuration layer is clean.
• The only third-party plugin that survives is one whose inject lists only always-present services (settings, loader); every plugin injecting agents / sessions / webServer gets disabled.

Root cause (confirmed from source + runtime injection)

1. applyEntryPatches (vendor/include/src/index.ts) pushes the insert entries by object reference into the composed tree (data.push(...insert)).
2. The loader's disposal hook (cordis-plugin-loader/src/index.ts, "case 7") writes fiber.entry.options.disabled = true directly on that shared object when a fiber is disposed by loader behavior.
3. After boot, watchUserPatches triggers internal/update; the Include plugin recomposes via applyPatches(this.data, config.patches). The same patch objects (including the now-mutated insert rows) are applied again, so every previously-disposed third-party row comes back disabled: true.
4. Verified: two internal/update events carry identical patch lists (50 entries), yet the first compose leaves dsh-at-file clean and the second compose yields disabled: true. Runtime probe at t+3s shows all third-party entries disabled=true, fiber=N except the one that was never disposed.

apps/cli/src/profile-boot.ts already documents this hazard ("the boot application must not mutate the objects later reloads recompose from") and clones for boot, but the mutation path through the loader's dispose hook still reaches the shared insert objects, and the HMR recompose re-applies them.

Impact

Every third-party bundle plugin silently loses host services and client UI shortly after boot. No error is printed (disabled is a valid state). dsh-doctor reports nothing actionable. Users are left with plugins that "installed but do nothing."

Workaround (verified)

Add explicit disabled: false overrides for every third-party row in the profile's own patch layer (~/.dsh/profiles/<name>/cordis.patch.yml):

- id: dsh-at-file
  disabled: false
- id: dsh-openpencil
  disabled: false

The profile layer applies after bundle layers on every recompose, so it wins over the polluted value. Verified: all 22 third-party plugins stay ACTIVE (fiber state 2) and their client manifests appear.

Suggested fix

• In the loader's dispose hook, do not mutate entry.options in place for shared insert rows — either clone the row before writing disabled, or drop the mutation entirely (the HMR applyPatches already recomposes from the layer list).
• Alternatively, deep-clone the composed data inside applyEntryPatches (currently structuredClone(data) only clones the previous tree, not the inserted objects coming from patches).
• Add a regression test: boot a profile with a third-party bundle whose row gets disposed once, then trigger a recompose, and assert the row is not disabled.

[argszero]

在 rc.7（99f6f02fec）上逐行验证——你的根因完全成立，而且这是插件 reconcile 家族的第 4 份现场报告，你发现的"共享对象被 loader 就地突变"是全新的第 4 个触发类。逐点确认：

1. 三处源码全部属实：

• vendor/include/src/index.ts:94 — data.push(...insert) 按引用插入。注意 :63 的 data = structuredClone(data) 只克隆了已有数据，insert 补丁对象本身从不在克隆范围——所以被 loader 突变的 insert 行对象会原样存活。
• vendor/loader/src/index.ts:155 — fiber.entry.options.disabled = true 是唯一的写入点（全仓库 grep 确认），且直接写在 fiber 持有的 entry（= 那个共享 insert 对象）上。
• vendor/include/src/index.ts:206-211 — internal/update 事件用同一份 config.patches 列表重新 applyPatches(this.data, config.patches)——已被就地置 disabled: true 的 insert 对象再次入树。

2. 为什么"只注入常驻服务的插件存活"是必然： 你的观察与 loader 的 inject 检查器行为吻合——注入 agents/sessions/webServer 的插件在树重组时因服务时序被 loader 判为需处置（case 7 命中），而只注入 settings/loader（常驻服务）的插件不在处置路径上，逃过了 disabled = true 写入。这解释了为什么同是第三方 bundle、存活与否取决于注入清单。

3. 家族汇聚——这是 reconcile 家族的触发类 #4：

• [Bug] plugin install reports success but silently disables an unresolved profile bundle #1377：resolveBundleDir 抛错 → exportsPatch 混淆"可解析但无 bundle"与"不可解析" → 静默从 bundles 剪除；
• dsh plugin add promotes pre-existing bundle-declaring deps into the bundle stack and breaks the next boot with "duplicate loader entry id" #1404：预存 bundle 依赖被提升 → 用户 patch 层与 bundle 层同一 entry id 重复 → 启动崩溃；
• Hot re-apply of an in-place updated plugin package fails with tool "X" already registered; module cache serves stale code #1610：热重载 import-before-dispose + 陈旧模块缓存 + 注册越过 fiber 存活；
• Third-party bundle plugins are silently disabled ~3s after boot (insert objects mutated by fiber disposal, HMR recompose persists it) #2854（你）：loader 处置把 disabled=true 就地写进补丁共享对象 → 下次 recompose 把禁用状态带回来——"热重应用无法验证撤回"的又一种实体化。
  共同根因正是我在家族记忆里记的：loader 的 replace/reconcile 路径假设前一个 fiber 已完全且正确地拆除——盲态 reconcile 看不到"怎么加载的"（bundle 还是用户 patch），热重应用也无法验证撤回是否干净。你的案例把"不干净的撤回"具体化为"对象级突变残留"。

4. 修复方向（任选其一，都有现成落点）：

• 克隆 insert 对象（最直接）：applyEntryPatches 的 data.push(...insert) 改为 data.push(...structuredClone(insert))（vendor/include/src/index.ts:94）——一行，从根上切断共享对象突变传播。注意 target.config.push(...insert)（:92，组内插入）同样要克隆。
• loader 处置不写共享对象：case 7（vendor/loader/src/index.ts:155）改为在 fiber 的私有 entry 副本上写 disabled，或改用 tree 级禁用标记而非就地突变 entry.options。
• recompose 前清洗：internal/update 路径在 applyPatches 前对 patches 做深度克隆（config.patches 是外部可变的，loader 不应依赖其不可变性）。
  推荐第一项（一处、低风险、覆盖组内/顶层两种插入）；理想是 1+2 双修（根治 + 防御）。

5. 连带提示：--dump-config 显示无 disabled 字段（配置层干净）而运行时被禁用——这种"配置面 vs 运行时面"的漂移正是本家族反复出现的模式（#1404 的 dump 不漏、运行时崩）。任何修复都应补一个断言：dump 出的配置与实际挂载树一致。

你的运行时注入探针（进程内验证 entry.options.disabled + fiber 销毁）把"静默"变成了"可观测"——建议保留这套探针作为回归测试的思路。