压缩前判定 Phocinae/dsh-context-verdict

context-verdict

整个会话在压缩之前，只给一个结论。

快速开始

dsh plugin --profile web add dsh-context-verdict@0.1.2

现在可以用 context_verdict_build / context_verdict_judge 了；先构建会话快照，再问一个问题：压缩会不会丢掉尚未落地的状态，只要一个结论。

要问的问题，以及这个工具拒绝回答的问题

有没有尚未落地的状态，一旦压缩就会丢失？

这个问题问的是会话整体，不是会话的某个部分。它有可判定的答案：工作要么已经存在于某个持久的地方，要么没有。

这个工具没法告诉你上下文里哪些部分重要。 这条路试过了。我们做过一个逐块筛查器——「这三十个块里哪些可以丢掉？」——把它建起来、测过，结果两个方向同时失败：

| 它判断的对象 | 结论 | 置信度 |
| 包含真正修复的那个块 | 可丢弃 | 0.323 |
| 一首童谣 | 值得保留 | 0.691 |

代价最大的错误和纯粹的噪声，出现在同一份数据、同一次运行里。所以这项能力是结构上就不存在，而不是政策上不提供——见下文「结构上不存在，而非口头承诺」。

三种结论

| 结论 | 含义 |
| safe_to_compact | 记录里没有任何未落地的内容 |
| wait | 记录无法定论，或者服务问不到 |
| preserve_first | 记录中的工作在任何持久位置都不存在，必须先写下来 |

只有这三种，顺序如上，没有任何论证能加出第四种。如果有人要你丢掉上下文，那这个工具就不对——直接说出来，改用三值答案。

什么算未落地

读取封闭字段集，渲染进状态，并计数。风险区间拿这个计数做比较，所以一个字段如果渲染了却没计数，就等于有工作结论看不见。五个未落地字段全部计数：未落地的待办、已改动未提交的文件、未回答的问题、未记录的决策、下一步。session 和 risk_hints 不是条目，不计数。

| 字段 | 是否计为未落地 | 原因 |
| uncommitted | 是 | 已改动、未提交 |
| todos | 是 | 在会话自己的记录里没标完成 |
| questions | 是 | 问了、没答 |
| decisions | 是 | 做了、没持久记录 |
| next_steps | 是 | 计划了、没落地 |
| risk_hints | 否 | 由上面的计数推导，不是条目 |
| session | 否 | 身份标识，不是工作 |

因此，一个会话如果唯一的未落地工作就是已记录的决策，它不是 safe_to_compact：计数大于零，本地规则要么退到 wait，要么越过 waitMin 直接答 preserve_first。

结构上不存在，而非口头承诺

「我们不会写那个循环」是一句承诺，而上面的测量结果就是只有承诺时的下场。四道闸门，每道都带可执行断言，产物检查会注入每道闸门禁止的东西： G1 — 模型的输入无法指定块。 状态只能来自唯一一个渲染器，字段集是封闭的（session、todos、uncommitted、questions、decisions、next_steps、risk_hints），其中没有任何字段能表达块。judge 只接受通过摘要绑定到其摘要的状态，因此手工拼装的状态会被拒绝，而不是凭它自己声称的内容被接受。

G2 — 三个值加一个刻度。 一个 choice 问题，恰好三个固定选项，再加一个 score。带四个选项的请求会被拒绝；四选项请求会被注入到产物检查中。

G3 — 没有可供选择的槽位。 FORBIDDEN_KEYS 是包含 35 个名称的常量，携带其中任一名称的载荷会抛出异常，而不是被剥离。剥离会返回一个看似合理的判定，同时掩盖上游确实在产生这种禁止形状的事实。拒绝信息会指出路径（$.outer.inner[0].perBlock）并引用测量结果。

G4 — 没有按块划分的 API 表面。 三个工具。没有 screen，没有 filter，没有 pick。

wait 的含义

wait 在三种情况下都是答案，且都不是 bug：

1. 记录在案的未落地数量有歧义——落在 safeMax 与 waitMin 之间的区间内——因此本地规则拒绝作答；
2. 没有配置服务，问题无法提出；
3. 询问了服务，但服务不在。

原因码会说明是哪一种。三种情况下答案都不是许可：这个工具从不把「我无法决定」当作「继续」。本地路径决定两端——没有未落地内容，或超过阈值——并且两端都不消耗请求。

退出码

| 码 | 含义 |
| 0 | 没有 lost 用例被放行 |
| 1 | 有 lost 用例被判定为 safe_to_compact |
| 2 | 状态超出字符预算——这是配置问题，不是判定 |
| 3 | 用法、配置或输入错误 |

服务缺席的运行退出码为 0，每个用例都计为 SKIP。这是有意为之，也是本项目唯一把未运行的检查当作成功的地方：退出码 0 意味着「没有东西被放行」，而未运行的检查没有放行任何东西。SKIP 会单独计数并列出，让这一区别保留到报告里，同时会报告 allSkipped，免得调用方只能自行推断。

verify 双向检查

verify 运行带标签的语料并报告两个比率，因为判定系统可能以两种方式失败，而只有一种是危险的：

* lost 被放行为 safe_to_compact——危险的那种。工作被压缩后消失。退出码 1。
* keep 被拒绝——安全方向，但仍是缺陷。一个永远回答 preserve_first 的工具从不丢失任何东西，也毫无用处，所以过度保守要被计数，而不是被称赞。

单一标签的语料会被拒绝，而不是被打分。 在没有 lost 用例的语料上得出「没有 lost 用例被放行」是真实但无意义的，这比一个红色检查——这正是这个项目整个系列反复踩中的失效模式。

限制：明说，而不是暗示

safe_to_compact 的意思是记录下来的内容没有未落地的。如果会话持有的工作以转录无法捕捉的形式存在，看起来会一模一样，这个工具分辨不出来。这是可观测性的边界，不是对会话的保证。

摘要是一次完整性校验，不是安全控制。谁都能重新算一个。它能防的是意外情况——调用方自己拼装状态，或者旧状态与它的摘要逐渐对不上——并且让绕过变成有意为之，而不是顺手发生。不要把它说成能防住存心绕开它的调用方。

要求

Node ^22.19.0 || >=24.0.0。无运行时依赖。@deepseek-ai/cordis 是可选的对等依赖。

测试

npm test # 43 assertions, no host required
npm run verify:artifacts # what npm publish would actually ship

验证器关注的是缺失，而这是最难查的东西：被移除的关卡，看起来和查完没发现问题的关卡一模一样。所以它把每样违禁内容都注入进去——全部 35 个违禁键、手工拼装的状态、带四个选项的请求、只带单个标签的语料——并要求代码拒绝它们。

许可证

Apache-2.0。