pi-jev-guard 0.6.0 → 0.7.0

package/README.md

@@ -4,7 +4,7 @@ Verifica le risposte con [TypeSafe Jev](https://docs.typesafe.ai) dentro [pi](ht
 
 - **A richiesta** (default): tool `jev_validate`, comando `/jev check`, skill `jev-review`. Zero verifiche implicite, zero costi se non lo usi.
 - **Domande tipate**: tool `jev_ask` per giudizi calibrati definiti dal modello (noul/choice/score) invece di prosa.
-- **Automatica**: gemello guarded `<modello>__jev` dentro lo stesso provider, che trattiene la risposta, la verifica con Jev e pubblica solo l'output approvato (con rigenerazione privata su `block`). Stessa auth del provider: nessun login extra, funziona anche con Codex/OAuth.
+- **Automatica**: in `automatic` il gate copre **il modello selezionato e ogni cambio modello**, senza alias o registrazioni extra: trattiene la risposta, la verifica con Jev e pubblica solo l'output approvato (con rigenerazione privata su `block`). Stessa auth del provider: nessun login extra, funziona anche con Codex/OAuth.
 - **Giudice output** (solo `automatic`, fail-open): dopo ogni `bash` cerca secret nel testo e classifica i fallimenti, allegando un consiglio al risultato.
 - **Verifica progetto** (opt-in): footer deterministico da `edit`/`write` osservati e check autorizzati da override locale, manifest globale utente o profilo comune integrato; il modello può eseguire soltanto quegli id, mai shell arbitraria.
 
@@ -30,7 +30,7 @@ export TYPESAFE_API_KEY="..."              # backend typesafe diretto
 Le nuove sessioni partono in `on-demand`: i modelli normali restano selezionabili e nessuna verifica parte da sola.
 `/jev mode automatic|on-demand` salva la scelta **nella sessione**, non nella config globale.
 La scelta sopravvive a `/reload`, riavvio e `/resume`; fork e `/tree` seguono lo stato del ramo.
-Credenziali, policy e catalogo dei twin restano condivisi.
+Credenziali e policy restano condivise.
 
 Migrazione: il vecchio `mode` in `jev-config.json` non controlla più l'estensione
 (resta compatibile con i consumer standalone). Nelle sessioni senza uno stato salvato,
@@ -48,13 +48,16 @@ In chat, l'LLM può chiamare `jev_validate` per controlli mirati.
 ## Uso protetto
 
 ```text
-/jev upstream deepseek deepseek-flash          # crea deepseek/deepseek-flash__jev
-/jev upstream openai-codex gpt-5.6-terra       # aggiunge openai-codex/gpt-5.6-terra__jev
-/jev twins                                    # elenca attivi e salvati
-/jev untwin openai-codex gpt-5.6-terra         # rimuove uno solo
-/jev mode automatic                           # seleziona il primario + attiva enforcement
+/model                          # scegli qualunque modello (o più modelli in sessioni diverse)
+/jev mode automatic             # ogni risposta passa dal gate Jev
+/jev off                        # gate disattivato, provider ripristinati
 ```
 
+Nessun alias `__jev`, nessuna registrazione: il gate lavora sullo stesso
+oggetto provider e riusa la credenziale già configurata (env, stored,
+OAuth/SSO come Codex business plan). I vecchi alias delle versioni ≤ 0.6.x
+vengono normalizzati automaticamente ai modelli originali.
+
 ### Backend e chiavi
 
 Due backend, stessa policy e stesse regole:
@@ -78,41 +81,17 @@ config), quindi i due backend possono coesistere. Precedenza: variabile
 d'ambiente → file del backend → file generico `jev.apiKeyFile` → percorso
 canonico. Vedi `config/jev-config.example.json`.
 
-**Più twin insieme**: ogni `/jev upstream` *aggiunge* un modello guarded, senza
-rimuovere i precedenti. I twin vengono registrati anche all'avvio (i modelli
-dinamici come Codex sono letti dal models-store), quando gli originali sono disponibili.
-Il **primario** salvato è il target di auto-selezione e revert; un twin già selezionato
-nella sessione viene mantenuto al reload, anche se non è il primario.
-
-Nessun login extra: i twin vivono nello stesso provider e riusano la credenziale già configurata (env, stored, OAuth/SSO come Codex business plan). I modelli originali restano intatti e selezionabili.
-
-I twin salvati vengono registrati prima del ripristino del modello anche in
-`on-demand`: registrazione e attivazione del gate sono indipendenti. Il suffisso
-`__jev` è locale e non viene inviato al provider; anche la cronologia viene
-normalizzata sull'identità originale senza perdere firme o metadati di continuazione.
-
-Torna normale con `/jev mode on-demand`, che seleziona anche il modello originale.
-In `automatic`, selezionare un modello non protetto lo fa ritornare
-subito al twin (enforcement a livello selezione).
-`/jev upstream` senza argomenti ripristina tutti i twin salvati, `/jev untwin P M`
-ne rimuove uno solo, `/jev off` li rimuove tutti
-(e salva on-demand nella sessione, selezionando l'originale prima di rimuovere il routing).
-`/jev off` conserva il catalogo salvato: al reload gli alias tornano disponibili,
-ma il gate rimane disattivato.
+**Qualunque modello**: in `automatic` il gate segue la selezione — cambi
+modello con `/model` e ogni risposta resta coperta, senza passaggi di setup.
+Il catalogo resta quello di pi: nessun alias, nessun modulo extra nel picker.
 
-Se filtri i modelli con `enabledModels`, usa i glob invece delle voci esplicite,
-così i twin futuri non restano nascosti:
-
-```json
-"enabledModels": ["openai-codex/*__jev", "deepseek/*__jev", "...altri pattern..."]
-```
+Torna normale con `/jev mode on-demand` (o `/jev off`, che ripristina anche i
+metodi originali dei provider). Entrambe le scelte vivono nella sessione e
+sopravvivono a `/reload` e `/resume`.
 
-Dopo aver aggiunto un twin serve `/reload` (lo scope è risolto all'avvio della sessione).
-`/jev upstream` avvisa subito quando il twin appena creato è fuori dal picker.
 L'installazione punta alla cartella: dopo un aggiornamento del codice basta `/reload`.
 
-Headless/CI: `JEV_MODE=automatic JEV_AUTO_UPSTREAM=provider/model` crea e attiva
-il guarded nelle sessioni senza uno stato Jev salvato.
+Headless/CI: `JEV_MODE=automatic` parte già col gate attivo sul modello usato.
 
 Un hold `[JEV — OUTPUT NON PUBBLICATO]` interrompe intenzionalmente il turno:
 controlla `/jev last`. Non viene aggirato con un proseguimento automatico.
@@ -130,10 +109,9 @@ del proprietario). Così i controlli di ownership altrui non vedono mai una
 aborted` istantaneo). Quando il proprietario sostituisce l'oggetto, il nuovo
 viene patchato ex-novo agli hook (`input`, `before_agent_start`, `turn_start`,
 `model_select`, `message_end`); `/jev off` ripristina i metodi originali senza
-`unregister`. I twin restano visibili nel registry per le letture altrui
-(`jev-overlay-reassert` solo quando un oggetto nuovo viene patchato).
-In più, rete di sicurezza: se un id `__jev` sfugge comunque nel payload, il
-gate toglie il suffisso registrando `jev-gate-bypass` e avvisando in TUI,
+`unregister` (`jev-overlay-reassert` solo quando un oggetto nuovo viene patchato).
+Rete di sicurezza legacy: se un id `__jev` delle vecchie versioni sfugge nel
+payload, viene normalizzato al modello originale registrando `jev-gate-bypass`,
 perché quel turno non è passato dalla verifica.
 Le conferme per comandi di rete sospetti attendono invece una decisione esplicita;
 la normale sequenza tool → risposta successiva continua senza un nuovo prompt.
@@ -191,7 +169,7 @@ diventare “test passati”.
 
 #### Nuovi progetti: zero manifest locale
 
-Una volta, in una sessione col twin `automatic`, abilita la modalità scelta:
+Una volta, in una sessione pi, abilita la modalità scelta:
 
 ```text
 /jev verification repair
@@ -229,8 +207,8 @@ Dopo un edit il modello può scegliere solo id già acquisiti:
 ```
 
 Il tool LLM `jev_verify` ha lo stesso vincolo, richiede un progetto trusted e
-non accetta shell arbitraria. Footer/repair/hold operano nel twin
-`automatic`; `/jev verify` è utilizzabile manualmente anche senza footer.
+non accetta shell arbitraria. Footer/repair/hold operano in `automatic`;
+`/jev verify` è utilizzabile manualmente anche senza footer.
 
 #### Override per progetti speciali
 
@@ -282,7 +260,7 @@ quelle di `edit`/`write`: una modifica shell non viene attribuita al modello.
 ## Configurazione
 
 `~/.pi/agent/jev-config.json` (o `$JEV_CONFIG`). Env: `JEV_MODE`, `JEV_BACKEND`
-(`openrouter`|`typesafe`|`auto`), `JEV_MODEL`, `JEV_AUTO_UPSTREAM`.
+(`openrouter`|`typesafe`|`auto`), `JEV_MODEL`.
 Vedi `config/jev-config.example.json` per tutti i campi.
 
 Chiave Jev (ordine: env vince sul file): `OPENROUTER_API_KEY` o
@@ -324,9 +302,9 @@ echo '{"requirements":"...","candidate":"..."}' | npm run jev-check
 ## Limiti onesti
 
 - `pass` = "supera i controlli configurati", non "corretto". Compilazione e test restano necessari.
-- Il gate copre solo il twin `__jev` selezionato; in `automatic` la
-  selezione di altri modelli viene rifiutata con revert al twin.
-  (`/jev off` ripristina il provider originale intatto.)
+- Il gate copre i turni che passano dal provider patchato in `automatic`;
+  se un provider non è patchato (raro: sostituzione concorrente) il turno
+  passa con una nota `jev-guarded`/diagnostica dichiarata.
 - Soglie calibrate su 20 casi (`docs/calibration-2026-09-19.md`): buone per
   iniziare, da rivalutare con corpus più ampio.
 - Jev è un giudice probabilistico, non un verificatore formale.

package/config/jev-config.example.json

@@ -24,19 +24,7 @@
   "automatic": {
     "transport": "provider-gate",
     "maxRegenerations": 2,
-    "requireGuardedModel": true,
-    "twins": [
-      {
-        "provider": "deepseek",
-        "model": "deepseek-flash"
-      },
-      {
-        "provider": "openai-codex",
-        "model": "gpt-5.6-terra"
-      }
-    ],
-    "upstreamProvider": "deepseek",
-    "upstreamModel": "deepseek-flash"
+    "repairOnReview": true
   },
   "limits": {
     "maxPayloadBytes": 120000,