Sessioni remote, routine asincrone e progetto finale
Lavorare in remoto o su pianificazione sposta il controllo nel tempo. Per restare affidabile, la routine deve sapere chi la possiede, dove conserva lo stato, quando fermarsi e quali azioni attendono una decisione umana.
Cosa affronti, passo dopo passo
Lo stato di una sessione
Quando una sessione dura più della tua presenza davanti allo schermo, il suo stato non può vivere soltanto nella conversazione. Se la connessione cade o torni il giorno dopo, devi distinguere ciò che è stato fatto, ciò che è stato soltanto proposto e ciò che non è mai partito.
Prima distingui l’ambiente: Remote Control continua a eseguire gli strumenti sulla tua macchina locale; una sessione cloud gira invece su infrastruttura remota. In entrambi i casi una sessione recuperabile registra input, commit o snapshot di partenza, lavoro svolto, artefatti, errori e prossimo passo.
Assegna un proprietario umano e un limite temporale. «Lavora finché hai finito» non è una stop condition; «analizza cinque dipendenze e produci un rapporto entro trenta minuti» lo è.
Una sessione remota ha analizzato dipendenze per venti minuti e poi ha perso la connessione. Non sai se abbia modificato file o soltanto prodotto un rapporto parziale.
- Leggi il checkpoint con run-id, commit iniziale e fase raggiunta; non affidarti all’ultimo messaggio visibile.
- Confronta lo stato Git attuale con lo snapshot e identifica ogni file modificato o artefatto creato.
- Verifica quali controlli hanno un esito registrato e considera non eseguiti quelli privi di output o exit code.
- Riparti dalla prima fase incompleta con gli stessi limiti, oppure chiudi la sessione se il repository non corrisponde più al punto di partenza.
Risultato: La ripresa nasce da dati persistenti. Non duplichi lavoro già provato e non attribuisci alla sessione attività che non hanno lasciato evidenza.
Pianificazioni idempotenti
Uno scheduler può avviare la stessa routine più di una volta, anche quando tu hai scritto «ogni notte». Retry, timeout e cambi d’orario rendono la ripetizione normale. L’idempotenza serve proprio qui: la seconda esecuzione non deve creare un secondo effetto come se fosse la prima.
Una routine giornaliera può partire due volte per retry, cambio d’orario o errore del servizio. Usa un identificatore che includa periodo logico e fuso orario, per esempio `review-2026-08-08-Asia-Singapore`, e controlla se il rapporto di quel periodo esiste già prima di produrne un altro.
I retry devono essere limitati e distanziati. Ripetere immediatamente un’operazione che fallisce per indisponibilità remota può aumentare il problema e consumare risorse senza nuova informazione.
Il controllo dipendenze parte alle 02:00, va in timeout durante la notifica e lo scheduler lo rilancia. Il rapporto era già stato salvato.
- Calcola il run-id con data, repository e versione della routine prima di qualsiasi scrittura.
- Salva il rapporto usando quel run-id come chiave e registra separatamente lo stato della notifica.
- Al retry, rileva il rapporto esistente e salta analisi e scrittura; riprendi soltanto la notifica ancora incompleta.
- Dopo il numero massimo di tentativi, conserva l’errore e invia un avviso diverso, senza rigenerare il rapporto.
Risultato: Ottieni un solo artefatto didattico e una traccia chiara dei tentativi di consegna. Il retry completa ciò che manca senza ripetere ciò che è già riuscito.
Controllo remoto e checkpoint umani
Controllare una sessione dal telefono o continuare dal browser cambia il canale, non cambia la responsabilità. Un pulsante remoto può essere comodo, ma non rende automaticamente sicura l’azione che avvia. Prima di approvare devi ancora capire stato, prova ed effetto.
Canali, controllo remoto e integrazioni browser sono superfici per inviare istruzioni o continuare una sessione. L’interfaccia remota non trasferisce magicamente filesystem e credenziali: contano sempre la macchina o il cloud che eseguono gli strumenti. Leggere un rapporto può essere automatico; pubblicare o modificare sistemi esterni richiede un permesso appropriato.
Una notifica utile contiene stato, prova, decisione richiesta e scadenza. Non deve costringere l’utente a ricostruire l’intera sessione per capire se approvare.
La routine ha preparato un aggiornamento di dipendenza e chiede dal canale remoto il permesso di aprire una pull request.
- Inserisci run-id, repository e commit di partenza, così l’utente sa esattamente quale lavoro sta valutando.
- Riassumi diff, test eseguiti e rischio residuo con link o artefatti verificabili, non con un semplice «tutto ok».
- Descrivi l’effetto richiesto: creare una pull request su un branch preciso, senza merge e senza pubblicazione.
- Aggiungi scadenza e comportamento in assenza di risposta: nessuna azione, checkpoint conservato e sessione chiusa.
Risultato: L’utente può approvare o rifiutare dal canale remoto senza ricostruire il contesto e senza concedere un’autorizzazione più ampia di quella richiesta.
Capstone: sistema completo, non autonomia totale
Il progetto finale non serve a mostrare quanti strumenti riesci ad accendere. Serve a dimostrare che sai costruire un flusso comprensibile anche quando qualcosa fallisce. Un sistema maturo non è quello che fa tutto da solo: è quello che rende chiari autorità, stato e prova in ogni passaggio.
Il workflow finale usa contesto stabile, una skill di review, un collegamento in sola lettura, hook locali, agenti con ownership e una pipeline strutturata. Ogni componente risolve un confine specifico; nessuno riceve potere solo perché esiste.
Alla fine devi poter aprire il rapporto e rispondere in due minuti: chi ha autorizzato cosa? Quale prova è passata? Da dove riparto se il servizio remoto non risponde? Se non sai rispondere, il workflow non è ancora pronto. La consegna separa implementato, verificato e non verificato e conserva abbastanza evidenza per riprendere.
- Crea un run-id e salva lo snapshot iniziale del repository.
- Carica contesto stabile e pianifica una routine con stop condition.
- Delega analisi indipendenti con ownership e accessi minimi.
- Applica hook, schema JSON, lint e test come gate recuperabili.
- Salva un checkpoint e chiedi approvazione prima di ogni effetto esterno.
- Consegna stato, prove, limiti e istruzioni precise per la ripresa.
Task Notes deve aggiungere il campo priorità, aggiornare i test, produrre una review e preparare una consegna remota senza pubblicare automaticamente.
- Crea uno snapshot Git, scrivi l’obiettivo nel contesto stabile e definisci criteri visibili: priorità salvata, mostrata e coperta dai test.
- Usa una fonte MCP in sola lettura per la documentazione, un Explorer per la mappa e ownership separate per parser e test.
- Applica hook locali a segreti e formattazione; poi esegui pipeline con schema JSON, lint, test e stop al primo gate fallito.
- Salva rapporto e checkpoint. Chiedi approvazione soltanto per creare una pull request; lascia merge e deploy fuori dall’autorità del flusso.
Risultato: Il progetto produce codice e prove, ma soprattutto una catena leggibile di decisioni. Un’altra persona può capire che cosa è successo, ripetere i controlli e riprendere senza fidarsi della memoria della sessione.
Revisione notturna senza auto-merge
Task Notes controlla dipendenze ogni notte ma conserva l’ultima decisione all’utente.
Trigger: 02:00, run-id = data + repository
Leggi: dipendenze e advisory, sola lettura
Analizza: massimo 5 aggiornamenti
Checkpoint: salva rapporto e log
Notifica: rischio, prove, decisione richiesta
Gate: nessun branch, push o merge senza approvazione