pi-jev-guard 0.3.3 → 0.5.0

package/README.md

@@ -6,6 +6,7 @@ Verifica le risposte con [TypeSafe Jev](https://docs.typesafe.ai) dentro [pi](ht
 - **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.
 - **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 esplicitamente autorizzati nel manifest locale; il modello può eseguire soltanto quegli id, mai shell arbitraria.
 
 ## Installazione
 
@@ -121,20 +122,19 @@ Verdetto **incerto** (`review`): il gate tenta prima una riparazione privata
 `policy.onUncertain` e `policy.onUnavailable` (`"hold"` default, oppure `"pass"`).
 Con `"pass"` il testo viene pubblicato con una nota di trasparenza sul verdetto.
 
-Se un'altra estensione ri-registra lo stesso provider (caso reale: `pi-accounts`
-al cambio account), l'overlay viene ricostruito sopra il provider live prima di
-ogni turno; in più il gate toglie il suffisso `__jev` da qualunque payload,
-registrando `jev-gate-bypass` e avvisando in TUI, perché quel turno non è
-passato dalla verifica.
-
-Coabitazione con `pi-accounts`: quell'estensione aborts i turni il cui modello
-non risulta nei modelli disponibili dell'account (`turn_start` → `ctx.abort()`,
-errore istantaneo `This operation was aborted`). Per questo i twin vengono
-registrati già all'evento `input`, prima di qualsiasi `before_agent_start`:
-quando pi-accounts legge il registry trova gli id `__jev` e non arma l'abort.
-Se vedi comunque quell'errore solo sui twin (il modello originale funziona),
-con un avviso `... is not available to account ...`, è quella gara di
-registrazione: apri un issue con le righe `jev-overlay-reassert` della sessione.
+Se un'altra estensione gestisce lo stesso provider (caso reale: `pi-accounts`
+con overlay auth su `openai-codex`), il gate NON ri-registra nulla: applica
+una patch in-place sull'oggetto provider live (stessa identità, stessa config
+del proprietario). Così i controlli di ownership altrui non vedono mai una
+"configuration changed" e non armano abort dei turni (`This operation was
+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,
+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.
 
@@ -181,6 +181,57 @@ le contraddizioni ad alta confidenza. Fail-open: se il verificatore non
 risponde, il testo passa senza nota. `/jev last` mostra anche l'esito
 grounding (`warned`/`repaired`/`held`).
 
+### Verifica progetto deterministica (opt-in)
+
+Il grounding è probabilistico; per **compilazione, lint e test** è meglio una
+prova deterministica. La verifica progetto mantiene, solo nella sessione,
+una lista di `edit`/`write` riusciti e degli esiti osservati dei check. Il
+footer della risposta viene generato dall'estensione, non dal modello:
+quindi non può trasformare un test non eseguito in “test passati”.
+
+1. Copia e adatta il manifest versionato/localmente controllato:
+
+```bash
+mkdir -p .pi
+cp config/jev-verification.example.json .pi/jev-verification.json
+```
+
+2. Controllalo tu e acquisiscilo nella sessione (o riacquisiscilo dopo una
+   modifica manuale):
+
+```text
+/jev verification reload
+/jev verification warn       # footer trasparente, nessuna rigenerazione
+# oppure: /jev verification repair|hold
+```
+
+3. Dopo un edit, il modello può eseguire soltanto gli id dichiarati nel
+   manifest — mai una shell string fornita dal modello:
+
+```text
+/jev verify recommended      # i check pertinenti non ancora freschi
+/jev verify all              # tutti, fino a verification.maxCommands
+/jev verify typecheck        # un id esplicito del manifest
+```
+
+Il tool LLM `jev_verify` ha lo stesso vincolo. Richiede un progetto trusted e
+non accetta comandi arbitrari. Footer/repair/hold operano nel twin in
+`automatic`; `/jev verify` può essere usato manualmente anche per controllare
+un progetto senza pubblicare un footer. Il manifest è acquisito a inizio sessione o
+con `/jev verification reload`; se cambia dopo, la verifica rifiuta di
+eseguire fino a una nuova acquisizione utente. `write`/`edit` del modello sul
+manifest sono bloccati; anche modifiche via shell vengono rilevate dal
+fingerprint e non aggiornano i comandi autorizzati. Il manifest è quindi una
+policy dell'utente/progetto, non una superficie di prompt injection.
+
+Modalità: `warn` aggiunge il footer; `repair` rigenera una volta con feedback
+che chiede di invocare `jev_verify`; `hold` trattiene le risposte quando un
+check è fallito, e dopo il tentativo bounded anche quando resta mancante.
+Nessun manifest o nessun check pertinente è una limitazione dichiarata, non
+un fallimento del codice e non produce hold. La raccolta delle modifiche è
+limitata a `edit`/`write` osservati: una modifica fatta con shell non viene
+attribuita automaticamente al modello.
+
 ## Configurazione
 
 `~/.pi/agent/jev-config.json` (o `$JEV_CONFIG`). Env: `JEV_MODE`, `JEV_BACKEND`
@@ -235,3 +286,6 @@ echo '{"requirements":"...","candidate":"..."}' | npm run jev-check
 - Il grounding controlla solo affermazioni verificabili sulla sessione
   (comandi, file, test, modifiche): niente fact-check di fatti esterni,
   e con contesti lunghi l'evidenza oltre budget viene elisa.
+- La verifica progetto dimostra solo i check dichiarati ed eseguiti dopo gli
+  `edit`/`write` osservati; non è una prova formale di correttezza, non vede
+  modifiche effettuate via shell e non sostituisce review umana.

package/config/jev-config.example.json

@@ -65,6 +65,15 @@
     "minConfidence": 0.6,
     "cacheSeconds": 120
   },
+  "verification": {
+    "enabled": false,
+    "mode": "warn",
+    "manifestPath": ".pi/jev-verification.json",
+    "maxRepairs": 1,
+    "commandTimeoutMs": 120000,
+    "outputChars": 6000,
+    "maxCommands": 3
+  },
   "exfilCheck": {
     "enabled": true,
     "tools": [

package/config/jev-verification.example.json

@@ -0,0 +1,22 @@
+{
+  "version": 1,
+  "checks": [
+    {
+      "id": "typecheck",
+      "description": "TypeScript static check",
+      "command": "npm run typecheck",
+      "files": ["src/**/*.ts", "extensions/**/*.ts", "test/**/*.ts"]
+    },
+    {
+      "id": "unit",
+      "description": "Unit tests",
+      "command": "npm run test:unit",
+      "files": ["src/**/*.ts", "extensions/**/*.ts", "test/**/*.ts"]
+    },
+    {
+      "id": "diff-check",
+      "description": "Whitespace and patch integrity",
+      "command": "git diff --check"
+    }
+  ]
+}