> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kazzle.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Creare e pubblicare

> Creazione di app con l'AI, iterazione su un'anteprima live e distribuzione in produzione.

## Creazione di un'app

Due modi:

* **Chiedi all'AI** - descrivi quello che vuoi in una conversazione e l'AI lo crea
* **Pulsante Nuova app** - fai clic su **+** nella barra laterale Drive e scegli **Nuova app**

L'AI sceglie un template iniziale in base a quello che chiedi:

| Template  | Cosa ottieni  | Usalo quando hai bisogno di              |
| --------- | ------------- | ---------------------------------------- |
| `ui`      | App web React | Un'app web, dashboard, landing page      |
| `process` | Server HTTP   | Un'API, gestore webhook, job programmato |

## Un'app, un ramo

Ogni app è un singolo checkout git su `main`. Non ci sono bozze separate, nessun cambio di ramo, nessun passaggio di merge. Ogni modifica finisce su `main` come commit; la pubblicazione è semplicemente "distribuisci il `main` attuale".

## Il ciclo di build

1. L'AI scrive il codice direttamente su `main`
2. L'AI avvia il dev server. Vedi un'anteprima live.
3. Iteri tramite chat: "sposta il grafico nella barra laterale", "aggiungi un tema scuro"
4. Il dev server ricarica a caldo dopo ogni modifica
5. Quando sei pronto, pubblica

## Pubblicazione

La pubblicazione distribuisce il commit `main` attuale. Non c'è un ramo di produzione separato — il commit pubblicato più di recente su `main` è quello live.

Quando pubblichi nel catalogo affinché altri possano installare, la tua app riceve un token di identità utente al lancio, una chiave di installazione per il suo backend e webhook di installazione/disinstallazione. Vedi [Pubblicazione](/apps/publishing).

## Caching, aggiornamenti e offline

Desktop e mobile aprono l'URL della tua app solo in una normale visualizzazione del browser. **Non** cancellano le cache del browser, non forzano caricamenti solo da rete, né scelgono una politica di cache diversa per app pubbliche rispetto a private.

La tua app web gestisce il caching:

* Header HTTP `Cache-Control` per documenti e asset
* Setup opzionale di service worker / PWA (i template includono `vite-plugin-pwa` con aggiornamento automatico)
* Se una nuova build si attiva immediatamente, ricarica una volta, o aspetta l'apertura successiva
* Fallback offline per l'ultima build attivata

Quando Kazzle vede una nuova versione pubblicata per una scheda app aperta, chiede al service worker registrato di verificare un aggiornamento (`registration.update()`). Le app senza service worker ignorano quel controllo e continuano a usare i loro header di cache HTTP.

Le app pubblicate possono quindi aprirsi istantaneamente dalla cache, raccogliere una nuova build senza un hard refresh, e mantenere l'ultima build disponibile offline.

## Distribuzione

Dopo la pubblicazione, distribuisci per ottenere un URL live:

* **App remote** si distribuiscono nel cloud di Kazzle e ottengono un URL pubblico
* **App locali** si installano sul tuo computer. L'UI si carica direttamente e la parte process esegue un dev server.

## App in tempo reale

Per app che hanno bisogno di letture locali istantanee e supporto offline, l'AI:

1. Crea un database
2. Attiva la sincronizzazione in tempo reale
3. Crea un'app a due parti: UI (React + client di sincronizzazione) e Process (endpoint token + caricamento sincronizzazione)
4. Collega le credenziali attraverso il [vault](/work/vault)

Vedi [Sincronizzazione in tempo reale](/apps/sync) per come funziona.

## Landing page

Le landing page sono app solo UI. Nessun backend, nessun database. Descrivi la pagina e l'AI la crea, la distribuisce e ti dà un URL live. Per usare un dominio personalizzato, punta il tuo dominio o sottodominio all'URL dell'app distribuita.