L'evidence pack di Accordo: fatti, interpretazioni, ipotesi

In breve. Questo è l'evidence pack dell'esperienza Accordo: ogni claim su repository, pilot e decisioni, classificato FACT, INTERPRETATION o HYPOTHESIS, con la fonte pubblicata accanto. I repository sono privati, quindi qui non compare nulla che non sia già pubblicato: i fatti vengono dagli articoli del cluster e dall'esempio pubblico, il resto è lettura mia o ipotesi dichiarata. Il contesto completo è nel pillar sull'autonomia sotto controllo.

La legenda: tre classi, una regola

FACT. Osservato dal vivo o riproducibile, con data e fonte pubblicata. Ogni riga cita dove verificarla.

INTERPRETATION. La mia lettura dei fatti, marcata come tale. Puoi condividerla o no senza contestare i fatti.

HYPOTHESIS. Non verificato. Per ognuna dico cosa la verificherebbe: finché manca, resta ipotesi.

La regola di provenance: i repository di Accordo e del pilot sono privati. Cito solo ciò che ho già pubblicato negli articoli o che gira sull'esempio pubblico su accordo.dev. Niente numeri dai quaderni interni, niente anticipazioni dal codice non pubblicato.

FACT dal repository e dalla demo

F1. Da un progetto creato con lo scaffolder, un agente fa avanzare due rinnovi mentre il terzo — 80.000 euro — resta in approval_pending, con lo step di valutazione che mostra il punto esatto del fermo. La scena è registrata con VHS dallo script nel repository: gli stessi comandi, rieseguiti, danno la stessa scena. Fonte: approvazioni umane e audit.

F2. La policy è codice deterministico versionato con una soglia di valore: ogni decisione porta con sé la versione esatta della regola che l'ha governata, e le decisioni vecchie restano legate alla regola vecchia. Fonte: approvazioni umane e audit.

F3. Nei test del workflow c'è un'asserzione esplicita: l'attore dell'approvazione non può essere l'agente. Il perimetro è scritto: l'attore è affermato, non autenticato, e il divieto vale contro un agente onesto, non contro un attaccante. Fonte: approvazioni umane e audit.

F4. Ogni mutazione lascia la stessa firma: attore che ha chiesto, decisione presa, policy con nome, versione e impronta, run che l'ha eseguita, istanti e conteggio dei tentativi. Si rilegge con il tool MCP crm_get_trace o con crm trace da terminale. Nessun secret finisce in audit, trace, backup o telemetria. Fonte: audit e trace delle mutazioni.

F5. Il coding agent lavora con 12 skill di dominio e un server MCP via stdio, e tutto ciò che genera o distrugge resta in dry-run finché non passi un flag di apply esplicito. Fonte: il pillar, sezione visione.

F6. Sull'esempio pubblico gira il preventivo Q-1042 da 180.000 euro, scontato del 25% oltre la soglia del 20%: la transizione dell'agente è rifiutata dalla policy standard-sales-discount v1, Sarah Rossi — sales manager nominata — approva alle 14:02, l'audit registra sul run 4d2a91. Fonte: approvazioni umane e audit e accordo.dev.

FACT dal pilot

F7. 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 356 su 356 da una parte e 235 su 235 dall'altra, drenaggio dal vivo del giorno prima, backup con restore di 16 tabelle identiche riga per riga. La milestone M1 è segnata validata dentro questi confini: prova l'operazione delimitata del pilot, non tutti i casi d'uso. Fonte: il diario del pilot.

F8. Nel dettaglio del 7 settembre: richiesta 89853f45 alle 14:39:47Z, liquidata al primo tick alle 14:39:51 con esito decision:9e6e9f94 e tentativi pari a 1. Il reinvio identico restituisce lo stesso id con stato succeeded: quattro richieste totali in tutto l'ambiente, coda vuota, nessuna duplicazione. Fonte: audit e trace delle mutazioni.

F9. Il giorno della M1 sono emersi due difetti solo-dal-vivo, chiusi lì: un URL che perdeva un parametro nel passaggio di mano e l'adattatore HTTP che lasciava cadere la query string. Fonte: il diario del pilot.

F10. Il 9 settembre 2026 la CI esterna era bloccata dalla fatturazione, con startup_failure su tutti i repository. Risposta: decisione TEMP_LOCAL_CI, sette giorni al massimo con scadenza il 16 settembre — stessi test, stesse scansioni, stessa revisione, su checkout puliti con PostgreSQL 16 reale. Actions restava dichiarata bloccata, mai riportata verde. Fonte: cosa ha insegnato il pilot.

F11. Tre difetti solo-dal-vivo con numero di caso e suite: handshake TLS con certificati senza SAN contro verifiche strette, chiuso dal pilot numero 64 con suite 437; web condiviso che decodificava ogni corpo come testo UTF-8 mentre il CRM legge dal buffer binario, pilot numero 68 con suite 395 su 395; fence del worker senza connect() per BEGIN/COMMIT, pilot numero 69 con suite 398 su 398. Fonte: cosa ha insegnato il pilot.

F12. L'import CSV dell'owner è arrivato in fondo il 10 settembre alle 19:56:46Z con ricevuta datata, dopo due fallimenti di upload da due cause radice del solo hosting condiviso, entrambe corrette dal vivo. La fondazione customer-data resta invece non mergiata: matrice di verifica chiusa, PR lasciata esplicitamente aperta. Due artefatti, due stati. Fonte: il diario del pilot.

F13. Il 10 settembre alle 20:3x il giro completo è andato verde dal vivo: upload CSV, import 3 su 3, qualifica 3 volte 100 su 100, bozza, approvazione nominata — e in mezzo un rifiuto governato POLICY_NOT_CONFIGURED, registrato, senza inviare niente. Poi policy TEST, import dimostrativo da 5 righe, consegna alla casella di test. Fonte: cosa ha insegnato il pilot.

F14. Alla fine del giro del 10 settembre l'owner ha dato il via registrato come ARVO_OWNER_ACCEPTED, con data e ora; da lì il lavoro è passato alla readiness di prodotto, sette slice numerate dal 72 al 78, ognuna dal vivo. L'11 settembre la piattaforma numero 90 ha portato dal vivo il successore con chiave derivata per le righe fallite. Fonte: cosa ha insegnato il pilot.

FACT dalle decisioni datate

F15. La classificazione dei 23 casi d'uso business dice: 1 validato end-to-end, 9 parzialmente supportati, 7 non applicabili, 6 differiti. Il risultato è controllato meccanicamente da un test: 23 righe, identificativi distinti, ogni riga positiva cita evidence eseguibile. La milestone è segnata classificata, non validata. Fonte: il diario del pilot.

F16. L'8 settembre 2026 il prodotto gestito di default è diventato un'applicazione condivisa multi-tenant; la proposta da 13 dollari al mese di stack dedicato per il secondo cliente non è stata approvata e non si deve fare provisioning. Fonte: il diario del pilot.

F17. Sempre l'8 settembre: l'app OAuth creata a mano per il pilot resta solo bootstrap dell'operatore e non deve mai diventare un passo di onboarding — il cliente non deve mai maneggiare Client ID o Secret. Finché non esiste un broker di autenticazione gestito, qualsiasi flusso che lo chiede fallisce il gate. Fonte: il diario del pilot.

F18. Fuori dallo scope del pilot, senza promozioni: marketing automation, profondità deal-desk, predizione data-science. Interactions non esiste. Il web CRM ha una baseline deployata ma il giro completo sulla nuova UX non è ancora stato ripercorso dal vivo. Fonte: il diario del pilot.

INTERPRETATION: le mie letture

I1. L'autonomia nel CRM regge solo sotto controllo: agenti che propongono, policy che blocca, persone che decidono. È la tesi del pillar, ed è interpretazione mia — i fatti sopra sono i punti di appoggio, non la dimostrazione.

I2. Il raccolto principale del pilot sono i difetti solo-dal-vivo (F9, F11): ciò che i test locali non potevano vedere per costruzione. Un pilot che non ne trova ha testato poco, non provato molto.

I3. Un rifiuto registrato vale più di un via libera dichiarato (F13): la policy che blocca davvero, con ricevuta, è la prova che il controllo esiste. Il resto è auspicio con un test sopra.

I4. La classificazione onesta batte il semaforo verde (F15): 1 su 23 con le parti mancanti nominate riga per riga dice dove lavorare la prossima settimana. Ventitré spunte ottimistiche non dicono niente.

HYPOTHESIS: da verificare

H1. Il disegno regge in produzione multi-tenant con clienti veri. Cosa la verificherebbe: Zeno, il cliente alla cieca, che completa l'onboarding e opera senza conoscere l'infrastruttura, poi un pilot esterno con la stessa disciplina di evidence.

H2. La policy a soglia scala oltre i rinnovi a pipeline arbitrarie e new business. Cosa la verificherebbe: un caso di new business governato dal vivo, con rifiuto registrato e approvazione nominata. Oggi la policy copre i rinnovi, non pipeline arbitrarie.

H3. Agenti più policy riducono il lavoro umano di riconciliazione rispetto a un CRM tradizionale. Cosa la verificherebbe: una misura prima/dopo su un team reale — tempo per chiudere un rinnovo, errori di instradamento, audit impugnati. Oggi non è misurata.

H4. Il broker di autenticazione gestito sblocca l'onboarding senza OAuth manuale. Cosa la verificherebbe: il gate dedicato superato con un cliente che non maneggia mai credenziali tecniche. Oggi il broker non esiste (F17).

Fatti e limiti, separati

Fatti: F1–F18 qui sopra, ognuno con data e fonte pubblicata. Limiti: i repository sono privati e questo pack cita solo il già pubblicato; la fondazione customer-data ha la PR aperta; il giro UX completo non è stato ripercorso dal vivo; una milestone di runtime non valida 23 casi d'uso né un servizio pubblico; le ipotesi H1–H4 restano ipotesi finché qualcuno non le esegue dal vivo.

Domande frequenti

Perché i repository non sono linkati?

Perché sono privati. Questo pack ricostruisce l'evidence solo da fonti pubblicate: gli articoli del cluster e l'esempio su accordo.dev. Se un giorno il codice si apre, ogni FACT guadagna un link diretto al commit — la classificazione resta, la provenance si allarga.

Cosa manca a questo pack per essere completo?

Tre cose, tutte scritte: la fondazione customer-data con la PR aperta, il giro completo sulla nuova UX del web CRM ripercorso dal vivo, e la produzione multi-tenant con clienti veri. Quando arrivano, diventano FACT con data; intanto restano fuori, nominati.

Quando un'ipotesi diventa un fatto?

Quando viene eseguita dal vivo con evidence datata, dentro confini scritti — la stessa regola della M1 (F7). Non quando viene mergiata, non quando viene annunciata.