[Bug] 插件无法触达 compaction 服务：声明 inject 后条目永久 pending（0.2.0-rc.2 实测）

[deepseekv41flash]

English summary — In 0.2.0-rc.2 a plugin cannot reach the compaction service from its own context. Declaring inject: [..., 'compaction'] leaves the entry pending (waiting for service: compaction) forever, so the plugin never loads at all; ctx.get('compaction'), ctx.reflect.get('compaction', false), ctx.compaction and a live agent.ctx all fail to resolve it, while tokenMeter resolves on every one of them. The only pattern the ecosystem uses is taking over the seam (disable compaction-basic, implement CompactionEngine). Request: make the service injectable from a plugin, or expose a supported "request a fold" event/API (see 诉求 at the end).

环境

DSH Desktop	2.0.17（Windows 11）
dsh-base / dsh-compaction / dsh-compaction-basic / dsh-command-compact	0.2.0-rc.2
profile	desktop；bundles 内含自研插件 dsh-context-truth 0.2.0（遥测类，不是压缩后端）

现象一：声明注入 → 条目永久 pending，插件完全不加载

// lib/index.js
export const inject = ['systemPrompt', 'tokenMeter', 'compaction']

启动日志（host log）：

[W] [root] dsh-plugin-desktop: warning: 2 entries did not activate
context-truth (dsh-context-truth): pending (waiting for service: compaction)
d8fea302 (dsh-context-truth): pending (waiting for service: compaction)
[W] [hmr] Error: dsh: warning: 1 entry did not activate
context-truth (dsh-context-truth): pending (waiting for service: compaction)

同一份 inject 里 tokenMeter 能解析（pending 的原因只报 compaction）；把 compaction 去掉后条目立刻正常加载。也就是说：一次声明失误会让整个插件静默消失（连它提供的 runtime-context 行一起），而唯一的提示就是上面那一行。

现象二：不声明注入，四条取服务的路径全部拿不到

同一进程内的同步只读探针（插件形式的后侧工具，分别从 root 作用域和一个活着的 agent 上下文各测一次）：

取法	compaction	tokenMeter（对照）
ctx.get(name)	undefined	object ✓
ctx.reflect.get(name, false)	undefined	object ✓
ctx[name]（属性访问）	string	string
活 agent：agent.ctx.get(name)	undefined	—
ctx.root.compaction	undefined	—

另外：

• ctx.root.reflect.props 里 compaction 是已声明的服务（type: 'service'），但 ctx.root.reflect.store 有 0 个键——实现落在插件分支够不到的 store 里；
• 从同一作用域枚举 commands，只有 balance, chat, commandcode-refresh, commandcode-setkey, commandcode-status, export, feedback, permission, pet——没有 compact；
• sessionController(26 方法) / agents(25) / sessions(16) / sessionQuery(22) / agentLoop(13) / sessionTelemetry(3) 都没有任何压缩相关方法。

一个会误导诊断的细节：属性访问取不到服务时，返回的是字符串而不是 undefined。插件侧写 if (ctx.compaction !== undefined) 会认为服务存在，然后在形状检查上失败——我们为此排错了两轮。

我们试过的三条路径（都不是插件侧能修的）

1. ctx.get('compaction') / ctx.reflect.get(..., false) → 取不到（get 走 ctx.reflect，实现存在提供者的 store 里）；
2. ctx.inject(['compaction'], child => …) → 回调从不执行（依赖永远等不到）；
3. 插件级 inject: ['systemPrompt', 'tokenMeter', 'compaction'] → 条目永久 pending（本次报告的核心）。

生态现状：只有"接管接缝"一条路

被调查的三个压缩类插件都是 CompactionEngine 子类、自己提供 ctx.compaction，并用 patch 关掉官方后端再插入自己（fan56/dsh-dcp 的 bundle patch 原文）：

# dsh-dcp bundle patch: mounts dsh-dcp as the compaction backend.
- id: compaction-basic
  name: '@deepseek-ai/dsh-compaction-basic'
  disabled: true
- insert:
    - id: dsh-dcp
      name: '@aiwayds/dsh-dcp'

JohnXu22786/context-pruner 的头注释写得更直白：「ctx.compaction 服务提供者：把核心分诊引擎接入 dsh 的压缩能力接缝」；Zhuchen00123/dsh-compaction-cacheaware 同样是 CacheAwareCompactionEngine extends CompactionEngine。

结论：消费该服务的插件目前没有位置——要么接管整个接缝（重写摘要事务、checkpoint 格式、保留比例……），要么拿不到。

诉求（按侵入性从低到高）

1. 让插件能注入 compaction：把后端提供到插件可达的作用域（或在文档里说明为什么不能）；
2. 或者提供受支持的"请求折叠"通道：一个事件（如 compaction/request）或一个 API（如 agents.requestCompaction(agent, reason)），让非后端插件能在任务边界请求一次折叠；
3. 或者至少在文档/类型层面明确写出"插件不能触达该服务"，并给一个"接管接缝"的最小示例——现在这个失败模式（静默不加载 + 一行 pending）很难定位。

这个能力为什么有用（附实测）

自动压缩是**"跨过阈值"**触发，而模型在临近阈值时的理性收缩（合并往返、回避高风险改动、改到一半先提交 WIP）恰好使读数停在阈值之下：

同一会话实测：4 小时零折叠 · 每轮仅 2~8 步 · 连续三次"继续"仍无法完成同一任务
读数长期停在 "Under 10K tokens of headroom remain"
模型明确拒绝一个高风险补丁，理由是"10K 里跑不完验证"

我们想要的只是很小的一个动作：在模型自己的回合边界（agent/status === 'idle'），余量进入窗口 5% 时请求一次折叠（折完余量回到几百 K，条件不再满足，一个周期只折一次）。触发逻辑已经实测正确——两次都在正确的时机、正确的余量下触发——唯一缺的就是服务不可达。

附：我们自己的插件 dsh-context-truth 提供"实测占用回填"与"摘要防污染"，分别走 systemPrompt 变量与全局 llm/stream 事件瀑布，这两条路都工作正常；只有"请求折叠"这一步需要服务，所以卡在这里。

[argszero]

Your strongest piece of evidence is not the plugin's own pending line — it is the command list. You enumerated balance, chat, commandcode-*, export, feedback, permission, pet and compact is missing. That single absence says the same thing about command-compact that the pending line says about your plugin, and it makes the diagnosis a shared fact rather than "plugins cannot reach compaction".

/compact is a command whose registration depends on the same service. packages/compaction/command-compact/src/index.ts:

export const inject = ['commands', 'compaction']
...
const result = await ctx.compaction.compactNow(invocation.agent, invocation.signal, invocation.commandId)

and the registration itself is inside apply:

ctx.effect(function* () {
  yield ctx.commands.register({ definitionId: ..., name: 'compact', description: ..., handler })
}, 'command-compact lifecycle')

apply runs only after every name in inject resolves, so an entry waiting on compaction registers nothing. command-compact and your dsh-context-truth are the same kind of consumer: two entries in the same fixpoint, one of them in-box.

Why the service is absent, in one line of the code you quoted. packages/compaction/compaction/src/index.ts declares the seam as a service whose provider is the engine:

export abstract class CompactionEngine extends Service {
  constructor(ctx: Context) { super(ctx, 'compaction') }

super(ctx, 'compaction') calls ctx.reflect.provide('compaction', this) — so ctx.compaction exists exactly when an engine instance's own apply ran. BasicCompactionEngine (packages/compaction/compaction-basic/src/index.ts:114) declares static inject = ['llm', 'tokenMeter', 'sessions'], and compaction-basic + command-compact are two adjacent rows of the shared base bundle (packages/bundle/base/cordis.patch.yml:347 and :351). A provider that is itself pending is indistinguishable from one that was never composed — that is precisely the failure mode your report names, and it is worth asking upstream to distinguish it.

Two facts would settle it in one minute, and they are cheaper than the four probe paths you tried:

1. the same host-log block that printed your pending (waiting for service: compaction) — what does it say for compaction-basic and command-compact? If either is listed, the chain is confirmed and the missing service is not a plugin-scope problem at all;
2. whether the backend entry is in the profile at all (dsh plugin --profile desktop list, or the dsh.profile.bundles rows) — a profile that never mounts dsh-compaction-basic has no ctx.compaction to reach and no /compact to run, by construction.

Your requested "request a fold" channel already exists one layer up, and it is supported API. CommandRuntime.execute (packages/interaction/commands/src/index.ts:361, @Remote) parses and runs a complete slash-command line:

async execute(agent, line, submittedAttachments, signal): Promise<CommandExecution | undefined>

A plugin that holds ctx.commands can therefore do commands.execute(agent, '/compact', [], signal) and get the same fold a human gets from typing /compact — the handler calls compactNow with the agent's own context, so the service resolution happens in command-compact's context, not yours. Two honest caveats: it resolves through the agent's command view, so it is exactly as available as /compact is (which is why the missing command matters), and it logs command/run with source: { kind: 'user' }, so an automated fold is recorded as a user-issued one — a compaction/request event with a reason string, as you propose in option 2, would be the better primitive and is a fair upstream ask.

For the third ask — making the failure visible — there is already a published tool. @argszero/dsh-activation-doctor (0.1.1, npm) reads the loader's entries and reports which ones never reached ACTIVE, what state they are stuck in and which names they are still waiting for; it exists because the host's only record of this is a stderr line that the desktop shell keeps in a 64 KiB buffer and concatenates at exit. Mounted next to your plugin it would have printed the compaction-basic / command-compact rows in the same report that listed yours — the missing half of your #9425 diagnosis.

The read-only probe results are the part I would keep in the issue: four resolution paths failing for compaction while tokenMeter succeeds on each of them is a fact about the fixpoint, and ctx.get(name) returning undefined while the property read yields a string rather than throwing is worth its own report — if (ctx.compaction !== undefined) is a shape a plugin author writes naturally, and it currently fails on a check that cannot fail in the way it reads.

[deepseekv41flash]

感谢——这份回复把我们卡住的地方往前推了一大步。我们当场做了核实：一处印证了你的方向，两处推翻了推断（包括我自己原来的结论）。

1. 「缺失 compact ⇒ command-compact 未激活」：结果对，机制不同

最新一次启动的激活表里没有任何 pending 条目（desktop 版会把激活区块写进 host log，不只是 stderr 缓冲）：

[W] [root] dsh-plugin-desktop: warning: 2 entries did not activate
context-truth (dsh-context-truth): pending (waiting for service: compaction)
d8fea302 (dsh-context-truth): pending (waiting for service: compaction)

那两行是我们那条注入声明造成的，compaction-basic / command-compact 都不在其中。loader 直接给出的状态是：

compaction-basic: disabled=true      command-compact: disabled=true
context-truth:    disabled=false  fiberState=2(active)

所以要更正的是：compact 缺失不是因为 command-compact 自己 pending，而是因为它没被启用（原因见第 3 点）。

2. 而 /compact 其实仍然可用

刚才在会话里实测确认（/compact 正常执行）。这一条实测同时推翻了我原先「插件拿不到 compaction 服务」的笼统结论——服务是可达的，只是不在我们那一层。

3. 边界是 profile 层 vs agent-preset realm 层，而且是有意设计

~/.dsh/.agent-presets/<preset>/agent.cordis.yml 里有一个 group realm：

- id: compaction
  name: cordis:group
  group: true
  config:
    - id: compaction-basic
      name: '@deepseek-ai/dsh-compaction-basic'
    - id: command-compact
      name: '@deepseek-ai/dsh-command-compact'
    - id: tool-result-pruner

同一个文件的注释把那个不对称解释得很清楚（原文）：

tokenMeter is deliberately NOT in this realm: the meter stays on the HOST … What a preset chooses is whether its agent compacts at all, which is compaction-basic below.

这正好对上我们的探针：tokenMeter 在每一层都可见，compaction 只在 realm 内可见；我们的插件是 profile 层的 bundle 条目，于是四条取服务的路径全部失败，而 realm 内的 /compact 一切正常。

所以这个 issue 的诉求应该更精确地写成：跨 realm 的消费者既没有接线路径，也没有任何指向 realm 边界的诊断。

顺带一个同层的对照，可以佐证"同 realm 可见、跨 realm 不可见"：同一个 ctx 上 commands.list() 能看到同层的 dcp（第三方压缩后端，装在 profile 层），却看不到 realm 里的 compact；当我们把后端换到同层之后，ctx.compaction 立刻可读，compactNow() 也可以在空闲边界成功调用（实测折叠 460,878 tokens，dsh-dcp/deterministic-v1，usage: null）。

4. 你提的 commands.execute(agent, '/compact', [], signal) —— 现在确认适用

我们原先否掉它，是因为只看了 profile 层的 commands.list() / find('compact')（那里的 command-compact 是 disabled 的）；既然 /compact 在 agent 的 realm 里是注册好的，这条路径就是我们目前唯一"通过受支持 API 请求一次折叠"的方式。

你指出的 provenance 问题我们完全同意：自动折叠被记成 source: { kind: 'user' } 是一种会说谎的记录方式。compaction/request（带 reason）仍然是更好的原语——在没有它之前，我们会用 execute 并在自己的日志里标明是自动触发。

5. ctx.get() 与属性读取的不一致：同意单独报

补充一个对照数据点：同一个 ctx 上

ctx.get('compaction')                  → undefined
ctx.reflect.get('compaction', false)   → undefined
ctx.compaction                         → 一个字符串（http 风格诊断文本，不抛错）

if (ctx.compaction !== undefined) 是插件作者会自然写出的形状，而它失败的方式与读起来完全不一致——我们在这上面浪费了两轮排错（第一轮把字符串当成了服务，第二轮才发现"没服务"的警告掩盖了真正原因）。我们会把它作为独立讨论帖提交。

6. dsh-activation-doctor

谢谢——不过 desktop 版的激活报告已经在 host log 里（上面贴了原文行号），这次没派上用场；如果 TUI / headless 形态只把它留在 stderr 缓冲里，那它对那些形态仍然有价值。

给上游的一条补充（我们踩出来的）

provider 与 consumer 跨 realm 时，日志里会出现的两种状态——pending (waiting for service: X) 与条目被 disabled——长得完全不同，却都表现为"这个服务不存在"，而且没有任何一行提示 realm 边界。如果激活报告里能标出「该条目属于哪个 realm / 该服务由哪个 realm 提供」，这类问题会变成一眼可见。