Nella prima puntata abbiamo seguito una domanda mentre diventava un lavoro: il modello sceglieva uno strumento, ne leggeva il risultato e decideva il passo successivo. Adesso fermiamo la scena a metà. Abbiamo chiesto a Velia di confrontare due documenti e preparare una nota con le differenze. Il primo documento è stato letto; sul secondo manca ancora una verifica. Poi il lavoro si interrompe.
Quando torniamo, vorremmo poter dire: «Eravamo al confronto fra le due versioni, finiamo da lì». Per costruire questa continuità occorre sapere che cosa è stato conservato, a quale tentativo appartiene e quanto sia ancora valido. Seguiremo un caso illustrativo, costruito sui meccanismi presenti nei sorgenti di Velia al 28 ottobre 2026: le azioni del racconto non sono il resoconto di una prova sul Mac della persona.
La prima scelta: dare una casa a cose diverse
Pensiamo a quattro domande. Che cosa ci siamo detti? Come preferisce lavorare la persona? Quali punti rimangono aperti in questo confronto? Quali operazioni sono state effettivamente registrate? Nel progetto, queste domande portano a depositi diversi: cronologia della chat, memoria generale, taccuino del lavoro e registro delle esecuzioni.
La cronologia conserva i messaggi e le loro versioni. Se cambiamo una domanda precedente e seguiamo un altro ramo della conversazione, il contesto corrente deve seguire quel ramo. La memoria generale raccoglie invece fatti e preferenze riutilizzabili fra conversazioni, quando è abilitata. Il taccuino appartiene al lavoro della chat. Il registro collega ogni esecuzione, chiamata run nel codice, ai suoi passi e ai loro esiti.
Nel nostro confronto, «preferisco una spiegazione sezione per sezione» può essere una preferenza durevole. «Manca la verifica del secondo documento» è invece un appunto di questo lavoro. «La lettura del primo documento è riuscita» appartiene al registro di un’operazione precisa. La distinzione ci aiuta a capire quale informazione cercare quando ripartiamo.
Un taccuino che conservi anche i dubbi
Una conversazione può essere lunga e contenere deviazioni utili al dialogo ma poco utili alla ripresa. Il taccuino offre uno spazio più mirato per obiettivo, vincoli, decisioni, risultati, domande aperte, prossimo passo e riferimenti ai materiali. Il coordinatore invita il modello ad aggiornarlo nei passaggi significativi. Questo invito non garantisce che ogni dettaglio venga annotato: la qualità degli appunti rimane parte del lavoro da verificare.
Il taccuino distingue la base di un appunto. Una decisione proposta dal modello deve rimandare a un messaggio della persona con una citazione esatta. Un risultato può rimandare a un messaggio o a un esito di strumento. Se manca il riferimento, il sistema tratta l’appunto come ipotesi. Così «il secondo documento potrebbe avere una sezione nuova» rimane una domanda da controllare, anche se la ritroviamo il giorno dopo.
Quando il filo si interrompe
Durante un tentativo, il contesto in uso cresce con risposte e risultati degli strumenti. I dati persistenti vengono invece conservati nei rispettivi archivi locali. Nel prototipo adulto, la memoria generale usa un database SQLite separato da quello che conserva chat e registro delle esecuzioni. È una scelta concreta di organizzazione dei dati: chiudere una finestra non dovrebbe cancellare il lavoro già depositato.
Un arresto improvviso dell’app lascia però una domanda: quali passi erano ancora in corso? All’apertura dell’archivio, la funzione di recupero esamina le esecuzioni rimaste attive e le marca come interrotte, oppure completa la cancellazione già avviata. Assegna inoltre una nuova generazione, un identificatore che distingue il lavoro ancora valido da quello della sessione precedente. Alcune operazioni preparate e prive di esito restano incerte.
La ripresa comincia da una nuova richiesta
Torniamo alla frase «finiamo da lì». Nel percorso corrente della chat, il coordinatore può segnalare al modello il tentativo precedente come candidato al recupero, se appartiene al ramo attuale ed è fallito o interrotto. Non cerca qualunque vecchia esecuzione e non tratta automaticamente come recuperabile ogni lavoro annullato. Il modello riceve inizialmente i metadati del candidato, compresa la richiesta originale quando disponibile.
È il modello a interpretare se la richiesta attuale riguarda quel lavoro. La persona può esprimerla liberamente; non serve una parola obbligatoria. Se il collegamento è pertinente, il modello può chiamare chat_recovery, la funzione che legge i riferimenti conservati del candidato. Per una domanda diversa deve lasciare da parte quel materiale. Se il collegamento rimane ambiguo, occorre chiarirlo.
Il recupero conversazionale ha un perimetro preciso. Può riportare risultati riusciti di consultazione dei manuali, ricerca e citazioni, insieme a testi precedenti del modello nei casi ammessi. Non riversa nel contesto tutti i vecchi risultati degli strumenti. Il materiale arriva come riferimento storico: non attesta che il documento finale sia stato consegnato e non trasferisce permessi.
Il documento potrebbe essere cambiato nel frattempo
Immaginiamo che, durante l’interruzione, qualcuno abbia sostituito il secondo documento. Gli appunti ci ricordano che cosa volevamo confrontare, ma per descrivere le differenze attuali dobbiamo verificare le fonti. Il modello può usare gli strumenti disponibili per rileggerle entro gli accessi ancora validi. Una citazione recuperata resta legata alla fonte e al momento a cui apparteneva.
Per gli inventari di cartella esiste anche una ripresa strutturata, distinta dal recupero conversazionale. Un checkpoint è un punto di ripresa identificato e conservato: permette di ritrovare l’inventario, le sue revisioni e le regole dichiarate. La ripresa controlla la compatibilità, ricostruisce lo stato in una nuova generazione e verifica i byte prima di riusarli. Avere acquisito un file, comunque, non dimostra di averne già completato l’interpretazione.
La nota che forse esiste già
C’è infine un caso più delicato. Spostiamo l’interruzione al momento in cui Velia ha chiesto di creare la nota finale, ma non ha ancora registrato una conferma sufficiente. La nota potrebbe esistere nell’applicazione anche se nel nostro registro manca un esito conclusivo. Scriverne subito un’altra rischia di creare un duplicato.
Il prossimo passo deve quindi riconciliare i due stati: confrontare ciò che risulta nel registro con ciò che è effettivamente presente nella destinazione, usando gli strumenti e gli accessi disponibili. Se il riscontro rimane insufficiente, l’esito resta incerto e va dichiarato. Un appunto «nota creata» o una vecchia frase del modello non sostituisce questo controllo. La ripresa non offre una garanzia universale di esecuzione “esattamente una volta”.
Ritrovare il lavoro e sapere che cosa manca
Alla fine del nostro racconto, ripartire significa ricostruire un punto affidabile da cui scegliere la prossima azione. La cronologia ritrova lo scambio, la memoria generale può fornire le preferenze abilitate, il taccuino mantiene il filo operativo e il registro aiuta a leggere gli esiti. Le fonti e i diritti correnti restano da controllare quando servono. È così che la continuità prende forma nel progetto: conservando anche domande aperte e limiti, finché abbiamo elementi sufficienti per superarli.
Questi meccanismi descrivono il codice del prototipo; non dimostrano che ogni interruzione sia recuperabile o che ogni appunto sia completo. Il contesto del modello mantiene inoltre limiti tecnici reali: un archivio persistente non lo rende infinito. Il passo successivo del diario seguirà l’altra metà di questa continuità: come un obiettivo mantiene attività e criteri di completamento nel tempo.