Replay Theater in Claude Code: rivedere le modifiche di un turno

Replay Theater è una demo di Claude Code Mods che permette di rileggere le edit di un turno, un passaggio alla volta. La distinzione decisiva è fra chiamata registrata e modifica riuscita: la sequenza può includere edit fallite o rifiutate. Per sapere cosa è davvero cambiato devi confrontare il replay con file e diff del repository. README ufficiale Replay Theater.

Le fonti sono verificate il 9 ottobre 2026. Questa guida propone un metodo di review e scenari ipotetici, senza dichiarare tempi risparmiati o test eseguiti da Giallo. Se vuoi prima orientarti nel prodotto, leggi cosa sono i Mods di Claude. Se ti interessa il controllo della correttezza, parti anche dalla guida alla revisione del codice con Claude.

Perché la sequenza delle edit può aiutare una review?

Un diff finale mostra uno stato rispetto a un riferimento. La sequenza può invece aiutare a capire l’ordine dei tentativi: quale file è stato toccato prima, quale parte è stata riscritta e dove potrebbe essere nata un’incoerenza. Sono due domande diverse. La vista del turno è utile quando l’attività risulta difficile da leggere come un unico blocco.

Questo non significa che l’ordine spieghi automaticamente il motivo. Un passaggio può essere parte di una correzione o un tentativo poi abbandonato. Per capire l’intenzione devi confrontarlo con la richiesta e con il ragionamento registrato nel workflow. Il pannello rende consultabile l’attività, ma non attribuisce una finalità affidabile a ogni chiamata.

Una review buona parte quindi da una frase: quale comportamento doveva cambiare? Poi usa il replay per trovare le parti interessate e il diff reale per controllare il risultato. Se non sai descrivere il comportamento atteso, una sequenza ben presentata può rendere più piacevole la lettura senza rendere più solida la decisione.

Quali operazioni osserva la demo ufficiale?

Il README descrive chiamate di edit come Edit, Write e MultiEdit, raggruppate per turno. Al termine propone un ingresso al replay, con navigazione fra passaggi e diff brevi. La demo osserva: non blocca, riscrive o ritarda le edit. Il suo ruolo è una lettura successiva, non una protezione prima dell’azione.

La guida agli eventi Mods aiuta a capire la differenza fra osservare una chiamata e rispondervi direttamente. Questo confine conta: se un team vuole impedire una modifica, deve scegliere un controllo con quella responsabilità. Un pannello apparso dopo il turno non può trasformarsi retroattivamente in autorizzazione preventiva.

Il perimetro va riportato nella procedura interna. «Replay del turno» non significa automaticamente «tutte le modifiche prodotte da qualunque processo». Un file può cambiare per una via diversa da quelle osservate. Per questo il confronto con il repository resta necessario anche quando ogni passaggio nel pannello sembra chiaro.

Chiamata, diff del turno e storico Git: cosa dimostrano?

Le tre rappresentazioni possono essere coerenti senza coincidere. Una chiamata dice che un’operazione è stata tentata o osservata. Un diff confronta due stati scelti. Uno storico Git conserva commit e relazioni fra essi. La conclusione deve essere proporzionata alla prova disponibile, non alla quantità di schermate aperte.

Il riferimento del diff deve essere esplicito. Confrontare con l’ultimo commit, con l’inizio del turno o con un branch differente può produrre insiemi diversi di modifiche. Se il repository conteneva già lavoro prima dell’attività, un diff globale non può essere attribuito integralmente a Claude. Annota lo stato iniziale prima di chiedere una modifica circoscritta.

Per chi usa Claude nello sviluppo, la guida a Claude per codice aiuta a definire richiesta e controllo umano. La demo aggiunge una forma di lettura a quel processo; non sostituisce l’identificazione del branch o la separazione del lavoro già presente.

Come trattare edit fallite o rifiutate?

Una chiamata fallita può essere importante per capire il percorso, ma non va contata come modifica applicata. Potrebbe aver cercato un testo non presente o incontrato un rifiuto. Se il replay la mostra, leggila come un tentativo da collegare al risultato. Non dedurre che una funzione sia stata corretta perché la proposta compare nel diff del pannello.

Il controllo pratico è semplice: trova il risultato della chiamata, apri il file reale e confronta la parte rilevante. Se il turno include una correzione successiva, controlla quale versione è rimasta. La decisione di review riguarda questa versione, anche se il tentativo precedente era più elegante. Un errore nel percorso può insegnare qualcosa senza restare un difetto nel risultato.

Una procedura condivisa dovrebbe usare parole coerenti: «tentativo», «applicato», «verificato». Non devono diventare sinonimi nel resoconto al responsabile. Se stai costruendo una vista tua, la guida al primo mod offre un modo per fissare prima il contratto di ciò che registri.

Perché serve aprire anche il diff completo?

La demo abbrevia i diff per mantenere leggibile la navigazione. Una porzione breve è utile per riconoscere il passaggio, ma può nascondere il contesto necessario: chiamanti, import, condizioni e dati vicini. La review non deve fermarsi nel punto in cui finisce la vista. Se la decisione dipende da una parte omessa, apri il file e il confronto completo.

Un rischio tipico è leggere soltanto le righe aggiunte. Un cambiamento apparentemente corretto può eliminare un controllo o alterare una condizione altrove. Anche la relazione fra file può essere importante: nome cambiato in un modulo e rimasto vecchio in un altro. Il replay suggerisce dove guardare; la ricerca e i controlli del progetto dimostrano se l’insieme è coerente.

Una review breve che usa il replay senza fermarsi al pannello

Rileggi il comportamento richiesto. Usa la sequenza per trovare file e tentativi rilevanti. Distingui gli esiti delle chiamate. Apri diff completo e contesto dei file. Esegui i controlli pertinenti. Scrivi infine quale comportamento è stato verificato e quale limite resta aperto, senza attribuire al replay una prova che appartiene ai test.

Dove appare la UI e quanto dura la registrazione?

Il README indica una superficie terminale, con pannello o rappresentazione nella banda a seconda del layout. Richiede Claude Code 2.1.287 o successiva per il percorso d’uso consigliato. Lo stato è in memoria e non va trattato come archivio permanente. Le prove e schermate delle build precedenti restano dichiarazioni dell’autore, non verifiche della macchina del lettore.

Prima di valutare l’utilità, controlla caricamento e spazio disponibile. Una UI mancante può dipendere dalla superficie; una sequenza azzerata può dipendere dal ciclo di vita dello stato. La diagnosi dei Mods distingue questi sintomi. Non chiedere a Claude di ripetere tutte le edit soltanto per ricostruire una vista scomparsa.

Per un passaggio di consegne conserva una nota del progetto: obiettivo, stato iniziale, file interessati, controlli e lavoro restante. Puoi consultare il replay mentre la prepari, ma la nota deve restare comprensibile anche senza quel pannello. È il criterio che permette a un collega di riprendere la review in una sessione diversa.

Come preparare una prova controllata della demo?

Scegli un repository didattico con una modifica piccola e uno stato iniziale noto. Prepara un caso normale e uno in cui una chiamata di edit non viene applicata. Il secondo caso serve a verificare l’interpretazione, non a provocare danni: deve essere progettato con contenuti sintetici e strumenti di test.

Confronta poi tre cose: passaggi osservati, risultati delle chiamate e diff effettivo. Scrivi dove coincidono e dove rispondono a domande differenti. Se la demo è utile, il team dovrebbe riuscire a spiegare quale ambiguità risolve. Una prova non deve necessariamente produrre una misura economica: può concludere che la vista è utile per alcuni task e superflua per altri.

La guida a testare i Mods spiega come simulare eventi e interazioni senza una chiamata al modello. Per il caricamento segui installazione e aggiornamento, dopo aver esaminato il codice. Un componente osservatore resta codice eseguito nel tuo ambiente e richiede fiducia nella fonte.

Due scenari ipotetici di review in Italia

Esempio ipotetico: una PMI di Parma aggiorna una schermata ordini. Claude Code tenta più edit su etichette e validazione. Il responsabile usa il replay per orientarsi, poi apre il diff del branch e scopre che una chiamata non è stata applicata. La correzione richiesta non può quindi essere considerata conclusa soltanto perché appare nella sequenza.

Il team verifica il caso d’uso con dati sintetici: un ordine valido, uno incompleto e una condizione al limite. Dopo il controllo prepara il resoconto delle modifiche rimaste. Il valore del replay è aver reso più facile trovare il tentativo rilevante, mentre l’esito viene dalle prove. Nessun dato reale di clienti serve per questa prima valutazione.

Esempio ipotetico: un’agenzia di Genova rinomina un componente condiviso. La sequenza mostra passaggi in diversi file e un diff breve per ciascuno. Il reviewer controlla il nome finale, i riferimenti rimasti e gli import, poi esegue il controllo previsto dal progetto. Un pannello con tutti i passaggi non dimostra da solo che non esistano riferimenti altrove.

Durante il passaggio di consegne il grafico non è più disponibile. Il collega usa branch, nota e diff, senza ripetere l’attività. Se il team vuole prevenire un’operazione delicata prima che avvenga, valuta invece Blast Radius o un gate coerente con la policy. Review dopo il turno e controllo prima dell’azione hanno responsabilità diverse.

Quali errori falsano la lettura del risultato?

Contare ogni passo come modifica riuscita nasconde rifiuti ed errori. Attribuire tutto il diff al turno ignora lavoro precedente. Leggere soltanto il diff breve omette contesto. Considerare la storia temporanea un archivio rende fragile il passaggio di consegne. Concludere che il progetto funziona dalla sequenza sostituisce i controlli con una rappresentazione dell’attività.

Per evitare questi errori usa un vocabolario preciso nel resoconto: quali chiamate sono state osservate, quali modifiche sono presenti e quali comportamenti sono stati verificati. Una frase come «ho visto cinque edit» non deve diventare «ho verificato cinque correzioni». Anche le allucinazioni AI si riducono nel processo quando le affermazioni vengono legate a prove identificabili.

Il confronto con la sicurezza dei dati conta se la vista conserva o presenta contenuti sensibili. Prima di adottare una registrazione custom, chiedi quale materiale deve essere mantenuto e per quanto tempo. Una UI di review non necessita automaticamente di diventare telemetria o archivio completo del lavoro delle persone.

Quale nota lasciare dopo aver letto il replay?

Conserva il comportamento richiesto, i file realmente cambiati e i controlli eseguiti. Se una chiamata è fallita ma una correzione successiva ha risolto il punto, distingui i due passaggi senza lasciare al collega una storia ambigua. La nota deve aiutare a verificare lo stato attuale anche quando il replay temporaneo non è più disponibile nella sessione.

Come inserirlo nella review del team senza aggiungere rumore?

Prova la demo su task in cui l’ordine dei tentativi aiuta davvero: modifica distribuita, correzione dopo errore o passaggio di consegne difficile. Per una modifica minuscola il diff può già bastare. Il criterio di adozione è la chiarezza della review, non il numero di schermate utilizzate. Una funzione opzionale permette al reviewer di scegliere quando aprirla.

Se serve una vista adattata al processo interno, il percorso di software su misura può partire dal contratto delle evidenze: tentativi, esiti e stato finale. Le guide a Claude Code e alla revisione del codice aiutano a mantenere il replay nel ruolo giusto, come supporto alla lettura del risultato.