仿照这个对billion-context-dsh进行bug扫描

[ranxianglei]

仿照这个对billion-context-dsh进行bug扫描 ranxianglei/billion-context-pi#305

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 收到。计划（对齐 pi#305 的方法，但用 billion-context 本仓的 bug 史做对照透镜）：

1. 拉取 Tyan66666/billion-context-dsh 源码通读。
2. 扫本仓 bug 史：git log / CHANGELOG / devlog / issues，重点提取「缓存命中」「压缩」「性能」三类模式。
3. 逐条映射 bc 已修 bug → dsh 是否同样存在；另做通用扫描（缓存/压缩/性能）。
4. 与 pi#305 已开的 dsh issue（refactor: remove V1 streaming loops (V2-only) + dedup forward headers/routes #108–fix(config/session): honor env proxy by default + validate port + bound session pool #111）去重，新发现带来源标记在 dsh 侧开 issue，最后在这里给完整报告。

先占位，随后出完整结论。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 ## billion-context-dsh bug 扫描报告(对照 billion-context bug 历史)

扫描对象:Tyan66666/billion-context-dsh v0.2.19 @ 08c68d5(clone 到本地逐文件读完 src/ 全部 12 个模块 + tests/ 覆盖核查 + npm install 后读宿主依赖源码取证)。方法同 pi#305:拿 billion-context 自己的 bug 史(CHANGELOG 全量 + git log)当透镜逐类映射,先与 dsh 已开的 #108–#111 查重再落新 issue。

✅ 新提 2 个 issue

Issue	级别	内容
dsh#112	🟠 recall	decompress / /acp decompress 输出无上限、无分页(src/tools.ts:549-572、src/commands.ts:115-131):大 block 恢复要么一次性灌爆上下文(抵消压缩收益、可能触发 #108 的 emergency 重注入路径形成"解压→爆→再压"震荡),要么被宿主 tool-result pruner(8192/4096/1024 档)静默截断成无用残片且模型无法续取。bc 侧对应物是 decompress 的 toFile 逃生通道;dsh 没有文件系统通道,建议 offset/limit 分页或硬上限+显式截断 footer。
dsh#113	🟡 memory	引擎级 per-session Map 无驱逐路径:AcpStateStore.states(src/state.ts:101,delete() 全仓库零调用方)、lastNudgeTurn(src/index.ts:198)、compressCallIdsToHide(src/index.ts:200);引擎只注册了 internal/service/session/event/agent/pre-step,无任何 session-end 钩子。长驻多会话宿主下内存随"进程见过的会话总数"线性增长(bc 同类问题经 bounded session pool 修复过)。

🔍 重点验证后排除的嫌疑(有证据,不重复报)

1. bc#252"压缩后 stale usage 二次压缩"类 → dsh 结构性免疫。怀疑点:resolveTokenCount(src/nudge.ts:54-71)优先信 sessionProjections.contextPressure.projectedTokens,若纯 provider-anchored,则 compress 成功后的下一个 pre-step(新响应未到达前)会读到压缩前的高水位 → 误触发 nudge/emergency。取证结果:@deepseek-ai/dsh-token-meter 的 contextPressure fold = max(0, pressureTokens + surfaceTokens − sampledSurfaceTokens),其中 surface 总量在每次 replace 时消费 shadow-price claim(deltaTokens = tokens(replacement) − claim.tokens(shadowed))——压缩落账即扣减,不等下一次 provider usage。dsh 的 shadow-price 协议(compaction/summary/prune 与 replace 同步相邻写入)正是为这个设计的,该通道干净。
2. bc#133 reasoning-pair 拆分致 DeepSeek 400 类 → N/A。两层:① acp-kernel 0.0.29(dist 内确认含 adjustBoundariesForReasoningPairs,applyCompression 已调用);② dsh 投影只产出 text/tool-call/tool-result CoreMessage(src/messages.ts:119-175),从不发 reasoning 消息,且压缩单位是整条 surface event、不可能拆散单条 assistant 事件内部的 reasoning+text。
3. expandShadowedSeqs 疑似 O(K×log) → 证伪。曾怀疑 region.ts:1061 每个 shadowed seq 都调 sessionEventsOf(session) 会整表重建;实际 dsh-session rc.6 的 events getter 是 memoized(eventsSnapshot ??= Object.freeze([...this.log]),append 间复用),单次调用 O(1)。撤回独立报障,fix: abort compress loop on client disconnect + drain race + session inFlight race #109 仍是真实 perf 问题。

📌 已知 #108–#111 的补充细节(不另开 issue,供修复参考)

• fix: abort compress loop on client disconnect + drain race + session inFlight race #109 补充两个实测热点:hideSurfaceSeqs 对每个隐藏节点调 findOpenTurn(全日志扫描,region.ts:613),orphan 清理循环里就是 O(K×N)(region.ts:765-771);allLogMessages 每次内部还要跑一遍 buildToolCallIndex 全量扫描(messages.ts:178-183),即 fix(responses): add mutatedThisTurn guard + use MAX_LOOP_ROUNDS in non-stream loop #110 的全日志成本至少 ×2。
• fix(responses): add mutatedThisTurn guard + use MAX_LOOP_ROUNDS in non-stream loop #110 补充:nudge 触发时 orphan-strip 跑两遍——pre-step 入口一次(index.ts:301)+ buildCompressibleSeqRanges 内又一次(region.ts:841,且在决策路径里改日志)。
• fix(config/session): honor env proxy by default + validate port + bound session pool #111 两个 mid-prefix 改写点确认无误:hideCompressToolPair(region.ts:631-668,microtask 延迟执行,正确性已处理但仍是改写)+ 每 pre-step 的 orphan strip。

🧹 Minor(按惯例只在报告里提,不开 issue)

• 工具注册失败是静默的:index.ts:229-268 注释声称 internal/service 和 ready 双路重试,代码只监听 internal/service;若 tools row 始终不出现,system prompt + nudge 照常生效但 compress 工具不存在 → 模型被引导调用不存在的工具(bc#217 "fail-fast capability claims" 同类)。建议加一条 loud warning。
• /acp compress 缺 orphan-strip 前置:handleCompress 强制先 stripOrphanedSurfaceToolMessages(tools.ts:296-302,issue release v0.1.6 #18 的教训),而 /acp compress(commands.ts:88)直接 resolveSurfaceRange——崩溃残留 orphan 后,手动命令会撞上工具路径本可自动清理掉的 balance 错误。
• stateFor 初始化时 rebuildKernelBlocks 跑两遍(state.ts:104-116 + nextBlockIdAfter 于 state.ts:90-98),一次性小浪费。
• windowFor 探测失败永久缓存(fallback 128K):属 initSessions: sort key (createdAt vs savedAt) doc/code mismatch #63 文档化权衡,label 已明示 "restart to re-probe",一致,不算 bug。

结论

dsh 的核心事务层比预期扎实:fail-fast 预校验 + 补偿性 compaction/end(region.ts:389-464)、partial-failure 语义(compress 单 range 失败不毒化其余)、双嵌套参数容错 + envelope peel 后补 items 级校验(nudge 死循环的两个历史坑都已堵)、shadow-price 协议让 token 计量与宿主完全同源(#54 类 CJK 超扣从机制上消除)。真正的风险仍集中在已开的四个(#108 emergency 无上限 > #109/#110 perf > #111 cache 测试缺口)+ 本次新增的 #112/#113。

[ranxianglei]

还有内核他也没更新 结合内核继续扫描.还有很多其他功能的 比如多模态,你拉一下我们的issue看看,最近关闭了几个是 大多数是bug

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 收到,继续第二轮扫描,范围扩大为:

1. 内核对照:dsh 钉在 acp-kernel 0.0.29,我拉最新内核版本做 diff(nudge 文本格式、applyCompression、reasoning-pairs、status report 等——dsh 的 nudge 适配层是对内核渲染文本做正则手术,内核改版会直接打穿它);
2. 最近关闭的 bc issue:拉出来当新的 bug 透镜(尤其多模态/图片类);
3. 多模态专项:dsh 投影层对 image block 的处理路径(projectEvent/extractEventText/shadow-price/宿主 pruner)。

有结果就回帖。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 ## 第二轮扫描报告(内核对照 + 最近关闭 issue + 多模态专项)

1️⃣ 内核对照 → 新提 dsh#116

dsh 钉 acp-kernel@0.0.29,主仓现在钉 0.0.54——落后 25 个版本。我把两个版本的 dist 拉下来逐模块 diff 了:

• 无 breaking change(dsh 用到的 pipeline/state/sync/refs/report/tokenize/config .d.ts 逐字节相同,其余纯增量);默认 prompts 和 nudge 配置两版逐字节一致 → dsh 对内核渲染文本的正则手术今天没被打穿,但属"巧合性安全",没有测试护栏。
• v54 有三个影响 dsh 的行为变化:① decideNudge 新增 minPressureBenefit 闸门(默认 max(5000, 1%×window)),emergency/pressure 注入要求剩余可压 ≥ 该值——直接缓解 refactor: remove V1 streaming loops (V2-only) + dedup forward headers/routes #108 的"无可压内容仍反复注入"分支;② 新增 firstSightMassReady:大初始上下文的会话在 ≥45% usage 时立即触发 nudge,不再等增长;③ T2 触发加了计数维度(≥5 个 block)。
• 新模块 absorb/viable/handoff/parse-compress-input 均为 additive;其中 parseCompressArgs 与 dsh 自研的 unwrap+validate(tools.ts:222-290)功能重叠,升级后可收敛到内核单一实现。
• 配套:dsh 自己的 upstream-tracker 要求每次 bump 复查 release v0.1.18 #38(ref-map 漂移 workaround)——本次 diff 未见明确修复证据,需在 0.0.54 上实测;且 release v0.1.18 #38 自认"尚未提交上游 issue";release v0.1.22 #46 依赖的 acp-kernel PR#123 基于 0.0.38,隔了 16 个版本有 stale 风险。建议按 §4b SOP 做受控 bump。

2️⃣ 最近关闭的 bc issue 当透镜(9/5–9/6 一批)

拉了最近 40 个 closed issue 逐条映射:大多数是 proxy 专属(preflight exhaustion/livelock #574/#330、passthrough 静默关死 #405、side-request 误降级 #546、SSE TextDecoder CJK 损坏 #541、dump GC #277、persist EPERM #367)——dsh 没有 proxy/persist 层,N/A。能映射的三条:

• 小模型(2B级)compress 循环空转:同参数重复失败烧满 10 轮 + 幻觉 ref + 摘要长度约束不遵守 #156/fix: short-circuit identical compress failures (#156) #182/fix: break the small-model same-parameter compress failure loop early (#156) #370(小模型 compress 循环空转)→ 已把"同参数失败短路"参考实现评论进 dsh#108,与其断路器诉求直接对照移植;
• **acp_status 会计缺陷:tool 结果全计为 text + 同一报告两套互斥的 tool 定义 + 双估计器混印不标尺 + pct 地板 #386/fix: acp_status uses one estimator scale — defaultCountTokens (#386) #567(双估计器混印)**→ dsh 设计上已统一 defaultCountTokens 标尺,但被图片结构性打破(见下);
• **acp_status 缝合报告:Compressible ranges/Nudge 读冻结的 ctx.nudge,压缩成功后旧区间与新块同框并存 #387/fix: acp_status derives ranges/nudge from live state, not the prepare-time snapshot (#389) #397(acp_status 读冻结快照)**→ 验证 dsh 免疫:handleStatus 每次调用都用最新 log 投影重跑 processTurn(tools.ts:732),不存在 prepare-time 快照。

3️⃣ 多模态专项 → 新提 dsh#117

grep 确认 dsh src/ 零处 image 引用,而宿主 dsh-llm 已有 ImageBlock(user content)+ 共享 image walk(capability gating / text-only serialization / compaction 三类策略)——平台能带图,引擎视而不见。断点链全部代码级验证:

1. extractText(messages.ts:27-41)只取 text 块 → image-only user message 投影为空 → 无 ref、无 bare-seq 边界资格(hasPlainRef 要求非空文本,region.ts:110-132)→ 模型拿图片消息当 compress 边缘时只会得到莫名其妙的 "no tool-pairing-balanced range" 或意外扩张;
2. 内核保护盲区:handleCompress 依赖 kernel 的 last-user 保护,而 image-only 事件不在 coreMessages 里 → 最后一条带图用户消息可被压缩掉(dsh 自己的 last-user 保护只覆盖 range 表路径,不覆盖工具直接请求);
3. 双标尺混印:nudge 闸门用 provider 口径 projectedTokens(含图片),acp_status breakdown/range 表全是 text-only 口径——图片密集会话里单图千级 token 记为 0,同一份报告两个世界(bc#386 同族,结构性的);
4. range 表按 tokens 排序 → 图片密集区间显示 ~0 token,压缩优先级被系统性误导;decompress/search 恢复内容静默丢图。

issue 里给了分层建议(最小修复:标尺标注 + meter 计价 + handleCompress 补保护;完整方案:image 占位 CoreMessage 全链路可见),供 owner 拍板。

小结

本轮新增 #116(内核漂移,含行为差异清单)+ #117(多模态盲区),另向 #108 补了两条修复参考。累计两轮:dsh 侧共 4 个新 issue(#112/#113/#116/#117)+ 3 条已知 issue 补充。核心事务层依旧扎实;风险排序更新为:#108(emergency 死循环)> #117(多模态账目错乱,图片会话必现)> #116(内核漂移,行为分叉)> #109/#110(perf)> #112/#113 > #111。

[ranxianglei]

看是否可以提交对应的pr

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 可以,开始提 PR。按风险从低到高排:

1. fix: reap decompress temp files (bounded retention) #112(decompress 分页)——自包含、低风险,先做:offset/limit 参数 + 显式截断 footer,工具与 /acp decompress 双入口同步;
2. fix: novel review bugs (registry ESM, logger rotation, persist drain, dump error, tarball cap) #113(引擎 Map 无界增长)——AcpStateStore LRU 上限(淘汰走既有 rehydration 路径,安全)+ lastNudgeTurn 同待遇;
3. [security][HIGH] Registry tarball not integrity/https-verified (S2, supply-chain RCE) #116(内核 bump 0.0.29→0.0.54)——本地跑全量测试验证,绿了才提(行为变化是升级目的,会在 PR 里列清);
4. [security][MEDIUM] Auto-update lock-steal race (update.ts:146) #117(多模态)——issue 里给了最小修复/完整方案两档,等你拍板选哪档再动。

跨仓流程走 fork(ranxianglei/billion-context-dsh)+ 跨仓 PR,base 用对方默认分支。有结果逐个回帖。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 可以。按之前定的顺序开始提 PR(跨仓 fork → Tyan66666/billion-context-dsh):

✅ PR 1/3 已开:dsh#118 — decompress 分页(#112)

• (fix) page large-block decompress output with offset/limit so one recovery can't flood or get silently trimmed Tyan66666/billion-context-dsh#118
• 大 block 恢复从"一次性全量灌入(被宿主 pruner 静默截断)"改为默认每页 100 条 + [messages X..Y of Z] 页脚 + 明确续读提示;工具参数与 /acp decompress <blockId> [offset] [limit] 都支持分页;小 block 行为不变。
• 验证:typecheck 干净;测试 211/211(基线 208 + 新增 3 个回归);build 干净(dist 已按对方 AGENTS.md §4 一并提交)。
• 注意:该 PR 基于 main @ 6348af8(v0.2.20)构建——扫描期间上游合了 v0.2.20,我已对齐最新代码。

⚠️ 顺带发现:本沙箱里另一个 ework 会话正在同一个 dsh 克隆上实现 #108(emergency nudge per-turn cap,未提交改动在 src/index.ts / src/nudge.ts)。我已在隔离 worktree 完成 PR1、没有碰它的改动;如果它随后也提了 #108 的 PR,属正常并行,合并时以它的为准即可。

继续:PR2 = #113(per-session Map LRU 驱逐),接着尝试 PR3 = #116(acp-kernel 0.0.29→0.0.54,本地全绿才提)。完成后统一汇报。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 三个 PR 全部提交完毕(跨仓 fork → Tyan66666/billion-context-dsh,均基于 main @ 6348af8 / v0.2.20——扫描期间上游合了 v0.2.20 #106,我已对齐;本地 typecheck/test/build 全绿,dist 按对方 AGENTS.md §4 一并提交):

PR	修复	验证
dsh#118 → #112	decompress//acp decompress 分页:默认每页 100 条 + [messages X..Y of Z] 页脚 + 显式续读提示(offset/limit 参数);大 block 不再一次性灌入被宿主 pruner 静默截断	211/211(基线 208+3 新回归)
dsh#121 → #113	per-session Map LRU 驱逐(cap 512):AcpStateStore.states + lastNudgeTurn;驱逐无损性已论证(bN 编号/消息 ref 从 append-only 日志确定性重建)+ 新增回归测试验证"驱逐后重水合与活状态不可区分"。顺带修了重水合不续 nextRunId 的潜在 runId 碰撞	213/213(+5 新测试;其中 1 个抓出了首版 LRU 实现的真 bug:Map.set 对已存在 key 不刷新 MRU 位置)
dsh#122 → #116	acp-kernel 0.0.29→0.0.54(精确 pin)。两个测试更新对应内核的有意行为变化:① firstSightMassReady(fresh 大会话立即发效率 nudge,默认 minContextLimitPct=0.45)② minPressureBenefit 地板(<max(5K,1%×window) 收益的 nudge 被抑制——部分缓解 #108)③ 重复范围守卫(已被 active block 覆盖的范围拒绝再压缩,dsh 生产路径本就排除 shadowed seqs,属纵深防御)。兼容性:两版 .d.ts 逐模块 diff,pipeline/state/sync/refs/report/tokenize/config 字节级一致,boundaries/types 纯增量;默认 prompt/nudge 文案字节一致(regex surgery 层安全)	208/208(含 CJK 估算、#38 ref-drift、nudge 文案手术回归)

每个 issue(#112/#113/#116)下也留了指向对应 PR 的评论。

未提 PR 的:

• [security][MEDIUM] Auto-update lock-steal race (update.ts:146) #117 多模态盲区 —— 按 triage 规则等 owner 拍板方案:推荐最小修(image block 在投影里落占位文本 token,让边界保护/last-user/range-table 看到真实体量)vs 完整占位投影。你定了我就做。
• refactor: remove V1 streaming loops (V2-only) + dedup forward headers/routes #108 emergency nudge cap —— ⚠️ 本沙箱另一个 ework 会话正在同一个 dsh 克隆上实现它(src/index.ts、src/nudge.ts 未提交改动,~22:00–22:04 还在活跃写入)。我全程在隔离 worktree 干活、没碰它的东西;如果它随后提了 refactor: remove V1 streaming loops (V2-only) + dedup forward headers/routes #108 的 PR,以它的为准,我这边没有重复劳动。

合并都是 maintainer 侧操作,我不代合。PR 落地后建议把 #111(prefix 字节稳定性回归测试)作为独立小 PR 跟进,我可以接着做。