Questo documento trasferisce a YELDO tutto ciò che serve per usare, mantenere ed evolvere il sistema di brand in autonomia: dove vive ogni componente, come si aggiorna la conoscenza, come si collauda, che cosa non va toccato. È il complemento operativo dell'Architettura del sistema, che ne descrive la logica.
I documenti live sono il sapere del sistema in forma leggibile. Il software è lo Studio — la web app che genera. Le skill sono gli stessi generatori in forma installabile nei vostri Claude Code. Tutto è già online e funzionante; questo elenco è l'inventario ufficiale della consegna.
Come previsto dal piano di messa a terra, tutto il sistema vive in un solo repo GitHub privato: niente copie sparse, una sola storia versionata. Chi possiede il repo possiede il sistema intero — web app, conoscenza, collaudo, skill e i sorgenti di ogni sito.
Lo Studio (Next.js): interfaccia, i tre generatori, la correzione chirurgica, il Quality Gate, l'estrazione PDF. È ciò che gira su studio.yeldo.com.
12 file di testo + 5 template HTML: tutta la conoscenza del sistema. I generatori non sanno nulla da soli — leggono questi file a ogni generazione. La mappa completa è al capitolo 04.
La suite automatica: 63 controlli end-to-end a costo zero, la batteria di estrazione PDF, il collaudo delle combinazioni reali. Con README dei comandi. Capitolo 05.
I generatori in forma di skill Claude Code installabili (generatore-ui · generatore-deck · generatore-copy), ognuna col suo README. Capitolo 06.
Le 13 cartelle dei siti statici — Brand Book, mockup, deck master, Image Library, documenti, questo stesso handoff. Ogni URL dell'inventario si ricostruisce da qui, con un deploy per cartella.
La guida eseguibile della migrazione: prendere possesso del repo, rimontare Studio e siti sui vostri account, collaudare, chiudere. È il capitolo 03 in forma di comandi.
Il sistema è già impacchettato e pronto: non serve nessuna richiesta, nessun invito, nessun account condiviso. Si scarica, si importa nel vostro GitHub e da quel momento è vostro.
State leggendo la copia del documento pubblicata dal vostro repository: il sistema completo ce l'avete già in mano — web app, conoscenza, collaudo, skill e i sorgenti di tutti i siti, incluso questo. I comandi per la migrazione sono in MIGRAZIONE.md nella radice; le due variabili da impostare sono descritte in .env.local.example.
La consegna è una migrazione completa e self-service: repository, hosting e chiavi passano interamente su account YELDO, e tutto ciò che serve è già in vostro possesso — il pacchetto qui sopra, questa pagina e il file MIGRAZIONE.md nella radice del repo (la stessa guida, comando per comando). Non c'è nulla da richiedere e nessun passaggio da concordare: alla fine nessun componente del sistema dipende più dall'infrastruttura di Dario Albini.
ANTHROPIC_API_KEY (la vostra) e ACCESS_CODE (il codice d'ingresso, lo scegliete voi). Deploy automatico a ogni modifica del repo, da subito.sites/.Stesso repo, Root Directory = sites/<nome>, preset "Other". Cinque minuti l'uno, nessuna variabile.tests/README.md.studio.yeldo.com e i documenti stanno tutti in un solo progetto, sotto docs.studio.yeldo.com/<nome>. I link incrociati puntano lì, quindi la chiusura delle istanze originali non li tocca.Generazioni (ordini di grandezza reali, misurati in produzione): un deck completo ≈ 0,50–1,00 € · una pagina web ≈ 0,30–0,60 € · un copy ≈ pochi centesimi · una correzione chirurgica ≈ 0,10–0,30 € · un Quality Gate ≈ 0,20–0,40 €. Hosting: Vercel Pro ≈ 20 $/utente/mese. Sul cruscotto Anthropic la spesa è visibile in tempo reale, con tetti mensili impostabili.
È il capitolo più importante di questo documento. I generatori non hanno la conoscenza "dentro il codice": la leggono a ogni generazione da file di testo in knowledge/. Aggiornare il sistema significa modificare quei file — un dato di track record che cambia, una nuova immagine ufficiale, una regola di canale che si affina. Nessuna modifica al software.
knowledge/.Esempio: il track record passa da 80 a 95 operazioni → si aggiorna il dato in brand-voice-identity.md. Da quel momento ogni nuovo asset lo userà.skills/ portano una copia degli stessi file: dopo ogni modifica va copiato lo stesso file anche lì (es. cp knowledge/brand-voice-identity.md skills/generatore-*/knowledge/). La regola del sistema è che lo stesso file non esiste mai in due versioni diverse: per verificare, gli hash devono coincidere (md5 -q knowledge/<file> skills/*/knowledge/<file>).tests/, capitolo 05).La suite non costa nulla e conferma che nulla si è rotto.vercel --prod e committa nel repo.La storia git è il registro delle decisioni: un commit chiaro per ogni modifica di knowledge.Il catalogo elenca solo immagini ufficiali e approvate. Una foto nuova entra in image-library.md (con URL, contesti ammessi e trattamento) solo dopo ratifica interna. Per le immagini di deal specifici c'è l'upload diretto nello Studio: incorpora il file nell'asset senza toccare il catalogo.
@media print dei deck master: garantiscono l'export PDF 1:1.Il sistema si fida solo di ciò che è verificato. Nel repo, la cartella tests/ contiene la suite con cui lo Studio è stato certificato — e con cui va ricertificato prima di ogni deploy.
L'intera interfaccia sotto test — versioni, correzioni, allegati, errori di rete, sessioni — con risposte AI simulate: costo zero. Gira in ~2 minuti, anche contro la produzione.
La batteria del PDF (8 casi limite) e una correzione chirurgica con chiamata AI reale, per certificare la catena completa a costo minimo.
26 prompt pronti con l'esito atteso: è il giro che fa una persona del team dopo ogni modifica di knowledge, per giudicare la qualità oltre alla correttezza.
I comandi esatti sono nel README dentro tests/. La regola di casa: build verde ≠ comportamento verde — la suite si lancia sempre, anche per la modifica "piccola".
La web app è la via più semplice; le skill sono la via più potente. Sono gli stessi tre generatori — stessa knowledge, stesse regole, stesso Quality Gate — in forma installabile nei Claude Code del team, per chi lavora da terminale o vuole integrarli nei propri flussi. Sostituiscono le skill auto-sviluppate usate finora: un solo sistema, versionato.
Intake → brief → build → gate. Genera pagine complete nei due temi del design system, dai componenti dei mockup.
La Scheda Deal compone il deck sul master giusto (deal pitch, product, crowd, libero), compliance inclusa, export PDF 1:1.
Testi per sito, LinkedIn e newsletter dai playbook di canale, nella voce YELDO.
Ogni skill ha il suo README di installazione nella propria cartella. Dopo ogni modifica alla knowledge, ricordate il passo 02 del rito: le copie dentro le skill vanno riallineate (0-drift).
Ogni output è una bozza finché una persona non la approva. I dati mancanti restano segnaposto evidenziati — mai inventati — e un asset con segnaposto non è inviabile.
Nuove immagini, nuove CTA, nuove deroghe entrano nel sistema solo con una decisione esplicita, che poi si scrive nei file di knowledge. Il sistema cresce per scelte, non per sedimentazione.
Ogni regola vive in un file solo; le copie si sincronizzano (0-drift). Se due file dicono cose diverse, uno dei due è sbagliato — e il collaudo lo trova.
I file di knowledge contengono la strategia di brand e materiali riservati di YELDO. Restano a uso interno, coperti dagli impegni di riservatezza del contratto (art. 9): repo privato, accessi nominali, nessuna distribuzione dei contenuti fuori dal team.
Con questa consegna il sistema è autonomo. Per le evoluzioni già mappate — nuovi master, nuovi canali, l'archivio condiviso multi-postazione, l'upload diretto in Image Library — e per qualsiasi supporto: Dario Albini · dario@darioalbini.com.