speccrew 0.5.10 → 0.5.11

package/docs/GETTING-STARTED.it.md

@@ -1,4 +1,4 @@
-# Guida Introduttiva SpecCrew
+# Guida Rapida all'Avvio di SpecCrew
 
 <p align="center">
   <a href="./GETTING-STARTED.md">简体中文</a> |
@@ -14,11 +14,11 @@
   <a href="./GETTING-STARTED.ar.md">العربية</a>
 </p>
 
-Questo documento ti aiuta a comprendere rapidamente come utilizzare il team Agent di SpecCrew per completare l'intero ciclo di sviluppo dai requisiti alla consegna seguendo i processi di ingegneria standard.
+Questo documento ti aiuta a comprendere rapidamente come utilizzare il team di Agenti di SpecCrew per completare lo sviluppo completo dai requisiti alla consegna seguendo processi di ingegneria standard.
 
 ---
 
-## 1. Preparazione
+## 1. Prerequisiti
 
 ### Installare SpecCrew
 
@@ -34,35 +34,110 @@ speccrew init --ide qoder
 
 IDE supportati: `qoder`, `cursor`, `claude`, `codex`
 
-### Struttura Directory Dopo l'Inizializzazione
+### Struttura delle Directory Dopo l'Inizializzazione
 
 ```
 .
 ├── .qoder/
-│   ├── agents/          # File di definizione Agent
-│   └── skills/          # File di definizione Skill
+│   ├── agents/          # File di definizione degli Agenti
+│   └── skills/          # File di definizione degli Skills
 ├── speccrew-workspace/  # Workspace
 │   ├── docs/            # Configurazioni, regole, template, soluzioni
 │   ├── iterations/      # Iterazioni in corso
 │   ├── iteration-archives/  # Iterazioni archiviate
 │   └── knowledges/      # Base di conoscenza
-│       ├── base/        # Informazioni base (rapporti diagnostica, debito tecnico)
-│       ├── bizs/        # Base conoscenza business
-│       └── techs/       # Base conoscenza tecnica
+│       ├── base/        # Informazioni di base (rapporti di diagnosi, debiti tecnici)
+│       ├── bizs/        # Base di conoscenza di business
+│       └── techs/       # Base di conoscenza tecnica
 ```
 
-### Riferimento Rapido Comandi CLI
+### Riferimento Rapido dei Comandi CLI
 
 | Comando | Descrizione |
-|---------|-------------|
-| `speccrew list` | Elenca tutti gli Agent e Skill disponibili |
+|------|------|
+| `speccrew list` | Elenca tutti gli Agenti e Skills disponibili |
 | `speccrew doctor` | Verifica l'integrità dell'installazione |
 | `speccrew update` | Aggiorna la configurazione del progetto all'ultima versione |
 | `speccrew uninstall` | Disinstalla SpecCrew |
 
 ---
 
-## 2. Panoramica Workflow
+## 2. Avvio Rapido in 5 Minuti Dopo l'Installazione
+
+Dopo aver eseguito `speccrew init`, segui questi passaggi per entrare rapidamente in stato di lavoro:
+
+### Passaggio 1: Scegli il Tuo IDE
+
+| IDE | Comando di Inizializzazione | Scenario di Applicazione |
+|-----|-----------|----------|
+| **Qoder** (Consigliato) | `speccrew init --ide qoder` | Orchestrazione completa degli agenti, worker paralleli |
+| **Cursor** | `speccrew init --ide cursor` | Workflow basati su Composer |
+| **Claude Code** | `speccrew init --ide claude` | Sviluppo CLI-first |
+| **Codex** | `speccrew init --ide codex` | Integrazione ecosistema OpenAI |
+
+### Passaggio 2: Inizializzare la Base di Conoscenza (Consigliato)
+
+Per progetti con codice sorgente esistente, si consiglia di inizializzare prima la base di conoscenza in modo che gli agenti comprendano il tuo codebase:
+
+```
+@speccrew-team-leader inizializza base di conoscenza tecnica
+```
+
+Poi:
+
+```
+@speccrew-team-leader inizializza base di conoscenza di business
+```
+
+### Passaggio 3: Inizia il Tuo Primo Compito
+
+```
+@speccrew-product-manager Ho un nuovo requisito: [descrivi il tuo requisito funzionale]
+```
+
+> **Suggerimento**: Se non sei sicuro di cosa fare, dì semplicemente `@speccrew-team-leader aiutami a iniziare` — il Team Leader rileverà automaticamente lo stato del tuo progetto e ti guiderà.
+
+---
+
+## 3. Albero di Decisione Rapido
+
+Non sei sicuro di cosa fare? Trova il tuo scenario qui sotto:
+
+- **Ho un nuovo requisito funzionale**
+  → `@speccrew-product-manager Ho un nuovo requisito: [descrivi il tuo requisito funzionale]`
+
+- **Voglio scansionare la conoscenza del progetto esistente**
+  → `@speccrew-team-leader inizializza base di conoscenza tecnica`
+  → Poi: `@speccrew-team-leader inizializza base di conoscenza di business`
+
+- **Voglio continuare il lavoro precedente**
+  → `@speccrew-team-leader qual è lo stato di avanzamento attuale?`
+
+- **Voglio verificare lo stato di salute del sistema**
+  → Esegui nel terminale: `speccrew doctor`
+
+- **Non sono sicuro di cosa fare**
+  → `@speccrew-team-leader aiutami a iniziare`
+  → Il Team Leader rileverà automaticamente lo stato del tuo progetto e ti guiderà
+
+---
+
+## 4. Riferimento Rapido degli Agenti
+
+| Ruolo | Agente | Responsabilità | Esempio di Comando |
+|------|-------|-----------------|-----------------|
+| Capo Team | `@speccrew-team-leader` | Navigazione progetto, inizializzazione base di conoscenza, verifica stato | "Aiutami a iniziare" |
+| Product Manager | `@speccrew-product-manager` | Analisi dei requisiti, generazione PRD | "Ho un nuovo requisito: ..." |
+| Designer Funzionalità | `@speccrew-feature-designer` | Analisi funzionale, progettazione specifiche, contratti API | "Avvia progettazione funzionalità per iterazione X" |
+| Designer di Sistema | `@speccrew-system-designer` | Progettazione architettura, progettazione dettagliata per piattaforma | "Avvia progettazione sistema per iterazione X" |
+| Sviluppatore di Sistema | `@speccrew-system-developer` | Coordinamento sviluppo, generazione codice | "Avvia sviluppo per iterazione X" |
+| Responsabile Test | `@speccrew-test-manager` | Pianificazione test, progettazione casi, esecuzione | "Avvia test per iterazione X" |
+
+> **Nota**: Non devi ricordare tutti gli agenti. Basta parlare con `@speccrew-team-leader` e instraderà la tua richiesta all'agente giusto.
+
+---
+
+## 5. Panoramica del Workflow
 
 ### Diagramma di Flusso Completo
 
@@ -71,10 +146,10 @@ flowchart LR
     PRD[Fase 1<br/>Analisi Requisiti<br/>Product Manager] --> FD[Fase 2<br/>Feature Design<br/>Feature Designer]
     FD --> SD[Fase 3<br/>System Design<br/>System Designer]
     SD --> DEV[Fase 4<br/>Sviluppo<br/>System Developer]
-    DEV --> TEST[Fase 5<br/>Test Sistema<br/>Test Manager]
+    DEV --> TEST[Fase 5<br/>Test di Sistema<br/>Test Manager]
     TEST --> ARCHIVE[Fase 6<br/>Archiviazione]
     
-    KB[(Base Conoscenza<br/>Throughout)] -.-> PRD
+    KB[(Base di Conoscenza<br/>Per Tutto il Processo)] -.-> PRD
     KB -.-> FD
     KB -.-> SD
     KB -.-> DEV
@@ -83,50 +158,50 @@ flowchart LR
 
 ### Principi Fondamentali
 
-1. **Dipendenze di Fase**: I deliverable di ogni fase sono l'input per la fase successiva
+1. **Dipendenze tra Fasi**: Il deliverable di ogni fase è l'input per la fase successiva
 2. **Conferma Checkpoint**: Ogni fase ha un punto di conferma che richiede l'approvazione dell'utente prima di procedere alla fase successiva
-3. **Guidato da Base Conoscenza**: La base di conoscenza percorre l'intero processo, fornendo contesto per tutte le fasi
+3. **Guidato dalla Base di Conoscenza**: La base di conoscenza attraversa l'intero processo, fornendo contesto per tutte le fasi
 
 ---
 
-## 3. Inizializzazione Base Conoscenza
+## 6. Passaggio Zero: Inizializzazione della Base di Conoscenza
 
-Prima di iniziare il processo di ingegneria formale, devi inizializzare la base di conoscenza del progetto.
+Prima di avviare il processo di ingegneria formale, è necessario inizializzare la base di conoscenza del progetto.
 
-### 3.1 Inizializzazione Base Conoscenza Tecnica
+### 6.1 Inizializzazione della Base di Conoscenza Tecnica
 
-**Esempio Conversazione**:
+**Esempio di Conversazione**:
 ```
-@speccrew-team-leader inizializzare la base conoscenza tecnica
+@speccrew-team-leader inizializza base di conoscenza tecnica
 ```
 
 **Processo in Tre Fasi**:
-1. Rilevamento Piattaforma — Identificare le piattaforme tecnologiche nel progetto
+1. Rilevamento Piattaforma — Identificare le piattaforme tecniche nel progetto
 2. Generazione Documentazione Tecnica — Generare documenti di specifica tecnica per ogni piattaforma
 3. Generazione Indice — Stabilire l'indice della base di conoscenza
 
 **Deliverable**:
 ```
 speccrew-workspace/knowledges/techs/{platform-id}/
-├── tech-stack.md          # Definizione stack tecnologico
+├── tech-stack.md          # Definizione dello stack tecnologico
 ├── architecture.md        # Convenzioni architetturali
 ├── dev-spec.md            # Specifiche di sviluppo
 ├── test-spec.md           # Specifiche di test
 └── INDEX.md               # File indice
 ```
 
-### 3.2 Inizializzazione Base Conoscenza Business
+### 6.2 Inizializzazione della Base di Conoscenza di Business
 
-**Esempio Conversazione**:
+**Esempio di Conversazione**:
 ```
-@speccrew-team-leader inizializzare la base conoscenza business
+@speccrew-team-leader inizializza base di conoscenza di business
 ```
 
 **Processo in Quattro Fasi**:
 1. Inventario Funzionalità — Scansionare il codice per identificare tutte le funzionalità
-2. Analisi Funzionalità — Analizzare la logica business per ogni funzionalità
-3. Riepilogo Moduli — Riassumere le funzionalità per modulo
-4. Riepilogo Sistema — Generare una panoramica business a livello di sistema
+2. Analisi Funzionalità — Analizzare la logica di business per ogni funzionalità
+3. Riepilogo per Modulo — Riepilogare le funzionalità per modulo
+4. Riepilogo di Sistema — Generare panoramica di business a livello di sistema
 
 **Deliverable**:
 ```
@@ -139,47 +214,47 @@ speccrew-workspace/knowledges/bizs/
 
 ---
 
-## 4. Guida Conversazione Fase per Fase
+## 7. Guida alla Conversazione Fase per Fase
 
-### 4.1 Fase 1: Analisi Requisiti (Product Manager)
+### 7.1 Fase 1: Analisi dei Requisiti (Product Manager)
 
-**Come Iniziare**:
+**Come Avviare**:
 ```
 @speccrew-product-manager Ho un nuovo requisito: [descrivi il tuo requisito]
 ```
 
-**Workflow Agent**:
+**Workflow dell'Agente**:
 1. Leggere la panoramica del sistema per comprendere i moduli esistenti
-2. Analizzare i requisiti utente
+2. Analizzare i requisiti dell'utente
 3. Generare documento PRD strutturato
 
 **Deliverable**:
 ```
 iterations/{numero}-{tipo}-{nome}/01.product-requirement/
-├── [feature-name]-prd.md           # Documento Requisiti Prodotto
+├── [feature-name]-prd.md           # Documento Product Requirements
 └── [feature-name]-bizs-modeling.md # Modellazione business (per requisiti complessi)
 ```
 
 **Checklist di Conferma**:
 - [ ] La descrizione del requisito riflette accuratamente l'intento dell'utente?
-- [ ] Le regole business sono complete?
+- [ ] Le regole di business sono complete?
 - [ ] I punti di integrazione con i sistemi esistenti sono chiari?
 - [ ] I criteri di accettazione sono misurabili?
 
 ---
 
-### 4.2 Fase 2: Feature Design (Feature Designer)
+### 7.2 Fase 2: Feature Design (Feature Designer)
 
-**Come Iniziare**:
+**Come Avviare**:
 ```
-@speccrew-feature-designer iniziare il feature design
+@speccrew-feature-designer avvia feature design
 ```
 
-**Workflow Agent**:
-1. Localizzare automaticamente il documento PRD confermato
-2. Caricare la base conoscenza business
+**Workflow dell'Agente**:
+1. Individuare automaticamente il documento PRD confermato
+2. Caricare la base di conoscenza di business
 3. Generare feature design (inclusi wireframe UI, flussi di interazione, definizioni dati, contratti API)
-4. Per PRD multipli, usare Task Worker per design parallelo
+4. Per più PRD, usare Task Worker per progettazione parallela
 
 **Deliverable**:
 ```
@@ -195,55 +270,55 @@ iterations/{iter}/02.feature-design/
 
 ---
 
-### 4.3 Fase 3: System Design (System Designer)
+### 7.3 Fase 3: System Design (System Designer)
 
-**Come Iniziare**:
+**Come Avviare**:
 ```
-@speccrew-system-designer iniziare il system design
+@speccrew-system-designer avvia system design
 ```
 
-**Workflow Agent**:
-1. Localizzare Feature Spec e Contratto API
-2. Caricare la base conoscenza tecnica (stack tech, architettura, specifiche per ogni piattaforma)
-3. **Checkpoint A**: Valutazione Framework — Analizzare i gap tecnici, raccomandare nuovi framework (se necessario), attendere conferma utente
+**Workflow dell'Agente**:
+1. Individuare Feature Spec e API Contract
+2. Caricare la base di conoscenza tecnica (stack tecnologico, architettura, specifiche per ogni piattaforma)
+3. **Checkpoint A**: Valutazione Framework — Analizzare gap tecnici, raccomandare nuovi framework (se necessario), attendere conferma utente
 4. Generare DESIGN-OVERVIEW.md
-5. Usare Task Worker per distribuire il design per ogni piattaforma in parallelo (frontend/backend/mobile/desktop)
-6. **Checkpoint B**: Conferma Congiunta — Mostrare il riepilogo di tutti i design delle piattaforme, attendere conferma utente
+5. Usare Task Worker per distribuire parallelamente il design per ogni piattaforma (frontend/backend/mobile/desktop)
+6. **Checkpoint B**: Conferma Congiunta — Mostrare riepilogo di tutti i design di piattaforma, attendere conferma utente
 
 **Deliverable**:
 ```
 iterations/{iter}/03.system-design/
-├── DESIGN-OVERVIEW.md              # Panoramica design
+├── DESIGN-OVERVIEW.md              # Panoramica del design
 ├── {platform-id}/
-│   ├── INDEX.md                    # Indice design piattaforma
-│   └── {module}-design.md          # Design modulo a livello pseudocodice
+│   ├── INDEX.md                    # Indice design per piattaforma
+│   └── {module}-design.md          # Design modulo livello pseudocodice
 ```
 
 **Checklist di Conferma**:
-- [ ] Il pseudocodice usa la sintassi del framework effettivo?
-- [ ] I contratti API multipiattaforma sono coerenti?
+- [ ] Lo pseudocodice usa la sintassi effettiva del framework?
+- [ ] I contratti API cross-piattaforma sono consistenti?
 - [ ] La strategia di gestione errori è unificata?
 
 ---
 
-### 4.4 Fase 4: Implementazione Sviluppo (System Developer)
+### 7.4 Fase 4: Sviluppo (System Developer)
 
-**Come Iniziare**:
+**Come Avviare**:
 ```
-@speccrew-system-developer iniziare lo sviluppo
+@speccrew-system-developer avvia sviluppo
 ```
 
-**Workflow Agent**:
+**Workflow dell'Agente**:
 1. Leggere i documenti di system design
-2. Caricare le conoscenze tecniche per ogni piattaforma
-3. **Checkpoint A**: Pre-controllo Ambiente — Verificare versioni runtime, dipendenze, disponibilità servizi; attendere risoluzione utente se fallito
-4. Usare Task Worker per distribuire lo sviluppo per ogni piattaforma in parallelo
-5. Controllo integrazione: allineamento contratto API, coerenza dati
-6. Emettere rapporto di consegna
+2. Caricare conoscenze tecniche per ogni piattaforma
+3. **Checkpoint A**: Pre-verifica Ambiente — Verificare versioni runtime, dipendenze, disponibilità servizi; attendere risoluzione utente se fallisce
+4. Usare Task Worker per distribuire parallelamente lo sviluppo per ogni piattaforma
+5. Verifica integrazione: allineamento contratti API, consistenza dati
+6. Produrre report di consegna
 
 **Deliverable**:
 ```
-# Codice sorgente scritto nella directory sorgente effettiva del progetto
+# Il codice sorgente viene scritto nella directory sorgente effettiva del progetto
 iterations/{iter}/04.development/
 ├── {platform-id}/
 │   └── tasks/                      # Registrazioni attività di sviluppo
@@ -252,25 +327,25 @@ iterations/{iter}/04.development/
 
 **Checklist di Conferma**:
 - [ ] L'ambiente è pronto?
-- [ ] I problemi di integrazione sono entro un range accettabile?
+- [ ] I problemi di integrazione sono in un intervallo accettabile?
 - [ ] Il codice è conforme alle specifiche di sviluppo?
 
 ---
 
-### 4.5 Fase 5: Test Sistema (Test Manager)
+### 7.5 Fase 5: Test di Sistema (Test Manager)
 
-**Come Iniziare**:
+**Come Avviare**:
 ```
-@speccrew-test-manager iniziare i test
+@speccrew-test-manager avvia test
 ```
 
 **Processo di Test in Tre Fasi**:
 
 | Fase | Descrizione | Checkpoint |
-|------|-------------|------------|
-| Design Casi di Test | Generare casi di test basati su PRD e Feature Spec | A: Mostrare statistiche di copertura casi e matrice di tracciabilità, attendere conferma utente di copertura sufficiente |
-| Generazione Codice Test | Generare codice di test eseguibile | B: Mostrare file di test generati e mappatura casi, attendere conferma utente |
-| Esecuzione Test e Reporting Bug | Eseguire automaticamente i test e generare rapporti | Nessuno (esecuzione automatica) |
+|-------|-------------|------------|
+| Progettazione Casi di Test | Generare casi di test basati su PRD e Feature Spec | A: Mostrare statistiche copertura casi e matrice di tracciabilità, attendere conferma utente di copertura sufficiente |
+| Generazione Codice di Test | Generare codice di test eseguibile | B: Mostrare file di test generati e mappatura casi, attendere conferma utente |
+| Esecuzione Test e Report Bug | Eseguire automaticamente test e generare report | Nessuno (esecuzione automatica) |
 
 **Deliverable**:
 ```
@@ -278,11 +353,11 @@ iterations/{iter}/05.system-test/
 ├── cases/
 │   └── {platform-id}/              # Documenti casi di test
 ├── code/
-│   └── {platform-id}/              # Piano codice test
+│   └── {platform-id}/              # Piano codice di test
 ├── reports/
-│   └── test-report-{date}.md       # Rapporto test
+│   └── test-report-{date}.md       # Report di test
 └── bugs/
-    └── BUG-{id}-{title}.md         # Rapporti bug (un file per bug)
+    └── BUG-{id}-{title}.md         # Report bug (un file per bug)
 ```
 
 **Checklist di Conferma**:
@@ -292,13 +367,13 @@ iterations/{iter}/05.system-test/
 
 ---
 
-### 4.6 Fase 6: Archiviazione
+### 7.6 Fase 6: Archiviazione
 
-Le iterazioni vengono automaticamente archiviate al completamento:
+Le iterazioni vengono archiviate automaticamente dopo il completamento:
 
 ```
 speccrew-workspace/iteration-archives/
-└── {numero}-{tipo}-{nome}-{date}/
+└── {numero}-{tipo}-{nome}-{data}/
     ├── 01.product-requirement/
     ├── 02.feature-design/
     ├── 03.system-design/
@@ -308,11 +383,11 @@ speccrew-workspace/iteration-archives/
 
 ---
 
-## 5. Panoramica Base Conoscenza
+## 8. Panoramica della Base di Conoscenza
 
-### 5.1 Base Conoscenza Business (bizs)
+### 8.1 Base di Conoscenza di Business (bizs)
 
-**Scopo**: Memorizzare descrizioni funzionali business del progetto, divisioni moduli, caratteristiche API
+**Scopo**: Memorizzare descrizioni funzionalità business del progetto, divisioni modulari, caratteristiche API
 
 **Struttura Directory**:
 ```
@@ -325,7 +400,7 @@ knowledges/bizs/
 
 **Scenari d'Uso**: Product Manager, Feature Designer
 
-### 5.2 Base Conoscenza Tecnica (techs)
+### 8.2 Base di Conoscenza Tecnica (techs)
 
 **Scopo**: Memorizzare stack tecnologico del progetto, convenzioni architetturali, specifiche di sviluppo, specifiche di test
 
@@ -343,21 +418,21 @@ knowledges/techs/{platform-id}/
 
 ---
 
-## 6. Gestione del Progresso del Workflow
+## 9. Gestione Avanzamento Workflow
 
-Il team virtuale SpecCrew segue un rigoroso meccanismo di validazione a stadi in cui ogni fase deve essere confermata dall'utente prima di procedere alla successiva. Supporta anche l'esecuzione riprendibile — al riavvio dopo un'interruzione, continua automaticamente da dove si era fermato.
+Il team virtuale SpecCrew segue un rigoroso meccanismo di stage-gating in cui ogni fase deve essere confermata dall'utente prima di procedere alla successiva. Supporta anche l'esecuzione riprendibile — quando riavviato dopo un'interruzione, continua automaticamente da dove si era fermato.
 
-### 6.1 File di Progresso a Tre Livelli
+### 9.1 Tre Livelli di File di Avanzamento
 
-Il workflow mantiene automaticamente tre tipi di file di progresso JSON, situati nella directory di iterazione:
+Il workflow mantiene automaticamente tre tipi di file JSON di avanzamento, situati nella directory di iterazione:
 
 | File | Posizione | Scopo |
-|------|-----------|-------|
-| `WORKFLOW-PROGRESS.json` | `iterations/{iter}/` | Registra lo stato di ogni fase del pipeline |
+|------|----------|---------|
+| `WORKFLOW-PROGRESS.json` | `iterations/{iter}/` | Registra lo stato di ogni fase della pipeline |
 | `.checkpoints.json` | Sotto ogni directory di fase | Registra lo stato di conferma dei checkpoint utente |
-| `DISPATCH-PROGRESS.json` | Sotto ogni directory di fase | Registra il progresso elemento per elemento per task paralleli (multi-piattaforma/multi-modulo) |
+| `DISPATCH-PROGRESS.json` | Sotto ogni directory di fase | Registra l'avanzamento item per item per attività parallele (multi-piattaforma/multi-modulo) |
 
-### 6.2 Flusso di Stato delle Fasi
+### 9.2 Flusso di Stato della Fase
 
 Ogni fase segue questo flusso di stato:
 
@@ -366,27 +441,27 @@ pending → in_progress → completed → confirmed
 ```
 
 - **pending**: Non ancora avviato
-- **in_progress**: Attualmente in esecuzione
-- **completed**: Esecuzione Agent completata, in attesa di conferma utente
-- **confirmed**: Confermato dall'utente tramite checkpoint finale, la fase successiva può iniziare
+- **in_progress**: In esecuzione
+- **completed**: Esecuzione agente completata, in attesa di conferma utente
+- **confirmed**: Utente confermato tramite checkpoint finale, la fase successiva può iniziare
 
-### 6.3 Esecuzione Riprendibile
+### 9.3 Esecuzione Riprendibile
 
-Al riavvio di un Agent per una fase:
+Quando si riavvia un Agente per una fase:
 
-1. **Verifica automatica a monte**: Verifica se la fase precedente è confermata, blocca e notifica se non lo è
-2. **Recupero checkpoint**: Legge `.checkpoints.json`, salta i checkpoint superati, continua dall'ultimo punto di interruzione
-3. **Recupero task paralleli**: Legge `DISPATCH-PROGRESS.json`, riesegue solo i task con stato `pending` o `failed`, salta i task `completed`
+1. **Verifica automatica upstream**: Verifica se la fase precedente è confermata, blocca e richiede se non
+2. **Recupero Checkpoint**: Legge `.checkpoints.json`, salta i checkpoint passati, continua dall'ultimo punto di interruzione
+3. **Recupero Attività Parallele**: Legge `DISPATCH-PROGRESS.json`, ri-esegue solo attività con stato `pending` o `failed`, salta attività `completed`
 
-### 6.4 Visualizzare il Progresso Attuale
+### 9.4 Visualizzare Avanzamento Attuale
 
-Visualizzare lo stato panoramico del pipeline tramite l'Agent Team Leader:
+Visualizzare lo stato panoramico della pipeline tramite l'Agente Team Leader:
 
 ```
-@speccrew-team-leader visualizzare il progresso dell'iterazione corrente
+@speccrew-team-leader visualizza avanzamento iterazione corrente
 ```
 
-Il Team Leader leggerà i file di progresso e mostrerà un riepilogo dello stato simile a:
+Il Team Leader leggerà i file di avanzamento e mostrerà una panoramica dello stato simile a:
 
 ```
 Pipeline Status: i001-user-management
@@ -397,29 +472,29 @@ Pipeline Status: i001-user-management
   05 System Test:    ⏳ Pending
 ```
 
-### 6.5 Compatibilità all'Indietro
+### 9.5 Compatibilità all'Indietro
 
-Il meccanismo dei file di progresso è completamente retrocompatibile — se i file di progresso non esistono (ad esempio, in progetti legacy o nuove iterazioni), tutti gli Agent verranno eseguiti normalmente secondo la logica originale.
+Il meccanismo dei file di avanzamento è completamente compatibile all'indietro — se i file di avanzamento non esistono (ad es. in progetti legacy o nuove iterazioni), tutti gli Agenti eseguiranno normalmente secondo la logica originale.
 
 ---
 
-## 7. Domande Frequenti (FAQ)
+## 10. Domande Frequenti (FAQ)
 
-### Q1: Cosa fare se l'Agent non funziona come previsto?
+### D1: Cosa fare se l'Agente non funziona come previsto?
 
 1. Eseguire `speccrew doctor` per verificare l'integrità dell'installazione
 2. Confermare che la base di conoscenza è stata inizializzata
-3. Confermare che i deliverable della fase precedente esistono nella directory di iterazione corrente
+3. Confermare che il deliverable della fase precedente esiste nella directory di iterazione corrente
 
-### Q2: Come saltare una fase?
+### D2: Come saltare una fase?
 
-**Non raccomandato** — L'output di ogni fase è l'input per la fase successiva.
+**Non consigliato** — L'output di ogni fase è l'input per la fase successiva.
 
-Se devi assolutamente saltare, prepara manualmente il documento di input della fase corrispondente e assicurati che rispetti le specifiche di formato.
+Se devi saltare, prepara manualmente il documento di input della fase corrispondente e assicurati che sia conforme alle specifiche di formato.
 
-### Q3: Come gestire requisiti paralleli multipli?
+### D3: Come gestire più requisiti paralleli?
 
-Creare directory di iterazione indipendenti per ogni requisito:
+Crea directory di iterazione indipendenti per ogni requisito:
 ```
 iterations/
 ├── 001-feature-xxx/
@@ -427,94 +502,96 @@ iterations/
 └── 003-feature-zzz/
 ```
 
-Ogni iterazione è completamente isolata e non influenza le altre.
+Ogni iterazione è completamente isolata e non influisce sulle altre.
 
-### Q4: Come aggiornare la versione di SpecCrew?
+### D4: Come aggiornare la versione di SpecCrew?
 
-L'aggiornamento avviene in due passaggi:
+L'aggiornamento richiede due passaggi:
 
 ```bash
 # Passaggio 1: Aggiornare lo strumento CLI globale
 npm install -g speccrew@latest
 
-# Passaggio 2: Sincronizzare Agent e Skill nella directory del progetto
+# Passaggio 2: Sincronizzare Agents e Skills nella directory del progetto
 cd /path/to/your-project
 speccrew update
 ```
 
-- `npm install -g speccrew@latest`: Aggiorna lo strumento CLI stesso (la nuova versione può contenere nuove definizioni Agent/Skill, correzioni di bug, ecc.)
-- `speccrew update`: Sincronizza i file di definizione Agent e Skill nel progetto all'ultima versione
-- `speccrew update --ide cursor`: Aggiorna solo la configurazione dell'IDE specificato
+- `npm install -g speccrew@latest`: Aggiorna lo strumento CLI stesso (le nuove versioni possono includere nuove definizioni Agent/Skill, correzioni bug, ecc.)
+- `speccrew update`: Sincronizza i file di definizione Agent e Skill del tuo progetto all'ultima versione
+- `speccrew update --ide cursor`: Aggiorna la configurazione per un IDE specifico soltanto
 
-> **Nota**: Entrambi i passaggi devono essere eseguiti. Eseguire solo `speccrew update` non aggiornerà lo strumento CLI stesso; eseguire solo `npm install` non aggiornerà i file nel progetto.
+> **Nota**: Entrambi i passaggi sono necessari. Eseguire solo `speccrew update` non aggiornerà lo strumento CLI stesso; eseguire solo `npm install` non aggiornerà i file del progetto.
 
-### Q5: `speccrew update` mostra una nuova versione ma dopo l'installazione è ancora la vecchia?
+### D5: `speccrew update` indica che è disponibile una nuova versione ma `npm install -g speccrew@latest` continua a installare la vecchia versione?
 
-Solitamente è causato dalla cache npm. Soluzione:
+Questo è solitamente causato dalla cache npm. Soluzione:
 
 ```bash
+# Pulire cache npm e reinstallare
 npm cache clean --force
 npm install -g speccrew@latest
+
+# Verificare versione
 npm list -g speccrew
 ```
 
-Se ancora non funziona, specifica il numero di versione:
+Se ancora non funziona, prova a installare con un numero di versione specifico:
 ```bash
 npm install -g speccrew@0.5.6
 ```
 
-### Q6: Come visualizzare le iterazioni storiche?
+### D6: Come visualizzare le iterazioni storiche?
 
-Dopo l'archiviazione, visualizzare in `speccrew-workspace/iteration-archives/`, organizzate per formato `{numero}-{tipo}-{nome}-{date}/`.
+Dopo l'archiviazione, visualizzare in `speccrew-workspace/iteration-archives/`, organizzato per formato `{numero}-{tipo}-{nome}-{data}/`.
 
-### Q7: La base di conoscenza necessita di aggiornamenti regolari?
+### D7: La base di conoscenza necessita di aggiornamenti regolari?
 
-La re-inizializzazione è necessaria nelle seguenti situazioni:
-- Cambiamenti importanti nella struttura del progetto
+È richiesta la reinizializzazione nelle seguenti situazioni:
+- Modifiche importanti alla struttura del progetto
 - Aggiornamento o sostituzione dello stack tecnologico
 - Aggiunta/rimozione di moduli business
 
 ---
 
-## 8. Riferimento Rapido
-
-### Riferimento Rapido Avvio Agent
+## 11. Riferimento Rapido
 
-| Fase | Agent | Conversazione di Avvio |
-|------|-------|------------------------|
+### Riferimento Rapido Avvio Agenti
 
-| Inizializzazione | Team Leader | `@speccrew-team-leader inizializzare la base conoscenza tecnica` |
+| Fase | Agente | Conversazione di Avvio |
+|-------|-------|-------------------|
+| Inizializzazione | Team Leader | `@speccrew-team-leader inizializza base di conoscenza tecnica` |
 | Analisi Requisiti | Product Manager | `@speccrew-product-manager Ho un nuovo requisito: [descrizione]` |
-| Feature Design | Feature Designer | `@speccrew-feature-designer iniziare il feature design` |
-| System Design | System Designer | `@speccrew-system-designer iniziare il system design` |
-| Sviluppo | System Developer | `@speccrew-system-developer iniziare lo sviluppo` |
-| Test Sistema | Test Manager | `@speccrew-test-manager iniziare i test` |
+| Feature Design | Feature Designer | `@speccrew-feature-designer avvia feature design` |
+| System Design | System Designer | `@speccrew-system-designer avvia system design` |
+| Sviluppo | System Developer | `@speccrew-system-developer avvia sviluppo` |
+| Test di Sistema | Test Manager | `@speccrew-test-manager avvia test` |
 
 ### Checklist Checkpoint
 
-| Fase | Numero Checkpoint | Elementi di Controllo Chiave |
-|------|-------------------|------------------------------|
-| Analisi Requisiti | 1 | Accuratezza requisiti, completezza regole business, misurabilità criteri di accettazione |
-| Feature Design | 1 | Copertura scenari, chiarezza interazioni, completezza dati, gestione eccezioni |
-| System Design | 2 | A: Valutazione framework; B: Sintassi pseudocodice, coerenza multipiattaforma, gestione errori |
-| Sviluppo | 1 | A: Prontezza ambiente, problemi integrazione, specifiche codice |
-| Test Sistema | 2 | A: Copertura casi; B: Eseguibilità codice test |
+| Fase | Numero Checkpoint | Elementi di Verifica Chiave |
+|-------|----------------------|-----------------|
+| Analisi Requisiti | 1 | Accuratezza requisiti, completezza regole business, misurabilità criteri accettazione |
+| Feature Design | 1 | Copertura scenari, chiarezza interazione, completezza dati, gestione eccezioni |
+| System Design | 2 | A: Valutazione framework; B: Sintassi pseudocodice, consistenza cross-piattaforma, gestione errori |
+| Sviluppo | 1 | A: Pronto ambiente, problemi integrazione, specifiche codice |
+| Test di Sistema | 2 | A: Copertura casi; B: Eseguibilità codice test |
 
 ### Riferimento Rapido Percorsi Deliverable
 
 | Fase | Directory Output | Formato File |
-|------|------------------|--------------|
+|-------|-----------------|-------------|
 | Analisi Requisiti | `iterations/{iter}/01.product-requirement/` | `[name]-prd.md`, `[name]-bizs-modeling.md` |
 | Feature Design | `iterations/{iter}/02.feature-design/` | `[name]-feature-spec.md` |
 | System Design | `iterations/{iter}/03.system-design/` | `DESIGN-OVERVIEW.md`, `{platform}/INDEX.md`, `{platform}/{module}-design.md` |
 | Sviluppo | `iterations/{iter}/04.development/` | Codice sorgente + `delivery-report.md` |
-| Test Sistema | `iterations/{iter}/05.system-test/` | `cases/`, `code/`, `reports/`, `bugs/` |
-| Archiviazione | `iteration-archives/{iter}-{date}/` | Copia iterazione completa |
+| Test di Sistema | `iterations/{iter}/05.system-test/` | `cases/`, `code/`, `reports/`, `bugs/` |
+| Archiviazione | `iteration-archives/{iter}-{date}/` | Copia completa dell'iterazione |
 
 ---
 
-## Prossimi Passi
+## Prossimi Passaggi
 
-1. Eseguire `speccrew init --ide qoder` per inizializzare il tuo progetto
-2. Eseguire l'inizializzazione della Base Conoscenza
-3. Procedere attraverso ogni fase seguendo il workflow, godendoti l'esperienza di sviluppo specification-driven!
+1. Esegui `speccrew init --ide qoder` per inizializzare il tuo progetto
+2. Esegui Passaggio Zero: Inizializzazione della Base di Conoscenza
+3. Progredisci fase per fase secondo il workflow, goditi l'esperienza di sviluppo guidato dalle specifiche!