DeepSeek Harness Plugin Hub

发布与管理完整 Harness Profiles,发现适合你的插件。

探索

插件目录环境预设文档中心动态

社区

发布插件联系我们报告问题

相关链接

Plugin Hub GitHubDeepSeek Harness 官方项目系统状态隐私说明
© 2026 DeepSeek Harness Plugin HubPowered byPaxTech

独立、非官方社区项目,与 DeepSeek 官方无隶属、授权或背书关系。

DeepSeek Harness Plugin Hub
ProfilesPlugins分类动态文档登录管理 Profiles
ProfilesPlugins分类动态文档登录
← Plugins

dsh-context-verdict

Context Verdict

DeepSeek Harness 插件:针对压缩是否会丢失未落地状态,提供一次会话级判定。在结构上无法进行逐块筛查,而此前的衡量方式是错误的。

插件会安装到这里;不确定时保持 web。

npx -y @deepseek-ai/dsh plugin --profile web add github:Phocinae/dsh-context-verdict#657d32adf701906f9820f4ab7116c3469c1678b0
README兼容性版本

兼容性与来源证明

Context Verdict 以 dsh-context-verdict 发布,当前版本为 0.1.2。Plugin Hub 会校验它的 manifest,并保存精确安装来源,便于复现安装结果。

DSH 兼容范围
*
运行环境
any
发布来源
github
Registry 更新时间
2026/11/4

版本

0.1.2stable
2026/10/20
0.1.1stable
2026/10/14
0.1.0stable
2026/10/14

相关插件

正在加载相关插件…

最新版
0.1.2
DSH
*
HMR
重启进程
Tree shaking
未声明可安全裁剪
解包体积
未提供
文件数
未提供
Surface
any
许可证
Apache-2.0
发布源
github
GitHub
★ 0
周下载
272
最近提交
2026/10/20
查看源码 ↗项目主页 ↗
README Badge

点击下方 Badge 复制 Markdown,粘贴到 README 即可。

这是你的 Plugin?认领权益 · 优先安全扫描

验证 package.json 声明的 GitHub 仓库,即可管理这个公开页面。认领后,Hub 会优先安排当前版本的安全扫描,并在通过后公开展示结果。

认领这个 Plugin →
报告问题

相关插件

继续浏览 memory-context 分类下经过校验的插件。

Experimental Session Search@deepseek-ai/dsh-experimental-session-search为 Agents 提供搜索和读取当前工作区早期会话的工具。Hindsight Coding Agents@vectorize-io/hindsight-coding-agents面向编程代理的仅反思式 Hindsight 长期记忆(可插拔支持多种运行框架:opencode、……),自动在后台导入(无需设置 CLI)。Contextdsh-context用于上下文洞察和管理的 DeepSeek Harness 插件,提供上下文仪表板和上下文命令,帮助了解上下文的构成及其演变过程。Memory Plugin@openviking/dsh-memory-plugin适用于 DeepSeek Harness 的 OpenViking 记忆与上下文套件

README

context-verdict

One verdict for a whole session, before it is compacted.

Quick start

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

context_verdict_build / context_verdict_judge is now available; Build a session snapshot, then ask for one verdict on whether compaction would lose unlanded state.

The question, and the question this tool refuses

Is there unlanded state that a compaction would lose?

That is a question about the session, not about any part of it. It has a decidable answer: work either exists somewhere durable or it does not.

This tool cannot tell you which parts of a context are important. That was tried. A per-block screener — "which of these thirty blocks can be dropped?" — was built and measured, and it failed in both directions at once:

what it judgedverdictconfidence
the block containing the actual fixdroppable0.323
a nursery rhymeworth keeping0.691

The most expensive possible error and pure noise, on the same data, in the same run. So the capability is absent by construction rather than by policy — see "Structural, not promised" below.

The three verdicts

verdictmeaning
safe_to_compactnothing recorded is unlanded
waitthe record does not settle it, or the service could not be asked
preserve_firstrecorded work exists nowhere durable and must be written down first

Exactly three, in that order, and there is no argument that adds a fourth. If you are asked to drop context, this is the wrong tool — say so, and use the three-value answer instead.

What counts as unlanded

The closed field set is read, rendered into the state, and counted. The count is what the risk band compares against, so a field that is rendered but not counted would be work the verdict cannot see. All five unlanded fields count: unlanded todos, changed-and-uncommitted files, unanswered questions, unrecorded decisions, and next steps. session and risk_hints are not items and are not counted.

fieldcounted as unlandedwhy
uncommittedyeschanged and not committed
todosyesnot marked done in the session's own record
questionsyesasked and not answered
decisionsyesmade and not recorded durably
next_stepsyesplanned and not landed
risk_hintsnoderived from the counts above, not an item
sessionnoidentity, not work

A session whose only unlanded work is recorded decisions is therefore not safe_to_compact: the count is above zero, so the local rules either decline into wait or, past waitMin, answer preserve_first.

Structural, not promised

"We will not write that loop" is a promise, and the measurement above is what happens when a promise is all you have. Four gates, each with an executable assertion, and the artefact check injects the thing each one forbids:

G1 — the model's input cannot name a block. The state comes from exactly one renderer over a closed field set (session, todos, uncommitted, questions, decisions, next_steps, risk_hints) and no field can express a block. judge accepts only a state bound to its summary by digest, so a hand-assembled state is refused rather than accepted on its word.

G2 — three values plus one scale. One choice question with exactly three fixed options, plus one score. A request with four options is refused; a four-option request is injected in the artefact check.

G3 — no slot for a selection. FORBIDDEN_KEYS is a constant of 35 names, and a payload carrying one throws rather than being stripped. Stripping would return a plausible verdict while hiding that something upstream produces the forbidden shape. The refusal names the path ($.outer.inner[0].perBlock) and cites the measurement.

G4 — no per-block API surface. Three tools. No screen, no filter, no pick.

What wait means

wait is the answer in three situations, and none is a bug:

  1. the recorded unlanded count is ambiguous — inside the band between safeMax and waitMin — so the local rules decline;
  2. no service is configured, so the question cannot be asked;
  3. the service was asked and was not there.

The reason codes say which. In all three the answer is not permission: this tool never treats "I could not decide" as "go ahead". The local path decides the two ends — nothing unlanded, or more than the threshold — and does not spend a request on either.

Exit codes

codemeaning
0no lost case was let through
1a lost case was judged safe_to_compact
2the state exceeded its character budget — a configuration problem, not a verdict
3usage, configuration or input error

A run where the service was absent is exit 0 with every case counted as SKIP. That is deliberate and it is the one place this project treats an unrun check as success: exit 0 means "nothing was let through", and a check that did not run let nothing through. SKIP is counted and listed separately so the distinction survives into the report, and allSkipped is reported so a caller is not left to infer it.

verify checks both directions

verify runs a labelled corpus and reports two rates, because a verdict system can fail in two ways and only one is dangerous:

  • lost let through as safe_to_compact — the dangerous one. Work is compacted and gone. Exit 1.
  • keep refused — the safe direction, and still a defect. A tool that always answers preserve_first never loses anything and is useless, so over-conservatism is counted rather than congratulated.

A single-labelled corpus is refused, not scored. "No lost case was let through" over a corpus with no lost cases is true and meaningless, which is worse than a red check — it is the failure mode this project's whole family keeps hitting.

Limits, stated rather than implied

safe_to_compact means nothing recorded is unlanded. A session holding work in a form the transcript does not capture would look identical, and this tool cannot tell the difference. That is a limit of what is observable, not a guarantee about the session.

The digest is an integrity check, not a security control. Anyone can recompute one. What it prevents is the accidental case — a caller assembling their own state, or an old state drifting from its summary — and it makes a bypass deliberate rather than incidental. Do not describe it as a defence against a caller who wants around it.

Requirements

Node ^22.19.0 || >=24.0.0. No runtime dependencies. @deepseek-ai/cordis is an optional peer.

Testing

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

The verifier is about absence, which is the hardest thing to check: a gate that has been removed looks exactly like a gate that found nothing wrong. So it injects each forbidden thing — all 35 forbidden keys, a hand-assembled state, a four-option request, a single-labelled corpus — and requires the code to refuse it.

License

Apache-2.0.