pi-jev-guard 0.5.0 → 0.6.1

package/README.md

@@ -6,7 +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.
+- **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.
 
 ## Installazione
 
@@ -183,54 +183,101 @@ 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”.
+Il grounding è probabilistico; per **compilazione, lint e test** serve una
+prova deterministica. La verifica progetto conserva, solo nella sessione,
+`edit`/`write` riusciti e gli esiti osservati dei check. Il footer viene
+generato dall'estensione, non dal modello: un test non eseguito non può
+diventare “test passati”.
 
-1. Copia e adatta il manifest versionato/localmente controllato:
+#### Nuovi progetti: zero manifest locale
+
+Una volta, in una sessione col twin `automatic`, abilita la modalità scelta:
+
+```text
+/jev verification repair
+```
+
+Da quel momento ogni progetto usa questa precedenza:
+
+1. `.pi/jev-verification.json` locale, se presente;
+2. `verification.globalManifestPath`, se l'hai configurato nella config
+   utente;
+3. profilo integrato `common` (default).
+
+Il profilo `common` non legge comandi dal repository: abilita esclusivamente
+comandi fissi dell'estensione quando trova segnali convenzionali:
+
+| Rilevamento | Check disponibili |
+|---|---|
+| `package.json` con script | `npm run typecheck`, `npm run lint`, uno tra `npm run test:unit`, `npm run test:ci`, `npm test` |
+| `Cargo.toml` | `cargo check`, `cargo test` |
+| `go.mod` | `go test ./...` |
+| configurazione pytest | `python -m pytest` |
+| repository Git | `git diff --check` |
+
+Il profilo sceglie un solo ecosistema (Node → Rust → Go → Python) e aggiunge
+il check Git quando applicabile. I comandi sono bounded da
+`verification.maxCommands` (default `4`) e timeout. Se nessun segnale è
+rilevato, non esegue nulla e il footer dichiara la limitazione.
+
+Dopo un edit il modello può scegliere solo id già acquisiti:
+
+```text
+/jev verify recommended      # check pertinenti non ancora freschi
+/jev verify all              # tutti, fino a verification.maxCommands
+/jev verify node-typecheck   # un id esplicito della policy corrente
+```
+
+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.
+
+#### Override per progetti speciali
+
+Per una pipeline specifica, aggiungi un manifest al progetto: prevale sempre
+sul profilo globale.
 
 ```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):
+Controllalo tu, poi acquisiscilo (e ripeti dopo ogni 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:
+In alternativa puoi definire **una** policy comune per tutti i tuoi progetti
+nella config utente, purché esista davvero e sia sotto il tuo controllo:
 
-```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
+```json
+{
+  "verification": {
+    "globalManifestPath": "~/.pi/agent/jev-verification.global.json",
+    "defaultProfile": "common"
+  }
+}
 ```
 
-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.
+Un `globalManifestPath` configurato ma assente o malformato non degrada
+silenziosamente al profilo integrato: la verifica segnala l'errore. Per
+disattivare il fallback integrato imposta `"defaultProfile": "off"`.
+`/jev verification` e `/jev status` mostrano l'origine effettiva della policy.
+
+Manifest e profilo sono acquisiti a inizio sessione, all'attivazione esplicita
+o con `/jev verification reload`. Se un manifest, un `package.json` o un file
+di configurazione che abilita il profilo cambia dopo l'acquisizione, nessun
+check parte fino al reload utente. In automatic, con tool policy e verifica
+attive, `write`/`edit` del modello su tali file sono bloccati; una modifica via shell
+viene comunque rilevata dal fingerprint. Questo evita che il modello trasformi
+uno script o un manifest in un nuovo comando autorizzato.
 
 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.
+che chiede `jev_verify`; `hold` trattiene dopo una failure concreta, o dopo il
+tentativo bounded se restano check mancanti. Nessun check pertinente non è un
+fallimento del codice e non produce hold. Le modifiche rilevate restano solo
+quelle di `edit`/`write`: una modifica shell non viene attribuita al modello.
 
 ## Configurazione
 

package/config/jev-config.example.json

@@ -69,10 +69,11 @@
     "enabled": false,
     "mode": "warn",
     "manifestPath": ".pi/jev-verification.json",
+    "defaultProfile": "common",
     "maxRepairs": 1,
     "commandTimeoutMs": 120000,
     "outputChars": 6000,
-    "maxCommands": 3
+    "maxCommands": 4
   },
   "exfilCheck": {
     "enabled": true,

package/extensions/index.ts

@@ -68,16 +68,16 @@ import type { PostPublishCheckFn, PostPublishCheckResult } from "../src/automati
 import {
   buildVerificationStatus,
   createVerificationState,
-  isVerificationManifestPath,
+  isVerificationPolicyPath,
   decideVerificationAction,
-  loadVerificationManifest,
+  loadVerificationPolicy,
   manifestCheckForCommand,
   normalizeObservedPath,
   recordObservedModification,
   recordVerificationRun,
   selectVerificationChecks,
-  trustVerificationManifest,
-  trustedVerificationManifest,
+  trustVerificationPolicy,
+  trustedVerificationPolicy,
   type VerificationManifestTrust,
   type VerificationStatus,
 } from "../src/verification.ts";
@@ -225,18 +225,18 @@ export default function (pi: ExtensionAPI) {
 
   function captureVerificationManifest(cwd: string): VerificationManifestTrust {
     verificationCwd = cwd;
-    verificationManifestTrust = trustVerificationManifest(cwd, config.verification.manifestPath);
+    verificationManifestTrust = trustVerificationPolicy(cwd, config.verification);
     return verificationManifestTrust;
   }
 
   function verificationSnapshot(cwd: string): {
-    loaded: ReturnType<typeof loadVerificationManifest>;
+    loaded: ReturnType<typeof loadVerificationPolicy>;
     status: VerificationStatus;
   } {
-    const loaded = trustedVerificationManifest(
+    const loaded = trustedVerificationPolicy(
       verificationManifestTrust,
       cwd,
-      config.verification.manifestPath,
+      config.verification,
     );
     return { loaded, status: buildVerificationStatus(verificationState, loaded) };
   }
@@ -269,8 +269,8 @@ export default function (pi: ExtensionAPI) {
   }
 
   /**
-   * Esegue SOLO check estratti dal manifest locale validato. Questa funzione
-   * serve sia al tool del modello sia al comando utente /jev verify.
+   * Esegue SOLO check estratti dalla policy acquisita (locale, globale o
+   * profilo integrato). Serve sia al tool del modello sia a /jev verify.
    */
   async function runProjectVerification(args: {
     cwd: string;
@@ -405,7 +405,7 @@ export default function (pi: ExtensionAPI) {
     refs: TwinRef[],
     registry: ModelRegistry,
     persist: boolean,
-  ): { ok: boolean; error?: string; twins?: string[] } {
+  ): { ok: boolean; error?: string; stack?: string; twins?: string[] } {
     const byProvider = new Map<string, string[]>();
     for (const ref of refs) {
       const list = byProvider.get(ref.provider) ?? [];
@@ -443,6 +443,7 @@ export default function (pi: ExtensionAPI) {
           return {
             ok: false,
             error: error instanceof Error ? error.message : String(error),
+            ...(error instanceof Error && error.stack ? { stack: error.stack } : {}),
           };
         }
         overlays.set(providerId, { twinIds: [...twinIds], live });
@@ -466,6 +467,7 @@ export default function (pi: ExtensionAPI) {
       return {
         ok: false,
         error: error instanceof Error ? error.message : String(error),
+        ...(error instanceof Error && error.stack ? { stack: error.stack } : {}),
       };
     }
   }
@@ -483,7 +485,7 @@ export default function (pi: ExtensionAPI) {
     );
     refs.push({ provider: providerId, model: modelId });
     const res = applyTwins(refs, registry, true);
-    if (!res.ok) return { ok: false, error: res.error };
+    if (!res.ok) return { ok: false, error: res.error, ...(res.stack ? { stack: res.stack } : {}) };
     return { ok: true, twin: `${providerId}/${twinIdFor(modelId)}` };
   }
 
@@ -616,7 +618,10 @@ export default function (pi: ExtensionAPI) {
         enabled: config.verification.enabled,
         mode: config.verification.mode,
         manifestPath: config.verification.manifestPath,
-        ...(loaded.ok ? { manifestLoaded: true } : { manifestLoaded: false, manifestError: loaded.error }),
+        defaultProfile: config.verification.defaultProfile,
+        ...(loaded.ok
+          ? { manifestLoaded: true, manifestSource: loaded.source, manifestSourceLabel: loaded.sourceLabel }
+          : { manifestLoaded: false, manifestError: loaded.error }),
         changedFiles: status.changedFiles,
         checks: status.checks.map((item) => ({ id: item.check.id, state: item.state })),
       };
@@ -630,12 +635,16 @@ export default function (pi: ExtensionAPI) {
         next.verification.mode = mode;
       }
       saveConfig(next);
-      return refresh();
+      const refreshed = refresh();
+      // L'attivazione è un'azione utente esplicita: acquisisce gli input
+      // correnti del fallback invece di riusare una snapshot presa quando era off.
+      if (mode !== "off" && verificationCwd) captureVerificationManifest(verificationCwd);
+      return refreshed;
     },
     reloadVerificationManifest: (cwd) => {
       const trusted = captureVerificationManifest(cwd);
       return trusted.ok
-        ? { ok: true, path: trusted.path }
+        ? { ok: true, path: trusted.path, sourceLabel: trusted.sourceLabel }
         : { ok: false, error: trusted.error };
     },
     runVerification: ({ cwd, selection, signal, trusted }) =>
@@ -702,6 +711,14 @@ export default function (pi: ExtensionAPI) {
       if (overlays.size === 0) {
         const restored = refreshUpstream(ctx.modelRegistry);
         if (!restored.ok) {
+          try {
+            pi.appendEntry("jev-refresh-upstream-error", {
+              error: restored.error,
+              ...(restored.stack ? { stack: String(restored.stack).slice(0, 4000) } : {}),
+            });
+          } catch {
+            // solo diagnostica
+          }
           if (ctx.hasUI) {
             ctx.ui.notify(`Jev automatic senza guarded: ${restored.error} (diagnostica sola).`, "warning");
           }
@@ -982,18 +999,34 @@ export default function (pi: ExtensionAPI) {
 
       if (event.toolName === "write" || event.toolName === "edit") {
         const input = event.input as { path?: unknown };
-        if (isVerificationManifestPath(input.path, ctx.cwd, config.verification.manifestPath)) {
+        const profileInput = verificationManifestTrust?.ok && verificationManifestTrust.source === "global-profile";
+        if (
+          isVerificationPolicyPath(input.path, ctx.cwd, verificationManifestTrust) &&
+          // Il profilo comune è opt-in: non rendere package.json immutabile
+          // nelle installazioni che non hanno attivato la verifica progetto.
+          (!profileInput || config.verification.enabled)
+        ) {
+          const ruleId = profileInput
+            ? "verification-profile-input-immutable"
+            : "verification-manifest-immutable";
           pi.appendEntry("jev-tool-block", {
             tool: event.toolName,
-            ruleId: "verification-manifest-immutable",
+            ruleId,
             revision: TOOL_POLICY_REVISION,
           });
           if (ctx.hasUI) {
-            ctx.ui.notify("Jev tool policy: il modello non può modificare il manifest che autorizza i suoi check.", "warning");
+            ctx.ui.notify(
+              profileInput
+                ? "Jev tool policy: il modello non può modificare un file che decide i check del profilo globale acquisito."
+                : "Jev tool policy: il modello non può modificare il manifest che autorizza i suoi check.",
+              "warning",
+            );
           }
           return {
             block: true,
-            reason: "Bloccato da jev tool policy (verification-manifest-immutable): modifica il manifest manualmente e poi usa /jev verification reload.",
+            reason: profileInput
+              ? "Bloccato da jev tool policy (verification-profile-input-immutable): modifica manualmente la configurazione del progetto e poi usa /jev verification reload."
+              : "Bloccato da jev tool policy (verification-manifest-immutable): modifica il manifest manualmente e poi usa /jev verification reload.",
           };
         }
         const verdict = checkFilePath(input.path);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-jev-guard",
-  "version": "0.5.0",
+  "version": "0.6.1",
   "type": "module",
   "description": "Jev validation guard for pi: on-demand tool + automatic provider gate. Dual backend: TypeSafe direct + OpenRouter.",
   "keywords": [