# Architettura

## Panoramica

`PRENOTAZIONI_IA` resta una legacy separata, ma oggi non e piu isolata dal resto della piattaforma.

La sua architettura attuale combina:

- frontend Next.js per il team operativo
- backend FastAPI service-oriented
- PostgreSQL per il dominio prenotazioni
- sync del contesto tenant tramite `backend-hub`

## Componenti principali

### Frontend

Responsabilita:

- dashboard operativa
- lista prenotazioni
- creazione/modifica prenotazione
- gestione tavoli
- floor plan
- configurazione WhatsApp

### Backend

Responsabilita:

- CRUD del dominio prenotazioni
- assegnazione tavoli e combinazioni
- booking settings del venue
- sync col contesto portale
- integrazione WhatsApp Cloud API

## Struttura backend

File e servizi chiave:

- `app/main.py` -> bootstrap FastAPI, CORS, schema runtime, seed iniziale
- `app/api/routes.py` -> endpoint HTTP del modulo
- `app/services/reservation_service.py` -> CRUD prenotazioni
- `app/services/assignment.py` -> algoritmo assegnazione tavoli
- `app/services/floor_plan_service.py` -> payload piantina
- `app/services/booking_settings_service.py` -> configurazioni prenotazioni e WhatsApp per venue
- `app/services/tenant_sync_service.py` -> sync del venue corrente dal token portale
- `app/services/whatsapp_service.py` -> integrazione Meta WhatsApp e prompt booking

## Risoluzione del venue corrente

Questo e il punto piu importante rispetto alla vecchia architettura standalone.

Flusso attuale:

1. il modulo riceve o conserva la sessione del portale
2. `tenant_sync_service` chiama `backend-hub /tenants/context`
3. il backend estrae `tenant_id`, `tenant_slug` e nome venue
4. il venue locale viene trovato o creato tramite `portal_tenant_id`
5. tutte le operazioni sensibili vengono limitate al venue corrente

Fallback:

- se non c'e una sessione del portale valida, il modulo ricade sul venue di default

## Persistenza

Persistenza primaria:

- PostgreSQL

Persistenza applicativa rilevante:

- venue
- rooms
- tables
- reservations
- customer
- booking settings
- log WhatsApp

Il backend applica anche upgrade runtime dello schema per:

- campi `portal_tenant_id` e `portal_tenant_slug`
- configurazioni WhatsApp per venue
- indici e constraint di supporto

## Booking settings e WhatsApp

Le impostazioni del modulo vivono nel dominio prenotazioni e non nel menu.

Per ogni venue si gestiscono:

- durata turno
- prompt WhatsApp dedicato
- Phone Number ID
- access token
- metadati WhatsApp Business

Il prompt effettivo del canale WhatsApp resta confinato al perimetro prenotazioni.

## Algoritmo di assegnazione

L'algoritmo resta volutamente pragmatico:

1. carica tavoli e combinazioni compatibili
2. filtra per capienza
3. scarta le sovrapposizioni temporali
4. preferisce il tavolo singolo prima delle combinazioni
5. minimizza lo spreco posti
6. conserva comunque la prenotazione anche se non trova assegnazione

## Integrazione col workspace

Nel repository principale il modulo e pubblicato tramite i wrapper `apps/prenotazioni-legacy`.

Il backend-hub non sostituisce il dominio prenotazioni, ma fornisce:

- sessione
- contesto tenant
- boundary comune tra moduli