Accordo sul campo: cosa ha insegnato il pilot

In breve. Il pilot gestito di Accordo su Arvo mi ha lasciato sei lezioni, e ognuna ha una data e un documento dietro: validato significa eseguito dal vivo, mai mergiato; i rifiuti sono funzioni con ricevuta; il via dell'owner è un fatto registrato, non un clima. Questo articolo è la sintesi oltre il diario: il resoconto giorno per giorno è in Accordo sul campo, qui ci sono le conclusioni che ne ho tirato, solo fatti con provenance, mai inventati. Pubblicato il 6 ottobre 2026.

1. Validato significa eseguito, non mergiato

Il 7 settembre 2026 una persona si è autenticata sul pilot, ha sottoposto una decisione di rinnovo, il worker ha liquidato e l'esito è rimasto lì dopo un riavvio. Dietro: suite locali verdi su entrambi i repository — 356 su 356 da una parte, 235 su 235 dall'altra — drenaggio dal vivo del giorno prima e un backup con restore che ha restituito 16 tabelle identiche riga per riga. Solo allora la milestone M1 è segnata validata, con i confini scritti: prova l'operazione delimitata del pilot, non tutti i casi d'uso e non un servizio pubblico.

La regola che ne ho ricavato governa tutto il cluster: una PR mergiata non si registra mai come capacità validata. La fondazione customer-data ne è il caso più istruttivo: matrice di verifica chiusa, PR lasciata esplicitamente aperta e non mergiata. Implementata e verificata, sì; live, no. E quando l'11 settembre la prova del rinnovo dal vivo si è chiusa con decisione eseguita dall'owner, il registro l'ha scritta come prova di rinnovo, non come via libera generale.

2. Se la CI è bloccata, sostituisci la sede, non il gate

Il 9 settembre 2026 la CI esterna era bloccata dalla fatturazione: account lock confermato da GitHub, startup_failure su tutti i repository. La risposta non è stata saltare i controlli, ma spostarli: decisione di campagna TEMP_LOCAL_CI, sette giorni al massimo, scadenza 16 settembre. Stessi test, stesse scansioni dei segreti, stessa revisione indipendente, stesse autorizzazioni: solo la sede di esecuzione cambiava, con checkout puliti, PostgreSQL 16 reale e report secret-free per ogni run.

Il dettaglio che conta: Actions restava BLOCKED_BY_BILLING e non veniva mai riportato verde. Sostituire la sede tenendo i gate è disciplina; dichiarare verde ciò che non gira è cosmetica. È la stessa onestà della classificazione M2: 23 casi d'uso, uno validato end-to-end, nove parziali, sette non applicabili, sei differiti — controllata meccanicamente da un test, con la milestone segnata classificata, non validata.

3. I difetti solo-dal-vivo sono il vero raccolto del pilot

Due difetti sono emersi solo dal vivo il giorno della M1 e sono stati chiusi lì: un URL che perdeva un parametro nel passaggio di mano e l'adattatore HTTP che lasciava cadere la query string. I test locali non potevano vederli, per costruzione.

Il giorno dopo ne sono arrivati altri due, entrambi del solo hosting condiviso, entrambi corretti dal vivo. Il web condiviso decodificava ogni corpo come testo UTF-8 e inoltrava solo il testo, mentre il CRM legge gli upload dal buffer binario: pilot #68, suite 395 su 395. Il fence del worker esponeva solo query, ma le operazioni servono connect() con BEGIN/COMMIT: ogni import veniva rifiutato — pilot #69, suite 398 su 398. E prima ancora, un bug TLS solo-dal-vivo — certificati senza SAN contro verifiche strette — chiuso dal pilot #64 con suite 437 su 0 e revisione indipendente. Il pilot è servito anche a trovare ciò che i test non potevano vedere: quella è la sua resa principale, non un incidente di percorso.

4. I rifiuti sono funzioni, con ricevuta

Il 10 settembre alle 20:3x il giro completo è andato verde dal vivo: upload CSV dell'owner, import 3 su 3, qualifica 3 volte 100 su 100, bozza, approvazione nominata — e poi un rifiuto governato POLICY_NOT_CONFIGURED, registrato, senza inviare niente. Poi adozione della policy TEST, import dimostrativo da 5 righe, ri-adozione, consegna alla casella di test. Il rifiuto in mezzo al giro verde non è un intoppo: è la prova che la policy blocca davvero, con ricevuta.

Stessa logica sul retry: rinviare una chiave di idempotenza che nominava una richiesta fallita restituiva per sempre la riga morta, e l'import del pilot era stato riaccodato con un UPDATE da operatore. Il giorno dopo, piattaforma #90 dal vivo: le righe fallite aprono un successore con chiave derivata, storia collegata, tempeste convergenti sullo stesso successore. Il racconto completo è nel retry che riceveva la riga morta. Un rifiuto registrato vale più di un via libera dichiarato.

5. Il via dell'owner è un fatto registrato

Alla fine del giro verde del 10 settembre, l'owner ha detto "si si funziona, vai avanti". Nel registro non è un clima: è ARVO_OWNER_ACCEPTED, con data e ora, e da lì il lavoro è passato alla readiness di prodotto — sette slice dal Today compatto al pattern Sealed sui rinnovi, pilot #72–#78, ognuna dal vivo.

Lo cito perché è il meccanismo che tiene insieme tutto il resto: le decisioni datate che cambiano strada. Due giorni prima, l'8 settembre, il prodotto gestito di default era diventato un'applicazione condivisa multi-tenant, e la proposta da 13 dollari al mese di stack dedicato per il secondo cliente non era stata approvata. Stesso giorno, il vincolo che l'app OAuth creata a mano resti solo bootstrap dell'operatore e non diventi mai un passo di onboarding. Decisioni con data, non intenzioni: si può rileggere perché il prodotto ha la forma che ha.

6. La classificazione onesta batte il semaforo verde

Chiudo con la lezione che contiene le altre. La M2 dice 1 validato, 9 parziali, 7 non applicabili, 6 differiti, e ogni riga positiva cita evidence eseguibile, ogni parziale nomina la parte mancante, ogni differita nomina la dipendenza. Predizione, conteggi di supporto, diritto del consenso, notifiche e Interactions non si chiudono con un pilot di runtime — ed è scritto, non taciuto.

Un registro che dice cosa manca, riga per riga, è più utile di un semaforo verde: dice dove lavorare la prossima settimana. Vale per il pilot come per il prodotto: marketing automation, profondità deal-desk e predizione restano fuori dallo scope senza promozioni, Interactions non esiste, e il giro completo sulla nuova UX del web CRM non è ancora stato ripercorso dal vivo. La tesi completa è nel pillar sull'autonomia sotto controllo: autonomia sotto controllo significa anche saper dire cosa il sistema non fa ancora.

Fatti e limiti, separati

Fatti: M1 validata dal vivo il 7 settembre 2026 con suite 356/356 e 235/235 e restore da 16 tabelle; TEMP_LOCAL_CI dal 9 settembre con scadenza 16, gate invariati; pilot #63/#64/#68/#69 dal vivo con suite e revisioni; import import-d7258029 riuscito il 10 settembre alle 19:56:46Z; giro dogfood verde con rifiuto POLICY_NOT_CONFIGURED registrato; ARVO_OWNER_ACCEPTED del 10 settembre; piattaforma #90 dal vivo l'11; M2 classificata 1/9/7/6 con test meccanico; decisioni owner datate dell'8 settembre.

Limiti: una milestone di runtime non valida 23 casi d'uso né un servizio pubblico; la fondazione customer ha la PR aperta; il giro UX completo non è stato ripercorso dal vivo; marketing automation, predizione e Interactions restano fuori. Sei lezioni da un pilot non misurano quanto il disegno regga in produzione: misurano cosa ha insegnato finora.

Domande frequenti

Cosa significa che una milestone è validata?

Che è stata eseguita dal vivo con evidence datata, dentro confini scritti. Non significa mergiata, non significa completa: la M1 prova l'operazione delimitata del pilot, e la M2 resta classificata finché i blocchi aperti non si chiudono.

Perché pubblicare una classificazione con un solo caso validato?

Perché è vera e verificabile meccanicamente, e dice dove lavorare: ogni parziale nomina la parte mancante, ogni differita la dipendenza. Una riga validata per esecuzione vale più di ventitré spuntate per ottimismo.

Cosa ha trovato il pilot che i test non vedevano?

Difetti solo-dal-vivo: parametri persi nei passaggi di mano, query string cadute, handshake TLS, decodifica dei corpi, fence senza connect. Chiusi lì, con suite e revisioni: è la resa principale del pilot, non un incidente.

Quando il pilot diventa prodotto?

Quando la sequenza lo dice con evidence eseguibile: pilot Arvo, hardening dei casi, baseline UI, fondazione condivisa, due run Zeno alla cieca, e solo dopo il pilot esterno. Ogni gate ha criteri scritti; nessuno si supera per dichiarazione.