continuum v0.1.0 · 桌面宿主实测缺陷报告
================================================
报告日期 : 2026-10-07
测试对象 : @local/dsh-context-continuum v0.1.0
测试环境 : DeepSeek Harness 桌面应用（desktop profile）
模型     : minimax / MiniMax-M3
会话     : session-<REDACTED>（cwd <WORKSPACE>）

基线说明：本轮首次在**真实桌面宿主**上观测到 continuum 产出（此前均为 web/headless）。
            索引产物 `<!-- CONTINUUM-INDEX v1 -->` + `T1` 条目证明插件确实生效。

================================================
缺陷 1 · 压缩把存在的任务信息判成「信息不足」（功能性失败）
================================================
严重度：高（会导致下游模型误判无任务可续）

实测证据（索引原文逐字）：
    <!-- CONTINUUM-INDEX v1 -->
    会话索引（不可变条目，只追加）
    T1 <think>
    状态：未完成（模型未给出）
    未决：信息不足
    产物：（本区间无产物记录）
    当前状态
    正在做：信息不足
    下一步：信息不足

后果（同一会话下游模型的实际输出）：
    「我没有看到上一轮的实际任务内容——刚才那段是空的。
      请告诉我你想继续什么：指定任务 / 指定文件 / 指定阶段」

但**信息实际存在**：
  · 工作区 AGENTS.md 明确写了 <VERIFICATION_SKILL> 三态判定与本地法律语料路径
  · available_skills 目录完整注入
  · 用户刚说过「继续」，意图明确
→ 压缩把这三项全部判为「没有」。下游模型据此反问用户要做什么，
  **而这些信息本来就在它被压掉的那段上下文里。**

与 README 的矛盾：README 称机制优势在于「早期内容不再被改写」。
本次实测恰恰相反——**信息存在却被压成了「信息不足」，等于改写成了「无」。**

建议：这是本轮最该修的一条。压缩产物应能从被压区间确定性回填任务元信息
（首个用户消息 / 工作区约定），而非完全依赖模型自述。

================================================
缺陷 2 · `<think>` 泄漏进条目（README 声称 0 泄漏）
================================================
严重度：中（污染索引内容）

README 原文：「官方叙事结构泄漏进摘要：每代都有 | **0 / 27 代**（装配器强制丢弃叙述正文）」

实测反例（同一份索引）：
    T1 <think>
    状态：未完成（模型未给出）
    ...
    <think>The user said "继续" (continue). The checkpoint indicates this
    is turn 1, step 1, and no prior progress has been made. The workspace
    context mentions a <VERIFICATION_SKILL> skill and legal corpus directories
    on <WORKSPACE> ...

即：**不仅标题被 `<think>` 污染，思维链正文整体进入了条目。**

疑因（与 README 缺陷 1 同源）：
  宿主在本插件指导消息**之后**又追加了自己的压缩指令，
  模型把思维链写进了被当作条目的位置；
  而装配器按固定标题行切分，不识别 `<think>` 块。

建议：现有单测未覆盖「模型把 `<think>` 写在条目首行」这一形态，建议补测试。

================================================
缺陷 3 · 压缩触发过晚，且压不动系统注入的大头（定位偏差）
================================================
严重度：中（与用户预期错位，非代码 bug）

装入的实际参数（desktop profile cordis.patch.yml）：
    thresholdRatio: 0.8        ← 涨到窗口 80% 才动手
    headroomTokens: 65536
    retainRatio: 0.16
    maxOverflowRetries: 1

实测时间线：
    20:32  CONTEXT_WINDOW_EXCEEDED (2013)   ← 撞满窗口，压缩未先触发
    20:34  压缩 3 条（约 674 tokens）        ← 被 400 逼出的应急兜底

结论：
1. 压缩**是被 400 错误逼出来的**，不是主动触发。
   若窗口为 512k，需涨到约 410k 才动手 —— 用户「感觉没压缩」的印象成立。
2. 更关键：`available_skills` 等**系统注入块不在被压区间内**，每轮重复计入。
   → **continuum 压的是对话历史，控不住上下文总量。**
   → 它解决「早期事实被反复磨平」，**不解决「上下文总量大」**。

建议：这是**定位问题**而非缺陷。若目标是控制总量，
需要让插件把系统注入块纳入压缩区间，或调低 thresholdRatio（如 0.5）。
README 应明确写出「本插件不控制上下文总量」以免误用。

================================================
已确认正常的部分（对照实测）
================================================
✅ `<!-- CONTINUUM-INDEX v1 -->` 头部标记正确产出
✅ `T1` 序号从 1 起（首代）
✅ 四段式条目结构：状态 / 未决 / 产物 / 当前状态
✅ 桌面端接管压缩后端成功（索引产出即证据）
✅ 依赖解析正常（junction 生效，插件被加载）
✅ 溢出恢复生效（maxOverflowRetries 兜住了 400）
⚠️ M2.7 在此配置下不可用（窗口仅 2013），必须用 M3
   —— 与 headless 环境同构，属配置约束

================================================
测试过程备注（供复现参考）
================================================
· 装入 diff：package.json +2 行、cordis.patch.yml +155/-0 行，纯新增
· provider 未被污染（minimax 全程保持）
· 装入脚本引入了 2 行中文注释乱码（UTF-8 被当 latin1），
  经核实**仅注释行、以 # 开头，YAML 解析跳过，功能无影响**
· 桌面 profile 与 continuum 压测相关的既有约束：
  `rejectElectronProfile()` 只拦 desktop，web 可由 CLI 加载（故此前走 headless 路线）