PerryLink / jevcore

# 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.**
---
**📖 Ecosystem knowledge base** — measured data, not marketing: plugin development guide · plugin-selection data · maintenance criteria.
## ⭐ 如果它帮到了你
这个插件是 DSH 插件家族的一员（95 个，全部 Apache-2.0）。如果你在用，**给个 star** —— 它不会解锁任何功能，但会让下一个人在搜索里更容易找到它。
*English:* part of a 95 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 { 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 pl