cc-viewer 1.6.182 → 1.6.183

package/concepts/it/Tool-CronList.md

@@ -0,0 +1,30 @@
+# CronList
+
+Elenca tutti i job cron pianificati tramite `CronCreate` nella sessione corrente. Restituisce un riepilogo di ogni cron attivo che include `id`, espressione cron, `prompt` abbreviato, flag `recurring`, flag `durable` e il prossimo orario di esecuzione.
+
+## Quando usare
+
+- Per verificare tutti i job attualmente pianificati prima di apportare modifiche o terminare una sessione.
+- Per trovare il corretto `id` di un job prima di chiamare `CronDelete` per eliminarlo.
+- Per diagnosticare perche un job atteso non si e mai avviato, confermandone l'esistenza e verificando il prossimo orario di esecuzione.
+- Per confermare che un job a esecuzione unica (non ricorrente) non si sia ancora attivato e sia ancora in attesa.
+
+## Parametri
+
+Nessuno.
+
+## Esempi
+
+### Esempio 1: verificare tutti i job pianificati
+
+Invocare `CronList` senza argomenti per ottenere l'elenco completo di tutti i job cron attivi. La risposta include per ogni job il suo `id`, l'espressione cron che ne definisce la pianificazione, una versione troncata del `prompt` che eseguira, se e `recurring` (ricorrente), se e `durable` (persistente tra i riavvii) e il prossimo orario di esecuzione previsto.
+
+### Esempio 2: individuare l'id di un task ricorrente specifico
+
+Se sono stati creati piu job cron e occorre eliminarne uno in particolare, invocare prima `CronList`. Scorrere l'elenco restituito per trovare il job il cui riepilogo del `prompt` e la cui espressione cron corrispondono al task da eliminare. Copiare il suo `id` e passarlo a `CronDelete`.
+
+## Note
+
+- Vengono elencati solo i job creati nella sessione corrente, a meno che non siano stati creati con `durable: true`, che ne consente la persistenza tra i riavvii di sessione.
+- Il campo `prompt` nel riepilogo e troncato; mostra solo l'inizio del testo completo del prompt, non il contenuto integrale.
+- I job a esecuzione unica (in cui `recurring` e `false`) che si sono gia attivati vengono eliminati automaticamente e non compaiono piu nell'elenco.

package/concepts/it/Tool-Edit.md

@@ -1,46 +1,38 @@
 # Edit
 
-## Definizione
+Esegue una sostituzione esatta di stringa all'interno di un file esistente. È il modo preferito per modificare i file perché viene trasmesso solo il diff, mantenendo le modifiche precise e verificabili.
 
-Modifica file tramite sostituzione esatta di stringhe. Sostituisce `old_string` con `new_string` nel file.
+## Quando usare
 
-## Parametri
+- Correggere un bug in una singola funzione senza riscrivere il file circostante
+- Aggiornare un valore di configurazione, una stringa di versione o un percorso di import
+- Rinominare un simbolo all'interno di un file con `replace_all`
+- Inserire un blocco vicino a un'àncora (espandi `old_string` per includere contesto circostante, poi fornisci la sostituzione)
+- Applicare piccole modifiche ben delimitate come parte di un refactor a più passi
 
-| Parametro | Tipo | Obbligatorio | Descrizione |
-|------|------|------|------|
-| `file_path` | string | Sì | Percorso assoluto del file da modificare |
-| `old_string` | string | Sì | Testo originale da sostituire |
-| `new_string` | string | Sì | Nuovo testo sostitutivo (deve essere diverso da old_string) |
-| `replace_all` | boolean | No | Se sostituire tutte le occorrenze, predefinito `false` |
+## Parametri
 
-## Scenari d'uso
+- `file_path` (string, obbligatorio): Percorso assoluto del file da modificare.
+- `old_string` (string, obbligatorio): Il testo esatto da cercare. Deve corrispondere carattere per carattere, inclusi spaziatura e indentazione.
+- `new_string` (string, obbligatorio): Il testo di sostituzione. Deve differire da `old_string`.
+- `replace_all` (boolean, opzionale): Quando `true`, sostituisce ogni occorrenza di `old_string`. Default `false`, che richiede che la corrispondenza sia unica.
 
-**Adatto per:**
-- Modificare sezioni specifiche di codice in file esistenti
-- Correggere bug, aggiornare la logica
-- Rinominare variabili (con `replace_all: true`)
-- Qualsiasi scenario che richieda la modifica precisa del contenuto di un file
+## Esempi
 
-**Non adatto per:**
-- Creare nuovi file — usare Write
-- Riscritture su larga scala — potrebbe essere necessario Write per sovrascrivere l'intero file
+### Esempio 1: Correggere un singolo call site
+Imposta `old_string` sulla riga esatta `const port = 3000;` e `new_string` su `const port = process.env.PORT ?? 3000;`. La corrispondenza è unica quindi `replace_all` può restare al default.
 
-## Note
+### Esempio 2: Rinominare un simbolo all'interno di un file
+Per rinominare `getUser` in `fetchUser` ovunque in `api.ts`, imposta `old_string: "getUser"`, `new_string: "fetchUser"` e `replace_all: true`.
 
-- Prima dell'uso è necessario aver letto il file tramite Read, altrimenti si verifica un errore
-- `old_string` deve essere unico nel file, altrimenti la modifica fallisce. Se non è unico, fornire più contesto per renderlo unico, oppure usare `replace_all`
-- Quando si modifica il testo, mantenere l'indentazione originale (tab/spazi), non includere il prefisso del numero di riga dall'output di Read
-- Preferire la modifica dei file esistenti anziché crearne di nuovi
-- `new_string` deve essere diverso da `old_string`
+### Esempio 3: Disambiguare uno snippet ripetuto
+Se `return null;` appare in diversi rami, allarga `old_string` per includere contesto circostante (ad esempio la riga `if` precedente) così che la corrispondenza sia unica. Altrimenti il tool darà errore piuttosto che indovinare.
 
-## Testo originale
-
-<textarea readonly>Performs exact string replacements in files.
+## Note
 
-Usage:
-- You must use your `Read` tool at least once in the conversation before editing. This tool will error if you attempt an edit without reading the file. 
-- When editing text from Read tool output, ensure you preserve the exact indentation (tabs/spaces) as it appears AFTER the line number prefix. The line number prefix format is: spaces + line number + tab. Everything after that tab is the actual file content to match. Never include any part of the line number prefix in the old_string or new_string.
-- ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required.
-- Only use emojis if the user explicitly requests it. Avoid adding emojis to files unless asked.
-- The edit will FAIL if `old_string` is not unique in the file. Either provide a larger string with more surrounding context to make it unique or use `replace_all` to change every instance of `old_string`.
-- Use `replace_all` for replacing and renaming strings across the file. This parameter is useful if you want to rename a variable for instance.</textarea>
+- Devi chiamare `Read` sul file almeno una volta nella sessione corrente prima che `Edit` accetti modifiche. I prefissi numerici di riga dell'output di `Read` non fanno parte del contenuto del file; non includerli in `old_string` o `new_string`.
+- Gli spazi bianchi devono corrispondere esattamente. Presta attenzione a tab contro spazi e spazi finali, specialmente in YAML, Makefile e Python.
+- Se `old_string` non è unico e `replace_all` è `false`, l'edit fallisce. O espandi il contesto o abilita `replace_all`.
+- Preferisci `Edit` a `Write` ogni volta che il file esiste già; `Write` sovrascrive l'intero file e perde contenuto non correlato se non stai attento.
+- Per più modifiche non correlate nello stesso file, emetti più chiamate `Edit` in sequenza piuttosto che una grande e fragile sostituzione.
+- Evita di introdurre emoji, testo promozionale o blocchi di documentazione non richiesti quando modifichi file sorgente.

package/concepts/it/Tool-EnterPlanMode.md

@@ -1,128 +1,35 @@
 # EnterPlanMode
 
-## Definizione
+Commuta la sessione in plan mode, una fase di esplorazione in sola lettura in cui l'assistente indaga il codebase e redige un piano di implementazione concreto da far approvare all'utente prima di modificare qualsiasi file.
 
-Passa Claude Code alla modalità pianificazione, utilizzata per esplorare il codebase e progettare un piano prima dell'implementazione.
+## Quando usare
+
+- L'utente richiede un cambiamento non banale che copre più file o sottosistemi.
+- I requisiti sono ambigui e l'assistente ha bisogno di leggere il codice prima di impegnarsi su un approccio.
+- Viene proposto un refactor, una migrazione o un upgrade di dipendenze e il raggio d'impatto non è chiaro.
+- L'utente dice esplicitamente "plan this", "facciamo prima un piano" o richiede una design review.
+- Il rischio è abbastanza elevato che procedere direttamente con le modifiche potrebbe sprecare lavoro o danneggiare lo stato.
 
 ## Parametri
 
-Nessun parametro.
+Nessuno. `EnterPlanMode` non accetta argomenti — invocalo con un oggetto parametri vuoto.
 
-## Scenari d'uso
+## Esempi
 
-**Adatto per:**
-- Implementazione di nuove funzionalità — richiede decisioni architetturali
-- Esistono più approcci possibili — richiede la scelta dell'utente
-- Le modifiche al codice influenzano il comportamento o la struttura esistente
-- Modifiche multi-file — potenzialmente coinvolgono 2-3 o più file
-- Requisiti poco chiari — necessario esplorare prima di comprendere l'ambito
-- Le preferenze dell'utente sono importanti — l'implementazione può avere più direzioni ragionevoli
+### Esempio 1: Richiesta di feature importante
 
-**Non adatto per:**
-- Correzioni di una o poche righe (errori di battitura, bug evidenti)
-- L'utente ha fornito istruzioni molto specifiche
-- Task puramente di ricerca/esplorazione — usare Task (tipo Explore)
+L'utente chiede: "Add SSO via Okta to the admin panel." L'assistente chiama `EnterPlanMode`, quindi dedica diversi turni alla lettura del middleware di autenticazione, archivio sessioni, route guard e UI di login esistente. Scrive un piano che descrive le modifiche richieste, i passi di migrazione e la copertura dei test, quindi lo sottomette via `ExitPlanMode` per l'approvazione.
 
-## Comportamento in modalità pianificazione
+### Esempio 2: Refactor rischioso
 
-Dopo l'ingresso in modalità pianificazione, Claude Code:
-1. Usa gli strumenti Glob, Grep, Read per esplorare in profondità il codebase
-2. Comprende i pattern e l'architettura esistenti
-3. Progetta il piano di implementazione
-4. Sottopone il piano all'approvazione dell'utente
-5. Se necessario, usa AskUserQuestion per chiarimenti
-6. Quando il piano è pronto, esce tramite ExitPlanMode
+L'utente dice: "Convert the REST controllers to tRPC." L'assistente entra in plan mode, esamina ogni controller, cataloga il contratto pubblico, elenca le fasi di rollout (shim, dual-read, cutover) e propone un piano di sequenziamento prima di toccare qualsiasi file.
 
 ## Note
 
-- Questo strumento richiede il consenso dell'utente per entrare in modalità pianificazione
-- In caso di dubbio sulla necessità di pianificare, preferire la pianificazione — allinearsi in anticipo è meglio che rifare il lavoro
-
-## Testo originale
-
-<textarea readonly>Use this tool proactively when you're about to start a non-trivial implementation task. Getting user sign-off on your approach before writing code prevents wasted effort and ensures alignment. This tool transitions you into plan mode where you can explore the codebase and design an implementation approach for user approval.
-
-## When to Use This Tool
-
-**Prefer using EnterPlanMode** for implementation tasks unless they're simple. Use it when ANY of these conditions apply:
-
-1. **New Feature Implementation**: Adding meaningful new functionality
-   - Example: "Add a logout button" - where should it go? What should happen on click?
-   - Example: "Add form validation" - what rules? What error messages?
-
-2. **Multiple Valid Approaches**: The task can be solved in several different ways
-   - Example: "Add caching to the API" - could use Redis, in-memory, file-based, etc.
-   - Example: "Improve performance" - many optimization strategies possible
-
-3. **Code Modifications**: Changes that affect existing behavior or structure
-   - Example: "Update the login flow" - what exactly should change?
-   - Example: "Refactor this component" - what's the target architecture?
-
-4. **Architectural Decisions**: The task requires choosing between patterns or technologies
-   - Example: "Add real-time updates" - WebSockets vs SSE vs polling
-   - Example: "Implement state management" - Redux vs Context vs custom solution
-
-5. **Multi-File Changes**: The task will likely touch more than 2-3 files
-   - Example: "Refactor the authentication system"
-   - Example: "Add a new API endpoint with tests"
-
-6. **Unclear Requirements**: You need to explore before understanding the full scope
-   - Example: "Make the app faster" - need to profile and identify bottlenecks
-   - Example: "Fix the bug in checkout" - need to investigate root cause
-
-7. **User Preferences Matter**: The implementation could reasonably go multiple ways
-   - If you would use AskUserQuestion to clarify the approach, use EnterPlanMode instead
-   - Plan mode lets you explore first, then present options with context
-
-## When NOT to Use This Tool
-
-Only skip EnterPlanMode for simple tasks:
-- Single-line or few-line fixes (typos, obvious bugs, small tweaks)
-- Adding a single function with clear requirements
-- Tasks where the user has given very specific, detailed instructions
-- Pure research/exploration tasks (use the Agent tool with explore agent instead)
-
-## What Happens in Plan Mode
-
-In plan mode, you'll:
-1. Thoroughly explore the codebase using Glob, Grep, and Read tools
-2. Understand existing patterns and architecture
-3. Design an implementation approach
-4. Present your plan to the user for approval
-5. Use AskUserQuestion if you need to clarify approaches
-6. Exit plan mode with ExitPlanMode when ready to implement
-
-## Examples
-
-### GOOD - Use EnterPlanMode:
-User: "Add user authentication to the app"
-- Requires architectural decisions (session vs JWT, where to store tokens, middleware structure)
-
-User: "Optimize the database queries"
-- Multiple approaches possible, need to profile first, significant impact
-
-User: "Implement dark mode"
-- Architectural decision on theme system, affects many components
-
-User: "Add a delete button to the user profile"
-- Seems simple but involves: where to place it, confirmation dialog, API call, error handling, state updates
-
-User: "Update the error handling in the API"
-- Affects multiple files, user should approve the approach
-
-### BAD - Don't use EnterPlanMode:
-User: "Fix the typo in the README"
-- Straightforward, no planning needed
-
-User: "Add a console.log to debug this function"
-- Simple, obvious implementation
-
-User: "What files handle routing?"
-- Research task, not implementation planning
-
-## Important Notes
-
-- This tool REQUIRES user approval - they must consent to entering plan mode
-- If unsure whether to use it, err on the side of planning - it's better to get alignment upfront than to redo work
-- Users appreciate being consulted before significant changes are made to their codebase
-</textarea>
+- La plan mode è in sola lettura per contratto. Durante la permanenza, l'assistente non deve eseguire `Edit`, `Write`, `NotebookEdit` o qualsiasi comando shell mutante. Usa solo `Read`, `Grep`, `Glob` e comandi `Bash` non distruttivi.
+- Non entrare in plan mode per modifiche banali da una riga, domande di pura ricerca o compiti in cui l'utente ha già specificato la modifica in dettaglio completo. L'overhead fa più male che bene.
+- In Auto mode, la plan mode è sconsigliata a meno che l'utente non la richieda esplicitamente — Auto mode preferisce l'azione alla pianificazione preventiva.
+- Usa la plan mode per ridurre le correzioni di rotta su lavoro costoso. Un piano di cinque minuti spesso salva un'ora di modifiche fuori strada.
+- Una volta in plan mode, concentra l'indagine sulle parti del sistema che cambieranno realmente. Evita tour esaustivi del repository non correlati al compito corrente.
+- Il piano stesso dovrebbe essere scritto su disco nel percorso che l'harness si aspetta così che `ExitPlanMode` possa sottometterlo. Il piano deve contenere percorsi di file concreti, nomi di funzioni e passi di verifica, non intenti vaghi.
+- L'utente può rifiutare il piano e chiedere revisioni. Itera all'interno della plan mode finché il piano non è accettato; solo allora esci.

package/concepts/it/Tool-EnterWorktree.md

@@ -1,56 +1,44 @@
 # EnterWorktree
 
-## Definizione
+Crea un worktree Git isolato su un nuovo branch, oppure commuta la sessione in un worktree esistente del repository corrente, così che il lavoro parallelo o sperimentale possa procedere senza toccare il checkout principale.
 
-Creates an isolated git worktree and switches the current session into it. Only used when the user explicitly asks to work in a worktree.
+## Quando usare
 
-## Parametri
-
-| Name | Type | Required | Description |
-|---|---|---|---|
-| name | string | No | A name for the worktree. If not provided, a random name is generated. |
-
-## Casi d'uso
+- L'utente dice esplicitamente "worktree" — ad esempio "start a worktree", "create a worktree" o "work in a worktree".
+- Le istruzioni di progetto in `CLAUDE.md` o nella memoria persistente indicano di usare un worktree per il compito corrente.
+- Vuoi continuare un compito precedentemente configurato come worktree (passa `path` per rientrarci).
+- Più branch sperimentali devono coesistere su disco senza un continuo cambio di checkout.
+- Un compito a lunga esecuzione dovrebbe essere isolato da modifiche non correlate nel working tree principale.
 
-**Adatto per:**
-- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree")
-
-**Non adatto per:**
-- The user asks to create/switch branches — use git commands instead
-- The user asks to fix a bug or work on a feature — use normal git workflow unless they specifically mention worktrees
-
-## Note
-
-- Must be in a git repository, or have WorktreeCreate/WorktreeRemove hooks configured
-- Must not already be in a worktree
-
-## Testo originale
-
-<textarea readonly>Use this tool ONLY when the user explicitly asks to work in a worktree. This tool creates an isolated git worktree and switches the current session into it.
+## Parametri
 
-## When to Use
+- `name` (string, opzionale): Un nome per una nuova directory worktree. Ogni segmento separato da `/` può contenere solo lettere, cifre, punti, underscore e trattini; la stringa completa è limitata a 64 caratteri. Se omesso e anche `path` è omesso, viene generato un nome casuale. Mutuamente esclusivo con `path`.
+- `path` (string, opzionale): Il percorso di filesystem di un worktree esistente del repository corrente su cui commutare. Deve apparire in `git worktree list` per questo repo; i percorsi che non sono worktree registrati del repo corrente vengono rifiutati. Mutuamente esclusivo con `name`.
 
-- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree", "use a worktree")
+## Esempi
 
-## When NOT to Use
+### Esempio 1: Creare un nuovo worktree con un nome descrittivo
 
-- The user asks to create a branch, switch branches, or work on a different branch — use git commands instead
-- The user asks to fix a bug or work on a feature — use normal git workflow unless they specifically mention worktrees
-- Never use this tool unless the user explicitly mentions "worktree"
+```
+EnterWorktree(name="feat/okta-sso")
+```
 
-## Requirements
+Crea `.claude/worktrees/feat/okta-sso` su un nuovo branch basato su `HEAD`, quindi commuta la working directory della sessione al suo interno. Tutte le modifiche ai file e i comandi shell successivi operano all'interno di quel worktree fino all'uscita.
 
-- Must be in a git repository, OR have WorktreeCreate/WorktreeRemove hooks configured in settings.json
-- Must not already be in a worktree
+### Esempio 2: Rientrare in un worktree esistente
 
-## Behavior
+```
+EnterWorktree(path="/Users/me/repo/.claude/worktrees/feat/okta-sso")
+```
 
-- In a git repository: creates a new git worktree inside `.claude/worktrees/` with a new branch based on HEAD
-- Outside a git repository: delegates to WorktreeCreate/WorktreeRemove hooks for VCS-agnostic isolation
-- Switches the session's working directory to the new worktree
-- On session exit, the user will be prompted to keep or remove the worktree
+Riprende il lavoro in un worktree precedentemente creato. Poiché ci sei entrato via `path`, `ExitWorktree` non lo eliminerà automaticamente — uscire con `action: "keep"` semplicemente riporta alla directory originale.
 
-## Parameters
+## Note
 
-- `name` (optional): A name for the worktree. If not provided, a random name is generated.
-</textarea>
+- Non chiamare `EnterWorktree` a meno che l'utente non l'abbia esplicitamente chiesto o le istruzioni di progetto lo richiedano. Normali cambi di branch o richieste di bug-fix dovrebbero usare comandi Git normali, non worktree.
+- Quando invocato all'interno di un repository Git, il tool crea un worktree sotto `.claude/worktrees/` e registra un nuovo branch basato su `HEAD`. Al di fuori di un repository Git, delega agli hook configurati `WorktreeCreate` / `WorktreeRemove` in `settings.json` per isolamento VCS-agnostico.
+- Solo una sessione worktree è attiva alla volta. Il tool rifiuta di funzionare se sei già dentro una sessione worktree; esci prima con `ExitWorktree`.
+- Usa `ExitWorktree` per uscire a metà sessione. Se la sessione termina mentre sei ancora dentro un worktree appena creato, all'utente viene chiesto se mantenerlo o rimuoverlo.
+- I worktree inseriti via `path` sono considerati esterni — `ExitWorktree` con `action: "remove"` non li eliminerà. È una protezione di sicurezza per proteggere i worktree che l'utente gestisce manualmente.
+- Un nuovo worktree eredita i contenuti del branch corrente ma ha una working directory e un indice indipendenti. Le modifiche staged e unstaged nel checkout principale non sono visibili all'interno del worktree.
+- Consiglio sui nomi: prefissa con il tipo di lavoro (`feat/`, `fix/`, `spike/`) così che più worktree concorrenti siano facili da distinguere in `git worktree list`.

package/concepts/it/Tool-ExitPlanMode.md

@@ -1,62 +1,42 @@
 # ExitPlanMode
 
-## Definizione
+Sottomette il piano di implementazione redatto durante la plan mode per l'approvazione dell'utente e — se approvato — fa transitare la sessione fuori dalla plan mode così che le modifiche possano iniziare.
 
-Esce dalla modalità pianificazione e sottopone il piano all'approvazione dell'utente. Il contenuto del piano viene letto dal file di piano scritto in precedenza.
+## Quando usare
 
-## Parametri
-
-| Parametro | Tipo | Obbligatorio | Descrizione |
-|------|------|------|------|
-| `allowedPrompts` | array | No | Lista di descrizioni dei permessi necessari per implementare il piano |
-
-Ogni elemento nell'array `allowedPrompts`:
-
-| Campo | Tipo | Obbligatorio | Descrizione |
-|------|------|------|------|
-| `tool` | enum | Sì | Lo strumento applicabile, attualmente supporta solo `Bash` |
-| `prompt` | string | Sì | Descrizione semantica dell'operazione (es. "run tests", "install dependencies") |
-
-## Scenari d'uso
+- Un piano scritto durante `EnterPlanMode` è completo e pronto per la revisione.
+- Il compito è focalizzato sull'implementazione (modifiche a codice o configurazione), non pura ricerca, quindi un piano esplicito è appropriato.
+- Tutte le letture e analisi prerequisite sono state effettuate; non serve ulteriore indagine prima che l'utente decida.
+- L'assistente ha enumerato percorsi di file, funzioni e passi concreti — non solo obiettivi.
+- L'utente ha chiesto di vedere il piano, o il workflow di plan mode sta per passare il controllo agli strumenti di editing.
 
-**Adatto per:**
-- In modalità pianificazione, il piano è completato e pronto per l'approvazione dell'utente
-- Solo per task di implementazione che richiedono la scrittura di codice
-
-**Non adatto per:**
-- Task puramente di ricerca/esplorazione — non è necessario uscire dalla modalità pianificazione
-- Voler chiedere all'utente "il piano va bene?" — questa è esattamente la funzione di questo strumento, non usare AskUserQuestion per chiederlo
-
-## Note
+## Parametri
 
-- Questo strumento non accetta il contenuto del piano come parametro — lo legge dal file di piano scritto in precedenza
-- L'utente vedrà il contenuto del file di piano per l'approvazione
-- Non usare AskUserQuestion per chiedere "il piano va bene?" prima di chiamare questo strumento, sarebbe ridondante
-- Non menzionare il "piano" nelle domande, poiché l'utente non può vedere il contenuto del piano prima di ExitPlanMode
+- `allowedPrompts` (array, opzionale): Prompt che l'utente può digitare nella schermata di approvazione per auto-approvare o alterare il piano. Ogni elemento specifica un permesso con scope (ad esempio, un nome di operazione e il tool a cui si applica). Lascia non impostato per usare il flusso di approvazione predefinito.
 
-## Testo originale
+## Esempi
 
-<textarea readonly>Use this tool when you are in plan mode and have finished writing your plan to the plan file and are ready for user approval.
+### Esempio 1: Sottomissione standard
 
-## How This Tool Works
-- You should have already written your plan to the plan file specified in the plan mode system message
-- This tool does NOT take the plan content as a parameter - it will read the plan from the file you wrote
-- This tool simply signals that you're done planning and ready for the user to review and approve
-- The user will see the contents of your plan file when they review it
+Dopo aver indagato un refactor di autenticazione all'interno della plan mode e aver scritto il file del piano su disco, l'assistente chiama `ExitPlanMode` senza argomenti. L'harness legge il piano dalla sua posizione canonica, lo mostra all'utente e attende approvazione o rifiuto.
 
-## When to Use This Tool
-IMPORTANT: Only use this tool when the task requires planning the implementation steps of a task that requires writing code. For research tasks where you're gathering information, searching files, reading files or in general trying to understand the codebase - do NOT use this tool.
+### Esempio 2: Azioni rapide pre-approvate
 
-## Before Using This Tool
-Ensure your plan is complete and unambiguous:
-- If you have unresolved questions about requirements or approach, use AskUserQuestion first (in earlier phases)
-- Once your plan is finalized, use THIS tool to request approval
+```
+ExitPlanMode(allowedPrompts=[
+  {"tool": "Bash", "prompt": "run tests"},
+  {"tool": "Bash", "prompt": "install dependencies"}
+])
+```
 
-**Important:** Do NOT use AskUserQuestion to ask "Is this plan okay?" or "Should I proceed?" - that's exactly what THIS tool does. ExitPlanMode inherently requests user approval of your plan.
+Permette all'utente di concedere in anticipo il permesso per comandi di follow-up di routine, così che l'assistente non debba fermarsi per ogni prompt di permesso durante l'implementazione.
 
-## Examples
+## Note
 
-1. Initial task: "Search for and understand the implementation of vim mode in the codebase" - Do not use the exit plan mode tool because you are not planning the implementation steps of a task.
-2. Initial task: "Help me implement yank mode for vim" - Use the exit plan mode tool after you have finished planning the implementation steps of the task.
-3. Initial task: "Add a new feature to handle user authentication" - If unsure about auth method (OAuth, JWT, etc.), use AskUserQuestion first, then use exit plan mode tool after clarifying the approach.
-</textarea>
+- `ExitPlanMode` ha senso solo per lavoro di tipo implementativo. Se la richiesta dell'utente è un compito di ricerca o spiegazione senza cambiamenti ai file, rispondi direttamente — non passare attraverso la plan mode solo per uscirne.
+- Il piano deve già essere scritto su disco prima di chiamare questo tool. `ExitPlanMode` non accetta il corpo del piano come parametro; legge dal percorso che l'harness si aspetta.
+- Se l'utente rifiuta il piano, ritorni in plan mode. Revisiona in base al feedback e sottometti di nuovo; non iniziare a modificare file mentre il piano non è approvato.
+- L'approvazione concede il permesso di lasciare la plan mode e usare strumenti mutanti (`Edit`, `Write`, `Bash` e così via) per lo scope descritto nel piano. Espandere lo scope successivamente richiede un nuovo piano o consenso esplicito dell'utente.
+- Non usare `AskUserQuestion` per chiedere "questo piano va bene?" prima di chiamare questo tool — richiedere l'approvazione del piano è esattamente ciò che fa `ExitPlanMode`, e l'utente non può vedere il piano fino a quando non viene sottomesso.
+- Mantieni il piano minimale e azionabile. Un revisore dovrebbe poterlo scorrere in meno di un minuto e capire esattamente cosa cambierà.
+- Se ti rendi conto durante l'implementazione che il piano era sbagliato, fermati e riferisci all'utente invece di deviare silenziosamente. Rientrare in plan mode è un passo successivo valido.

package/concepts/it/Tool-ExitWorktree.md

@@ -0,0 +1,41 @@
+# ExitWorktree
+
+Esce da una sessione di worktree creata in precedenza da `EnterWorktree` e riporta la sessione alla directory di lavoro originale. Questo strumento agisce esclusivamente sui worktree creati da `EnterWorktree` nella sessione corrente; se non è attiva alcuna sessione di questo tipo, la chiamata non ha effetto.
+
+## Quando usare
+
+- Il lavoro in un worktree isolato è terminato e si desidera tornare alla directory di lavoro principale.
+- Un'attività in un worktree di branch di funzionalità è completata e, dopo il merge, si vuole ripulire il branch e la directory.
+- Si desidera conservare il worktree per un uso successivo e tornare semplicemente alla directory originale senza eliminare nulla.
+- Si vuole abbandonare un branch sperimentale o temporaneo senza lasciare artefatti su disco.
+- È necessario avviare una nuova sessione `EnterWorktree`, il che richiede di uscire prima da quella corrente.
+
+## Parametri
+
+- `action` (stringa, obbligatorio): `"keep"` conserva la directory del worktree e il branch su disco per potervi tornare in seguito; `"remove"` elimina sia la directory sia il branch, eseguendo un'uscita pulita.
+- `discard_changes` (booleano, opzionale, predefinito `false`): Rilevante solo quando `action` è `"remove"`. Se il worktree contiene file non committati o commit assenti dal branch originale, lo strumento rifiuta la rimozione a meno che `discard_changes` non sia impostato su `true`. La risposta di errore elenca le modifiche specifiche in modo da poter confermare con l'utente prima di richiamare lo strumento.
+
+## Esempi
+
+### Esempio 1: uscita pulita dopo il merge delle modifiche
+
+Dopo aver terminato il lavoro in un worktree e aver eseguito il merge del branch nel main, chiama `ExitWorktree` con `action: "remove"` per eliminare la directory del worktree e il branch, e tornare alla directory di lavoro originale.
+
+```
+ExitWorktree(action: "remove")
+```
+
+### Esempio 2: eliminazione di un worktree temporaneo con codice sperimentale non committato
+
+Se un worktree contiene modifiche sperimentali non committate da scartare completamente, tenta prima `action: "remove"`. Lo strumento rifiuterà e elencherà le modifiche non committate. Dopo aver confermato con l'utente che le modifiche possono essere scartate, richiama con `discard_changes: true`.
+
+```
+ExitWorktree(action: "remove", discard_changes: true)
+```
+
+## Note
+
+- Questo strumento agisce esclusivamente sui worktree creati da `EnterWorktree` nella sessione corrente. Non influirà sui worktree creati con `git worktree add`, sui worktree di sessioni precedenti né sulla directory di lavoro normale se `EnterWorktree` non è mai stato chiamato — in questi casi la chiamata è priva di effetto.
+- `action: "remove"` viene rifiutato se il worktree ha modifiche non committate o commit non presenti nel branch originale, a meno che non venga fornito esplicitamente `discard_changes: true`. Conferma sempre con l'utente prima di impostare `discard_changes: true`, poiché i dati non possono essere recuperati.
+- Se una sessione tmux è collegata al worktree: con `remove` viene terminata; con `keep` continua a essere eseguita e il suo nome viene restituito affinché l'utente possa riconnettersi in seguito.
+- Al termine di `ExitWorktree`, è possibile chiamare nuovamente `EnterWorktree` per avviare una nuova sessione di worktree.

package/concepts/it/Tool-Glob.md

@@ -1,39 +1,35 @@
 # Glob
 
-## Definizione
+Abbina i nomi dei file a un pattern glob e restituisce i percorsi ordinati dal più recentemente modificato per primo. Ottimizzato per localizzare rapidamente i file in codebase di qualsiasi dimensione senza chiamare `find` via shell.
 
-Strumento veloce di corrispondenza per pattern di nomi file, supporta codebase di qualsiasi dimensione. Restituisce i percorsi dei file corrispondenti ordinati per data di modifica.
+## Quando usare
 
-## Parametri
+- Enumerare ogni file di una specifica estensione (ad esempio, tutti i file `*.ts` sotto `src`)
+- Scoprire file di configurazione o fixture per convenzione di denominazione (`**/jest.config.*`, `**/*.test.tsx`)
+- Restringere la superficie di ricerca prima di eseguire un `Grep` mirato
+- Verificare se un file esiste già a un pattern noto prima di chiamare `Write`
+- Trovare file toccati recentemente affidandosi all'ordinamento per tempo di modifica
 
-| Parametro | Tipo | Obbligatorio | Descrizione |
-|------|------|------|------|
-| `pattern` | string | Sì | Pattern glob (es. `**/*.js`, `src/**/*.ts`) |
-| `path` | string | No | Directory di ricerca, predefinita la directory di lavoro corrente. Non passare "undefined" o "null" |
+## Parametri
 
-## Scenari d'uso
+- `pattern` (string, obbligatorio): L'espressione glob da abbinare. Supporta `*` per wildcard a segmento singolo, `**` per corrispondenze ricorsive e `{a,b}` per alternative, ad esempio `src/**/*.{ts,tsx}`.
+- `path` (string, opzionale): Directory in cui eseguire la ricerca. Deve essere un percorso di directory valido quando fornito. Ometti interamente il campo per cercare nella working directory corrente. Non passare le stringhe `"undefined"` o `"null"`.
 
-**Adatto per:**
-- Cercare file per pattern di nome file
-- Trovare tutti i file di un tipo specifico (es. tutti i file `.tsx`)
-- Localizzare file quando si cerca una definizione di classe specifica (es. `class Foo`)
-- È possibile lanciare più chiamate Glob in parallelo in un singolo messaggio
+## Esempi
 
-**Non adatto per:**
-- Cercare contenuto di file — usare Grep
-- Esplorazione aperta che richiede più cicli di ricerca — usare Task (tipo Explore)
+### Esempio 1: Ogni file sorgente TypeScript
+Chiama `Glob` con `pattern: "src/**/*.ts"`. Il risultato è una lista ordinata per mtime, quindi i file modificati più di recente appaiono per primi, il che è utile per concentrarsi sugli hot spot.
 
-## Note
+### Esempio 2: Localizzare un candidato di definizione di classe
+Quando sospetti che una classe si trovi in un file di cui non conosci il nome, cerca con `pattern: "**/*UserService*"` per restringere i candidati, poi segui con `Read` o `Grep`.
 
-- Supporta la sintassi glob standard: `*` corrisponde a un livello, `**` a più livelli, `{}` per selezione multipla
-- I risultati sono ordinati per data di modifica
-- Più consigliato rispetto al comando `find` di Bash
+### Esempio 3: Scoperta parallela prima di un compito più grande
+In un unico messaggio, emetti più chiamate `Glob` (ad esempio una per `**/*.test.ts` e una per `**/fixtures/**`) così che entrambe vengano eseguite in parallelo e i loro risultati possano essere correlati.
 
-## Testo originale
+## Note
 
-<textarea readonly>- Fast file pattern matching tool that works with any codebase size
-- Supports glob patterns like "**/*.js" or "src/**/*.ts"
-- Returns matching file paths sorted by modification time
-- Use this tool when you need to find files by name patterns
-- When you are doing an open ended search that may require multiple rounds of globbing and grepping, use the Agent tool instead
-- You can call multiple tools in a single response. It is always better to speculatively perform multiple searches in parallel if they are potentially useful.</textarea>
+- I risultati sono ordinati per tempo di modifica del file (più recenti per primi), non alfabeticamente. Ordina a valle se ti serve un ordinamento stabile.
+- I pattern sono valutati dal tool, non dalla shell; non devi citarli o farne l'escape come faresti sulla riga di comando.
+- Per esplorazione aperta che richiede più cicli di ricerca e ragionamento, delega a un `Agent` con il tipo agente Explore invece di concatenare molte chiamate `Glob`.
+- Preferisci `Glob` a invocazioni `Bash` di `find` o `ls` per la scoperta di nomi di file; gestisce i permessi in modo coerente e restituisce output strutturato.
+- Quando cerchi contenuti all'interno dei file piuttosto che nomi di file, usa invece `Grep`.