failproofai 0.0.5-beta.0 → 0.0.6-beta.0

package/.next/standalone/docs/it/architecture.mdx

@@ -1,11 +1,12 @@
 ---
+
 ---
 title: Architettura
-description: "Come il gestore di hook, il caricamento della configurazione e la valutazione delle politiche funzionano internamente"
+description: "Come funzionano internamente il gestore hook, il caricamento della config e la valutazione delle policy"
 icon: sitemap
 ---
 
-Questo documento spiega come failproofai funziona internamente: come il sistema di hook intercetta le chiamate agli strumenti dell'agente, come viene caricata e unita la configurazione, come vengono valutate le politiche e come il dashboard monitora l'attività dell'agente.
+Questo documento spiega come failproofai funziona internamente: come il sistema di hook intercetta le chiamate agli strumenti dell'agente, come viene caricata e unita la configurazione, come vengono valutate le policy e come il dashboard monitora l'attività dell'agente.
 
 ---
 
@@ -13,14 +14,14 @@ Questo documento spiega come failproofai funziona internamente: come il sistema
 
 failproofai ha due sottosistemi indipendenti:
 
-1. **Gestore di hook** - Un veloce subprocess CLI che Claude Code richiama ad ogni chiamata dello strumento dell'agente. Valuta le politiche e restituisce una decisione.
-2. **Agent Monitor (Dashboard)** - Un'applicazione web Next.js per il monitoraggio delle sessioni dell'agente e la gestione delle politiche.
+1. **Hook handler** - Un veloce subprocess CLI che Claude Code invoca a ogni chiamata di strumento dell'agente. Valuta le policy e restituisce una decisione.
+2. **Agent Monitor (Dashboard)** - Un'applicazione web Next.js per monitorare le sessioni dell'agente e gestire le policy.
 
-Entrambi i sottosistemi condividono file di configurazione in `~/.failproofai/` e nella directory `.failproofai/` del progetto, ma vengono eseguiti come processi separati e comunicano solo tramite il filesystem.
+Entrambi i sottosistemi condividono i file di configurazione in `~/.failproofai/` e nella directory `.failproofai/` del progetto, ma vengono eseguiti come processi separati e comunicano solo attraverso il filesystem.
 
 ---
 
-## Gestore di hook
+## Hook handler
 
 ### Integrazione con Claude Code
 
@@ -45,7 +46,7 @@ Quando esegui `failproofai policies --install`, scrive voci come questa in `~/.c
 }
 ```
 
-Claude Code quindi richiama `failproofai --hook PreToolUse` come subprocess prima di ogni chiamata allo strumento, passando un payload JSON su stdin.
+Claude Code invoca quindi `failproofai --hook PreToolUse` come subprocess prima di ogni chiamata di strumento, passando un payload JSON su stdin.
 
 ### Formato del payload
 
@@ -61,9 +62,9 @@ Claude Code quindi richiama `failproofai --hook PreToolUse` come subprocess prim
 }
 ```
 
-Per eventi `PostToolUse`, il payload contiene anche `tool_result` con l'output dello strumento.
+Per gli eventi `PostToolUse`, il payload contiene anche `tool_result` con l'output dello strumento.
 
-Il gestore applica un limite di 1 MB per stdin. I payload che superano questo limite vengono scartati e tutte le politiche consentono implicitamente.
+L'handler applica un limite di stdin di 1 MB. I payload che superano questo limite vengono scartati e tutte le policy permettono implicitamente.
 
 ### Formato della risposta
 
@@ -95,17 +96,17 @@ Il gestore applica un limite di 1 MB per stdin. I payload che superano questo li
 }
 ```
 
-**Evento Stop instruct:**
+**Instruct per evento Stop:**
 - Exit code: `2`
 - Motivo scritto su stderr (non stdout)
 
 **Allow:**
 - Exit code: `0`
-- Stdout vuoto
+- stdout vuoto
 
-**Allow con messaggio (beta):**
+**Allow con messaggio:**
 
-A partire da v0.0.2-beta.3, `allow(message)` consente a una politica di inviare un contesto informativo a Claude anche quando l'operazione è consentita. Il gestore di hook scrive il seguente JSON su **stdout** (non in un file di configurazione — questa è la risposta del gestore a Claude Code, proprio come le risposte deny e instruct sopra):
+`allow(message)` consente a una policy di inviare contesto informativo a Claude anche quando l'operazione è consentita. L'hook handler scrive il seguente JSON su **stdout** (non su un file di config — questa è la risposta dell'handler a Claude Code, proprio come le risposte deny e instruct sopra):
 
 ```json
 // Written to stdout by the hook handler process
@@ -115,9 +116,9 @@ A partire da v0.0.2-beta.3, `allow(message)` consente a una politica di inviare
   }
 }
 ```
-- Exit code: `0` (l'operazione è consentita)
-- Quando più politiche restituiscono `allow` con un messaggio, i loro messaggi vengono uniti con newline in una singola stringa `additionalContext`
-- Se nessuna politica fornisce un messaggio, stdout è vuoto (come prima)
+- Exit code: `0` (operazione consentita)
+- Quando più policy restituiscono `allow` con un messaggio, i loro messaggi vengono uniti con newline in un'unica stringa `additionalContext`
+- Se nessuna policy fornisce un messaggio, stdout è vuoto (come prima)
 
 ### Pipeline di elaborazione
 
@@ -140,13 +141,13 @@ stdin JSON
   → exit
 ```
 
-L'intero processo viene eseguito in meno di 100ms per i payload tipici senza chiamate LLM.
+L'intero processo viene eseguito in meno di 100ms per payload tipici senza chiamate LLM.
 
 ---
 
 ## Caricamento della configurazione
 
-`src/hooks/hooks-config.ts` implementa il caricamento della configurazione a tre ambiti.
+`src/hooks/hooks-config.ts` implementa il caricamento della config a tre ambiti.
 
 ```text
 [1] {cwd}/.failproofai/policies-config.json        ← project  (highest priority)
@@ -155,39 +156,39 @@ L'intero processo viene eseguito in meno di 100ms per i payload tipici senza chi
 ```
 
 Logica di unione:
-- `enabledPolicies` - unione deduplicate tra tutti e tre i file
-- `policyParams` - per ogni politica, il primo file che la definisce vince completamente
-- `customPoliciesPath` - il primo file che la definisce vince
-- `llm` - il primo file che la definisce vince
+- `enabledPolicies` - unione deduplicated in tutti e tre i file
+- `policyParams` - per policy, il primo file che lo definisce vince completamente
+- `customPoliciesPath` - il primo file che lo definisce vince
+- `llm` - il primo file che lo definisce vince
 
-Il dashboard web utilizza `readHooksConfig()` (solo globale) per lettura e scrittura, poiché non viene richiamato con un cwd di progetto.
+Il dashboard web utilizza `readHooksConfig()` (solo globale) per leggere e scrivere, poiché non viene invocato con un cwd del progetto.
 
 ---
 
-## Valutazione delle politiche
+## Valutazione delle policy
 
-`src/hooks/policy-evaluator.ts` esegue le politiche in ordine.
+`src/hooks/policy-evaluator.ts` esegue le policy in ordine.
 
-Per ogni politica:
+Per ogni policy:
 
-1. Cerca lo schema `params` della politica (se ne ha uno).
-2. Legge `policyParams[policy.name]` dalla configurazione unita.
-3. Unisce i valori forniti dall'utente sui valori predefiniti dello schema per produrre `ctx.params`.
+1. Cerca lo schema `params` della policy (se ne ha uno).
+2. Leggi `policyParams[policy.name]` dalla config unita.
+3. Unisci i valori forniti dall'utente sui default dello schema per produrre `ctx.params`.
 4. Chiama `policy.fn(ctx)` con il contesto risolto.
-5. Se il risultato è `deny`, ferma immediatamente e restituisci quella decisione.
+5. Se il risultato è `deny`, fermati immediatamente e restituisci quella decisione.
 6. Se il risultato è `instruct`, accumula il messaggio e continua.
-7. Se il risultato è `allow`, continua alla politica successiva.
+7. Se il risultato è `allow`, continua con la policy successiva.
 
-Dopo che tutte le politiche vengono eseguite:
-- Se è stato restituito qualsiasi `deny`, emetti la risposta di deny.
-- Se sono stati raccolti risultati `instruct`, emetti una singola risposta instruct con tutti i messaggi uniti.
+Dopo che tutte le policy vengono eseguite:
+- Se è stato restituito un qualsiasi `deny`, emetti la risposta deny.
+- Se sono stati raccolti dei ritorni `instruct`, emetti un'unica risposta instruct con tutti i messaggi uniti.
 - Altrimenti, emetti una risposta allow (stdout vuoto, exit 0).
 
 ---
 
-## Politiche integrate
+## Policy built-in
 
-`src/hooks/builtin-policies.ts` definisce tutte le 26 politiche integrate come oggetti `BuiltinPolicyDefinition`:
+`src/hooks/builtin-policies.ts` definisce tutte le 26 policy built-in come oggetti `BuiltinPolicyDefinition`:
 
 ```typescript
 interface BuiltinPolicyDefinition {
@@ -205,13 +206,13 @@ interface BuiltinPolicyDefinition {
 }
 ```
 
-Le politiche che accettano `params` dichiarano un `PolicyParamsSchema` con tipi e valori predefiniti per ogni parametro. L'evaluator di politiche inietta i valori risolti in `ctx.params` prima di chiamare `fn`. Le funzioni di politica leggono `ctx.params` senza null-guarding perché i valori predefiniti vengono sempre applicati per primi.
+Le policy che accettano `params` dichiarano uno `PolicyParamsSchema` con tipi e default per ogni parametro. L'evaluator delle policy inietta i valori risolti in `ctx.params` prima di chiamare `fn`. Le funzioni delle policy leggono `ctx.params` senza null-guarding perché i default vengono sempre applicati per primi.
 
-Il pattern matching all'interno delle politiche utilizza token di comando parsati (argv), non corrispondenza di stringhe grezze. Questo previene il bypass tramite iniezione di operatori shell (ad esempio, un pattern per `sudo systemctl status *` non può essere bypassato aggiungendo `; rm -rf /` al comando).
+Il pattern matching all'interno delle policy utilizza token di comando analizzati (argv), non corrispondenza di stringhe grezze. Questo previene il bypass via iniezione di operatori shell (ad es. un pattern per `sudo systemctl status *` non può essere bypassato aggiungendo `; rm -rf /` al comando).
 
 ---
 
-## Politiche personalizzate
+## Policy personalizzate
 
 `src/hooks/custom-hooks-registry.ts` implementa un registro supportato da `globalThis`:
 
@@ -226,25 +227,25 @@ export function getCustomHooks(): CustomHook[] { ... }
 export function clearCustomHooks(): void { ... }  // used in tests
 ```
 
-`src/hooks/custom-hooks-loader.ts` carica il file di politica dell'utente:
+`src/hooks/custom-hooks-loader.ts` carica il file di policy dell'utente:
 
-1. Leggi `customPoliciesPath` dalla configurazione; salta se assente.
-2. Risolvi al percorso assoluto; verifica che il file esista.
+1. Leggi `customPoliciesPath` dalla config; salta se assente.
+2. Risolvi al percorso assoluto; controlla che il file esista.
 3. Riscrivi tutti gli import `from "failproofai"` al percorso dist effettivo in modo che `customPolicies` si risolva nello stesso registro `globalThis`.
 4. Riscrivi ricorsivamente gli import locali transitivi per garantire la compatibilità ESM.
 5. Scrivi file `.mjs` temporanei e `import()` il file di entry.
 6. Chiama `getCustomHooks()` per recuperare gli hook registrati.
-7. Pulisci tutti i file temporanei in un blocco `finally`.
+7. Pulisci tutti i file temp in un blocco `finally`.
 
-In caso di errore (file non trovato, errore di sintassi, errore di import), l'errore viene registrato in `~/.failproofai/hook.log` e il loader restituisce un array vuoto. Le politiche integrate non sono interessate.
+In caso di errore (file non trovato, errore di sintassi, errore di import), l'errore viene registrato in `~/.failproofai/hook.log` e il loader restituisce un array vuoto. Le policy built-in non ne sono interessate.
 
-Le politiche personalizzate vengono valutate dopo tutte le politiche integrate. Un `deny` di politica personalizzata continua a cortocircuitare ulteriori politiche personalizzate (ma tutte le integrate sono già state eseguite a questo punto).
+Le policy personalizzate vengono valutate dopo tutte le policy built-in. Un `deny` di policy personalizzata continua a fare short-circuit delle ulteriori policy personalizzate (ma tutte le built-in sono già state eseguite a questo punto).
 
 ---
 
-## Logging dell'attività
+## Registrazione dell'attività
 
-Dopo ogni evento di hook, il gestore aggiunge una riga JSONL a `~/.failproofai/hook-activity.jsonl`:
+Dopo ogni evento hook, l'handler aggiunge una riga JSONL a `~/.failproofai/hook-activity.jsonl`:
 
 ```json
 {
@@ -259,7 +260,7 @@ Dopo ogni evento di hook, il gestore aggiunge una riga JSONL a `~/.failproofai/h
 }
 ```
 
-Una riga per ogni politica che ha preso una decisione non-allow. Le decisioni allow non vengono registrate (per mantenere il file piccolo).
+Una riga per policy che ha preso una decisione non-allow. Le decisioni allow non vengono registrate (per mantenere il file piccolo).
 
 ---
 
@@ -287,16 +288,16 @@ app/
 
 **Flusso di dati:**
 
-- I componenti pagina chiamano `lib/projects.ts` e `lib/log-entries.ts` per leggere i dati di progetto/sessione direttamente dal filesystem (nessun livello API per le letture).
-- La pagina Policies utilizza Server Actions per tutte le mutazioni (toggle, aggiornamento params, installa/rimuovi).
-- Il visualizzatore di sessione parsifica il formato di trascritto JSONL di Claude e renderizza una timeline di messaggi e chiamate di strumenti.
+- I componenti pagina chiamano `lib/projects.ts` e `lib/log-entries.ts` per leggere i dati del progetto/sessione direttamente dal filesystem (nessun livello API per le letture).
+- La pagina Policies utilizza Server Actions per tutte le mutazioni (toggle, aggiornamento params, install/remove).
+- Il visualizzatore di sessione analizza il formato di trascritto JSONL di Claude e renderizza una timeline di messaggi e chiamate di strumento.
 
-**Decisioni di design chiave:**
+**Decisioni di progettazione chiave:**
 
 - Nessun database - tutto lo stato persistente è in file semplici (`~/.failproofai/`, `~/.claude/projects/`).
 - Server Actions per mutazioni - nessuna API REST necessaria per le operazioni CRUD.
-- React Server Components per pagine di lettura - caricamento iniziale più veloce, nessun bundle client per il recupero dati.
-- Componenti client solo dove è necessaria l'interattività (toggle di politiche, ricerca attività, visualizzatore di log).
+- React Server Components per le pagine di lettura - caricamento iniziale più veloce, nessun bundle client per il fetch dei dati.
+- Componenti client solo dove è necessaria l'interattività (toggle policy, ricerca attività, visualizzatore log).
 
 ---
 

package/.next/standalone/docs/it/configuration.mdx

@@ -1,29 +1,28 @@
 ---
----
 title: Configurazione
-description: "Formato del file di configurazione, sistema a tre scope e regole di merge"
+description: "Formato del file di configurazione, sistema a tre livelli e regole di merge"
 icon: gear
 ---
 
-failproofai utilizza file di configurazione JSON per controllare quali policy sono attive, come si comportano e da dove vengono caricate le policy personalizzate. La configurazione è progettata per essere facilmente condivisibile con il tuo team - committila nel tuo repository e ogni sviluppatore avrà la stessa rete di sicurezza per gli agenti.
+failproofai utilizza file di configurazione JSON per controllare quali policy sono attive, come si comportano e da dove vengono caricate le policy personalizzate. La configurazione è progettata per essere facile da condividere con il tuo team - commitla nel tuo repository e ogni sviluppatore otterrà la stessa rete di sicurezza per l'agent.
 
 ---
 
-## Scope di configurazione
+## Ambiti di configurazione
 
-Esistono tre scope di configurazione, valutati in ordine di priorità:
+Esistono tre ambiti di configurazione, valutati in ordine di priorità:
 
-| Scope | Percorso del file | Scopo |
-|-------|------------------|-------|
-| **project** | `.failproofai/policies-config.json` | Impostazioni per-repository, committate nel controllo di versione |
-| **local** | `.failproofai/policies-config.local.json` | Override personali per-repository, gitignored |
-| **global** | `~/.failproofai/policies-config.json` | Impostazioni predefinite a livello di utente su tutti i progetti |
+| Ambito | Percorso file | Scopo |
+|--------|---------------|-------|
+| **project** | `.failproofai/policies-config.json` | Impostazioni per-repo, committate nel controllo versione |
+| **local** | `.failproofai/policies-config.local.json` | Override personali per-repo, gitignored |
+| **global** | `~/.failproofai/policies-config.json` | Impostazioni predefinite a livello utente su tutti i progetti |
 
 Quando failproofai riceve un evento hook, carica e unisce tutti e tre i file che esistono per la directory di lavoro corrente.
 
 ### Regole di merge
 
-**`enabledPolicies`** - l'unione di tutti e tre gli scope. Una policy abilitata a qualsiasi livello è attiva.
+**`enabledPolicies`** - l'unione di tutti e tre gli ambiti. Una policy abilitata a qualsiasi livello è attiva.
 
 ```text
 project:  ["block-sudo"]
@@ -33,7 +32,7 @@ global:   ["block-sudo", "sanitize-api-keys"]
 resolved: ["block-sudo", "block-rm-rf", "sanitize-api-keys"]  ← unione deduplicated
 ```
 
-**`policyParams`** - il primo scope che definisce i parametri per una determinata policy vince completamente. Non c'è alcun deep merging dei valori all'interno dei parametri di una policy.
+**`policyParams`** - il primo ambito che definisce i parametri per una determinata policy vince completamente. Non esiste un merge profondo dei valori all'interno dei parametri di una policy.
 
 ```text
 project:  block-sudo → { allowPatterns: ["sudo apt-get update"] }
@@ -43,16 +42,16 @@ resolved: { allowPatterns: ["sudo apt-get update"] }   ← project vince, global
 ```
 
 ```text
-project:  (no block-sudo entry)
-local:    (no block-sudo entry)
+project:  (nessuna voce block-sudo)
+local:    (nessuna voce block-sudo)
 global:   block-sudo → { allowPatterns: ["sudo systemctl status"] }
 
-resolved: { allowPatterns: ["sudo systemctl status"] }  ← ricade a global
+resolved: { allowPatterns: ["sudo systemctl status"] }  ← ricade nel global
 ```
 
-**`customPoliciesPath`** - il primo scope che lo definisce vince.
+**`customPoliciesPath`** - il primo ambito che lo definisce vince.
 
-**`llm`** - il primo scope che lo definisce vince.
+**`llm`** - il primo ambito che lo definisce vince.
 
 ---
 
@@ -101,79 +100,79 @@ resolved: { allowPatterns: ["sudo systemctl status"] }  ← ricade a global
 
 ### `enabledPolicies`
 
-Type: `string[]`
+Tipo: `string[]`
 
-Elenco dei nomi delle policy da abilitare. I nomi devono corrispondere esattamente agli identificatori delle policy mostrati da `failproofai policies`. Vedi [Built-in Policies](/it/built-in-policies) per l'elenco completo.
+Elenco dei nomi delle policy da abilitare. I nomi devono corrispondere esattamente agli identificatori delle policy mostrati da `failproofai policies`. Consulta [Built-in Policies](/it/built-in-policies) per l'elenco completo.
 
 Le policy non in `enabledPolicies` sono inattive, anche se hanno voci in `policyParams`.
 
 ### `policyParams`
 
-Type: `Record<string, Record<string, unknown>>`
+Tipo: `Record<string, Record<string, unknown>>`
 
 Override dei parametri per-policy. La chiave esterna è il nome della policy; le chiavi interne sono specifiche della policy. Ogni policy documenta i suoi parametri disponibili in [Built-in Policies](/it/built-in-policies).
 
 Se una policy ha parametri ma non li specifichi, vengono utilizzati i valori predefiniti integrati della policy. Gli utenti che non configurano affatto `policyParams` ottengono un comportamento identico alle versioni precedenti.
 
-Le chiavi sconosciute all'interno del blocco parametri di una policy vengono silenziosamente ignorate al momento dell'attivazione dell'hook ma segnalate come avvisi quando esegui `failproofai policies`.
+Le chiavi sconosciute all'interno del blocco dei parametri di una policy vengono silenziosamente ignorate al momento dell'esecuzione dell'hook ma contrassegnate come avvisi quando esegui `failproofai policies`.
 
 #### `hint` (cross-cutting)
 
-Type: `string` (optional)
+Tipo: `string` (opzionale)
 
-Un messaggio aggiunto al motivo quando una policy restituisce `deny` o `instruct`. Usalo per dare a Claude una guida praticabile senza modificare la policy stessa.
+Un messaggio aggiunto al motivo quando una policy restituisce `deny` o `instruct`. Usalo per dare a Claude una guida pratica senza modificare la policy stessa.
 
-Funziona con qualsiasi tipo di policy — integrata, personalizzata (`custom/`), convenzione di progetto (`.failproofai-project/`), o convenzione utente (`.failproofai-user/`).
+Funziona con qualsiasi tipo di policy — built-in, personalizzata (`custom/`), convenzione progetto (`.failproofai-project/`), o convenzione utente (`.failproofai-user/`).
 
 ```json
 {
   "policyParams": {
     "block-force-push": {
-      "hint": "Try creating a fresh branch instead."
+      "hint": "Prova a creare un nuovo branch."
     },
     "block-sudo": {
       "allowPatterns": ["sudo apt-get"],
-      "hint": "Use apt-get directly without sudo."
+      "hint": "Usa apt-get direttamente senza sudo."
     },
     "custom/my-policy": {
-      "hint": "Ask the user for approval first."
+      "hint": "Chiedi prima l'approvazione all'utente."
     }
   }
 }
 ```
 
-Quando `block-force-push` nega, Claude vede: *"Force-pushing is blocked. Try creating a fresh branch instead."*
+Quando `block-force-push` nega, Claude vede: *"Il force-push è bloccato. Prova a creare un nuovo branch."*
 
-I valori non stringa e le stringhe vuote vengono silenziosamente ignorate. Se `hint` non è impostato, il comportamento non cambia (retrocompatibile).
+I valori non-string e le stringhe vuote vengono silenziosamente ignorate. Se `hint` non è impostato, il comportamento è invariato (backward-compatible).
 
 ### `customPoliciesPath`
 
-Type: `string` (absolute path)
+Tipo: `string` (percorso assoluto)
 
-Percorso a un file JavaScript contenente policy hook personalizzate. Viene impostato automaticamente da `failproofai policies --install --custom <path>` (il percorso viene risolto a assoluto prima di essere archiviato).
+Percorso di un file JavaScript contenente policy hook personalizzate. Viene impostato automaticamente da `failproofai policies --install --custom <path>` (il percorso viene risolto in assoluto prima di essere archiviato).
 
-Il file viene caricato nuovo su ogni evento hook - non c'è caching. Vedi [Custom Policies](/it/custom-policies) per i dettagli di authoring.
+Il file viene caricato da zero su ogni evento hook - non esiste alcun caching. Consulta [Custom Policies](/it/custom-policies) per i dettagli sulla creazione.
 
-### Policy basate su convenzione (v0.0.2-beta.7+)
+### Policy basate su convenzione
 
 Oltre al `customPoliciesPath` esplicito, failproofai scopre e carica automaticamente i file di policy dalle directory `.failproofai/policies/`:
 
-| Livello | Directory | Scope |
-|---------|-----------|-------|
-| Project | `.failproofai/policies/` | Condiviso con il team via controllo di versione |
-| User | `~/.failproofai/policies/` | Personale, si applica a tutti i progetti |
+| Livello | Directory | Ambito |
+|---------|-----------|--------|
+| Progetto | `.failproofai/policies/` | Condiviso con il team tramite controllo versione |
+| Utente | `~/.failproofai/policies/` | Personale, si applica a tutti i progetti |
 
-**File matching:** Solo i file corrispondenti a `*policies.{js,mjs,ts}` vengono caricati (ad es. `security-policies.mjs`, `workflow-policies.js`). Gli altri file nella directory vengono ignorati.
+**Corrispondenza file:** Solo i file che corrispondono a `*policies.{js,mjs,ts}` vengono caricati (ad es. `security-policies.mjs`, `workflow-policies.js`). Gli altri file nella directory vengono ignorati.
 
-**Nessuna configurazione necessaria:** Le policy di convenzione non richiedono voci in `policies-config.json`. Basta eliminare i file nella directory e verranno raccolti al prossimo evento hook.
+**Nessuna configurazione necessaria:** Le policy di convenzione non richiedono voci in `policies-config.json`. Basta depositare file nella directory e verranno caricati al prossimo evento hook.
 
-**Union loading:** Entrambe le directory di convenzione di progetto e utente vengono scansionate. Tutti i file corrispondenti da entrambi i livelli vengono caricati (a differenza di `customPoliciesPath` che utilizza first-scope-wins).
+**Caricamento union:** Entrambe le directory di convenzione progetto e utente vengono scansionate. Tutti i file corrispondenti da entrambi i livelli vengono caricati (a differenza di `customPoliciesPath` che utilizza il primo ambito che vince).
 
-Vedi [Custom Policies](/it/custom-policies) per ulteriori dettagli ed esempi.
+Consulta [Custom Policies](/it/custom-policies) per ulteriori dettagli ed esempi.
 
 ### `llm`
 
-Type: `object` (optional)
+Tipo: `object` (opzionale)
 
 Configurazione del client LLM per le policy che effettuano chiamate AI. Non richiesto per la maggior parte delle configurazioni.
 
@@ -188,7 +187,7 @@ Configurazione del client LLM per le policy che effettuano chiamate AI. Non rich
 
 ---
 
-## Gestione della configurazione da CLI
+## Gestione della configurazione dalla CLI
 
 I comandi `policies --install` e `policies --uninstall` scrivono nel `settings.json` di Claude Code (i punti di ingresso dell'hook), mentre `policies-config.json` è il file che gestisci direttamente. I due sono separati:
 
@@ -199,9 +198,9 @@ Puoi modificare `policies-config.json` direttamente in qualsiasi momento; le mod
 
 ---
 
-## Esempio: config a livello di progetto con impostazioni predefinite del team
+## Esempio: configurazione a livello di progetto con impostazioni predefinite del team
 
-Committa `.failproofai/policies-config.json` nel tuo repo:
+Committa `.failproofai/policies-config.json` nel tuo repository:
 
 ```json
 {
@@ -220,4 +219,4 @@ Committa `.failproofai/policies-config.json` nel tuo repo:
 }
 ```
 
-Ogni sviluppatore può quindi creare `.failproofai/policies-config.local.json` (gitignored) per override personali senza influenzare i compagni di squadra.
+Ogni sviluppatore può quindi creare `.failproofai/policies-config.local.json` (gitignored) per gli override personali senza influenzare i compagni di squadra.