specpi 0.27.0 → 0.29.0

package/CHANGELOG.md

@@ -1,5 +1,55 @@
 # Changelog
 
+## 0.29.0 - 2026-09-20
+
+- Return the command guard to `specpi-jev-guard`, and leave it there. 0.28.0 built the guard into the layer as its eighth system, for three stated reasons that were properties of the package as it stood: a global configuration file with no session scope, a key read from the environment only, and a fail-closed posture. Two of the three are fixed upstream. Guard 0.3.0 ships `/jev-guard setup | on | off [--global] | check | model | backend`, so it has a session scope and a switch of its own, and it resolves Pi's saved login before the environment, so `/login openrouter` serves it exactly as it serves the advisor. What remains is fail-closed, which is a disclosed trade rather than a defect. `extensions/jev-advisor/risk.mjs` and `questions/guard.mjs` are gone, the package is pinned again, and the base is eight.
+- Keep the guard out of the Jev layer entirely, rather than half in it. There is no `/jev guard` command, no `systems.guard`, no `guard` pair in the layer's settings, no guard row in the Chat panel and no guard line in `/jev status`; the advisor imports nothing from it, and a test walks `extensions/jev-advisor/` to keep it that way. Two switches over one gate is what made the package's own shape a problem the first time, and adding a second one back would have reintroduced it with the roles swapped. The package owns its switch; SpecPi owns whether the package is installed and that it arrives off.
+- Move the seam to `scripts/jev-guard.mjs`, because it is an installer concern and nothing else. It was a managed resource copied into every agent directory, where after this change nothing would have loaded it. The managed set drops from 34 files to 33, and the seam ships with the CLI instead.
+- Write the inert posture at install and update, and nowhere else. The old seam re-asserted it at every session start, which is what made a `--global` save through the package's own command fail to survive a restart; it does not run at session time now, so the package's switch stays the package's between installer runs. The install-time write is still unconditional, because an install carrying a stale `enabled: true` from before the package was last unpinned would otherwise arm a fail-closed gate the moment it came back. That is the one case where establishing the default takes something away, so the run reports it by name and says which command restores it.
+- Drop both older guard keys in schema 4 rather than migrating either. Schema 2 kept `guard: { enabled, startup }` and schema 3 kept `systems.guard`; neither was ever the authority over whether the guard runs, so keeping a copy could only produce a second answer that disagreed with the package's own file. Nothing about anyone's guard changes: a schema-2 preference had already been written through to that file by the last session that read it, and schema 3 shipped with the package unpinned.
+- Drop the package-retirement machinery with the package it existed for. `retiredPackages`, `removeRetiredPackages` and `retireBasePackages` unpinned `specpi-jev-guard` by name on every install and update, including under `--skip-package-install`, and `specpi doctor` failed on an entry that was still configured. With the package pinned again all three would strip the entry SpecPi itself writes, so they are gone rather than filtered. The transaction's watched set returns to its narrower condition, which is correct again now that nothing writes settings outside it.
+- Pin the command guard at 0.4.0 and show its counter in SpecPi Chat. The package publishes one status line per session under the key `jev-guard` -- classifier calls, blocked calls once there are any, and the last verdict -- and Chat already stored it, as a raw key/value row inside the collapsed generic runtime list behind up to twenty-four other widgets. It is a first-class readout now: a chip in the session footer beside the token and cache counts, showing the leading count, turning amber once something has been blocked, with the package's whole line in the tooltip. The key joins the reserved set so a busy session cannot crowd it out. Chat renders the string and does nothing else with it -- no recount from the session records, no reformatting, and no control, because the guard is configured in Pi and not here. The chip is absent exactly when the guard is not gating, since the package clears its own line when it is switched off or its audit display is.
+- Leave `auditDisplay` to the package. It defaults to `status`, which is what publishes the counter, and asserting it in the install-time seam would take a display preference away from the user to guarantee a readout in one frontend.
+- Raise the session call ceiling from 512 to 2048, and the per-system ceilings with it. 512 was sized the way 120 was before it -- against sessions shorter than the ones the layer now runs in. The long-session evals are what showed it: a session long enough to compact several times spends in the hundreds, so a backstop meant to be reachable only by a loop had drifted close enough to real use to stop a session that was working correctly. The per-system numbers move too, because the total is only a constraint while the per-system ceilings can add up past it: 2048 against a sum of 2322, scaled from the same firing frequencies rather than re-derived. `capability` stays at 2, alone, because it is bounded by construction rather than by frequency -- it asks once a session and then never again. A test pins the inequality rather than the literals, so the next change to either number has to consider the other. The whole ceiling is about six cents and two megabytes of digest.
+- Take the guard out of the eval row it was never going to measure. `eval-harnesses.mjs` asked for `guard: true` and verified the advisor read it back, which now throws rather than silently measuring less than it asked for — the check working as designed. The disposable homes do not install the package, so the row does not claim it. The tier-6 and Terminal-Bench tables keep their recorded guard rows, labelled as the native guard they measured, because deleting a measurement is not the same as correcting one.
+
+## 0.28.0 - 2026-09-18
+
+- Read the key Pi already has. The layer resolved its credential from `OPENROUTER_API_KEY` and nothing else, while Pi had long since stored an OpenRouter key where it stores every provider credential — the `openrouter` entry that `/login openrouter` writes to `auth.json`. So a person who had logged in, whose every model call was working, was told `key: missing` by the one component that had opted out of Pi's credential store, and there was no interface anywhere that would have explained the gap. The advisor now follows Pi's own documented resolution order, the store first and then the environment, which is what makes `/login openrouter` the answer to "how do I configure the API key" rather than a second thing to set up. `/jev status` lists every source and marks the one in force, because "missing" with nothing to act on is what sent people looking for a key field that does not exist.
+- Make turning the layer on turn the layer on. `/jev on` set the master switch and left all seven systems off, so the layer ran and did nothing; the notification said so and then asked for seven more commands. Enabling it now enables every system that is off, and only when none are on, so a deliberate subset survives being toggled. The command guard is one of the eight and comes on with them, and because it is the only system that can refuse a tool call, the notification now says so in as many words rather than listing it among seven that only ever add advice.
+- Remember the switch. `/jev on` changed one session and wrote nothing, so the layer had to be re-enabled from scratch every time Pi started — the startup preference was a separate command most people never found. Turning the layer on or off now writes the preference, with `--session` for the one-off case that must not change tomorrow.
+- Stop storing one intention as two switches that can cancel each other. `master` and `startup` are both written whenever either changes, because the advisor only acts when both are true: a file saying `master: true, startup: false` describes a layer that is on and never runs, which is exactly the state the Chat panel's two independent checkboxes made it easy to save.
+- Drop the `specpi-jev-guard` package and build the command guard into the layer natively, as its eighth system. Four review rounds kept returning to the same handful of causes, and all of them were properties of that package rather than of the feature: its configuration was one global file with no session scope, so there was no such thing as enabling it for a session and `--session` could not scope it; it read its key from the environment only, so the credential `/login openrouter` had already stored was invisible to it; and it was fail-closed, so a missing or stale key turned every shell call in the session into a refusal. As `systems.guard` it is gated, budgeted, reported and toggled by exactly the same code as the other seven — `/jev enable guard`, one key, one budget, one switch — and the separate `guard: { enabled, startup }` pair is gone with the persistence disagreements it caused. Schema 3 migrates `guard.startup` into `systems.guard`, and the base drops from eight pinned packages to seven. An install that already has the package is unpinned on update, by name and only when the entry is the one SpecPi wrote, because dropping a line from the template would otherwise leave a fail-closed gate running on every machine that already had it with the command to disarm it deleted. `specpi doctor` reports a retired entry that is still configured. Its downloaded files stay where Pi put them; Pi stops loading it.
+- Invert the failure posture. The native guard **fails open**: no key, no budget, a timeout, an unconfident answer or a middle-band verdict with nobody to ask all hand the call to `@gotgenes/pi-permission-system`, which decides it exactly as it did before the layer existed. That is not a weakening — the guard sits in front of the permission system, so fail-closed meant an outage stopped work while fail-open returns policy to the component that owned it anyway. It is also the rule the rest of the extension already followed.
+- Hold the local allowlist to one rule: a binary is admitted only if it is simple whatever flags it is given. `rg --pre` runs an arbitrary preprocessor, `date -s` sets the clock, `hostname` with an argument sets the hostname, `file -C` writes a compiled magic file — none reads as dangerous, all four were admitted, and each was a general bypass. The list is a *budget* mechanism rather than a safety one, which is the thing that had gone unsaid: the guard has 208 calls, so a fast path exists to stop a session of `ls` and `grep` spending them all and leaving nothing for the calls that matter. That makes the admission test "would asking about this spend the budget without learning anything", and under it a rare binary is never worth a silent hole. Jev is the analyser; anything that merely looks simple belongs to it.
+- Say why the two local lists are maintained under opposite pressures, in the file itself. A wrong `safe` is a silent permanent hole, because it is the one verdict with no second reader; a wrong `unknown` costs one call out of 208 and Jev decides; a wrong `dangerous` blocks real work with no recourse but switching the guard off. Six review rounds treated both lists as one thing called "the guard" and hardened them the same way, which is backwards.
+- Stop writing fixture credentials in real vendor shapes. Every "secret" in the suite was a fixture and always had been, but they were spelled like genuine OpenRouter and Anthropic keys, so GitGuardian failed the pull request on them — the scanner working exactly as intended and the fixtures being wrong. They are named for what they are now, and a test refuses any tracked file containing a vendor prefix followed by a plausible key body, because a scanner that cries wolf on your own test data is one people learn to click past.
+- Close the ways round the guard that its own first implementation left open. A read-only binary was judged by its name and never its arguments, so `cat ~/.ssh/id_rsa` and `grep -r . ~/.aws/credentials` took the free path — leaving the exfiltration half of the question the guard asks unreachable for the commands that answer it; `printenv` was on the same list for the same reason and is not any more. `env`, `find`, `fd`, `sort` and `uniq` sat there too, each one a general bypass: `env rm -rf build` begins with a binary that changes nothing. The catastrophic delete rule anchored on the end of the line, so it matched `rm -rf /`, which GNU `rm` refuses on its own, and missed `rm -rf / --no-preserve-root`, which does not. And a shell tool's text was read from `input.command` alone, so `write_stdin` — which types into a live shell — was classified as the empty string and spent a budgeted call asking about nothing.
+- Stop two failures from turning into consent. `ctx.ui.notify` reaches the host over RPC and can throw; called inline inside the guard's fail-open catch, one failed notification unwound a decided refusal into an allow. And a `ctx.ui.select` that rejected — a host without the method, a disconnect, a cancel that throws rather than resolving — was swallowed by the same catch and read as approval, on the single path in the feature where a human was asked directly. The announcement can no longer change a decision, and a question that could not be put is a refusal. Which answer counts as consent is now one exported function with a test, rather than a string comparison inside a closure nothing imports.
+- Say that the guard can refuse a command on every path that arms it, not only on `/jev on`. `/jev enable guard` and `/jev startup on` armed the same system in silence, so the first thing either taught you was a blocked call — the outcome the rule exists to prevent.
+- Give the command guard the history it is documented to weigh. `recent` was appended to in exactly one place, inside retention's success path, so a session running the guard with retention off evaluated the intent half of the block rule against an empty history for its whole length. Every tool result is recorded now; retention refines its own entry rather than adding a second.
+- Cache an unparseable `auth.json` as firmly as a parseable one. Recording only successful parses left the worst case uncached: a truncated store threw on every call, so every request paid a fresh stat, a 256 KiB read and a failing parse inside the same latency budget the cache was added to protect, forever.
+- Unpin a retired package whatever shape its entry has, and keep that write inside the installer's transaction. Preserving a user-modified `specpi-jev-guard` entry preserved the fail-closed gate this release deleted the controls for — the deliberate exception to "a modified entry is yours", and the only one. The write also ran outside the watched set on the `--skip-package-install` path, so it was neither backed up nor rolled back when a later step in the same run failed.
+- Stop the Chat panel re-arming eight systems when someone turns the last one off. `couple` read that as the broken dead-layer file it repairs and ticked every box back on, the blocking command guard included, with a note describing a file that never existed — while `/jev disable` read the identical situation as "switch the layer off". The panel now does the same, and still repairs a file that genuinely arrives dead.
+- Give the guard its own gate thresholds. It asked under the name `gap`, which `thresholdsFor` resolves identically by falling through its default — so adding a `guard` entry, the natural change for the one system whose action takes a tool call away, would have changed nothing at all and said nothing about it.
+- Stop `/jev off` reading Pi's credential store to discard the answer, and stop `applyLayer` accepting two arguments it never looked at.
+- Settle most calls locally, for nothing. Read-only commands and ordinary project writes never leave the machine, and a deliberately tiny list of catastrophic, unambiguous commands is blocked with no call at all. A `ls` costs nothing; a command carrying any shell control character never takes the fast path, because `ls; rm -rf ~` begins with `ls`. Blocking on a Jev verdict needs two answers to agree — a confident destructive reading *and* a confident reading that the request does not account for the call — because the likeliest way to be wrong is a destructive-looking command the person asked for in as many words. Both answers must survive the confidence gate: reading a missing intent answer as agreement would have made the safeguard apply to about one call in five, since roughly four Score answers in five do not gate. The shell tools are gated under every alias the harness maps onto `bash`, the write tools under every name `multi_edit`, `apply_patch`, `create_file` and `str_replace` arrive as, and a write whose target cannot be read is asked about rather than waved through. When the guard asks a human, only the affirmative runs the call; dismissing the dialog is not consent.
+- Make Chat and the advisor agree about a symlinked `auth.json`. One reader was fixed to follow links and the other was not, so `/jev status` reported "in use from auth.json" beside a panel reporting "No key anywhere" — the drift the pin test exists to catch, which it missed because it never created a link. It does now.
+- Merge `/jev enable` and `/jev disable` into the stored systems rather than overwriting them with the session's copy, which silently turned off systems enabled on disk since the session started. Disabling the last system now switches the layer off and says so, instead of writing the dead-layer state that four other code paths exist to prevent.
+- Cache the parsed credential store against the file's size and modification time. `ask()` resolves a key per request and retention fires on every large tool result, so the store was being stat'd, read and parsed inside a 1500 ms latency budget on the tool path, where it used to be one environment lookup.
+- Move `/jev on` and `/jev off` out of `index.ts` and into a module a test can call. Nothing imported that file, so the ~200 lines that are this feature were covered by prose alone while the suite reported green — which is how two review rounds found, among other things, a stored preference destroyed by a command that had decided nothing about it, a notification reporting a gate "left off" while it was on and blocking every call, and a rollback that never ran because the flag was set before the write. `layer.mjs` takes its world as an argument and holds no state, so what `/jev on` means is now something a test can call rather than something the prose asserts.
+- Bind the backend in `keyPresent`, `keySource`, `keySources` and `keyEnvName`, not just `apiKey`. All five were re-exported with a `"openrouter"` parameter default, so `keyPresent()` reported a key on the direct TypeSafe route that `resolveKey()` would never return. `backend()` moved into `key-source.mjs` so each one binds it rather than defaulting to a literal.
+- Read a symlinked `auth.json`. Refusing links recreated the exact divergence this layer was written to remove: a dotfile manager links the file, Pi resolves the credential, every model call works, and this layer alone reports "key: none found". Links are refused where SpecPi *writes*; this is a bounded read of a file Pi owns.
+- Stop the Chat panel throwing while opening the very file it exists to repair. A layer on with no systems was a validation error, so the panel rendered red with Save disabled before anything was touched, and the one mechanism that could fix it skipped the case. The rule now lives where the write happens: the form repairs and announces it, and the host refuses it on save.
+- Persist `/jev enable` and `/jev disable`. They announced a session-scoped change that a later `/jev on` copied to disk anyway, so a choice described as temporary became permanent through an unrelated command.
+- Write both halves of the startup preference in `/jev startup`, which had been the one command still writing `startup` without `master` — the exact two-keys-for-one-intention trap this release removes, left in the command named after it, while its own notification claimed new sessions would start on. It also fills in the systems when none are chosen, for the same reason `/jev on` does.
+- Bind `apiKey()` to the active backend again. Re-exporting the resolver under that name rebound every no-arg caller — the calibration and triage scripts among them — to the OpenRouter default, so with `JEV_BACKEND=typesafe` a script's `if (!apiKey())` guard passed on a stored OpenRouter key while every request underneath it returned `no-key`.
+- Keep measured runs off a personal account. With the credential store consulted first, `scripts/jev-calibrate.mjs` and `scripts/jev-triage.mjs` would have billed a developer's own `/login openrouter` credential rather than the key in `evals/.env`, and `--probe` would have verified a key the run did not use. Both now set `JEV_KEY_SOURCE=environment`, which restricts resolution to the environment.
+- Refuse a layer that is switched on with nothing to run. The Chat panel filled in the systems in its form, but the full-configuration textarea bypassed that, so the dead-layer state this release exists to remove stayed one hand-edit from disk. It is refused rather than silently corrected.
+- Report the key from one place in the Chat panel. `saveJev` resolved `auth.json` from a different agent directory than `loadJev`, so with a workspace-relative `PI_CODING_AGENT_DIR` pressing Save flipped a working panel to "No key anywhere"; and the report named the credential store even on the direct TypeSafe API, which has no entry there. Both now follow the advisor's own conditions.
+- Stop the advisor's tests from writing to the real agent directory, which they had been doing for as long as any of them were async. `withAgentDir` wrapped its callback in `try/finally` around a bare `return run(dir)`, and an async callback returns its promise at the first `await` — so the cleanup ran there, restoring `PI_CODING_AGENT_DIR`, `HOME` and `USERPROFILE` to the developer's real values and deleting the temporary directory while the test body was still going. Nineteen tests in that file pass an async callback, so most of the suite was isolated only up to its first suspension point. It destroyed a real credential store before it was found: a fixture `auth.json` written after an `await` landed in a developer's own `~/.pi/agent`, and because Pi's `AuthStorage` merges onto whatever it reads, one write replaced three logged-in providers with the single fake entry the fixture held. The suite reported every test passing while doing it, which is what kept it invisible. Cleanup now waits for a returned promise, and the fixture writer refuses any path outside the temporary directory: OAuth tokens cannot be recovered, so a failed test is the only acceptable cost of that check.
+- Isolate the key variables in the advisor's tests. `withAgentDir` restored `OPENROUTER_API_KEY` afterwards but never cleared it for the body of a test, so "a missing key reads as unavailable" passed or failed depending on the shell the suite was started from.
+
 ## 0.27.0 - 2026-09-18
 
 - Put a measured number on the rule the whole layer is built around. "Any tool-set decision happens once, before the first request, or not at all" rested on a cache argument that was reasoned about here for months and never weighed. Three arms on `t3-cascade-ledger` differing only in when Browser QA's fourteen tools reach the request settle it: flipping them on at turn 6 collapsed cached tokens to 3,200 at the very next request in three attempts out of three — from 25,984, 17,792 and 21,120 — while the prompt kept climbing, one request going from 3,673 fresh tokens to 31,337. The re-warm cost 14.6%, 21.6% and 23.9% of the attempt, against a 10% threshold written down before the run. Arming the same group from turn 1 cost 16% more than never arming it, against 47% for flipping mid-session, so paying up front is about three times cheaper than paying when the need appears. Recorded to `evals/runs/cache-probe/`; `scripts/cache-probe.mjs` reproduces the analysis.

package/NPM_RELEASE.md

@@ -6,7 +6,7 @@ Publishing, tags, deprecation, ownership changes and GitHub Releases require exp
 
 ## Prepare
 
-1. This candidate is SpecPi **0.23.0**, paired with the unchanged Chat **0.8.1** VSIX. Browser QA **0.1.0** is already independently published; do not republish or edit its source as part of this release. Choose an unused version; update `package.json`, the dated `CHANGELOG.md` entry, README, and the website. Check Chat's version and VSIX download links. Preserve historical changelog entries.
+1. This candidate is SpecPi **0.29.0**, paired with the Chat **0.14.0** VSIX. Browser QA **0.3.0** is already independently published; do not republish or edit its source as part of this release. Choose an unused version; update `package.json`, the dated `CHANGELOG.md` entry, README, and the website. Check Chat's version and VSIX download links. Preserve historical changelog entries.
 2. Validate:
 
     ```sh

package/README.md

@@ -44,7 +44,7 @@ Everything it touches is written down, versioned, and easy to undo.
 
 ## Measured context
 
-This chart shows first-call context from a clean install: all seven pinned packages, the working agreement, and the skills Pi finds. It predates `specpi-jev-guard`, the eighth pin, and has not been re-measured since. "Enabled" means browser QA, delegation, and web access are switched on, with no goal, scope, or improvement selection active.
+This chart shows first-call context from a clean install: all eight pinned packages, the working agreement, and the skills Pi finds. It has not been re-measured since the command guard returned to a pinned package rather than a native system. "Enabled" means browser QA, delegation, and web access are switched on, with no goal, scope, or improvement selection active.
 
 The solid rows are measured by us, from the request each setup actually sends through one local test provider. That includes OpenCode, the DeepSeek Harness, and Oh My Pi, all measured as installed. The faded Codex CLI and Claude Code rows come from HarnessTax's published numbers, measured under their own setup. Treat those as a rough reference, not a head-to-head test. These are character counts. They say nothing about tokens, cost, or how well each tool does the job. The research page [breaks down the enabled setup by feature](https://tannermidd.github.io/SpecPi/research/#specpi), so you can see what each switch costs on its own.
 
@@ -123,7 +123,7 @@ Full setup options, package details, and requirements: [website](https://tannerm
 
 | | |
 | --- | --- |
-| [Packages](https://tannermidd.github.io/SpecPi/#packages) | The eight pinned packages and what each provides |
+| [Packages](https://tannermidd.github.io/SpecPi/#packages) | The seven pinned packages and what each provides |
 | [Scope control](https://tannermidd.github.io/SpecPi/wiki/#scope) | `/scope` commands and drift monitoring |
 | [Improvement loop](https://tannermidd.github.io/SpecPi/#loop) | Local wishlist, `/harness-improvement`, and retirement with evidence |
 | [SpecPi Chat](https://tannermidd.github.io/SpecPi/#vscode-chat) | VS Code frontend and VSIX install · [Chat guide](https://github.com/TannerMidd/SpecPi/blob/main/vscode/README.md) |

package/SECURITY_MODEL.md

@@ -34,19 +34,27 @@ Two of the seven systems do something the other five do not, and both are off by
 
 **System 5, progress detection**, is the only one that can change what the model does. On a confident verdict that a session has stopped making progress it adds one fixed, code-written line at a turn boundary. It ships set to `notify`, which tells the person and cannot change the session; `message`, which appends the line for the model to read, is a deliberate opt-in. It is written once per session and never retracted, it never aborts or blocks, and it is suppressed entirely when the same call reports that a person would have to answer something first. Nothing the model produced ever enters the transcript: the line is chosen from a fixed table by failure mode.
 
+The command guard is **not** part of this layer. It is a separate pinned package with its own gate, its own configuration file, its own commands and a fail-closed posture, and it has its own section below. It is named here because a reader who took "the advisor holds no authority" to cover everything SpecPi installs would be wrong about exactly one component. No switch in SpecPi turns it on: `/jev` does not mention it, the advisor imports nothing from it, and the only thing SpecPi ever writes to its configuration is the off side of it, at install time.
+
 **System 7, untrusted-content classification**, prepends a fixed warning line to externally fetched content that confidently reads as instructions addressed to an agent. It applies only to web and browser tool results, never to the agent's own shell output or file reads. It is defence in depth and explicitly not a control: it never blocks, it has no authority over what the model then does, and it should not be relied on to stop prompt injection. Its value is that untrusted content in a fetched page is currently owned by nothing at all.
 
 An earlier version of this document said its false-positive rate was measurable on tier 5 of the eval suite. It is not, and the re-run that checked found out why: **this system has never been called once**. It rides on a web or browser tool result, no task in any tier produces one, and the run that would have exercised Browser QA keeps it withdrawn because capability arming needs an interactive human. So the honest statement is that system 7 ships unmeasured, and the eval suite as it stands cannot measure it. That is a gap in the suite, not a property of the system, and it is stated here rather than left as an absent number that would read as a zero.
 
-Settings live in `<agent-dir>/specpi/jev/settings.json`, written atomically with owner-only permissions. Links, irregular files, oversize files, an unrecognised schema and unparseable contents all read as off. The one exception is the layer's own previous schema: a `schema: 1` file is migrated forward rather than read as unrecognised, because "collapse to all-off" is a rule for corrupt input and applying it to our own earlier version would silently disable a layer the user had switched on. Call budgets are per system under a session total, so one busy system cannot exhaust the allowance of the others and leave them dead for the rest of the session with event ordering deciding which one won. Session toggles write no startup preference. The key is read from the environment only; Pi authentication, credentials, trust decisions, sessions and history are never read.
+Settings live in `<agent-dir>/specpi/jev/settings.json`, written atomically with owner-only permissions. Links, irregular files, oversize files, an unrecognised schema and unparseable contents all read as off. The one exception is the layer's own previous schemas: an older file is migrated forward rather than read as unrecognised, because "collapse to all-off" is a rule for corrupt input and applying it to our own earlier version would silently disable a layer the user had switched on. Two keys are deliberately dropped rather than migrated. A `schema: 2` file kept a `guard` pair and a `schema: 3` file kept `systems.guard`; schema 4 keeps neither, because whether the command guard runs is not this file's answer to hold. The package keeps its own switch in its own configuration, and a stale copy here could only ever disagree with it. Call budgets are per system under a session total, so one busy system cannot exhaust the allowance of the others and leave them dead for the rest of the session with event ordering deciding which one won. Turning the layer on or off writes that preference, because a switch that forgets is not a switch; `--session` is how a one-off change is kept out of the file. The key is resolved the way Pi resolves every provider credential, in Pi's own documented order: the `openrouter` entry that `/login openrouter` writes to `<agent-dir>/auth.json`, then the environment variable. That is a deliberate, narrow exception to the rule that Pi state is never read, and it is bounded to exactly one question &mdash; the one `api_key` entry for the one provider this layer calls. Be precise about when: the key's *value* is read only on a call path the master switch already gates, but whether an entry *exists* is checked whenever status is displayed, including with the layer off, because that is the answer someone needs in order to configure it in the first place. A presence check reports a source name and nothing else. An `oauth` entry is ignored rather than unwrapped, because Pi refreshes those under its own lock and a second reader would race a rotation. The value is returned by a single function straight into a request header; nothing else in the layer receives it, and status output, the ledger and the Chat panel carry source names only. Pi trust decisions, sessions, missions and history are never read. `JEV_KEY_SOURCE=environment` restricts resolution to the environment, which is what this repository's own eval scripts set so a measured run cannot silently bill a developer's personal account.
 
 ## Command policy and the Jev guard
 
-`specpi-jev-guard` is pinned in the base set but ships **inert**. Its own default is `enabled: true`, so left alone a fresh install would begin gating shell and file calls through a third-party service immediately; SpecPi writes `enabled: false` and `/jev guard on` is how a human opts in. `@gotgenes/pi-permission-system` stays pinned and, while the guard is off, decides every tool call exactly as it did before the guard existed.
+`specpi-jev-guard` is pinned in the base set but ships **inert**. Its own default is `enabled: true`, so left alone a fresh install would begin gating shell and file calls through a third-party service immediately; SpecPi writes `enabled: false`, and the package's own `/jev-guard setup` is how a human opts in — no SpecPi command does. `@gotgenes/pi-permission-system` stays pinned and, while the guard is off, decides every tool call exactly as it did before the guard existed.
+
+Be precise about what the guard does once it is on, because it cannot be configured away. The guard is **fail-closed by design**: with no key, an unreachable endpoint, an answer it cannot parse, or a middle-band verdict in a session with no UI, it blocks the call and reports why. There is no setting that hands the decision back to the permission system instead &mdash; `uncertain` chooses between asking and denying the middle band, and only its `allow` value lets that band through unattended. So switching it on accepts that an outage stops gated work until it is switched off again. That trade is the user's to make, which is why SpecPi only ever writes the off side of it and why turning it on takes the package's own `/jev-guard` command.
+
+SpecPi asserts only three fields in `<home>/.pi/jev-guard.json` and merges them into whatever is already there, so a user's own thresholds, safe-command globs and protected paths survive: `enabled: false`, `uncertain: "ask"` so a middle-band verdict asks a human wherever there is one to ask, and `backend: "openrouter"` so the guard and the advisor resolve the same credential. Off is a written configuration, not an absence of one. SpecPi writes only the global file; a project-local override under a workspace's `.pi/` remains the user's to make.
+
+That write happens at install and update, and nowhere else. It deliberately does not repeat at session start, so the package's own `/jev-guard on [--global]` is the only switch and a saved choice survives every restart. It does repeat on the next installer run, unconditionally: an install left holding a stale `enabled: true` from before the package was last unpinned would otherwise arm a fail-closed gate the moment the package came back. That is the one case where establishing the default takes something away from someone, so the run reports it by name rather than doing it quietly.
 
-Be precise about what the guard does once it is on, because it cannot be configured away. The guard is **fail-closed by design**: with no key, an unreachable endpoint, or a middle-band verdict in a session with no UI, it blocks the call and reports why. There is no setting that hands the decision back to the permission system instead. So switching it on accepts that an outage stops gated work until it is switched off again. That trade is the user's to make, which is why it ships off and why `/jev status` and `specpi doctor` state plainly whether it is on, which backend it uses and whether that backend's key is present.
+As of 0.3.0 the guard resolves its key the way the advisor does and the way Pi resolves every provider credential: Pi's saved login first, then the environment. One `/login openrouter` therefore serves both without either component knowing about the other. `/jev-guard` reports its own state, including which backend and whether a key is present; `/jev status` does not, because the guard is not part of the layer it describes. Neither the guard nor the advisor is an OS sandbox.
 
-SpecPi asserts only three fields in `<home>/.pi/jev-guard.json` and merges them into whatever is already there, so a user's own thresholds, safe-command globs and protected paths survive: `enabled`, `uncertain: "ask"` so a middle-band verdict asks a human wherever there is one to ask, and `backend: "typesafe"` so the guard and the advisor read the same `TYPESAFE_API_KEY` rather than the guard needing a separate `OPENROUTER_API_KEY`. Those fields are rewritten at every session start, outside the advisor's master switch, because whether the guard is inert is a property of the install rather than a feature of the advisor — and off is a written configuration, not an absence of one. SpecPi writes only the global file; a project-local override under a workspace's `.pi/` remains the user's to make. Neither the guard nor the advisor is an OS sandbox.
+0.4.0 publishes a per-session counter as a Pi status item under the key `jev-guard` — the number of classifier calls, the number of blocked calls once there are any, and the last verdict. SpecPi Chat renders that line in its session footer and does nothing else with it: it does not recount from the session records, reformat the text, or offer a control. The key is absent whenever the guard is off or its `auditDisplay` is, so the readout appears exactly when the guard is gating. Every judged call is also written to Pi's own session file by the package, which is the durable audit trail and is not SpecPi's to manage.
 
 ## Improvement authority and evidence
 
@@ -72,7 +80,7 @@ Legacy migration restores only recorded settings ownership, preserves differing
 
 ## VS Code frontend
 
-SpecPi Chat is a separate VSIX, retained alongside the npm harness. It launches Pi only in a trusted filesystem workspace and communicates over local RPC. Provider credentials stay with Pi. Sign-in is delegated rather than implemented: Chat can start the configured Pi executable in a user-visible VS Code terminal, without RPC flags or a session, and Pi alone prompts, runs any OAuth flow, and writes `auth.json`. Chat sends no input to that terminal, reads no credential store, runs no Pi auth subcommand, and accepts no credential over RPC; it observes only the terminal's closure, and restarts the connection so Pi re-resolves its catalogue. Its sign-in prompt is derived from Pi's own available-model list and missing-credential error text. The frontend manages only its own workspace-storage conversation catalog and sessions for user-directed history, branching, and export; it does not import unrelated Pi histories. Attachments, images, webview messages, and file navigation are validated and bounded. Rendered model and tool output is untrusted text, never executable HTML.
+SpecPi Chat is a separate VSIX, retained alongside the npm harness. It launches Pi only in a trusted filesystem workspace and communicates over local RPC. Provider credentials stay with Pi. Sign-in is delegated rather than implemented: Chat can start the configured Pi executable in a user-visible VS Code terminal, without RPC flags or a session, and Pi alone prompts, runs any OAuth flow, and writes `auth.json`. Chat sends no input to that terminal, runs no Pi auth subcommand, and accepts no credential over RPC; it reads `auth.json` for one question only &mdash; whether an `openrouter` api_key entry is present &mdash; and the host sends the webview a boolean per source and never a value, so the panel reports where a key would come from without being a place one could leak from; it observes only the terminal's closure, and restarts the connection so Pi re-resolves its catalogue. Its sign-in prompt is derived from Pi's own available-model list and missing-credential error text. The frontend manages only its own workspace-storage conversation catalog and sessions for user-directed history, branching, and export; it does not import unrelated Pi histories. Attachments, images, webview messages, and file navigation are validated and bounded. Rendered model and tool output is untrusted text, never executable HTML.
 
 Approval replies are tied to the current conversation, client, and request ID. Disconnect, cancellation, and expiry never grant permission. Multiline package approval context is shown in the dialog body; requests exceeding the display budget are cancelled rather than approved against incomplete context. The Permissions editor can change only the package's documented global/project `config.json`, with bounded UTF-8/schema validation, explicit native confirmation, connection/scope binding, stale-revision checks, private backups, and atomic replacement. It reads no permission logs, trust decisions, credentials, or agent frontmatter. Symlinks, hardlinks, and special files are refused. Backups remain local and may contain sensitive policy; another same-user process can still race filesystem operations. Saving does not claim runtime activation: the user can restart the selected chat and inspect `/permission-system show`. Global/project changes may affect other chats as upstream reloads them; session approvals are cleared by restart. Delegated agent activity comes from a read-only, connection-local widget the delegation package publishes; Chat registers no tools or commands of its own for it. The VSIX does not install packages or duplicate their enforcement; only Permission System configuration has an explicit editing UI. TUI-only custom components are outside Pi's RPC rendering support.
 
@@ -80,7 +88,7 @@ The optional **Destructive guard** preset replaces the complete global configura
 
 ## Upstream package boundary
 
-The seven packages add their own extensions, tools, prompts, skills, network connections, filesystem operations, and subprocesses under their upstream defaults. They are not confined by the improvement loop's selection requirement. Permission System owns tool policies; SpecPi does not inject a duplicate guard or claim its coverage. Delegation starts real Pi child sessions in the same process tree, restricted to a frozen source snapshot and three read-only tools; experiments run the user's own `git` and create worktrees on disk. Neither is an OS sandbox. See [delegation](packages/delegation/SECURITY.md) and [experiments](packages/experiments/SECURITY.md). `pi-lens` and `pi-background-tasks` (including its Anthropic provider wrapper) are no longer part of the default base. Normal updates remove only unchanged entries originally added by SpecPi; pre-existing or modified entries and downloaded bytes remain. `--skip-package-install` preserves the old base. Restart Pi and Chat connections to unload retired extensions. Independently retained installations remain trusted upstream code; retained Pi Lens can still apply configured formatting/autofixes. Web access and usage reporting can contact services and use credentials through their upstream implementations. SpecPi's local-only wishlist collection policy does not describe all activity of those packages.
+The eight packages add their own extensions, tools, prompts, skills, network connections, filesystem operations, and subprocesses under their upstream defaults. They are not confined by the improvement loop's selection requirement. Permission System owns tool policies; SpecPi does not inject a duplicate guard or claim its coverage. Delegation starts real Pi child sessions in the same process tree, restricted to a frozen source snapshot and three read-only tools; experiments run the user's own `git` and create worktrees on disk. Neither is an OS sandbox. See [delegation](packages/delegation/SECURITY.md) and [experiments](packages/experiments/SECURITY.md). `pi-lens` and `pi-background-tasks` (including its Anthropic provider wrapper) are no longer part of the default base. Normal updates remove only unchanged entries originally added by SpecPi; pre-existing or modified entries and downloaded bytes remain. `--skip-package-install` preserves the old base. Restart Pi and Chat connections to unload retired extensions. Independently retained installations remain trusted upstream code; retained Pi Lens can still apply configured formatting/autofixes. Web access and usage reporting can contact services and use credentials through their upstream implementations. SpecPi's local-only wishlist collection policy does not describe all activity of those packages.
 
 Top-level versions are pinned; upstream transitive dependency ranges are not frozen by SpecPi. `doctor` reads configured pins and installed package metadata, then invokes the installed Browser QA bin for real offline rendering, pixel-comparison, and accessibility checks when the managed base includes it. Doctor never downloads a browser, and missing Chromium or OS libraries fail with recovery guidance. It does not validate provider access or browser readiness for independently retained BetterWright. Core-only installations do not run browser checks. `check:base` acquires the packages, checks combined resource loading and Chat RPC startup, and exercises upstream approval, denial, and cancellation with synthetic context. It uses temporary home/configuration directories and sends no model prompt. The base check also exercises Node-only Chromium setup and offline Browser QA readiness; authenticated services, OS isolation, and every upstream tool's behavior remain outside that check. See [THIRD_PARTY.md](THIRD_PARTY.md) for sources and compatibility limits.
 

package/THIRD_PARTY.md

@@ -11,7 +11,7 @@ Development formatting uses Prettier **3.9.6** (MIT), ESLint **10.9.1** (MIT), `
 
 ## Default packages
 
-Reviewed on 2026-09-16 against published npm metadata and integrity-verified source archives. All eight top-level packages declare the MIT license. Pins are authoritative in `templates/settings.json`.
+Reviewed on 2026-09-16 against published npm metadata and integrity-verified source archives, and `specpi-jev-guard` 0.4.0 on 2026-09-20. All eight top-level packages declare the MIT license. Pins are authoritative in `templates/settings.json`.
 
 SpecPi requests exact npm dependency saves for these pins and checks installed top-level versions before completing installation. The override applies to package acquisition without changing the user's global npm configuration.
 
@@ -24,17 +24,17 @@ SpecPi requests exact npm dependency saves for these pins and checks installed t
 | pi-goal-x                      | 0.31.2  | [tmonk/pi-goal-x](https://github.com/tmonk/pi-goal-x)                     |
 | @sreetej510/pi-usage           | 0.10.0  | [Sreetej510/pi-extensions](https://github.com/Sreetej510/pi-extensions)   |
 | @gotgenes/pi-permission-system | 32.0.2  | [gotgenes/pi-packages](https://github.com/gotgenes/pi-packages)           |
-| specpi-jev-guard               | 0.1.0   | [TannerMidd/specpi-jev-guard](https://github.com/TannerMidd/specpi-jev-guard) |
+| specpi-jev-guard               | 0.4.0   | [TannerMidd/specpi-jev-guard](https://github.com/TannerMidd/specpi-jev-guard) |
 
 Transitive dependencies and their notices remain in Pi's npm installation tree. Top-level pins do not freeze upstream dependency ranges or constitute a full transitive security audit. Pi invokes npm with its upstream package-management semantics, including dependency lifecycle scripts. Browser QA has no install hook: confirmed SpecPi install/update explicitly invokes its installed Node setup bin, unless acquisition or browser setup is skipped. It downloads package-pinned Chromium without installing OS libraries. BetterWright is optional/manual and retains its own Bun-based setup; SpecPi neither removes Bun nor deletes user-owned tools. Usage reporting and web packages make their own provider/service connections. Consult upstream licenses and security policies before redistributing their components.
 
 Pi Lens is no longer a default package. Normal updates retire only unchanged entries added by SpecPi; independent or modified entries and downloaded bytes remain, with their upstream notices. Restart Pi to unload Lens.
 
-The combined base is tested with Pi 0.84.4. Pi Goal X declares Pi `>=0.83.0 <0.85.0`; compatibility with newer hosts is not assumed. SpecPi's former custom browser, structural-search, background-task, and command-guard implementations, DonSeTch, and Pi themes have been removed. Its delegation and experiment implementations were not discarded: they now ship as the independent `specpi-delegation` and `specpi-experiments` packages described below. Removal restores owned package settings but does not delete downloaded upstream packages or tools. Retired private runtimes remain in local backups with their notices.
+The combined base is tested with Pi 0.84.4. Pi Goal X declares Pi `>=0.83.0 <0.85.0`; compatibility with newer hosts is not assumed. SpecPi's former custom browser, structural-search, background-task, and native command-guard implementations, DonSeTch, and Pi themes have been removed; command gating is the pinned `specpi-jev-guard` package's again. Its delegation and experiment implementations were not discarded: they now ship as the independent `specpi-delegation` and `specpi-experiments` packages described below. Removal restores owned package settings but does not delete downloaded upstream packages or tools. Retired private runtimes remain in local backups with their notices.
 
 ## Network services
 
-The optional Jev advisor and `specpi-jev-guard` both reach TypeSafe's System One endpoint. Neither is a bundled dependency: the advisor is first-party source that uses Node's built-in `fetch` and declares no package, and the guard is a pinned MIT package with no declared dependencies. Both require a key supplied by the user through the environment -- `OPENROUTER_API_KEY` on the default OpenRouter route, `TYPESAFE_API_KEY` when `JEV_BACKEND=typesafe` selects the direct API. The two are not interchangeable: the other service rejects the wrong one with a bare 401. SpecPi never provisions, stores or reads provider credentials for them.
+The optional Jev advisor and `specpi-jev-guard` both reach TypeSafe's System One endpoint. Neither is a bundled dependency: the advisor is first-party source that uses Node's built-in `fetch` and declares no package, and the guard is a pinned MIT package with no declared runtime dependencies. Both resolve their key the way every other Pi provider credential is resolved, in Pi's own documented order: the `openrouter` entry that `/login openrouter` writes to Pi's `auth.json`, then `OPENROUTER_API_KEY` from the environment (`TYPESAFE_API_KEY` when the direct API is selected &mdash; `JEV_BACKEND=typesafe` for the advisor, `/jev-guard backend typesafe` for the guard). Guard 0.3.0 is the release that added the credential-store half; before it the package read the environment alone. The two keys are not interchangeable: the other service rejects the wrong one with a bare 401. SpecPi never provisions or stores a provider credential, and reads one only to place it in the request header of the call the user has switched on.
 
 Requests go to `openrouter.ai` by default, or to `api.typesafe.ai` on the direct backend, unless `TYPESAFE_BASE_URL` redirects them, which exists so tests never reach the network and the eval proxy can price advisor traffic. Retention and processing of what is sent are governed by TypeSafe and, on the default route, by OpenRouter as well -- not by SpecPi; the advisor ships off, asks before its first transmission and records a hash of every payload locally. The frozen eval price list carries `jev-1.13.0` at $0.042/MTok input and free output so a measured SpecPi + Jev row never reports a cost that excludes its own advisor.
 
@@ -42,7 +42,7 @@ Worth stating plainly, because it is the part a reader is most likely to assume
 
 ## Standalone delegation and experiments
 
-`packages/delegation` and `packages/experiments` are first-party packages extracted from SpecPi's own retired harness code under MIT. Neither bundles third-party runtime code or declares a production dependency; every runtime import is a Node builtin or a Pi-supplied optional peer. Experiments invokes the user's own `git` as an external program through Pi's `exec` seam; Git is not bundled, vendored or version-pinned. Delegation's extraction drops the Command Guard admission path, which SpecPi no longer ships, and reports its guard posture as `absent`. See their dependency notices and security boundaries: [delegation](packages/delegation/THIRD_PARTY.md) / [boundary](packages/delegation/SECURITY.md), [experiments](packages/experiments/THIRD_PARTY.md) / [boundary](packages/experiments/SECURITY.md).
+`packages/delegation` and `packages/experiments` are first-party packages extracted from SpecPi's own retired harness code under MIT. Neither bundles third-party runtime code or declares a production dependency; every runtime import is a Node builtin or a Pi-supplied optional peer. Experiments invokes the user's own `git` as an external program through Pi's `exec` seam; Git is not bundled, vendored or version-pinned. Delegation's extraction drops the Command Guard admission path, which it does not integrate with, and reports its guard posture as `absent`. See their dependency notices and security boundaries: [delegation](packages/delegation/THIRD_PARTY.md) / [boundary](packages/delegation/SECURITY.md), [experiments](packages/experiments/THIRD_PARTY.md) / [boundary](packages/experiments/SECURITY.md).
 
 ## Standalone browser QA
 
@@ -52,4 +52,4 @@ The separately released `packages/browser-qa` source reuses the retired QA imple
 
 The website uses the bundled IBM Plex Sans and Plex Mono fonts under the SIL Open Font License 1.1; see [`site/fonts/LICENSE.txt`](https://github.com/TannerMidd/SpecPi/blob/main/site/fonts/LICENSE.txt). The website's scripts and diagrams are first-party code and assets. The README loads public package/license badges from Shields.io and build status from GitHub. Website fonts and media are not included in the npm package.
 
-SpecPi Chat 0.8.3 is a separately packaged VS Code extension with no bundled runtime dependencies. It uses VS Code's host APIs and Pi's RPC protocol. Generic tool output, visible custom messages, widgets, and dialogs stay owned by their upstream packages. Playwright **1.62.1** (Apache-2.0, [Microsoft Playwright](https://github.com/microsoft/playwright)) is a pinned development dependency for Chat's rendering tests; its browser is used for those checks and is not shipped in either artifact. The default Browser QA package independently uses the same pinned Playwright version for its runtime. Chat's global Destructive guard preset is a full replacement configuration reviewed against Permission System 32.0.2's schema and native pattern semantics. No upstream patch, new dependency, policy-layer merger, or independent command evaluator is included. See [the security model](SECURITY_MODEL.md) for its limits.
+SpecPi Chat 0.14.0 is a separately packaged VS Code extension with no bundled runtime dependencies. It uses VS Code's host APIs and Pi's RPC protocol. Generic tool output, visible custom messages, widgets, and dialogs stay owned by their upstream packages. Playwright **1.62.1** (Apache-2.0, [Microsoft Playwright](https://github.com/microsoft/playwright)) is a pinned development dependency for Chat's rendering tests; its browser is used for those checks and is not shipped in either artifact. The default Browser QA package independently uses the same pinned Playwright version for its runtime. Chat's global Destructive guard preset is a full replacement configuration reviewed against Permission System 32.0.2's schema and native pattern semantics. No upstream patch, new dependency, policy-layer merger, or independent command evaluator is included. See [the security model](SECURITY_MODEL.md) for its limits.

package/extensions/jev-advisor/client.mjs

@@ -6,6 +6,22 @@
 // the path it would have run before this extension existed. That is fail-silent, not fail-closed —
 // nothing here is ever the reason a tool is blocked.
 
+import { backend, resolveKey } from "./key-source.mjs";
+
+/**
+ * Where a key comes from is resolved in key-source.mjs, which follows Pi's own order: the
+ * `auth.json` entry `/login openrouter` writes, then the environment variable.
+ *
+ * Every one of these defaults its route to `backend()` rather than to the string "openrouter", so a
+ * no-arg call resolves against the backend actually in force. That matters because it briefly did
+ * not: when `apiKey` was first replaced by a re-export of a function whose parameter defaulted to a
+ * literal, `apiKey()` returned a stored OpenRouter key under `JEV_BACKEND=typesafe` -- a script's
+ * `if (!apiKey())` guard passed and it spent a run, while every request underneath came back
+ * `no-key`. The fix belongs at the definition, which is where it now is; a wrapper here would only
+ * have hidden that three sibling exports had the same defect.
+ */
+export { backend, keyEnvName, keyPresent, keySource, keySources, resolveKey as apiKey } from "./key-source.mjs";
+
 export const DEFAULT_MODEL = "jev-1.13.0";
 export const OPENROUTER_MODEL = "typesafe/jev-1.13";
 // Measured round trip is ~250-400ms through OpenRouter. 800ms left no headroom for a slow call,
@@ -14,32 +30,6 @@ export const OPENROUTER_MODEL = "typesafe/jev-1.13";
 export const DEFAULT_TIMEOUT_MS = 1500;
 const MAX_TIMEOUT_MS = 5000;
 
-/**
- * Jev is reached through OpenRouter by default: that is where it is published, it is what
- * specpi-jev-guard already uses, and an OpenRouter key (`sk-or-...`) is rejected by the direct
- * TypeSafe API with a bare 401. `JEV_BACKEND=typesafe` selects the direct API for a TypeSafe key.
- */
-export function backend() {
-    return process.env.JEV_BACKEND === "typesafe" ? "typesafe" : "openrouter";
-}
-
-/**
- * The key variable follows the backend, matching specpi-jev-guard's own `keyEnvName`, so one key
- * serves the whole layer. TYPESAFE_API_KEY is still accepted on the OpenRouter path so an existing
- * env file keeps working.
- */
-export function apiKey() {
-    const name = backend() === "openrouter" ? "OPENROUTER_API_KEY" : "TYPESAFE_API_KEY";
-    const direct = process.env[name];
-    if (typeof direct === "string" && direct.trim().length > 0) {
-        return direct.trim();
-    }
-
-    const legacy = backend() === "openrouter" ? process.env.TYPESAFE_API_KEY : undefined;
-
-    return typeof legacy === "string" && legacy.trim().length > 0 ? legacy.trim() : undefined;
-}
-
 /** Overridable so tests never reach the network and the eval proxy can price the traffic. */
 export function baseUrl() {
     const configured = process.env.TYPESAFE_BASE_URL;
@@ -119,7 +109,7 @@ function normalizeAnswer(raw) {
  * every question that state can answer rather than paying for the state again.
  */
 export async function ask(state, questions, options = {}) {
-    const key = apiKey();
+    const key = resolveKey(backend());
     if (!key) {
         return unavailable("no-key");
     }

package/extensions/jev-advisor/config.mjs

@@ -1,7 +1,13 @@
 // Jev is the first thing in SpecPi that talks to a third party, so its switch is the first thing
-// every other module in this directory consults. Master off means no key read, no consent read, no
-// network call and no prompt injection: the harness behaves exactly as it did before the extension
-// existed.
+// every other module in this directory consults. Master off means no key value read, no consent
+// read, no network call and no prompt injection: the harness behaves exactly as it did before the
+// extension existed. `/jev status` still reports whether a key exists while the layer is off, by
+// name and never by value, because "how do I configure this" is a question asked before enabling
+// anything -- see key-source.mjs.
+//
+// The command guard is not here at all. It is a separate pinned package that keeps its own
+// configuration and its own switch, and nothing in this file tracks it -- see scripts/jev-guard.mjs
+// for the one place SpecPi touches it, which is install time.
 //
 // The file is SpecPi's own, hardened the same way as web-access and capability-policy: atomic
 // write, mode 0600, symlinks refused, and a missing or unreadable file read as off.
@@ -42,8 +48,8 @@ export const SYSTEM_NAMES = Object.freeze([
 export const NUDGE_MODES = Object.freeze(["notify", "message"]);
 
 const MAX_SETTINGS_BYTES = 4096;
-const MAX_CALL_BUDGET = 256;
-const MAX_TOTAL_BUDGET = 512;
+const MAX_CALL_BUDGET = 1024;
+const MAX_TOTAL_BUDGET = 2048;
 
 /**
  * One shared budget could not survive a turn-level system. A system that fires once per turn would
@@ -51,8 +57,11 @@ const MAX_TOTAL_BUDGET = 512;
  * session, and which one won would be decided by event ordering rather than by anyone's policy.
  *
  * So the ceiling is two-level: each system gets its own, and the total is a real constraint because
- * it is deliberately less than their sum. Running out of one system's budget stops that system and
- * nothing else.
+ * it is deliberately less than their sum -- 2048 against 2322. That relationship is the invariant,
+ * not either number: raising the total without raising the per-system ceilings would leave a total
+ * no combination of systems could ever reach, which is a limit that reads as a limit and is not
+ * one. `tests/jev-advisor.test.mjs` pins the inequality so a future change to one has to consider
+ * the other. Running out of one system's budget stops that system and nothing else.
  *
  * The per-system numbers follow how often each one can fire: retention on every large read-only
  * result, compaction once or twice in a long session, gap per report, sources per delegation batch.
@@ -60,7 +69,7 @@ const MAX_TOTAL_BUDGET = 512;
 export const DEFAULT_BUDGETS = Object.freeze({
     // A backstop, not a working limit, and the number says which. Measured, a full tier-3 task -- a
     // 120-step repair chain over about 25 model requests -- spends 4 to 7 calls, and the busiest
-    // attempt ever recorded spent 12. A session would have to run for days before 512 bound
+    // attempt ever recorded spent 12. A session would have to run for days before 2048 bound
     // anything a person was actually doing, which is the point: the ceiling should only ever be hit
     // by a loop, and hitting it should therefore be information rather than an inconvenience.
     //
@@ -68,28 +77,36 @@ export const DEFAULT_BUDGETS = Object.freeze({
     // runs for two minutes; an interactive session runs for a day, and a turn-level system at one
     // call every four turns reaches 120 somewhere in the afternoon and then goes quiet without
     // having found anything wrong. A ceiling that a normal long session reaches is not protecting
-    // anyone, it is just failing later than it looks.
+    // anyone, it is just failing later than it looks. 512 was the same mistake one order of
+    // magnitude further out, and the long-session evals are what showed it: a session long enough
+    // to compact several times spends in the hundreds, so the backstop sat close enough to real
+    // use to be reachable by a session that was working correctly.
     //
-    // Cost is not what these are for. A call is about $0.00003, so the whole total is about a cent
-    // and a half. They bound two things that do not get cheaper with scale: how much digest leaves
-    // the machine for a third party, at up to 1 KB a call, and how much awaited latency a runaway
-    // loop can add before something stops it. Half a megabyte of digest and an announced stop is
-    // the shape of the trade.
-    total: 512,
-    retention: 208,
-    compaction: 12,
-    gap: 48,
-    sources: 32,
+    // Cost is not what these are for. A call is about $0.00003, so the whole total is about six
+    // cents. They bound two things that do not get cheaper with scale: how much digest leaves the
+    // machine for a third party, at up to 1 KB a call, and how much awaited latency a runaway loop
+    // can add before something stops it. Two megabytes of digest and an announced stop is the shape
+    // of the trade.
+    total: 2048,
+    // The per-system numbers move with the total, because a total the per-system ceilings can never
+    // add up to is not a constraint at all -- see below. They are scaled rather than re-derived:
+    // each one's rationale is a firing frequency, and none of those frequencies changed.
+    retention: 832,
+    compaction: 48,
+    gap: 192,
+    sources: 128,
     // Turn-level, but gated behind local signals and a four-turn cooldown, so it only spends on
     // sessions that already look wrong. The ceiling is what stops a genuinely thrashing session
     // from spending the total on being told it is thrashing.
-    progress: 176,
+    progress: 704,
     // Usually free: when retention is on, system 7's question rides the call retention was already
     // making against the same state. This ceiling only binds when retention is off, or when the
     // fetched result is too small for retention to be interested in it.
-    untrusted: 104,
+    untrusted: 416,
     // Once per session by construction, and only when local signals already suggest it. Two rather
-    // than one so a retried first turn is not silently un-served.
+    // than one so a retried first turn is not silently un-served. The one number here that does not
+    // scale with the total, because it is not sized by a frequency: the system asks once and then
+    // never again, so a larger ceiling would buy nothing and would only misdescribe what it does.
     capability: 2,
 });
 
@@ -127,16 +144,12 @@ export function regularFile(file, label) {
 /** Every unknown shape collapses to the same all-off default rather than a partial enable. */
 export function defaultSettings() {
     return {
-        schema: 2,
+        schema: 4,
         master: false,
         startup: false,
         systems: Object.fromEntries(SYSTEM_NAMES.map((name) => [name, false])),
         budgets: { ...DEFAULT_BUDGETS },
         progressNudge: "notify",
-        // The guard is a separate package with its own gate, so it carries its own switch rather
-        // than riding the advisor's master. Both ship off: nothing in the Jev layer is active on a
-        // fresh install, and `startup` is how a user chooses to default one on.
-        guard: { enabled: false, startup: false },
     };
 }
 
@@ -174,22 +187,55 @@ function migrate(raw) {
     return { ...raw, schema: 2, budgets, callBudgetPerSession: undefined };
 }
 
+/**
+ * Schema 4 removes every trace of the command guard from this file, from either shape it took.
+ *
+ * Schema 2 kept a `guard: { enabled, startup }` pair, from when SpecPi re-asserted the package's
+ * switch at every session start; schema 3 made the guard the layer's eighth system under
+ * `systems.guard`. Both keys go, because neither answer is SpecPi's to hold any more: the package
+ * owns its switch in its own file, and a stale copy here could only ever disagree with it.
+ *
+ * Dropping them changes nothing about whether anyone's guard is on. A schema-2 file's preference
+ * had already been written through to the package's own configuration by the last session that
+ * read it, and schema 3 shipped with no guard package installed at all.
+ */
+function migrateToFour(raw) {
+    const { guard: _pair, ...rest } = raw ?? {};
+    const { guard: _system, ...systems } = rest.systems ?? {};
+
+    return { ...rest, schema: 4, systems };
+}
+
+/**
+ * What the advisor will read, given a settings object, without writing it anywhere.
+ *
+ * Exported for callers that compose a settings file for somewhere other than this process's own
+ * agent directory -- the eval harness writes one into a disposable home -- and need to check what
+ * they composed. Building a literal and trusting it is how the harness came to run every published
+ * tier with a system it believed it had enabled switched off: it hardcoded a schema number, the
+ * migration for that number read a preference from a key that shape does not have, and nothing ever
+ * compared the result to the ask. Compose, then normalize, then assert -- not compose and trust.
+ */
+export function normalizeSettings(raw) {
+    return normalize(raw);
+}
+
 function normalize(raw) {
-    const source = raw?.schema === 1 ? migrate(raw) : raw;
-    if (source?.schema !== 2) {
+    const one = raw?.schema === 1 ? migrate(raw) : raw;
+    const source = one?.schema === 2 || one?.schema === 3 ? migrateToFour(one) : one;
+    if (source?.schema !== 4) {
         return defaultSettings();
     }
 
     const systems = Object.fromEntries(SYSTEM_NAMES.map((name) => [name, source.systems?.[name] === true]));
 
     return {
-        schema: 2,
+        schema: 4,
         master: source.master === true,
         startup: source.startup === true,
         systems,
         budgets: normalizeBudgets(source.budgets),
         progressNudge: NUDGE_MODES.includes(source.progressNudge) ? source.progressNudge : "notify",
-        guard: { enabled: source.guard?.enabled === true, startup: source.guard?.startup === true },
     };
 }
 
@@ -220,9 +266,9 @@ export function writeFileAtomic(file, contents) {
 }
 
 export function saveSettings(settings) {
-    // A caller handing back a schema-1 shape is migrated rather than reset, so a round trip through
+    // A caller handing back an older shape is migrated rather than reset, so a round trip through
     // an old reader cannot quietly disable the layer.
-    const next = normalize(settings?.schema === 1 ? settings : { ...settings, schema: 2 });
+    const next = normalize([1, 2, 3].includes(settings?.schema) ? settings : { ...settings, schema: 4 });
     const file = settingsFile();
     if (fs.existsSync(file)) {
         regularFile(file, "Jev settings");
@@ -236,19 +282,3 @@ export function saveSettings(settings) {
 export function settingsPath() {
     return settingsFile();
 }
-
-/**
- * The key is never read into any structure that gets logged or serialized. Callers only ever ask
- * whether one is present; the client reads it directly at call time.
- */
-export function keyPresent() {
-    // OPENROUTER_API_KEY on the default path, TYPESAFE_API_KEY on the direct one; see client.mjs.
-    for (const name of ["OPENROUTER_API_KEY", "TYPESAFE_API_KEY"]) {
-        const value = process.env[name];
-        if (typeof value === "string" && value.trim().length > 0) {
-            return true;
-        }
-    }
-
-    return false;
-}