Da design a CRM: dal manifest al modulo funzionante

In breve. In Accordo descrivi un modulo CRM con un manifest dichiarativo — nome, descrizione, campi — e il framework lo valida con errori precisi e ci genera sopra migrazione SQL deterministica, servizio, risorsa REST, metodo SDK e schermate Admin, senza scrivere codice di pagina. La tesi che ne ricavo, ed è interpretazione mia: il design-to-CRM funziona quando il manifest è l'unica fonte di verità, e si rompe appena qualcuno ritocca il generato a mano. Con l'esempio partner e i limiti scritti. Pubblicato il 6 ottobre 2026.

L'esempio: i partner di canale

Il manifest è un piccolo file JSON che descrive un'entità. Quello di esempio nel repository si chiama partner: "Channel partners that resell or refer the product", con tre campi — name obbligatorio, tier tra silver, gold e platinum, territory libero. Nome in minuscolo con trattini, versione del formato 1, unica supportata: un manifest scritto per un formato più nuovo fallisce con errore esplicito invece di essere frainteso.

Da qui parte il flusso: brief, ispezione della composizione, piano verificato, generazione di modulo, servizio, API e Admin, verifica di progetto. Il framework valida il manifest con errori precisi e genera SQL di migrazione deterministico: lo stesso manifest produce sempre output byte-identico. I manifest non eseguono niente e non toccano il database: sono input di comandi CLI espliciti, in dry-run di default.

Cosa esce dal giro

Dall'altra parte escono cinque cose, tutte dal manifest: la migrazione, il servizio con validazione e audit, la risorsa REST, il metodo SDK e le schermate Admin — collezione, dettaglio, form, controlli di azione, tutto derivato dai metadati del modulo. Niente codice di pagina scritto a mano per il CRUD.

L'Admin generato ha una disciplina di rendering stretta: ogni valore è testo, mai HTML; i controlli si disabilitano durante l'invio; i render vecchi vengono scartati; i limiti delle liste sono dichiarati. E c'è già una cucitura di override, usata due volte per viste focalizzate: la board della pipeline e la vista preventivi con firma. Quindi il framework sa già renderizzare una vista custom: semplicemente non ha ancora un modo per sentirsi dire come dovrebbe apparire.

Cosa resta scritto a mano

Il limite principale è dichiarato nella solution: solo CRUD generato. La factory non genera workflow o approvazioni per un oggetto custom — quelli restano scritti a mano. È lo stesso confine che vale ovunque nel cluster: la meccanica si genera, le decisioni si scrivono.

Il secondo limite è la pipeline di design, che esiste solo come disegno: applicare i colori e la tipografia di un brand all'Admin, scegliere moduli e navigazione, controllare ordine dei campi e layout per modulo non sono supportati. Solo la sostituzione di un componente senza forkare è parzialmente supportata, grazie alla cucitura interna già usata due volte — ma senza contratto dichiarato, registro o percorso per plugin. Le fasi future vanno dai token dichiarati all'interpretazione del riferimento grafico, dove l'agente propone e un umano approva prima dell'applicazione: output revisionabile, non CSS generato.

Perché il manifest unico regge

Il punto di principio è quello del cluster sul CRM su misura: personalizzare non significa forkare il motore. Finché il manifest resta l'unica fonte di verità, rigenerare è sicuro: stesso input, stesso output, byte-identico. Appena qualcuno ritocca il generato a mano, la catena si spezza e nessuno sa più cosa produrrebbe una rigenerazione.

È la stessa disciplina che governa i package: il nucleo resta agnostico, il business vive nei moduli generati e nei package. E la tesi completa sull'autonomia che ne deriva è nel pillar sull'autonomia sotto controllo.

Fatti e limiti, separati

Fatti: manifest JSON dichiarativo con validazione ed errori precisi; migrazione SQL deterministica e byte-identica; comandi CLI espliciti in dry-run di default; Admin generato dai metadati con disciplina di rendering; cucitura di override usata per board pipeline e vista preventivi.

Limiti: solo CRUD generato, workflow e approvazioni custom scritti a mano; branding, navigazione e layout dichiarativi non supportati; override senza contratto dichiarato né percorso plugin; pipeline di design solo disegnata. Un manifest e cinque artefatti generati non misurano quanto il disegno regga in produzione: misurano che la catena esiste e gira.

Domande frequenti

Cosa contiene un manifest di modulo?

Nome, descrizione e campi dell'entità, in JSON dichiarativo: per esempio partner con nome obbligatorio, tier tra tre valori e territorio libero. Il framework lo valida e ci genera sopra migrazione, servizio, API e Admin.

Perché lo stesso manifest produce sempre lo stesso output?

Perché la generazione è deterministica: migrazione SQL byte-identica a parità di input. Così rigenerare è sicuro e le differenze tra due versioni si rileggono come differenze tra manifesti, non come sorprese.

Cosa non genera la factory?

Workflow e approvazioni per oggetti custom, che restano scritti a mano. E tutta la parte di design — brand, navigazione, layout — che esiste solo come disegno con fasi future dichiarate.

Posso ritoccare il codice generato?

Puoi, ma rompi la catena: se il manifest non è più l'unica fonte di verità, nessuno sa cosa produrrebbe una rigenerazione. Per le viste custom la strada è la cucitura di override, oggi interna e senza contratto dichiarato.