压缩计数 Wepoi9/dsh-compaction-counter

dsh-compaction-counter

一个 DeepSeek Harness 插件，在输入框下方的上下文计量条旁边显示当前会话的上下文被压缩了多少次。

4 turns 432 steps · 168 tok/s 74.3M tok · Cache hit 95% 30% Compactions: 1

统计什么

当前会话每成功压缩一次，计数加一。

| 事件 | 是否计数 | 原因 |
| compaction/summary | 是 | 在同步提交步骤内追加，与替换正文一起写入，所以失败的尝试会以带 error 的 compaction/end 收尾，永远不会产生 summary。 |
| 带 error 的 compaction/end | 否 | 失败的尝试只记录错误，不产生 summary。 |
| compaction/prune | 否 | 裁剪工具结果不算压缩对话。 |
| 分叉会话继承的前缀 | 否 | 那些压缩属于父会话，不属于分叉。 |

计数是持久化的会话投影，所以重载页面、重新打开会话都不会丢：宿主会从会话日志重新算出它。

安装

从本地检出目录安装：

dsh plugin --profile web add "link:<absolute path to this directory>"

插件自带 bundle 补丁，安装时会把它追加到配置档的 dsh.profile.bundles 选择里。之后重启 dsh web，再硬刷新浏览器。

插件不改动压缩行为、压缩配置和平台 bundle：它只加一个投影单元和一个 composer-dock 条目。

工作原理

宿主部分（index.js）在 ctx.sessionProjections 上注册一个投影单元 compactionCount。这个单元对已提交的会话事件做纯折叠；客户端通过标准投影通道拿到它的完整值。

客户端部分（client.js）向平台的 conversation.composer.dock 槽位注册一个条目——就是自带的活动与用量胶囊用的同一个官方槽位。条目通过会话标准的 useProjection 座位读取 compactionCount 投影，所以宿主部分没挂载时它什么都不渲染。

摆放位置。 平台会把整个 dock 槽位渲染在标准上下文圆环之前，所以槽位条目自己的 order 没法把读数放到圆环右边——它总是落在圆环左边。因此条目还在自己的元素上设了 CSS order: 1。dock 是 flex 行，标准圆环不带 order（默认 0），这样读数就移到了圆环之后，而自带的胶囊保持原位。于是视觉顺序和 DOM 顺序不一致，对于一个不可交互的读数来说，这是可以接受的取舍。

文案跟随浏览器的语言偏好，加载时选一次（主语言子标签为 zh 用中文，否则用英文）。它不读取 DSH 的 Language 设置，改语言要重载才生效。

开发

npm install
npm test # unit and host-integration tests
npm run check
tests/projection.test.mjs 单独覆盖折叠逻辑。tests/host-integration.test.mjs 用真实的 @deepseek-ai/dsh-session 和 @deepseek-ai/dsh-session-projection 包运行这个单元，其中包含 fork 场景。

zod

插件自身的 zod 依赖下限为 ^4.6.6，这是首个包含 CVE-2023-54404 修复的版本（该漏洞通过无界数组校验造成资源消耗失控）。插件只校验数字和对象，因此这里走不到有漏洞的数组路径，但设下限能保证每次安装都带上已修复的版本。

overrides 条目为 DSH 开发依赖引入的传递副本锁定同一版本，让整棵依赖树解析到同一个已修复的 zod。该条目只对本包自身的安装生效；DSH 各包保留自己的 zod 版本锁定。

License

MIT