specpi 0.28.0 → 0.29.0

package/CHANGELOG.md

@@ -1,5 +1,18 @@
 # 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.

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 has not been re-measured since the command guard became a native system rather than an eighth pinned package. "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.
 

package/SECURITY_MODEL.md

@@ -1,6 +1,6 @@
 # Security model
 
-SpecPi provides scope monitoring, an explicit harness improvement loop and an optional Jev advisor, and installs seven pinned packages as its default base. Extensions run as trusted code with Pi's permissions. Scope is not an OS sandbox or a general command guard. Use OS isolation for hostile code.
+SpecPi provides scope monitoring, an explicit harness improvement loop and an optional Jev advisor, and installs eight pinned packages as its default base. Extensions run as trusted code with Pi's permissions. Scope is not an OS sandbox or a general command guard. Use OS isolation for hostile code.
 
 ## Scope monitoring
 
@@ -30,29 +30,31 @@ The advisor also keeps `<agent-dir>/specpi/jev/usage.json`, the running call cou
 
 The advisor holds no authority. It never grants a capability, never calls a tool and never allows one. Its only blocking action is to refuse a capability-gap report that looks like it carries a credential, which asks the model to rewrite its own text and discards nothing. Failure is silent, not closed: a timeout, HTTP error, missing key, missing consent, an exhausted per-system or session budget, or ungated confidence produces no advice, and the existing code path runs unchanged. Tool-result retention can shorten a large read-only result before it is appended; it never alters a write, edit or error result, and the replacement says the output is recoverable by re-running.
 
-Three of the eight systems do something the other five do not, and all three are off by default like everything else here.
+Two of the seven systems do something the other five do not, and both are off by default like everything else here.
 
 **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.
 
-**System 8, the command guard**, is the only one that can refuse a tool call, and it has its own section below. It is named here because the rest of this layer never blocks anything, and a reader who took "the advisor holds no authority" to cover every system would be wrong about exactly one of them. `/jev on` enables it with the other seven and says in the same notification that it can refuse a command; `/jev disable guard` turns it off. An unattended schema migration never arms it.
+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. 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.
+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
 
-The command guard is the layer's eighth system, native since schema 3, and ships off like the other seven. It was a pinned third-party package until that package's shape proved to be its own source of defects: a global configuration file with no session scope, a key read from the environment only — so a credential `/login` had stored was invisible to it — and a fail-closed posture, which meant an outage or a missing key stopped shell work rather than degrading. `@gotgenes/pi-permission-system` stays pinned and decides every call the guard defers, which is every call it does not confidently judge destructive.
+`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.
 
-The guard **fails open**, which is the deliberate inversion of what it replaced. Local rules settle most calls without sending anything: simple commands and ordinary project writes pass for nothing, and a very short list of catastrophic, unambiguous commands is blocked with no call at all. The allowlist is a budget mechanism and not a safety one &mdash; it exists so a session of `ls` and `grep` cannot spend the guard's whole call budget and leave nothing for the calls that matter &mdash; so a binary is admitted only when it is simple whatever flags it is given. Anything that can launch a program, write a file or change machine state under any flag goes to the model, however harmless its name reads. The catastrophic list is separate and deliberately tiny: its real job is the case where Jev is unreachable, since a model that can weigh intent catches everything a pattern would and more. Anything else is scored, and a call is blocked only on a confident destructive verdict that the request does not account for — both, because a destructive-looking command the person asked for in as many words is the likeliest way to be wrong. A confident verdict that a write targets a real credential file blocks on its own. Everything else — no key, no budget, a timeout, an unconfident answer, or a middle-band verdict with no human to ask — hands the call to `@gotgenes/pi-permission-system`, which decides it exactly as it did before this layer existed. Deferring is not allowing.
+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.
 
-Both halves of the block rule must clear the same confidence gate. A destructive verdict alone is not enough and neither is an absent intent answer read as agreement: roughly four Score answers in five do not gate, so treating "no answer" as "not what was asked for" would have made the second half apply to about one call in five. When there is a human and the guard asks, only the affirmative reply runs the call; a dismissed dialog is not consent.
+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.
 
-What is gated is stated rather than implied: the shell tools under every alias the harness maps onto `bash`, and the write tools under every name — `write`, `edit`, `multi_edit`, `apply_patch`, `create_file`, `str_replace`. A shell call's text is read from whichever field carries it, so a tool that types into a live shell is judged on what it types rather than on an empty string. A write whose target cannot be read from the tool input is asked about rather than passed, because a field this layer does not recognise should cost a question and not open a hole. A protected path is matched anywhere in a resolved path, directory as well as file, so `secrets/api.txt` is a secret and not an ordinary project file, and a read-only command pointed at one — `cat ~/.ssh/id_rsa` changes nothing and still hands over a key — leaves the free path and is asked about like anything else. Neither the guard nor the advisor is an OS sandbox.
+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.
 
-Two failures do not fail open, and both are about a person. An announcement that cannot be delivered never changes a decision already taken; and once a verdict says a call needs human approval, a host that cannot present the question has not obtained it, so the call is refused rather than run. Everything that fails open fails open *before* anyone was asked.
+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.
+
+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
 
@@ -66,11 +68,11 @@ Wishlist records remain local under `<agent-dir>/specpi/`. Sanitization and salt
 
 Package acquisition requests exact npm dependency saves through the child process environment and verifies the installed top-level versions before completing the transaction. A mismatch fails the operation and triggers managed-state rollback. Upstream transitive dependency ranges remain outside this pinning guarantee.
 
-`plan` is read-only. Installation, updates, and removal require confirmation or `--yes`. SpecPi manages its two first-party extension families, improvement skill, manifest, AGENTS marker block, and the seven package entries listed in `templates/settings.json`. Normal install/update runs `pi install npm:<name>@<pin>` for every default package. Only package entries are merged; existing resource filters and unrelated settings are retained. `--skip-package-install` allows a core-only install or preserves an already configured base during update, skipping Chromium setup too. Confirmed install/update otherwise invokes the installed Browser QA Node bin with bounded subprocesses to download Chromium and check readiness. `--skip-browser-install` skips that setup only; doctor still checks readiness. SpecPi never passes `--with-deps`, auto-installs OS libraries, or installs/removes Bun. No new shell profile integration is installed.
+`plan` is read-only. Installation, updates, and removal require confirmation or `--yes`. SpecPi manages its two first-party extension families, improvement skill, manifest, AGENTS marker block, and the eight package entries listed in `templates/settings.json`. Normal install/update runs `pi install npm:<name>@<pin>` for every default package. Only package entries are merged; existing resource filters and unrelated settings are retained. `--skip-package-install` allows a core-only install or preserves an already configured base during update, skipping Chromium setup too. Confirmed install/update otherwise invokes the installed Browser QA Node bin with bounded subprocesses to download Chromium and check readiness. `--skip-browser-install` skips that setup only; doctor still checks readiness. SpecPi never passes `--with-deps`, auto-installs OS libraries, or installs/removes Bun. No new shell profile integration is installed.
 
 Managed configuration and files are locked and backed up before mutation; first-party writes are atomic and checksum-tracked. Failure restores the saved configuration and first-party files. Package acquisition runs upstream package-manager scripts and may leave downloads, dependency changes, or external script effects even after configuration rollback. Those effects, including downloaded browser-cache bytes, are outside SpecPi's transaction and survive uninstall. Updates require `--force` before replacing modified retained resources. Retired resources are backed up before deactivation; pre-install files are restored where ownership records identify them. Old runtime directories are moved into backups without inspecting their contents. Backups and private evidence remain after uninstall and can contain sensitive local material.
 
-Legacy migration restores only recorded settings ownership, preserves differing user values, and removes only the SpecPi shell marker block before applying the new base. The installer does not enumerate or modify authentication, provider credential stores, trust, sessions, missions, history, or unrelated private evidence. Normal updates deliberately reapply the default package pins, retaining the original entry for removal. A package a past version pinned and this one has retired is unpinned by name on install and update, including under `--skip-package-install`, because skipping acquisition has never meant leaving an entry SpecPi wrote pointing at code whose controls SpecPi has removed; `specpi doctor` reports one that is still configured. Its downloaded files remain, as every other package's do. Uninstall restores only package entries that still match the last installed value; user edits are preserved. Downloaded packages and tools are not deleted. Resources that SpecPi never owned require separate human management.
+Legacy migration restores only recorded settings ownership, preserves differing user values, and removes only the SpecPi shell marker block before applying the new base. The installer does not enumerate or modify authentication, provider credential stores, trust, sessions, missions, history, or unrelated private evidence. Normal updates deliberately reapply the default package pins, retaining the original entry for removal. Uninstall restores only package entries that still match the last installed value; user edits are preserved. Downloaded packages and tools are not deleted. Resources that SpecPi never owned require separate human management.
 
 ## Browser QA package
 
@@ -86,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,16 +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.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 layer, command guard included, reaches TypeSafe's System One endpoint. It is not a bundled dependency: it is first-party source that uses Node's built-in `fetch` and declares no package. The guard used to be a separate pinned package; it is now the layer's eighth system, so one switch, one budget and one key serve the whole thing. That key is resolved the way every other Pi provider credential is resolved, in Pi's own documented order: the `openrouter` entry that `/login openrouter` writes to `<agent-dir>/auth.json`, then `OPENROUTER_API_KEY` from the environment (`TYPESAFE_API_KEY` when `JEV_BACKEND=typesafe` selects the direct API). 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.
+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.
 
@@ -41,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
 
@@ -51,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/broker.mjs

@@ -28,7 +28,6 @@ export const SYSTEM_LABELS = Object.freeze({
     progress: "Progress and thrash detection",
     untrusted: "Untrusted-content classification",
     capability: "Turn-zero capability arming",
-    guard: "Command guard",
 });
 
 export function createBroker(options = {}) {

package/extensions/jev-advisor/config.mjs

@@ -5,6 +5,10 @@
 // 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.
 
@@ -22,14 +26,6 @@ export const SYSTEM_NAMES = Object.freeze([
     "progress",
     "untrusted",
     "capability",
-    // The command guard, native since schema 3. It used to be a separate pinned package with its own
-    // global configuration file, which is why it used to carry its own switch here: a second switch,
-    // outside the master, with its own startup preference and its own persistence rules. Those rules
-    // disagreed with the layer's often enough to be their own source of defects -- a preference
-    // erased by a command that had decided nothing about the guard, a state written by one command
-    // and reverted by the next session. As a system it is gated, budgeted, reported and toggled by
-    // exactly the same code as the other seven.
-    "guard",
 ]);
 
 /**
@@ -52,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
@@ -61,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.
@@ -70,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.
     //
@@ -78,35 +77,37 @@ 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,
-    // Per gated tool call that local rules could not settle, so its frequency is retention's rather
-    // than compaction's -- and like retention, most calls never reach it: read-only commands and
-    // ordinary project writes are answered locally for nothing. Running out means the guard defers
-    // to the permission system for the rest of the session, which is what it does for every other
-    // kind of unavailability.
-    guard: 208,
 });
 
 /** 0 is a real budget meaning no calls. Switching a system off is what `systems[name] = false` is for. */
@@ -143,7 +144,7 @@ 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: 3,
+        schema: 4,
         master: false,
         startup: false,
         systems: Object.fromEntries(SYSTEM_NAMES.map((name) => [name, false])),
@@ -187,36 +188,49 @@ function migrate(raw) {
 }
 
 /**
- * Schema 2 carried the command guard as a separate `guard: { enabled, startup }` pair, because it
- * was a separate package with its own global configuration file. Schema 3 makes it the eighth
- * system, so the stored preference becomes `systems.guard`.
+ * 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.
  *
- * `guard.startup` is what migrates, not `guard.enabled`: the former is what the user chose for new
- * sessions, and the latter was a session flag that happened to be written to disk. A file where the
- * guard was wanted at startup but the layer itself was not produces a system that is on inside a
- * layer that is off, which is inactive -- the guard used to sit outside the master switch and now
- * does not. That direction is deliberate: a gate quietly becoming inactive is recoverable in one
- * command, and a gate quietly becoming active is how a session stops being able to run anything.
+ * 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 migrateToThree(raw) {
-    const systems = { ...(raw?.systems ?? {}), guard: raw?.guard?.startup === true };
+function migrateToFour(raw) {
+    const { guard: _pair, ...rest } = raw ?? {};
+    const { guard: _system, ...systems } = rest.systems ?? {};
 
-    const { guard: _guard, ...rest } = raw ?? {};
+    return { ...rest, schema: 4, systems };
+}
 
-    return { ...rest, schema: 3, 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 one = raw?.schema === 1 ? migrate(raw) : raw;
-    const source = one?.schema === 2 ? migrateToThree(one) : one;
-    if (source?.schema !== 3) {
+    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: 3,
+        schema: 4,
         master: source.master === true,
         startup: source.startup === true,
         systems,
@@ -252,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?.schema === 2 ? settings : { ...settings, schema: 3 });
+    const next = normalize([1, 2, 3].includes(settings?.schema) ? settings : { ...settings, schema: 4 });
     const file = settingsFile();
     if (fs.existsSync(file)) {
         regularFile(file, "Jev settings");

package/extensions/jev-advisor/gate.mjs

@@ -156,20 +156,6 @@ export const THRESHOLDS = Object.freeze({
         high: 0.85,
         low: 0.15,
     }),
-    guard: Object.freeze({
-        // The same measured Score operating point as every other system, written out rather than
-        // inherited by falling through `thresholdsFor`'s default. The guard asked under the name
-        // "gap" for exactly as long as it took to notice that adding a `guard` entry would then have
-        // changed nothing -- a silent no-op on the one system whose action takes a tool call away.
-        scoreConfidence: 0.6,
-        boundary: 0.3,
-        choiceConfidence: 0.75,
-        margin: 0.2,
-        // Unused: this system reads only the Score side. Kept so every system has a full set, and
-        // so the calibration tests cover this entry like any other.
-        high: 0.85,
-        low: 0.15,
-    }),
     sources: Object.freeze({
         scoreConfidence: 0.6,
         boundary: 0.3,