Il contratto vive anche nel codice
File leggibili e versionati. Il cuore resta in Zeno.
zeno.json · nel repo del cliente
{
"project": "osteria-del-cilento",
"modules": {
"moduli": "0.1.0",
"prenotazioni": "1.0.0"
},
"blocks": {
"prenotazioni-calendario": "1.0.0",
"prenotazioni-form": "1.0.0"
}
}Letto al build: una versione non attiva o incompatibile produce un errore esplicito. In locale l’SDK punta allo stesso progetto o a un progetto di prova.
zeno.module.json · manifesto
{
"name": "prenotazioni",
"version": "1.0.0",
"requires": {
"modules": [
"moduli"
]
},
"entities": [
"risorsa",
"servizio",
"prenotazione"
],
"permissions": {
"mcp": [
"zeno:prenotazioni:read",
"zeno:prenotazioni:write"
]
},
"blocks": [
"calendario",
"form-prenotazione"
],
"settings": {
"caparra": false
}
}Estratto illustrativo. Entità e permessi generano pannello e contratto API; le migrazioni SQL sono scritte e riviste da Armonia, mai eseguite dal manifesto.
Personalizza ciò che il cliente vede
npx shadcn add @zeno/prenotazioni-calendario
# I file copiati sono tuoi:
src/components/prenotazioni/calendario.tsx
src/components/prenotazioni/form.tsx
// Cambi layout e testi, non il controllo dei posti.
const slots = await zeno.prenotazioni.disponibilita({
giorno: "2026-11-20", persone: 4
});Registry e metodo SDK sono esempi di contratto, non comandi già disponibili. Anche variante HTML, come il template ristorante.
Tre strumenti MCP
Legge gli slot per risorsa e dataread
Prenota passando dal lock centralewrite
Richiede confirm: truewrite
Permessi espliciti per progetto, mai concessi di default. Nomi proposti per il pilota.
Punto previsto: api/zeno/prenotazioni/valida_richiesta.ts. Firma, timeout e fallback dichiarati; prima o dopo l’operazione, mai dentro il lock. Pages Functions da abilitare per sito.