dsh-projcache-lru

DSH 投影缓存 LRU 淘汰补丁：防止 session_projcache.json 无限膨胀，
从源头掐断 DSH 服务器周期性假死 / watchdog 误杀链。

A patch plugin for DeepSeek Harness (DSH) that keeps the global
session_projcache.json projection-cache index bounded via LRU eviction,
fixing the periodic event-loop stalls and watchdog kill-loop caused by
unbounded whole-file rewrites of the JSON storage backend.

问题是什么

DSH 的会话投影缓存（session_projcache.json）是全部会话投影检查点的全局
索引，底层 JSON 存储后端（@deepseek-ai/dsh-storage-json）对每次写原语
都做"全量序列化 + 整文件原子重写"，且官方没有任何淘汰机制：

• 每派生一个子代理会话，缓存永久增加一条记录，滚雪球式膨胀（实测一晚积累
  1,170 个切片 / 64.6MB）
• 回合结束时的强制检查点落盘会对 64MB 文档做同步 JSON.stringify + fsync，
  阻塞单线程 event loop 30~120 秒
• 期间健康检查超时 → watchdog 判定"已死"→ 强杀服务器 → 在途工具调用全部
  中断；重启后投影重建又加速膨胀，形成恶性循环（一晚实测 8 次屠杀 + 1 次
  被拦下的假死）

完整证据链（时间线、物证、源码引用、修复验证）见 EVIDENCE.md。

补丁怎么解决

插件通过域诊断接口直接操作投影缓存表，实现 大小硬顶 + LRU + 子代理优先：

策略	实现
≤10MB 硬顶	估算 + 实测双监控，软目标 8MB 即开扫，超硬顶放大删除预算
LRU 淘汰	每类保留最新 N 条（子代理 50 / 普通 400），老记录按活跃 seq 淘汰
子代理优先	孤儿记录 → 子代理（delegationDepth>0 或含 parentSession）→ 最老普通会话
活会话豁免	sessions.list() 中的会话记录绝不淘汰
小批量限速	单轮 8 条（超硬顶 20 条），避免删除本身引发重写风暴
零数据风险	只删索引缓存，sessions/ 下原始对话日志分毫不动

安装

# 依赖 DSH 的 super-injector（本仓库作者的环境为 profile web）
# 或直接把本包加进 profile 的 dsh.profile.bundles + dependencies link

持久化装配三件套：dsh.profile.bundles 登记 + dependencies link: +
node_modules junction，重启后自动加载。

配置

键	默认	含义
intervalMs	60000	定时扫描间隔
softTargetBytes	8388608	软目标 8MB，超过即开始淘汰
hardCapBytes	10485760	硬顶 10MB，超过放大删除预算
keepNewestSub	50	保留最新子代理记录数
keepNewestMain	400	保留最新普通会话记录数
maxDeletesPerSweep	8	常规单轮删除预算
maxDeletesOverHard	20	超硬顶单轮删除预算
dryRun	false	只统计不删除

工具与运维

• 模型工具 projcache_evict（可选 aggressive）：手动触发一轮淘汰并返回
  统计（记录构成、估算/实测体积、淘汰明细）。
• 自证日志 ~/.dsh/tmp/projcache-lru.log：每轮扫描一行，自动截断。
• 构建（esbuild 全量打包，产物 lib/index.js 零外部依赖）：

  node esbuild src/index.ts --bundle --format=esm --platform=node \
    --outfile=lib/index.js --external:node:*
  

已知边界

• 缓存记录全为活会话时豁免优先，可能暂时超过软目标（安全取舍）。
• 依赖 storageDomain.get('session_projcache') 诊断接口；DSH 升级改动该
  接口时插件会自证失败并停手，不影响服务器。

上游修复建议

本插件是外部补丁。根治方案需在 deepseek-ai/deepseek-harness 上游落地
（PR/Issue 见 EVIDENCE.md §6）。