jevcore

TypeSafe Jev for DeepSeek Harness and any other MCP host.

Jev is not a chat model. It answers typed questions — noul (yes/no), choice, score — and returns calibrated probabilities. It does not write prose, and asking it to is a category error. This project gives an agent exactly that surface, and nothing more.

Offline by default. Egress disclosed. Nothing default-on.

---

⭐ 如果它帮到了你

这个插件是 DSH 插件家族的一员（40+ 个，全部 Apache-2.0）。如果你在用，给个 star —— 它不会解锁任何功能，但会让下一个人在搜索里更容易找到它。

English: part of a 40+ plugin family for DeepSeek Harness. If it is useful, a star helps the next person find it — nothing is gated behind it.

Three packages, one decision layer

Package	What it is	Use it when
jevcore	The decisions. Imports nothing from DeepSeek Harness or Cordis.	You want Jev in a plain script, a service, or your own harness
jevcore-dsh	The DSH plugin: one service, three tools, two opt-in gates	You are running DeepSeek Harness
jevcore-mcp	The same three tools over MCP, with a stdio binary	Your host speaks MCP but is not DSH

The adapters are thin on purpose. packages/dsh is four files: it declares tool schemas and translates hook payloads. Everything decision-shaped — the primitives, the providers, the egress contract, the policy, the gates — lives in core, so a new adapter cannot drift from the guarantees the others make. One runtime requirement differs across the three: jevcore-dsh tracks the harness and needs Node ^22.19.0 || >=24.0.0, while jevcore and jevcore-mcp need >=20.

---

Why this exists

Between 2026-09-17 and 09-20, nineteen plugins appeared that wire Jev into DSH. Auditing their source found a consistent pattern: the module labelled guard, gate, or warden was also the module shipping prompts, tool arguments, and file contents to a third party, and the README generally did not say so. Several were enabled by default. One gate could be reconfigured by the model it was guarding.

This project is the same idea with those failure modes designed out:

Property	How it is guaranteed here
No network call unless you ask for one	Default provider is an offline mock; the live path needs both provider: live and a resolved credential
Every transmission named before it happens	One startup log line per feature: off or SENDS <feature> { fields }
Gates register nothing when disabled	Verified by test, not by policy — a disabled gate adds no event listener at all
The model cannot widen its own constraints	No tool exposes gate configuration
A judge that cannot answer never means "allow"	Undecided resolves through explicit config, defaulting to ask

---

The egress contract

This is the part worth reading before installing.

Transmission is decided per feature, and every feature defaults to off. The plugin prints its own contract at load:

[jevcore] provider=mock  endpoint=none  egress=OFF  (no network calls will be made; every answer is synthetic)
[jevcore] ready - provider=mock - gates: safety=off context=off

With provider: live and every feature enabled, the same report becomes explicit about what leaves:

…