Approfondimento tecnico — intervento del 15 ottobre 2026
Prodotto: JoyInCloud, ideato e commissionato da Media Marketing S.r.l.
Ambito: prenotazione online, backend/package, consumer, sincronizzazione, legacy, migrazioni e rilascio
Nota di lettura. Questo racconto deriva dalla ricostruzione dell’intervento fornita dal responsabile tecnico a partire dalla chat di lavoro e dal dossier di progetto. Distingue test eseguiti, distribuzione e acceptance finale; non sostituisce un audit indipendente né implica l’autorizzazione a pubblicare sorgenti o dettagli operativi riservati.
1. La richiesta che sembrava un pulsante
Il committente chiedeva di consentire al cliente finale di richiedere l’inserimento in lista d’attesa quando uno slot risultava occupato, mostrando gli avvisi necessari nel percorso di prenotazione.
Ma il comportamento richiesto attraversava più sistemi:
- il salone doveva poter abilitare o disabilitare la funzionalità;
- una richiesta in lista d’attesa non doveva consumare disponibilità aggiuntiva;
- il pagamento poteva avvenire soltanto in negozio;
- il salone poteva accettare o rifiutare;
- una scadenza poteva determinare un rifiuto automatico;
- modifiche, cancellazioni e notifiche dovevano attraversare la sincronizzazione tra vecchio e nuovo sistema.
L’analisi individuò elementi già presenti nel modello, nella configurazione e nella corrispondenza con il sistema precedente, ma un campo esistente non equivale a un processo implementato.
Due lacune cambiarono il perimetro: la configurazione della prenotazione online non veniva sincronizzata continuamente; inoltre il nuovo sistema sopprimeva notifiche provenienti dal componente di inoltro, compresi gli aggiornamenti che avrebbero dovuto informare dell’accettazione da parte del salone.
2. Prima i contratti, poi il parallelismo
Il coordinatore stabilì i contratti condivisi e divise il lavoro tra tre specialisti AI:
| Ambito | Responsabilità |
|---|---|
| Backend e package Cicero | Modello, disponibilità, creazione/modifica prenotazioni, pagamento, scadenza, notifiche |
| Sync e legacy | Mapping, direzioni di sincronizzazione, eventi di configurazione, scadenze |
| Consumer | Orari occupati, ingresso in lista, avvisi, riepilogo e modifiche |
Il parallelismo non era basato su confini di repository arbitrari. I contratti dovevano preservare il significato condiviso dell’operazione.
Due dettagli lo mostrano bene.
L’origine conta più dello stato corrente. Una richiesta nata in lista d’attesa non doveva diventare pagabile online dopo la transizione dalla lista d’attesa alla conferma. Il solo stato corrente non bastava: il contratto conservava un’informazione persistente sull’origine della richiesta.
Omesso non significa nullo. Negli aggiornamenti, omettere un campo doveva preservare il valore esistente, mentre un valore nullo esplicito poteva cancellarlo. Nella sincronizzazione delle scadenze questa differenza era parte della correttezza, non un dettaglio di serializzazione.
Il coordinatore conservò la responsabilità dei contratti comuni; gli specialisti implementarono aree circoscritte. Quando emerse la necessità di modificare anche il gestionale e l’agenda del sistema precedente, l’ampliamento del perimetro fu dichiarato prima di procedere.
- 1. Evento e analisiUna richiesta visiva viene ricondotta ai comportamenti del dominio.
- 2. Contratto e specialistiPrima i significati condivisi, poi gli incarichi nei tre ambiti.
- 3. Verifiche e integrazioneTest dei componenti, build, review e integrazione delle modifiche.
Delivery autorizzata: distribuzione dei quattro componenti del nuovo sistema e applicazione di due migrazioni. Il collaudo completo tra cliente, sistema precedente, nuovo sistema e push reale resta un livello distinto, non completato nella delivery descritta.
3. Che cosa hanno fatto Cicero e JIC
Le sorgenti applicative del nuovo sistema sono state aggiornate nei package Cicero: dichiarazioni YAML, handler, inject, job, notifiche e migrazioni. Il flusso riportato è stato:
Sorgenti committate → distribuzione Cicero → generazione target isolato → codegen consumer → test e build.
Il codice specifico della lista d’attesa non è stato tutto generato: gli agenti hanno implementato logiche applicative; consumer, componente di inoltro e moduli Java legacy hanno richiesto modifiche proprie. Cicero ha fornito la struttura del modello e le superfici generabili ed estensibili.
JIC ha fornito il substrato operativo: sessioni e worktree, capacità progressive per preparare sorgenti, target, runtime e verifiche; stato persistente delle operazioni; supporto a integrazione e cleanup. JIC non ha deciso quali agenti avviare né assegnato loro i compiti.
4. Il crash della conversazione
Durante il lavoro l’applicazione di chat del coordinamento è andata in crash. Alla ripresa, le modifiche già persistite nei tre worktree erano recuperabili; sono state lanciate tre nuove istanze di specialisti sugli stessi tre ambiti.
Non si tratta quindi di sei agenti attivi contemporaneamente. La ripresa ha richiesto ispezione dello stato e riallineamento, non è avvenuta automaticamente senza intervento.
L’evidenza è circoscritta ma concreta: un’interruzione del canale conversazionale non ha cancellato il lavoro salvato negli ambienti operativi.
5. Prerequisiti mancanti e difetti della fabbrica
Prima della compilazione del servizio gestionale precedente, l’aggiornamento Git previsto dalla procedura era bloccato da un errore di accesso SSH. Le verifiche indipendenti sono proseguite; il prerequisito bloccato è rimasto visibile. Il responsabile umano ha aggiornato il checkout principale del sistema precedente, e il coordinatore ha portato gli aggiornamenti nel worktree effettivamente utilizzato da JIC.
Una volta superato il blocco, la compilazione ha esposto un errore reale nel payload: mancava un metodo di lettura di un identificativo. Dopo la correzione, build e test dell’evento di configurazione sono passati.
Un altro problema riguardava JIC stesso: il refresh del target tentava di riutilizzare una sessione annidata già chiusa; un workaround sul nome della sessione entrava in conflitto con i controlli di identificazione delle risorse. Una proposta iniziale avrebbe allentato eccessivamente i controlli di cleanup ed è stata respinta in review.
La verifica è proseguita in una sessione separata, preservando codice e risorse. Successivamente è stata applicata una correzione più stretta: accettare il nome personalizzato solo se corrispondeva all’override esplicito, mantenendo controlli su percorso e ownership. I relativi test del lifecycle sono passati.
Il recupero non ha richiesto di trasformare un errore operativo in autorizzazione a cancellare o forzare risorse non verificate.
6. Le verifiche documentate
| Componente | Verifiche riportate |
|---|---|
| Backend del nuovo sistema | 96 test in 17 suite |
| Consumer | 67 test in 10 file e build TypeScript/Vite |
| Componente di inoltro | 192 test superati, uno saltato, e build |
| Import offline | 40 test |
| Agenda precedente | Build e 2 test sulla scadenza |
| Gestionale precedente | Build e 1 test sull'evento configurazione |
| Totale | 398 test superati, 1 saltato |
Non sono 398 nuovi test, né 398 percorsi end-to-end. Comprendono test pertinenti e di regressione sui diversi componenti.
Le verifiche hanno incluso anche l’aggiornamento di fixture, la sopravvivenza della scadenza attraverso l’import iniziale e la compatibilità delle integrazioni coinvolte.
I commit sono stati integrati nei rami di destinazione. Worktree, branch e target temporanei sono stati ripuliti. Alla chiusura dello sviluppo non erano ancora stati effettuati push o deploy: la delivery era un’operazione successiva, soggetta a un’autorizzazione distinta.
7. La delivery: cosa era verificato e cosa no
La successiva autorizzazione ha riguardato quattro componenti del nuovo sistema: backend, gestionale, servizio di sincronizzazione e webapp consumer. Android e iOS erano esclusi; il rilascio del sistema precedente era gestito separatamente.
La prima build backend è fallita perché Docker Desktop non era attivo. Non era stata pubblicata alcuna immagine. È stato poi usato il daemon di sistema con un contesto esplicito, senza alterare quello globale.
Il rilascio ha verificato la corrispondenza dei digest tra immagini pubblicate e pod attivi, lo stato del rollout, la health e l’assenza di riavvii dei nuovi pod. Due migrazioni sono state applicate senza eseguire un seed globale; la migrazione dei testi standard preservava gli override dei saloni.
Al termine di questa delivery, però, non risultava ancora collaudato l’intero percorso cliente → sistema precedente → nuovo sistema → notifica push reale. Il browser aveva coperto catalogo e scelta del servizio sul pilota; il passo successivo richiedeva il login, e non erano stati creati appuntamenti live né inviate push reali in quella verifica. La gestione completa della scadenza richiedeva anche il rilascio del sistema precedente dell’agenda e del gestionale, su un percorso distinto.
Le evidenze sostengono quindi: implementazione, integrazione, test dei componenti, recupero dopo interruzioni e delivery verificata dei componenti del nuovo sistema. Non giustificano la frase «flusso completo verificato end-to-end» alla data di chiusura del dossier.
8. Cosa insegna questo episodio
- Un requisito UI può essere un problema di semantica del dominio. Il contratto su stato, origine, pagamento e scadenza è venuto prima del pulsante.
- Il parallelismo richiede architettura. Gli agenti non hanno deciso autonomamente tre versioni incompatibili dello stesso contratto.
- Isolare non significa eliminare i conflitti. Worktree e sessioni separano il lavoro; integrazione e review ne risolvono i significati concorrenti.
- Gli strumenti vanno considerati parte del prodotto ingegneristico. JIC ha avuto un difetto, che è stato limitato e corretto senza nasconderlo.
- Un test verde non autorizza ogni conclusione. Costruzione, integrazione, delivery e acceptance sono stati trattati come livelli diversi di evidenza.
Una fabbrica affidabile non è quella in cui nulla si rompe. È quella che rende riconoscibili gli errori, conserva il lavoro e permette di recuperare senza perdere il controllo.
Scopri la fabbrica software · Leggi il caso JoyInCloud · Il nostro metodo