In Claude Code:

/plugin marketplace add dagoSte/squadra
/plugin install squadra@squadra

Dal terminale, per Codex:

codex plugin marketplace add dagoSte/squadra
codex plugin add squadra@squadra

Il plugin porta la skill, i suoi script, i riferimenti e la dashboard. Non aggiunge il comando squadra al PATH: gli agenti eseguono python3 <cartella della skill>/scripts/squadra.py, anche per le istruzioni che Squadra stampa, come squadra ack …. Se vuoi il comando squadra, usa al posto del plugin l'installatore autonomo qui sotto. Usa il plugin oppure l'installatore autonomo, non entrambi, così la skill non viene registrata due volte.

git clone https://github.com/dagoSte/squadra.git
cd squadra
python3 -B scripts/install.py \
  --backup "$HOME/.local/state/squadra/install-backup-001"
export PATH="$HOME/.local/bin:$PATH"
squadra --version

Installa da un checkout pulito, senza modifiche fuori dai commit, con una nuova cartella di backup ogni volta; l'installatore conserva le skill e il comando precedenti, così puoi tornare indietro: python3 -B scripts/install.py --undo <cartella di backup> ripristina le skill precedenti e conserva il backup. La riga export PATH vale solo per quel terminale: aggiungila al profilo della shell (per esempio ~/.zshrc o ~/.bashrc) perché i terminali nuovi trovino squadra. Senza installare, usa python3 -B scripts/squadra.py <comando>. Dettagli e ritorno alla versione precedente, in inglese.

Con /plugin. In Claude Code esegui /plugin marketplace update squadra, poi /plugin update squadra@squadra, poi riavvia Claude Code. Per Codex esegui codex plugin marketplace upgrade, poi di nuovo codex plugin add squadra@squadra.

Con l'installatore autonomo. Dalla 3.6.1 in poi le versioni conservano la loro storia: esegui git pull, poi di nuovo l'installatore, con una nuova cartella di backup ogni volta. Un checkout della 3.6.0 o precedente richiede invece git fetch origin e git reset --hard origin/main, che cancella le modifiche locali di quel checkout.

git pull
python3 -B scripts/install.py \
  --backup "$HOME/.local/state/squadra/install-backup-002"
squadra --version

Ogni rilascio alza il numero di versione, tranne un aggiornamento che arricchisce un rilascio mantenendone il numero, come per la 3.10.2 il 17 ottobre 2026. I plugin installati dallo Store mantengono la loro versione finché squadra plugin install <nome> non viene rieseguito dalla nuova release (Plugin inclusi nella release). Le finestre già aperte mantengono la versione letta finché non si riavviano, e una squadra al lavoro mantiene il suo protocollo finché non la cambi esplicitamente.

Aggiornare dalla 3.10.3 o dalla 3.10.2 alla 3.10.4: il registro resta com'è.

• Le finestre possono passare una alla volta. Finestre 3.10.2, 3.10.3 e 3.10.4 condividono lo stesso registro; niente viene convertito.
• Aggiorna prima il coordinatore. La regola per cui rilegge l'altro modello vale per gli incarichi registrati da una finestra 3.10.4, e una finestra precedente non la controlla a check e close. Gli incarichi registrati prima dell'aggiornamento si chiudono come prima.
• Plugin dello Store: esegui di nuovo squadra plugin install <nome>, come dopo ogni rilascio.

Aggiornare dalla 3.10.1 alla 3.10.2: il registro resta com'è.

• Le finestre possono passare una alla volta. Finestre 3.10.1 e 3.10.2 condividono lo stesso registro mentre le aggiorni; niente viene convertito.
• Due cose aspettano l'ultima finestra. Una modifica delle impostazioni fatta da una finestra 3.10.1 riporta ai valori predefiniti le due nuove soglie di attesa (to-forward e plan). E rimuovere un file finito nel registro per errore, con una decisione registrata, fa fallire su quel file mancante la verifica completa e la dashboard di una finestra 3.10.1: aggiorna tutte le finestre prima di rimuoverne uno.
• Plugin dello Store: esegui di nuovo squadra plugin install <nome>, come dopo ogni rilascio.

Aggiornare dalla 3.10.0 o precedenti alla 3.10.1: meno lavoro ripetuto sulla storia, e tutte le finestre devono passare insieme.

• Prima di aggiornare il coordinatore salva la squadra: squadra save --actor <coordinatore> --to <una cartella nuova>. È la tua strada per tornare indietro.
• Il registro che hai viene letto così com'è. Niente viene convertito e la storia già scritta non si tocca. Dal primo comando sulla 3.10.1, gli eventi nuovi si scrivono nel formato più leggero.
• Aggiorna tutte le finestre insieme, Claude Code e Codex. Una finestra rimasta alla 3.10.0 si ferma al primo evento nuovo con Event integrity failure at sequence N. È voluto: una versione vecchia si ferma invece di accettare eventi che non sa leggere. Non si perde niente: aggiorna quella finestra e riparte.
• Sullo stesso registro non si torna indietro. Dopo l'aggiornamento la 3.10.0 non può più usare quel registro. Per tornare indietro ripristina il salvataggio fatto prima di aggiornare, con l'una o l'altra versione, poi continua a usare la versione vecchia sulla copia ripristinata: il primo comando della 3.10.1 o successiva su quella copia scrive di nuovo il formato più recente.
• Se hai dubbi, esegui squadra doctor sulla 3.10.1: ti dice quando un registro richiede la 3.10.1 o successiva.
• Plugin dello Store: esegui di nuovo squadra plugin install <nome>, come dopo ogni rilascio.
• Se hai installato Squadra dalla directory di Claude, ricevi la versione indicata nella directory finché non passa alla 3.10.1.

La prima finestra che scrive su un registro precedente o spostato costruisce la cache; le altre attendono. Se un comando risponde registry busy, retry, riprova quando la prima scrittura è terminata.

Requisiti: Python 3.12+, Git e la libreria standard di Python. Node.js esegue i controlli JavaScript della dashboard nella suite di test e in selftest: senza Node quei controlli falliscono, non vengono mai saltati. Un browser per la dashboard; la CLI di Codex o di Claude solo per i runner nativi. L'ambiente di processi provato è macOS/POSIX; il controllo dei processi su Windows e il ripristino con submodule, LFS o checkout sparsi non sono qualificati.

È la prima volta con Squadra? Prova questi dodici passi una volta, dall'inizio alla fine, su un progetto di prova. Una finestra è una sessione di lavoro: un agente Codex, Claude o Cursor, oppure una persona. Tutte le finestre usano lo stesso registro.

1. Installa e imposta export SQUADRA_ROOT=... in ogni finestra.
2. Crea il registro e registra ogni finestra con init e agent.
3. Trova le finestre e presentati: census le elenca senza scrivere nulla; send e transport consegnano la presentazione; ogni finestra risponde con ack.
4. Racconta in parole semplici di cosa si tratta con brief --project.
5. Assegna il primo incarico e spiegalo con task e brief --task.
6. Il costruttore conferma e comincia: ack, poi start.
7. Il costruttore prova e consegna: prove esegue la verifica concordata sui file esatti; deliver li consegna.
8. Legge qualcun altro: un lettore che non ha scritto il lavoro registra il verdetto con review.
9. Il coordinatore chiude: check, poi close.
10. Controlla chi risponde ancora: il coordinatore lancia ping --all; ping --sweep mette in stand-by una finestra che non ha risposto, senza fermare nulla di ciò che esegue.
11. Apri la dashboard con dash --open; «Come leggere questa pagina» spiega ogni termine.
12. Registra quello che dice il proprietario con decision, --owner-words, --channel e --task.

Ogni passo più in dettaglio: avvio e presentazione, in inglese.

I dodici passi come comandi

squadra census --project /path/to/project
squadra send --actor coord --to builder --id HELLO-builder --body-file /evidence/introduction.md
squadra transport --actor coord --message HELLO-builder --via manual
squadra ack --actor builder --message HELLO-builder
squadra brief --actor coord --project --file /evidence/project.md
squadra task --actor coord --id T1 --owner builder --reviewer reader \
  --title "Key rotation" --repo /path/to/builder-checkout \
  --scope-file /evidence/scope.md --proof-file /evidence/argv.json
squadra brief --actor coord --task T1 --file /evidence/t1.md
squadra ack --actor builder --message assign-T1
squadra start --actor builder --task T1
squadra prove --actor builder --task T1 -- python3 -B -m unittest discover -s tests -v
squadra deliver --actor builder --task T1
squadra ack --actor reader --message "review-ID-RETURNED-BY-DELIVER"
squadra review --actor reader --task T1 --verdict accepted --report /evidence/code-read.md
squadra check --actor coord --task T1
squadra close --actor coord --task T1
squadra ping --actor coord --all
squadra ack --actor builder --message "PING-ID-RETURNED-BY-PING"
squadra ping --actor coord --sweep
squadra decision --actor coord --reason "Istruzione del proprietario" --task T1 \
  --owner-words "Teniamo leggibili le chiavi vecchie per un mese" --channel typed-here
squadra dash --open

Costruire e consegnare (finestra costruttrice)

Conferma il tuo incarico, poi costruiscilo nel tuo checkout.
Quando la modifica è pronta, congelala, esegui la prova concordata sui file esatti e consegnala
al lettore. Registra un output con l'esito e il prossimo passo, poi fermati.

Chiedere una lettura indipendente (finestra revisora)

Conferma il passaggio di lettura che hai ricevuto, poi leggi il candidato congelato su una copia privata.
Esegui sonde tue, scrivi prima il rapporto e registra il verdetto con i requisiti che copre.
Bloccano solo i rilievi gravi; elenca gli altri come attività da seguire, ognuna con un responsabile.

Chiudere un incarico (coordinatore)

Controlla che prova e lettura riguardino lo stesso candidato, poi chiudi l'incarico T1.
Fai un checkpoint e mostrami la tabella dell'avanzamento. Non pubblicare nulla.

Aprire la dashboard

Apri nel mio browser la dashboard di squadra per questo registro.

Una finestra Codex la cui sandbox blocca la rete non può aprire la porta locale della dashboard: chiedilo a una finestra Claude.

Registrare una decisione (coordinatore)

Registra la mia decisione, collegata all'incarico T1, come scritta qui:
"Teniamo leggibili le chiavi vecchie per un mese." Poi avvisa il costruttore.

Mettere in pausa e riprendere (coordinatore)

Metti in pausa la squadra: ferma solo i processi che possiedi, salva il registro e il codice e dimostra
il salvataggio con un vero controllo di ripristino. Ti dirò io quando riprendere.

Riprendi la squadra: rileggi il mandato e il registro, riconcilia sorgenti e risorse,
registra la ripresa e dimmi il prossimo passo.

Prima di un cambio di sessione o con il contesto pieno

Il tuo contesto si sta riempiendo. Salva un checkpoint e un passaggio di consegne completo con incarico,
identità, branch, rilievi aperti e il prossimo passo esatto, così una sessione nuova può continuare.

Plugin (il secondo prompt è per il coordinatore)

Mostrami nella dashboard la pagina del plugin "memo": cos'è, le sue impostazioni e le sue bozze.

Ho selezionato delle bozze e premuto "Invia per revisione" nella dashboard. Leggi l'AGENTS.md del plugin
ed esegui solo il suo consumatore per la richiesta in attesa, nei permessi già autorizzati.
Poi dimmi com'è andata.

Da ricordare alla chiusura

Prima di chiudere T1, rispondi alla domanda "da ricordare". Scrivi da-ricordare.json con una frase
per ogni decisione, vincolo o trappola, ognuna con la sua prova e quanto ne sei sicuro,
senza segreti, dati personali o percorsi privati. Allegalo al tuo output di chiusura.

Le regole in pratica (coordinatore)

Abbiamo appena chiuso T4. Guarda nella dashboard dove è andato il suo tempo e dimmi, in una riga,
come il prossimo incarico può andare più veloce. Poi applicalo quando assegni il successivo.

Lavora in parallelo: dai subito a ogni finestra libera un incarico indipendente, ciascuno con
il suo albero e i suoi file, e unisci tu le corsie quando consegnano.

Mostrami la tabella dell'avanzamento con la colonna del tempo: i tempi misurati dal board,
più la tua stima di quanto manca per ogni incarico, segnata come stima.

Prima di riportare un numero, un identificativo o un percorso, leggilo dall'uscita di un
comando, non dalla memoria.

Se un test fissa qualcosa che ti ho chiesto di cambiare, registra prima la mia decisione,
poi cambia insieme il test e il codice.

Prima di una chiamata a pagamento (modelli, voce, immagini), dimmi il costo previsto e un
tetto, e fermati al tetto.

Usa il blocco finale predefinito: fissa le giunture, unisci le consegne provate e congela
un candidato. Claude e Codex non autori leggono ogni delta; fai un giro di correzione
e rileggine insieme i delta. Conserva i rinvii non gravi per la tappa successiva.

Aggiornamento e sicurezza. La pagina si aggiorna ogni due secondi, sospende gli aggiornamenti quando la scheda è nascosta e si aggiorna subito al ritorno. La ricerca trova incarichi, esecuzioni, messaggi, risultati, decisioni, domande e letture per inizio di parola, senza distinguere gli accenti; il menù mostra prima i più recenti e offre un prompt da copiare per il tuo agente. Gli artefatti registrati si aprono in una finestra. È in sola lettura salvo impostazioni e selezioni dichiarate dei plugin installati; le azioni sul registro passano dalla CLI. Ascolta su 127.0.0.1, verifica Host e token, controlla Origin per il salvataggio di impostazioni e selezioni, e non carica script remoti né CDN. --port sceglie una porta (senza, ne cerca una libera); Ctrl-C chiude il server della dashboard, non gli agenti; se si disconnette, la pagina conserva l'ultima vista con un avviso.

Un plugin porta nella dashboard i dati di un altro strumento: una cartella $HOME/.squadra/plugins/<name>/ con un manifesto plugin.json, in cui un programma separato, il produttore del plugin, scrive i pannelli di dati. Il gruppo Plugin del menù elenca ogni manifesto installato, oppure dice «Nessun plugin installato» e spiega dove si installano; scegline uno per vedere i suoi dati per il registro aperto.

Le cartelle dei plugin devono appartenere a te e non essere scrivibili da gruppo o altri; lo Store le crea private.

Chi esegue la richiesta? Un plugin installato può fornire $HOME/.squadra/plugins/<name>/AGENTS.md con istruzioni per gli agenti. La finestra coordinatrice lo legge all’avvio e alla ripresa ed esegue solo i comandi indicati, nei permessi già autorizzati e solo finché squadra plugin list riporta quel plugin con instructions: valid e files: verified: il produttore dopo una chiusura, il consumatore quando la dashboard mostra una richiesta in attesa, poi riferisce l’esito. Vale solo un file regolare di proprietà dell’utente, non scrivibile da gruppo o altri e non un link simbolico. Senza un file valido, la richiesta resta in attesa e la coordinatrice lo segnala: non devi lanciare comandi. La dashboard non legge, non scrive e non esegue questo file. Questo file non amplia mai i permessi e non autorizza installazioni, push, pubblicazioni o decisioni riservate all’utente; per qualunque richiesta oltre a eseguire il produttore o il consumatore di quel plugin, fermarsi e riferire.

Schemi, dimensioni, limiti e codici di rifiuto esatti: contratto dei plugin, metadati about, sito e icona.

Costruisci il tuo. Il formato è aperto: chiunque nella community può pubblicare un plugin per squadra, gratuito o a pagamento. Un plugin è fatto di dati e di un programma separato. La dashboard e la CLI non eseguono mai il codice dei plugin; gli agenti lo eseguono solo come indicato nell'AGENTS.md del plugin, rispettando le condizioni di affidabilità del file e i permessi già concessi dall'utente. Parti dal formato dei plugin.

Passo per passo: la guida per creare un plugin (in inglese) costruisce un plugin funzionante, lo prova con la dashboard e spiega come pubblicarlo, gratuito o a pagamento.

Pubblica il tuo plugin: leggi la panoramica italiana, che rimanda alla guida tecnica in inglese per esempi, verifiche e compatibilità. Questi plugin di dati sono separati dall’installazione di Squadra tramite /plugin; pubblicare un pacchetto non lo inserisce automaticamente in un catalogo, non lo installa e non lo approva.

Altri termini, come log ed exit, UTC, PID e cwd: la guida della pagina, in inglese.

La squadra parte da una finestra Claude: la prima finestra Claude che applica la skill diventa il coordinatore, trova ogni finestra Codex, Claude o Cursor del progetto e si presenta a ciascuna. Una finestra Codex chiamata per prima non coordina, perché dalla sua sandbox non riesce né a trovare né a raggiungere le finestre Claude: te lo dice, ti dà la frase da scrivere in una finestra Claude e aspetta come esecutore. Poi la finestra Claude si presenta a ogni finestra, compresa quella Codex. Se non hai una finestra Claude decidi tu, dopo che la finestra Codex ti ha detto che cosa non può fare. Un coordinatore già presente nello stesso registro, che risponde a un ping, mantiene il ruolo; un ping in attesa o scaduto non trasferisce mai la guida o le risorse. Con la presentazione, a ogni ripresa e quando una finestra entra o esce, il coordinatore ti dice come dividere il lavoro tra finestre Claude e Codex (la riga Composizione di squadra status e della dashboard): è solo un consiglio, non assegna nulla. La regola completa è nella skill; i limiti del censimento e come entrare in una squadra sono in avvio e presentazione, in inglese.

Le finestre Cursor lavorano solo in modo interattivo: sei tu ad aprire l'agente Cursor (cursor-agent), che poi usa la CLI di squadra come ogni altra finestra. Squadra non lo avvia mai da sola, perché Cursor esegue gli hook del team, dell'utente e dell'azienda fuori da qualunque sandbox e non permette di disattivarli.

Crea un unico registro durevole, fuori dalle cartelle temporanee:

export SQUADRA_ROOT="$HOME/.local/state/squadra/my-project"
squadra init --name "My project" --project /path/to/project
squadra agent --id coord --identity window-01 --session CLAUDE-SESSION-ID \
  --role coordinator --client claude --repo /path/to/project
squadra agent --id builder --identity window-02 --session CLAUDE-SESSION-ID \
  --role builder --client claude --repo /path/to/builder-checkout
squadra agent --id reader --identity window-03 --session CODEX-THREAD-ID \
  --role reviewer --client codex --repo /path/to/reader-checkout
squadra status
squadra dash --open

--session è l'identificativo della sessione della finestra: il nome del file della sua trascrizione in ~/.claude/projects/<progetto>/, senza .jsonl, per Claude Code, l'UUID alla fine del suo file ~/.codex/sessions/…/rollout-… per Codex. Usage e Balance misurano una finestra solo attraverso questo, e la coda di Codex ne ha bisogno.

Il coordinatore affida subito lavoro indipendente a ogni finestra disponibile (Codex, Claude, Cursor interattivo), e nessuna finestra resta ferma mentre c'è lavoro: un costruttore per albero, letture su copie congelate, e la lettura finale di un rilascio fatta da un lettore Claude e da un lettore Codex nello stesso momento. Se scrive Codex rilegge Claude, e viceversa: conta la lettura dell'altro modello, una lettura dello stesso modello si aggiunge soltanto, e task rifiuta un lettore dello stesso modello del titolare dell'incarico, a meno che tu non registri il motivo con --same-client-reason. Il coordinatore costruisce solo l'unione e il rilascio e affida le corsie ai costruttori, così resta attento alla posta e alle giunture. Il coordinatore legge la posta del registro a ogni passo, perché una finestra può ricevere lavoro direttamente dal proprietario e riferirlo solo lì.

Ogni aggiornamento al proprietario mostra la tabella di squadra board: In corso, Da fare e Fatti, colonne Finestra | Lavoro | Stato | Tempo (circa), «Realizzati X su Y» in fondo, poi «Tu adesso: …». I tempi sono misurati, le stime sono segnate come stime, nessuna percentuale inventata.

Fissato il perimetro di un giro, un problema trovato durante il giro diventa un nuovo incarico solo se blocca una chiusura; il resto aspetta nella decisione di rinvio del giro fino all'avvio del successivo. Ai momenti di ripresa, assegnazione, consegna e push, la finestra esegue squadra checklist: un fail ferma il passo; ogni limite unverifiable resta esplicito. Guida e hook pre-push facoltativo, in inglese.

Le finestre silenziose da due giorni sono elencate da doctor --resume come archiviabili o no, e messe in stand-by con standby solo su parola del proprietario. I test già rossi su main pulito stanno in tests/known_reds.json: il runner parallelo li separa dai rossi nuovi, --accept-known fa passare una prova d'incarico solo sui rossi noti e la prova di rilascio resta rigorosa. A ogni ripresa il coordinatore lancia prima squadra doctor --resume: i checkout mancanti di incarichi aperti bloccano, distanza dal rilascio e finestre silenziose sono elencate. Fondamentale: il coordinatore controlla sempre che le finestre coordinate non si sovrappongano (albero, ramo, file, risorse, commit) prima di assegnare lavoro. Leggi prima di citare; registra la decisione prima di cambiare un test che fissa un requisito; ogni corsia parallela ha i suoi file; dichiara costo e tetto prima di spendere. Il metodo predefinito è un blocco finale: contratto comune prima del lavoro, unione delle consegne verdi, registro di ogni delta e candidato congelato per letture non autrici Claude/Codex, poi un giro di correzione e un blocco di rilettura. Bloccano solo i reperti gravi; i rinvii diventano incarichi all'avvio della tappa successiva. Ogni chiusura dice come accelerare il prossimo incarico. Resta l'ora limite due ore dopo che il perimetro è fissato, salvo altro orario scelto dal proprietario; le prove riguardano la testa del rilascio e le letture ferme passano a lettori liberi. Le letture per corsia restano un'opzione su parola del proprietario. Tutte le regole per intero: la skill.

Scegli il percorso. Il costruttore propone e il coordinatore registra la scelta usando le cinque domande della pagina di triage IT/EN; il lettore non autore la controlla nel blocco assegnato. Nessuna regex, nessun modello di percorso e nessun punteggio sceglie il percorso. Le tappe coordinate usano il blocco finale predefinito; i comandi seguenti illustrano un incarico isolato o una lettura per corsia scelta dal proprietario.

• Correggi subito con prova: reversibile, Q1 no e Q3 sì; un breve controllo di un non autore prima della chiusura.
• Una lettura del codice: una scelta ordinaria e delimitata, con perimetro, prova vincolata e una lettura indipendente.
• Percorso completo: Q1 sì o incerta, Q2 irrisolta, un danno silenzioso rilevante in Q5, o un mandato esistente: prova completa, lettura di un non autore e verifiche richieste. La lettura del piano può precedere il lavoro su parola del proprietario o per un confine di fiducia; un piano già richiesto resta obbligatorio.

Le regole della lettura: blocca solo un rilievo grave; nel blocco finale i reperti non gravi irrisolti vanno in una decisione di rinvio, poi diventano incarichi all'avvio della tappa successiva, ognuno con responsabile, verifica di accettazione e reperto di origine. Mai passare comandi al proprietario. Tutte le regole: dettagli, in inglese.

Contratto, prova, lettura e chiusura. Tieni le prove fuori dal checkout consegnato: scope.md (comportamento, percorsi posseduti, dipendenze, risorse, verifiche, confini del rilascio), argv.json come elenco esatto di argomenti, non una stringa di shell (["python3", "-B", "-m", "unittest", "discover", "-s", "tests", "-v"]), e un requirements.json facoltativo ([{"id": "R1", "text": "I valori si sommano correttamente"}, {"id": "R2", "text": "La somma di una lista vuota è zero"}]).

squadra task --actor coord --id T1 --owner builder --reviewer reader \
  --title "Verificare la funzione di somma" --repo /path/to/builder-checkout \
  --scope-file /evidence/scope.md --proof-file /evidence/argv.json \
  --requirements-file /evidence/requirements.json
squadra ack --actor builder --message assign-T1
# Facoltativo o già richiesto: un piano letto da un non autore prima della costruzione.
squadra plan --actor coord --task T1 --file /evidence/plan.md
squadra review --actor reader --task T1 --stage plan \
  --verdict accepted --report /evidence/plan-read.md
squadra start --actor builder --task T1
# Implementa la modifica, poi congela i sorgenti.
squadra prove --actor builder --task T1 --covers R1 --covers R2 \
  --timeout 120 -- python3 -B -m unittest discover -s tests -v
squadra deliver --actor builder --task T1
squadra inbox --agent reader
# Usa l'ID esatto restituito da deliver; leggi il candidato congelato e scrivi prima il rapporto.
squadra ack --actor reader --message "review-ID-RETURNED-BY-DELIVER"
squadra review --actor reader --task T1 --covers R1 --covers R2 \
  --verdict accepted --report /evidence/code-read.md
squadra check --actor coord --task T1
squadra close --actor coord --task T1

Opzioni, budget e che cosa registrano prove, deliver, review e check: dettagli, in inglese.

Il completamento non dà l'autorità di pubblicare. Il protocollo completo è in lavoro, prova e lettura.

I briefing sono brevi descrizioni in testo semplice scritte dal coordinatore, da leggere prima di qualunque identificativo.

squadra brief --actor coord --project --file /evidence/project.md
squadra brief --actor coord --task T1 --file /evidence/t1.md

# Atlas
Atlas tiene in ordine le chiavi d'accesso dei clienti. Questa fase porta in produzione il servizio delle chiavi.

## Passi
- [x] Piano del servizio delle chiavi
- [ ] Servizio delle chiavi in produzione

## Glossario
- JEV: verifica del motore dei lavori

Collegamenti registrati.

squadra decision --actor coord --id D-SCOPE --task T1 \
  --follows ask:Q1 --follows decision:D-EARLIER \
  --owner-words "Teniamo leggibili le chiavi vecchie per un mese" --channel relayed \
  --reason "Istruzione del proprietario riferita dal coordinatore"

Ogni riquadro del grafo è un fatto registrato; le linee continue sono collegamenti registrati, le tratteggiate dicono solo «dopo, nello stesso incarico». Le regole per briefing, collegamenti delle decisioni, sostituzione di un incarico e lettura del grafo sono nei dettagli, in inglese.

squadra send --actor coord --to builder --id M1 \
  --task T1 --body-file /evidence/message.md
squadra inbox --agent builder
squadra ack --actor builder --message M1
squadra output --actor coord --task T1 --file /evidence/update.md \
  --next "Lettura indipendente del candidato congelato" --artifact /evidence/result.json

Salva un output sostanziale per ogni passo completato; il prossimo passo che dichiara non prova che sia successo qualcosa. Un avviso di avanzamento che non chiede risposta si manda con send --info: resta visibile senza aspettare un ACK. Risposte, destinatari attesi e trasporti: dettagli, in inglese.

Alla chiusura, registra quello che vale la pena ricordare (una decisione e chi l'ha presa, un vincolo, una trappola già pagata) in da-ricordare.json, allegato all'output di chiusura, ognuno con la sua prova e quanto ne sei sicuro. Mai inserire segreti, dati personali o percorsi privati: gli artefatti registrati sono immutabili, quindi un segreto inserito per errore non si può più togliere. Se è in uso un servizio di memoria, dichiara alla chiusura e non proporre la stessa voce attraverso un altro canale; nulla viene proposto o approvato da solo. Vedi lo schema e gli esempi, in inglese.

ask registra una domanda prima che venga mostrata, con almeno due opzioni dai valori id, label e say distinti (say è la frase da dire); buys, costs ed example sono facoltativi.

[
  {"id": "A", "label": "Tieni questo perimetro", "say": "Continua con il perimetro già letto"},
  {"id": "B", "label": "Prima il piano", "say": "Pianifica prima l'integrazione facoltativa"}
]

squadra ask --actor coord --id Q1 --task T1 --waiting builder \
  --question "Quale perimetro costruiamo?" \
  --options-file /evidence/choices.json --recommended A
# Solo dopo la risposta effettiva del proprietario:
squadra decision --actor coord --reason "Il proprietario ha scelto il perimetro A" \
  --answers Q1 --choice A --channel typed-here \
  --owner-words "Continua con il perimetro già letto"

Parole riferite, ritiri e che cosa non vale mai come decisione: dettagli, in inglese.

Le attese si calcolano quando una vista viene letta; valori predefiniti in secondi: ACK 900, delivered 3600, reviewed 1800, heartbeat 1800, alive 300. Un avviso non riprova, non riassegna e non rilascia nulla. I comandi stampano le attese raggruppate, al massimo cinque; squadra status --all le stampa tutte. Riserva gate, porte e database prima di usarli. Lo stand-by non ferma nulla: non annulla processi, non rilascia risorse, non trasferisce ruoli e non riassegna lavoro.

Soglie, chiamate di presenza e perché tutte le finestre dovrebbero usare la stessa versione: dettagli, in inglese.

Gli agenti fanno i checkpoint senza aspettare che tu lo chieda. È il modo di lavorare richiesto dalla skill, non un servizio in background né un contatore invisibile di token.

squadra checkpoint --to /durable/checkpoint-001
squadra save --actor coord --to /durable/recovery-001
squadra restore-check --actor coord --from /durable/recovery-001 --to /durable/restore-test-001
squadra pause --actor coord --reason "Il proprietario ha chiesto lo stop"
squadra doctor
squadra resume --actor coord --reason "Il proprietario ha ripreso esplicitamente"

checkpoint copia solo il registro; save, solo per il coordinatore, aggiunge ogni repository Git registrato con il suo lavoro non finito; restore-check dimostra un pacchetto ripristinandolo davvero in una cartella nuova. Quando il contesto si riempie, l'agente salva un passaggio di consegne prima di continuare. Dettagli, in inglese.

Limiti del ripristino: i filtri per i segreti sono parziali, non una scansione completa di storia e artefatti; una copia sullo stesso disco non sopravvive a un guasto del disco; --declared-offsite è una dichiarazione, non un archivio remoto verificato. Il contratto completo è in ripristino e passaggio di contesto.

run avvia un nuovo turno non interattivo di Codex o Claude e non si collega mai a una finestra aperta; un exit 0 da solo non è un esito valido. Cursor viene rifiutato: Squadra non avvia cursor-agent. Vedi il riassunto e i contratti di esecuzione, in inglese, prima di usare i runner in automatico.

Per un incarico dichiarato con task --defect-fix, la chiusura richiede la prova che il test rilevi il difetto senza la modifica: gli stessi byte del test falliscono per un'asserzione sulla base registrata e passano sul candidato esatto. Il coordinatore può dichiarare un'eccezione motivata; il lettore indipendente la verifica, e non compare mai come una verifica riuscita. Vedi l'esempio completo e i limiti, in inglese.

squadra selftest --output /durable/selftest-001

selftest mette alla prova il toolkit senza chiamare alcun modello, non il tuo prodotto né un modello; il confronto offline usa client finti e non proclama mai un vincitore. Vedi il riassunto e i contratti di sfide e confronti, in inglese.

I comandi di sola lettura non scrivono nel registro né nelle sue viste derivate. Usa squadra export quando servono esportazioni complete, inclusa la storia della posta. Prima di considerare completa una vista, confronta la sequenza e l'impronta dell'ultimo evento dichiarate dalla vista con quelle correnti lette tramite Store: un evento può essere registrato prima che i file esportati lo mostrino. La cache conserva lo stato già calcolato e i suoi indici; il punto di ripartenza è l'ultimo evento già incorporato in quello stato.

Le altre letture ordinarie indicate sopra non ricontrollano gli eventi precedenti, le parti della cache non lette o la sua impronta complessiva rispetto alla ricostruzione completa dello stato. Una cache mancante o estranea richiede una ricostruzione verificata. Se il controllo completo trova una discordanza tra cache e registro, doctor resta in sola lettura e rifiuta il risultato; anche la dashboard smette di fornire dati. Usa esplicitamente doctor --repair in un registro scrivibile per ricostruire la cache; salvataggi e checkpoint rifiutano la riparazione. Una verifica fallita non diventa un successo grazie alla cache. Gli indici derivati possono aumentare lo spazio usato; il nuovo formato degli eventi non promette un database più piccolo. Aggiorna tutte le finestre insieme prima della prima scrittura nel nuovo formato. Gli eventi di questa versione includono un indicatore di formato nella loro impronta: Squadra 3.10.0 si ferma con un errore di integrità a quel punto, anche con status/check/close. Il rifiuto è intenzionale, non una perdita di dati; usa la CLI aggiornata. Gli eventi precedenti restano invariati. Scrivi sempre attraverso la CLI, mai nei file generati. L'integrità non prova che le affermazioni siano vere, né autentica crittograficamente le identità. Dettagli, in inglese.

Il coordinatore può dichiarare task --route light per una modifica delimitata e reversibile: al massimo 80 righe aggiunte più eliminate in quattro file, e 16 KiB di righe cambiate (criterio light-v1 / P2), contate dalla base Git originale pulita. Script, pacchetti dei plugin, la pagina della dashboard, file di istruzioni e contratti normativi restano protetti, e un impatto sulla sicurezza o un gate completo richiesto portano comunque al percorso completo. Il percorso leggero salta la lettura del piano e usa la prova mirata concordata; restano la lettura di un non autore, i legami e i budget. Solo il coordinatore può promuovere un incarico al percorso completo, e la promozione non azzera mai un budget. Vedi il percorso leggero e i dettagli, in inglese.

Controlli statici, comportamentali e delle dipendenze, con tests/ esclusa. Il controllo passa in assenza di rilievi HIGH o CRITICAL; quelli di gravità inferiore restano nel report. Clicca sul badge per i risultati.

3.11.2 — regole che si controllano da sole: nessuna sovrapposizione, ripresa in un passo, rossi noti, finestre ferme, checklist e perimetro del giro

• Nessuna sovrapposizione tra finestre. Il coordinatore controlla checkout, ramo, file posseduti, base, risorse riservate e commit attesi prima di ogni assegnazione (guida).
• Ripresa in un passo. doctor --resume riporta l'interprete, ogni checkout di incarichi aperti e finestre attive, la distanza dal rilascio e le finestre silenziose; un checkout mancante di un incarico aperto blocca con codice 1.
• Rossi noti di main. tests/known_reds.json elenca i test già rossi su main pulito; il runner parallelo separa KNOWN RED da NEW RED e --accept-known fa passare una prova d'incarico solo sui rossi noti. La prova di rilascio resta rigorosa, e l'elenco è di nuovo vuoto.
• Finestre ferme. doctor --resume segna le finestre silenziose come archivable o dice cosa le trattiene (keeps), su tutti i posti di un'identità; solo la parola del proprietario le mette in stand-by con standby.
• Checklist. squadra checklist --moment resume|assign|deliver|push controlla in sola lettura i momenti critici: al push, un'email di autore o committer mai vista prima fa fallire.
• Perimetro del giro. Fissato il perimetro di un giro, ciò che emerge aspetta il giro successivo, salvo che blocchi una chiusura.
• Correzioni. test_rf4a_upgrade gira su una fixture verificata di 5099f0c; test_challenge non entra più in corsa con la manutenzione di Git.
• Audit delle skill non aggiornati. Le scansioni registrate in assets/skill-audits.json precedono le modifiche di questa versione a SKILL.md e scripts/squadra.py; la pagina System skills mostra ogni skill come non verificata (file cambiati) fino a una nuova scansione.

3.11.1 — sostituzione delle finestre, permessi all’ingresso, una posta per finestra e contesto di rientro

• Sostituisci in un passo le finestre chiuse. replace (o --map) passa incarichi, letture, posta e risorse dalle finestre vecchie alle nuove in un solo evento registrato, conservando autori, budget, il vincolo di approvazione del piano (il successore lo fa riapprovare) e le prenotazioni dei processi ancora vivi. --dry-run mostra l’anteprima e ripetere è sicuro; census --unregistered elenca le sessioni nuove.
• Limiti del servizio visibili. wait --until ORA --cause 429|outage mostra in stato, tabella e dashboard che una finestra aspetta il servizio del modello.
• Permessi verificati all’ingresso. access probe registra, dall’interno della finestra, se può scrivere nel registro e nel suo clone; access status mostra verificato, negato o non verificato.
• Una posta per finestra. inbox e il suo follower leggono tutti i ruoli della stessa finestra e conservano il destinatario di ogni ACK; ready mostra un lettore in attesa della consegna.
• Contesto di rientro. context --for FINESTRA --since SEQ:HASH mostra cosa è cambiato per una finestra e conserva sempre vincoli, ACK dovuti, budget e prove attuali.
• Correzioni. transport non riconsegna più in silenzio un messaggio vecchio con un ID riusato; save --repo segnala come avvisi i repository non selezionati mancanti.
• Plugin: memoranda 1.0.10, Playwright 1.0.11, Sentry 0.1.8.

3.11.0 — consegne congelate, letture riassegnabili e migliora

Aggiornamento: l’avvio della dashboard libera la lettura del WAL; risposte JSON e transport brevi, deroghe registrate per singolo percorso e rifiuti di recupero più chiari.

• Il costruttore può continuare dopo la consegna. La copia del candidato verificato resta nel registro e contiene anche le modifiche non committate.
• Cambia lettore senza rifare la prova. reassign conserva candidato, prove e budget, richiedendo il nuovo ACK.
• Posta e risorse più leggibili. Il cursore della posta si salva; resource status mostra titolare e coda. Le prenotazioni possono indicare l’incarico.
• Comandi più brevi. Verdetti identici senza duplicati, note a consegna e chiusura, prova dichiarabile con argomenti diretti e risposta breve di send.
• Migliora. Una skill automatica per gli attriti dimostrati: regole circoscritte, verifica e commit locale dei propri file dopo le letture richieste dal progetto.
• Plugin: memoranda 1.0.9, Playwright 1.0.10, Sentry 0.1.7.