jev
Jev is TypeSafe's decision model: it picks one option from a list and says how sure it is.
With the Claude Code plugin, ship-check can ask it three things about a review's findings:
- harm: does this finding do real harm (money, data, a side effect done twice or sent
wrong, security, legal, a crash, stuck work, or the change not doing its job)? Jev can
make a finding real harm. It can never clear one the review named, and an answer below
its confidence floor, or any failure, leaves the call to the rules.
- priority: for the list of smaller findings, which to recommend fixing now.
- proof: for a small fix the user picked, the least proof it needs (the repo's checks
only, a unit test, a test against the real database or service, or a browser test). A
real-harm fix always gets the full proof.
Without the judge, the rules make each call as written. Nothing here is needed to use
first-pass.
What leaves the machine
For each finding asked about: its scenario, its worst case, who meets it and, for proof,
the fix in one line, after secrets, emails and phone numbers are blanked. They go to
TypeSafe's API (https://api.typesafe.ai/v1/systemone) with the key. TypeSafe charges per
word sent; check the current price on its models page (https://docs.typesafe.ai/models)
before telling the user a number. Its data terms: https://docs.typesafe.ai/legal.
1. Where it stands
For the current folder, and for one repo of each group the user keeps apart (two companies
with separate accounts):
node "${CLAUDE_SKILL_DIR}/../../scripts/cli.mjs" jev status <repo>
It prints on or off, why, where the key comes from (a variable name and a file, never the
key) and the config file's path.
2. What the user wants
From what they typed (nothing: show the status and ask; "off" or "on": do that), or ask in
one message:
- Do they have a Jev API key? If not, say where one comes from (TypeSafe's console,
https://console.typesafe.ai/keys) and stop.
- Where is it set? The name of the variable that holds it, and whether it is in the
environment or in an env file (the file's path; it must be one git ignores). Never ask for
the key itself; if one is pasted, don't repeat it, and say it should be rotated.
- For which repos? One key for everything, or a key per group of repos when they belong
to separate accounts (then every group is named, and a repo no entry names has the judge
off).
3. Write the config
The config file is the path jev status printed (first-pass/jev.json in the Claude Code
config folder, ~/.claude unless CLAUDE_CONFIG_DIR says otherwise). Read it first if it
exists and change only what the user asked:
One key for everything:
{ "keys": [{ "env": "TYPESAFE_API_KEY" }] }
A key per account:
{
"keys": [
{ "env": "COMPANY_A_TYPESAFE_API_KEY", "file": "/abs/path/company-a/.env.local", "repos": ["/abs/path/company-a", "/abs/path/company-a-site"] },
{ "env": "COMPANY_B_TYPESAFE_API_KEY", "repos": ["/abs/path/company-b"] }
]
}
env: the variable's name. It is read from the environment first, then from file.file: optional, an env file holding NAME=value.repos: absolute paths. The deepest one that holds the folder wins, and a checkout of a
named repo elsewhere (a worktree, a clean checkout in the temp folder) counts as that repo,
even inside a folder named for another key. An entry without repos covers every folder,
and is allowed only as the only entry: with separate accounts, a folder no entry names has
the judge off, never another account's key.- With separate accounts, name each repo's own folder. Never name a folder that also holds
another account's repos (the main folder above them all, say): a named folder covers every
folder inside it, new repos included, so a repo cloned there later would get that key.
"off": true switches the judge off everywhere and keeps the rest. "model" pins a
version (default jev-latest); pin one when you have tuned against it."url": only to send somewhere other than TypeSafe's endpoint (https, or this machine for
a test server); jev status then shows it. Leave it out otherwise, and remove one the user
did not ask for.- Before writing a
file path, check git ignores it: git -C <its repo> check-ignore -q <file>. If it is not ignored, say so and don't use it.
4. Check it works
Run jev status <repo> again for each group, then once per key:
node "${CLAUDE_SKILL_DIR}/../../scripts/cli.mjs" jev test <repo>
It sends one made-up finding (no code, no customer data) and prints Jev's pick and how sure
it was. A refused key or no answer prints why.
5. Report
Jev judge: <on for <repos> (key from <NAME>, in the environment | in <file>) | off, <why>>, one line per key
Verified: jev test → <Jev's pick and confidence, or the error>, one line per key
Config: <the file, and what changed>