JeVerifier

Keeps a codebase maintainable and its docs consistent while Claude works on it. JeVerifier puts Jev (TypeSafe's fast classifier) beside a Claude coding session to run checks nobody would pay a frontier model to run on every change:

• Code rule checks (wiki lint): every function against the project's own architectural rules, with their documented exceptions.
• Doc consistency checks (wiki check): statements that contradict each other across the docs, including a milestone plan before it is implemented.
• Context retrieval (ctx find, ctx digest): reading lists for a task, and session digests for handover.

After one full review, every re-check looks only at what changed, and each verdict is recorded so it is not paid for twice. Jev only selects, ranks and labels; it never writes code or summaries, so it can miss something but cannot invent anything, and Claude judges everything it flags.

What it catches, and what it saves

Measured on one game project (about 170k tokens of design docs, 1,400 GDScript functions):

• Code rules: each rule caught 19–20 of 20 planted violations and flagged none of 40 clean functions. A full run over 1,410 functions is about $0.03 at TypeSafe's list price, and a re-run costs nothing for unchanged code.
• Docs: the first review found 10 stale statements; a milestone plan's review found 4 real errors before implementation, one of which no reviewer would likely have found.
• Token savings are modest. Jev replaces judgments and lookups, not code generation, so expect around 10% at most from Jev alone. In the first milestone measured, reading lists did not reduce what agents read, and all doc reading is 6–12% of the token bill.
• Logic bugs: not caught. Replayed on real bugs a review later confirmed, the code rule check flagged none of the buggy functions, even with the rule reworded after the fact. It checks one function at a time, and such bugs often span two (a preview branch and a commit branch). It keeps code consistent with its rules; it does not replace review.

Numbers and method: Measurements, Token savings.

Setup

Linux and macOS:

python3 -m venv .venv && .venv/bin/pip install -e ".[dev]"
source .venv/bin/activate   # puts `jeverifier` on PATH

On Debian and Ubuntu, the system Python needs sudo apt install python3-venv first, and python3-tk if you want the keys window.

Windows (PowerShell):

python -m venv .venv; .venv\Scripts\pip install -e ".[dev]"
.venv\Scripts\Activate.ps1

Jev provider

You need a key for one of these:

• TypeSafe (TYPESAFE_API_KEY): Jev's maker. This is the default whenever the key is stored, and the model is pinned to jev-1.13.0.
• OpenJEV (OPENJEV_API_KEY): a third-party public gateway to Jev (openjev.sh), paid for by fees from its $JEV token. It's used when no TypeSafe key is stored. It only offers the model alias openjev, so the underlying Jev version can change without notice.

To force one, set JEVERIFIER_JEV_PROVIDER=typesafe or openjev.

OpenJEV allows 10 requests per second per account, shared by all your keys; going over it can lock the account out for a while (reported as 503 "Authentication is temporarily unavailable"). JeVerifier sends at most 5 requests per second per process, retries included, so two runs at once stay under the limit; set JEVERIFIER_RPS to change that.

API keys (no env-var editing)

jeverifier keys gui opens a window for pasting keys; "Add a key" stores a key for any other service under an env-var-style name. Keys go in the OS credential vault (Windows Credential Manager, the macOS Keychain, or GNOME Keyring / KWallet on Linux) and are loaded into the environment of every jeverifier run:

jeverifier keys set OPENJEV_API_KEY --clipboard   # copy the key first; the clipboard is cleared afterwards
jeverifier keys set TYPESAFE_API_KEY              # or paste at a hidden prompt
jeverifier keys list                              # masked
jeverifier keys import-env                        # move keys that are already env vars into the vault

The environment wins over the vault; on Windows, user environment variables saved in the registry are checked too, so a variable set after the terminal opened still works. No vault, as on a headless server or in CI? Skip the keys commands and export the variables instead (export OPENJEV_API_KEY=...).

From Claude Code

Register the MCP server so a session can ask for a reading list itself (the context_find tool):

claude mcp add jeverifier --scope user -- <checkout>/.venv/bin/python -m jeverifier.mcp_server          # Linux, macOS
claude mcp add jeverifier --scope user -- <checkout>\.venv\Scripts\python.exe -m jeverifier.mcp_server  # Windows

The workflow

Docs stay consistent. One full review, then only what changed:

jeverifier wiki check <repo>                 # first run: Jev-ranked contradiction pairs; later runs: only pairs touching edits
jeverifier wiki verdict <repo> <id> false-alarm   # a false alarm stays silent until either statement changes
jeverifier wiki accept <repo>                # record the reviewed state; later checks are deltas (--deep for the full list)
jeverifier wiki selftest <repo>              # plant contradictions in a scratch copy and measure recall

Code keeps its rules. Rules a parser can't check live in docs/wiki/checks/lint.json with their documented exceptions; unchanged functions are answered from the cache:

jeverifier wiki lint <repo>

Context: a reading list for the task.

jeverifier ctx find <repo> "<task>"          # doc sections the task needs, within a token budget (default 25k)
jeverifier ctx find <repo> "<task>" --code "scripts/**/*.gd"   # ...and the code APIs it touches
jeverifier ctx index <repo>                  # every doc section with its size

Handover: a digest, not the transcript.

jeverifier ctx digest <session|latest> --since 2026-09-20 --handover <repo>/docs/HANDOVER.md
jeverifier wiki log <repo> latest --since <date>     # the digest as a dated session log in the repo's wiki

The wiki itself: jeverifier wiki init <repo> sets up docs/wiki/ (conventions, style guide, seven maintenance protocols, home page, overview, doc map, session logs); wiki map regenerates the doc map, wiki coverage finds orphan pages and broken links, and wiki publish mirrors an allowlisted part of a private repo to a public one.

Paid runs stop before they would pass --max-cost (default $1). How each part works, and what it measured: How it works, Measurements.

Tests

.venv/bin/python -m pytest -q        # Windows: .venv\Scripts\python -m pytest -q

The tests run offline and need no keys: the real TypeSafe SDK talks to a mock transport. CI runs them on Ubuntu (Python 3.12 and 3.14) and Windows.

Known limits

• ctx find --code lists code APIs for GDScript only; without it, a task that pins an API still needs a code read.
• Code rule checks extract GDScript functions only; other languages are added when a project needs them.
• Recall figures come from one project; run jeverifier wiki selftest on yours before relying on them.
• Checks judge one function or one pair of statements at a time, so a defect that only shows across two functions is invisible to them.
• Jev 1.13 is weak at arithmetic, dates and counting (see the TypeSafe "jaggedness" page), so numbers are compared in code and Jev only judges whether two statements are about the same thing.