# Hospitality Platform Workspace

Workspace unico della suite hospitality `powerup.cool`.

Il repository non ospita un singolo prodotto, ma una piattaforma composta da:

- un hub UI centrale (`apps/portal`)
- un backend centrale (`apps/backend-hub`)
- un modulo nativo ordini (`apps/ordini`)
- due legacy preservate e integrate (`PRENOTAZIONI_IA` e `MENU2.0`)

## Stato reale del workspace

Moduli attualmente presenti nel catalogo:

- `Prenotazioni` -> legacy integrata da `PRENOTAZIONI_IA`
- `Menu` -> legacy integrata da `MENU2.0`
- `Ordini` -> modulo nativo tenant-aware in `apps/ordini`
- `Libro Homemade` -> placeholder architetturale inattivo

Componenti principali:

- `apps/portal` -> React + Vite, login/registrazione reale, `/home`, `/dashboard`, `/documents`, launcher moduli
- `apps/backend-hub` -> FastAPI, auth, tenancy, sessioni, Home assistant, Google Workspace, configurazioni AI tenant-aware
- `apps/ordini` -> frontend statico + Nginx, backend FastAPI + SQLAlchemy, accesso dal portale con sessione condivisa
- `PRENOTAZIONI_IA` -> legacy prenotazioni preservata, resa tenant-aware tramite sync del contesto portale
- `MENU2.0` -> legacy menu preservata, con configurazione tenant gestita lato backend-hub
- `packages/*` -> layer shared leggero; `config`, `types`, `shared`, `llm` sono usati davvero, gli altri package sono ancora placeholder

## Auth e tenancy oggi

Lo stato reale di auth e tenancy non vive nei package placeholder, ma nel `backend-hub`.

In particolare:

- `POST /auth/register` crea tenant, venue, utente admin, moduli attivi e database dedicato del locale
- il registry centrale e le sessioni sono salvati in SQLite
- path di default del registry: `/data/platform_registry.sqlite3`
- database tenant: `/data/tenants/<tenant-slug>.sqlite3`
- `ordini-backend` condivide il volume `/data` con `backend-hub` e usa lo stesso token del gestionale
- `packages/auth` e `packages/tenancy` non sono ancora la sorgente di verita runtime

## Home operativa e LLM

La schermata `Home` del portale usa il `backend-hub`, non logica mock lato frontend.

Oggi l'assistente operativo:

- legge dati reali di ordini, prodotti, storico acquisti, prenotazioni, note condivise e obiettivi
- puo creare o aggiornare prenotazioni, note, obiettivi e ordini sospesi
- puo creare documenti Google quando l'account Workspace e collegato
- combina regole deterministiche, tool reali e sintesi LLM

Le configurazioni AI tenant-aware vengono salvate dal `backend-hub`. Per il modulo `menu`, il prompt finale viene composto lato server e puo usare i file caricati in `Configura menu`.

## Routing reale

In Docker locale i servizi principali sono:

- Portal: `http://localhost:3000`
- Ordini integrato dal portal: `http://localhost:3000/ordini/`
- Backend Hub: `http://localhost:8101`
- Prenotazioni frontend: `http://localhost:3100`
- Prenotazioni backend: `http://localhost:8100`
- Menu legacy: `http://localhost:3200`
- Ordini frontend diretto: `http://localhost:3300`
- Ordini backend diretto: `http://localhost:8200`

In produzione corrente la topologia documentata in `AGENT.md` e':

- `https://powerup.cool/` -> portal
- `https://powerup.cool/api/` -> backend-hub
- `https://powerup.cool/prenotazioni` -> frontend prenotazioni
- `https://powerup.cool/prenotazioni-api/` -> backend prenotazioni
- `https://powerup.cool/menu/` -> menu legacy
- `https://powerup.cool/ordini/` -> modulo ordini corretto lato prodotto

Nota importante:

- non trattare `powerup.cool:3300` come URL pubblico di prodotto
- in produzione `ordini` passa dal portal Nginx, che proxya `/ordini/` verso `ordini-frontend`

## Avvio rapido con Docker

1. Copia `.env.example` in `.env`
2. Se lavori in locale, sostituisci gli URL pubblici di esempio con URL `localhost`
3. Avvia tutto dalla root:

```bash
docker compose up --build
```

Override minimo consigliato per uso locale:

```env
PORTAL_PUBLIC_URL=http://localhost:3000
BACKEND_HUB_PUBLIC_URL=http://localhost:8101
PRENOTAZIONI_FRONTEND_PUBLIC_URL=http://localhost:3100
PRENOTAZIONI_BACKEND_PUBLIC_URL=http://localhost:8100
MENU_LEGACY_PUBLIC_URL=http://localhost:3200/
ORDINI_FRONTEND_PUBLIC_URL=http://localhost:3300
ORDINI_BACKEND_PUBLIC_URL=http://localhost:8200
```

Script utili:

- `./scripts/dev-all.sh`
- `./scripts/start-portal.sh`
- `./scripts/start-backend-hub.sh`
- `./scripts/start-legacy-prenotazioni.sh`
- `./scripts/start-legacy-menu.sh`
- `./scripts/start-ordini.sh`

## Configurazione LLM

La configurazione LLM remota e' centralizzata in `.env`:

```env
LLM_BASE_URL=http://amicifede.ddns.net:1234/v1
LLM_API_KEY=
ASSISTANT_DISPLAY_NAME=Assistente Locale
ASSISTANT_MODEL=
ASSISTANT_TEMPERATURE=0.2
ASSISTANT_SYSTEM_PROMPT=...
ASSISTANT_OPERATIONAL_CONTEXT=...
```

Il `portal` usa il `backend-hub` per tutte le operazioni di Home assistant. Il prompt operativo e l'eventuale contesto sensibile restano lato server.

## Google Workspace

Il repository include un flusso reale per collegare un account Google del locale, generare anteprime AI di Google Docs o Google Sheets e creare il file nel cloud.

Variabili principali:

```env
GOOGLE_WORKSPACE_CLIENT_ID=
GOOGLE_WORKSPACE_CLIENT_SECRET=
GOOGLE_WORKSPACE_REDIRECT_PATH=/google-workspace/oauth/callback
GOOGLE_WORKSPACE_STATE_FILE=/data/google_workspace_state.json
```

La UI dedicata e' la pagina `Documenti` del portale. In piu, la Home puo creare documenti via tool se l'account e collegato e la richiesta e abbastanza chiara.

## Documentazione

- `AGENT.md`
- `docs/architettura.md`
- `docs/docker.md`
- `docs/deploy-ubuntu.md`
- `docs/google-workspace.md`
- `docs/integrazione-app-esistenti.md`
- `docs/roadmap.md`