Calendario: si vedono tutti gli orari validi, e il PDF ne fa una pagina ciascuno

Il popup mostrava solo l'orario del momento: chi guarda ad agosto vuole sapere com'e' settembre per intero, e una griglia sola gli fa credere che valga per sempre. Ora ci sono tutti quelli non ancora scaduti, ognuno con la sua etichetta - In vigore, oppure la data da cui parte - e quelli passati spariscono da soli. Il bottone scarica /calendario/tutti.pdf: un orario per pagina, con le giornate fuori griglia ripetute su ognuna, perche' un foglio stampato da solo deve bastare a se stesso. Gli id singoli restano validi per mandarne uno solo. calendarioDaMostrare (uno) diventa calendariDaMostrare (tutti): una funzione sola, non due che dicono cose simili - e' lo stesso difetto dei due link della pagina servizi, che erano due espressioni per lo stesso indirizzo e sono divergute. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Calendario: il 19 e il 20 settembre non sono un buco, sono un evento e una chiusura
2026-08-17 17:22:22 +02:00 · 2026-08-17 17:07:24 +02:00 · 2026-08-17 16:44:19 +02:00 · 2026-08-17 16:14:02 +02:00 · 2026-08-17 15:58:47 +02:00 · 2026-08-17 15:38:03 +02:00
392 changed files with 47361 additions and 7608 deletions
@@ -1,8 +1,17 @@
-SMTP_HOST=smtp.example.com
-SMTP_PORT=587
-SMTP_USER=user
-SMTP_PASS=pass
+# SMTP Aruba — il dominio insanitylab.it invia la posta via Aruba (SPF: include:aruba.it)
+# Server posta in uscita autenticato: smtps.aruba.it:465 (SSL). Verificato funzionante.
+SMTP_HOST=smtps.aruba.it
+SMTP_PORT=465
+# Casella reale del dominio usata per l'invio autenticato (con la sua password Aruba)
+SMTP_USER=postmaster@insanitylab.it
+SMTP_PASS=la-password-della-casella
+# Aruba impone che il mittente sia la casella autenticata: uguale a SMTP_USER
+CONTACT_FROM=postmaster@insanitylab.it
+# Dove arrivano i messaggi del form
 CONTACT_TO=info@insanitylab.it
-CONTACT_FROM=sito@insanitylab.it
 DB_PATH=data/insanitylab.db
 UPLOADS_DIR=uploads
+
+# Google Tag Manager: ID container preso da tagmanager.google.com (accanto al nome container).
+# Formato GTM-XXXXXXX. Lascia vuoto per non caricare GTM (es. in locale/staging).
+GTM_ID=GTM-XXXXXXX
@@ -2,6 +2,7 @@ node_modules/
 dist/
 .astro/
 .env
+.env.bak*
 data/*.db*
 uploads/*
 !uploads/.gitkeep
@@ -14,6 +14,8 @@ COPY package.json package-lock.json ./
 RUN npm ci --omit=dev && npm cache clean --force
 COPY --from=build /app/dist ./dist
 COPY scripts ./scripts
+# Contenuti della sezione Campus (generati con `npm run sync-campus` e committati)
+COPY campus-content ./campus-content

 ENV HOST=0.0.0.0 \
    PORT=4321 \
@@ -1,145 +1,208 @@
 # InsanityLab Website

-Sito vetrina per InsanityLab con blog integrato e form di contatti.
+Sito ufficiale di InsanityLab: vetrina aziendale, blog integrato, form di contatti, piattaforme riservate ai clienti abilitati e sistema di contenuti modificabili senza toccare il codice. In produzione su **https://insanitylab.it**.

 ## Descrizione

-Il progetto realizza un sito web per InsanityLab, combinando una vetrina aziendale con un sistema di blog gestito tramite SQLite e un form di contatti funzionante. L'architettura è costruita su **Astro 7** con adapter **Node.js** per deployment su server, garantendo performance ottimali e SEO-friendly pages.
+Il sito è costruito su **Astro 7** in modalità server (SSR) con adapter **Node.js standalone**, servito in un container Docker dietro **Traefik** (TLS Let's Encrypt automatico). I contenuti testuali e le immagini della parte vetrina sono "taggati" e salvati su **SQLite**: si modificano da un pannello di amministrazione o direttamente in pagina, senza deploy. Il blog è gestito internamente con editor rich‑text, e il form di contatti invia email tramite SMTP.

-## Stack Tecnologico
+Accanto alla vetrina vivono due sezioni riservate, raccolte sotto `/piattaforme` e visibili solo agli utenti abilitati: il **Biohacking Campus** (guide di studio generate da un progetto esterno) e **Stress Index** (piattaforma di monitoraggio HRV). Quest'ultima è l'unica parte del sito che usa React, sotto forma di isole limitate ai grafici e alle viste interattive.

- **Framework**: Astro 7
- **Runtime**: Node.js (adapter standalone)
- **Database**: SQLite (better-sqlite3)
- **Autenticazione**: bcryptjs
- **Email**: Nodemailer
- **Markup Editor**: TipTap (rich text)
- **Font System**: @fontsource (Montserrat, Open Sans)
- **Sitemap**: endpoint runtime `/sitemap.xml` (route vetrina, programmi e articoli pubblicati)
- **Testing**: Vitest
+## Stack tecnologico
+
+- **Framework**: Astro 7 (output `server`, `prerender = false` sulle pagine dinamiche)
+- **Runtime**: Node.js 22 (adapter `@astrojs/node` standalone)
+- **Database**: SQLite via `better-sqlite3`
+- **Autenticazione**: sessioni con password hashate (`bcryptjs`)
+- **Email**: Nodemailer (SMTP)
+- **Editor articoli**: TipTap (rich text)
+- **Isole interattive**: React 19 via `@astrojs/react`, solo nella piattaforma Stress Index
+- **Grafici**: Recharts (caricati unicamente sulle pagine della piattaforma)
+- **Font**: `@fontsource` (Montserrat, Open Sans) — nessun CDN esterno
+- **Sitemap**: endpoint runtime `/sitemap.xml` (route vetrina + articoli pubblicati)
+- **Test**: Vitest
 - **Linguaggio**: TypeScript
+- **Deploy**: Docker (multi‑stage, `node:22-slim`) + Traefik su VPS

-## Installazione
+## Funzionalità principali
+
+- **Vetrina**: home, chi siamo, training, servizi (con schede di dettaglio), blog, contatti, landing "Promo ed eventi".
+- **Contenuti taggati**: ogni testo/immagine ha un tag (es. `home.hero.title-line-1`) modificabile dal pannello o in pagina.
+- **Modifica inline**: chi ha i permessi può attivare l'overlay dei tag e modificare i contenuti direttamente mentre naviga il sito.
+- **Blog** con editor TipTap, immagini caricate, firma autore, proprietà degli articoli per ruolo, filtro per tematica senza ricaricare la pagina e conteggio degli articoli per categoria.
+- **Cestino degli articoli**: l'eliminazione sposta in `/admin/cestino`, da dove si ripristina o si cancella in via definitiva.
+- **Gestione utenti** con quattro ruoli (`admin`, `superuser`, `user`, `piattaforme`), creazione su pagina dedicata e password impostabile a mano o generata.
+- **Piattaforme riservate** (`/piattaforme`): indice delle sezioni accessibili ai soli utenti abilitati — Biohacking Campus e Stress Index.
+- **Form contatti** con validazione, honeypot anti‑spam, rate‑limit e invio email via SMTP.
+
+## Installazione (sviluppo)

 ### Prerequisiti
-
 - Node.js 18+ e npm

 ### Setup
-
 ```bash
-# Installa dipendenze
 npm install
-
-# Copia il template di configurazione env
-cp .env.example .env
-
-# Crea il primo utente amministratore (dopo aver configurato il DB)
-npm run create-user -- admin tuapassword
+cp .env.example .env          # poi compila i valori reali
+npm run create-user -- admin <password> admin
+npm run dev                   # http://localhost:4321
 ```

-Modifica `.env` con le credenziali SMTP, percorsi database e upload directory secondo il tuo ambiente.
+Il database `data/insanitylab.db` viene creato al primo avvio ed è popolato automaticamente con i contenuti di default (seed) e le migrazioni idempotenti.

-## Comandi Disponibili
+## Comandi

 | Comando | Descrizione |
 |---------|-------------|
-| `npm run dev` | Avvia il server di sviluppo (localhost:4321) |
-| `npm run build` | Compila il progetto per production |
-| `npm run preview` | Visualizza l'anteprima della build (locale) |
-| `npm run start` | Avvia il server production (richiede `npm run build` preliminare) |
-| `npm run test` | Esegui i test con Vitest |
-| `npm run create-user` | Crea un nuovo utente: `-- <nome> <password> [admin\|editor]` |
+| `npm run dev` | Server di sviluppo (localhost:4321) |
+| `npm run build` | Build di produzione |
+| `npm run preview` | Anteprima locale della build |
+| `npm run start` | Server di produzione (`node --env-file=.env`) |
+| `npm run test` | Test con Vitest |
+| `npm run create-user` | Crea/aggiorna utente: `-- <nome> <password> [admin\|superuser\|user\|piattaforme]` |
+| `npm run sync-campus` | Rigenera i contenuti del Campus: `-- <path-progetto-biohacking-campus>` |
+| `npm run seed-blog` | Carica i venti articoli divulgativi tratti dal corso base del Campus (salta quelli già presenti) |

-## Gestione Contenuti
+## Gestione contenuti

-I testi e le immagini del sito vetrina sono contenuti taggati, modificabili senza toccare il codice tramite il pannello `/admin/content`. Ogni blocco di contenuto è identificato da un tag (ad esempio `home.hero.title`) e può essere aggiornato nel valore, negli stili predefiniti (dimensione, peso, colore) e — per le immagini — sostituito con un upload o riportato all'originale.
+I testi e le immagini della vetrina sono **blocchi taggati** salvati nella tabella `content_blocks`. Ogni blocco ha un tag stabile (es. `home.hero.title-line-1`), un valore, eventuali stili predefiniti, un tipo (`text` / `html` / `image`) e un **GUID** univoco.

-Il pannello raggruppa i tag per pagina, offre una ricerca per tag o contenuto e mostra per ogni blocco l'ultima modifica effettuata. Visitando il sito da utente autenticato con il parametro `?annotate=1` (link "Vedi sito con tag" nel pannello), ogni contenuto taggato viene evidenziato con un badge che rimanda direttamente al form di modifica corrispondente.
+- **Pannello** `/admin/content`: i blocchi sono raggruppati per pagina, con ricerca per tag o contenuto, upload delle immagini e ripristino all'originale.
+- **Modifica inline**: attivando "Mostra tag" dal menu utente, ogni blocco mostra un badge (nome tag + matita) che apre una finestra di modifica direttamente in pagina.
+- **Componenti** `<T>` e `<TImg>`: rendono i blocchi con fallback automatico al seed quando un tag non è ancora nel database.

-Sono previsti due ruoli utente: `admin` ha accesso completo (articoli del blog, contenuti, upload), mentre `editor` può operare esclusivamente sul pannello contenuti. Gli utenti si creano con `npm run create-user -- <nome> <password> editor`.
+Il seed dei contenuti è in `src/data/content-seed.ts`; le variazioni sui contenuti già esistenti (rinomine, testi aggiornati) si applicano tramite **migrazioni idempotenti** in `src/lib/db.ts`, così da non sovrascrivere le modifiche fatte dal pannello.

-## Struttura Progetto
+> Nota tecnica: gli elementi resi dai componenti `<T>`/`<TImg>` **non** ereditano il `data-astro-cid` del componente che li usa. Uno stile scoped basato solo sulla classe (es. `.hero__line`) non li raggiunge: va ancorato a un contenitore che ha il cid usando `:global()` (es. `.hero__text :global(.hero__line)`).
+
+## Blog
+
+Gli articoli stanno nella tabella `posts` e si gestiscono da `/admin`. La pagina pubblica `/blog` filtra per tematica e pagina senza ricaricare — si scarica la stessa pagina e si sostituiscono soltanto griglia e filtri — mantenendo indirizzi veri e cronologia del browser: senza JavaScript la navigazione funziona come prima.
+
+L'eliminazione di un articolo non cancella nulla: valorizza `deleted_at` e lo sposta nel **cestino** (`/admin/cestino`), da dove si ripristina o si elimina davvero. Ogni lettura pubblica — elenco, recenti, archivio per mese, pagina del singolo articolo — esclude il cestino, e chi non ha ruolo di gestione vede nel cestino soltanto i propri articoli.
+
+Lo script `npm run seed-blog` carica venti articoli divulgativi ricavati dal corso base del Campus, dieci tecnici e dieci educativi. È versionato apposta: il database di produzione è un volume del VPS e il deploy non lo tocca, quindi articoli creati a mano in locale resterebbero in locale. Lo script salta gli slug già presenti e crea, se mancano, i due utenti che firmano gli articoli — la firma pubblica è lo `username` dell'autore.
+
+## Ruoli e accessi
+
+Quattro ruoli, con autorizzazione a matrice di prefissi in `src/lib/auth.ts`:
+
+| Ruolo | Può fare |
+|-------|----------|
+| `admin` | Tutto: contenuti, blog, upload, **gestione utenti** (`/admin/users`), piattaforme |
+| `superuser` | Pannello contenuti + blog |
+| `user` | Solo i **propri** articoli del blog |
+| `piattaforme` | Solo le sezioni riservate (`/piattaforme`, `/campus`); nessun accesso al pannello |
+
+Login pubblico su `/login` (`?next` sanitizzato contro open redirect). Dopo l'autenticazione ogni ruolo viene indirizzato alla propria pagina iniziale: il pannello per admin e user, i contenuti per superuser, l'indice delle piattaforme per il ruolo `piattaforme`. La gestione utenti (`/admin/users`, solo admin) consente creazione su pagina dedicata (`/admin/users/new`), cambio password — scelta a mano o generata, mostrata una sola volta perché nel database resta il solo hash — cambio ruolo ed eliminazione, con guardie contro l'auto‑eliminazione e la rimozione dell'ultimo admin.
+
+> Il ruolo `campus` è stato rinominato in `piattaforme` quando le sezioni riservate sono diventate due. Una migrazione in `src/lib/db.ts` aggiorna da sé gli utenti esistenti.
+
+## Piattaforme riservate
+
+Le sezioni riservate sono raccolte sotto `/piattaforme`, che è anche la pagina di atterraggio del ruolo omonimo. L'elenco vive in `src/data/piattaforme.ts`: aggiungerne una è una riga, e il menu dell'header la mostra da sé a chi ha i permessi.
+
+### Biohacking Campus (`/campus`)
+
+La sezione `/campus` raccoglie le guide di studio del corso Biohacking Campus. È protetta dal middleware come il pannello: un visitatore anonimo viene mandato al login, un utente con ruolo non abilitato torna alla propria pagina iniziale. Le pagine non montano l'header e il footer del sito — la navigazione avviene attraverso la barra laterale delle aree, con un unico richiamo per tornare all'indice delle piattaforme — ma usano i font, i colori e il CSS globale di InsanityLab.
+
+I contenuti non vengono scritti a mano: lo script `npm run sync-campus` legge le guide sorgente (`*.studio.md`) dal progetto Biohacking Campus, le converte in frammenti HTML e produce la cartella `campus-content/` (indice `nav.json`, pagine e immagini delle slide), che va committata perché il deploy la copia nell'immagine Docker. Lo script è idempotente: rigenerarlo dopo l'aggiunta di nuove lezioni aggiorna indice e pagine e rimuove quelle non più presenti. Le nuove guide vanno prima dichiarate nella struttura dei capitoli in `scripts/campus/structure.mjs`.
+
+Le immagini delle slide sono servite dalla route `/campus/assets/...`, anch'essa protetta: non sono raggiungibili senza una sessione valida.
+
+> Il progetto sorgente sta in `/home/adriano/Wasabi-Adp-Work/AI-OS/projects/personale/biohacking-campus` (percorso predefinito dello script). In sviluppo, dopo un sync, il server va riavviato: `src/lib/campus.ts` tiene l'indice in cache in memoria e le guide nuove darebbero 404.
+
+### Stress Index (`/piattaforme/stress-index`)
+
+Piattaforma di monitoraggio HRV portata dentro il sito da un prototipo Next.js esterno: nove viste — cruscotto giornaliero, elenco clienti, scheda cliente, analytics di studio, modulo sport con sessioni e atleti, team live, impostazioni, organizzazione. Il design system del prototipo (Tailwind, palette teal) è stato sostituito con quello del sito: lo stile sta in `src/styles/stress-index.css`, un foglio globale prefissato `.si` perché le stesse classi servono sia ai componenti Astro sia alle isole React, che lo scope di Astro non raggiungerebbe.
+
+React è limitato a ciò che ha davvero bisogno di stato: la scheda cliente, la vista Analytics, il modulo Sport e i grafici Recharts. Il resto è Astro con qualche riga di JavaScript. I dati sono **dimostrativi** e stanno in `src/lib/stress-index/data.ts`; le aggregazioni con una logica propria (finestre temporali, distribuzioni, riepiloghi atleta) vivono in `analytics.ts` e `sport.ts` accanto, coperte da test.
+
+## Struttura del progetto

 ```
 insanitylab-website/
 ├── src/
-│   ├── pages/               # Pagine Astro (routing automatico)
-│   ├── components/          # Componenti Astro riutilizzabili
-│   ├── layouts/             # Layout master
-│   ├── utils/               # Funzioni di utilità
-│   ├── env.d.ts            # Type definitions globali
-│   └── ...
-├── data/                    # Database SQLite e dati persistenti
-│   └── insanitylab.db      # (generato al primo avvio)
-├── uploads/                 # Directory per upload immagini e file
-├── dist/                    # Output build (server)
-├── tests/                   # Test suite
-├── astro.config.mjs        # Configurazione Astro
-├── tsconfig.json           # Configurazione TypeScript
-├── vitest.config.ts        # Configurazione test framework
-├── .env.example            # Template variabili di ambiente
-├── .env                    # Variabili di ambiente (non versionato)
-├── package.json            # Dipendenze e script npm
-└── README.md               # Questo file
+│   ├── pages/            # Route Astro (vetrina, /admin, /api, /campus, /piattaforme)
+│   ├── components/       # Componenti (home/, content/, stress-index/, Header, Footer, …)
+│   ├── layouts/          # Layout Base, Admin, Campus, StressIndex
+│   ├── data/             # Dati statici + seed contenuti (services, trainings, site, piattaforme, content-seed)
+│   ├── lib/              # db, auth, content, mailer, rate-limit, safe-next, env, stress-index/
+│   ├── assets/img/       # Immagini ottimizzate da Astro
+│   └── styles/           # global.css, stress-index.css
+├── data/                 # SQLite (volume in produzione)
+├── uploads/              # Upload immagini (volume in produzione)
+├── campus-content/       # Contenuti del Campus generati da sync-campus
+├── scripts/              # create-user, sync-campus, seed-blog-biohacking, smoke test
+├── astro.config.mjs      # Config Astro (site, allowedDomains, redirects)
+├── compose.yaml          # Stack Docker + label Traefik
+├── Dockerfile            # Build multi-stage
+├── .env.example          # Template variabili d'ambiente
+└── README.md
 ```

-## Configurazione Ambiente
+## Variabili d'ambiente

-Il file `.env` richiede le seguenti variabili:
+Il file `.env` (non versionato) richiede:

- `SMTP_HOST`: Host SMTP per invio email
- `SMTP_PORT`: Porta SMTP (solitamente 587)
- `SMTP_USER`: Utente SMTP
- `SMTP_PASS`: Password SMTP
- `CONTACT_TO`: Email di destinazione contatti
- `CONTACT_FROM`: Email mittente
- `DB_PATH`: Percorso database SQLite
- `UPLOADS_DIR`: Cartella upload file
+| Variabile | Descrizione |
+|-----------|-------------|
+| `SMTP_HOST` | Host SMTP (produzione: `smtps.aruba.it`) |
+| `SMTP_PORT` | Porta SMTP (`465` con SSL) |
+| `SMTP_USER` | Casella di invio (deve coincidere con `CONTACT_FROM`) |
+| `SMTP_PASS` | Password della casella |
+| `CONTACT_FROM` | Mittente delle email (= `SMTP_USER`) |
+| `CONTACT_TO` | Destinatario dei messaggi del form |
+| `DB_PATH` | Percorso del database SQLite |
+| `UPLOADS_DIR` | Cartella degli upload |
+| `CAMPUS_DIR` | Cartella dei contenuti del Campus (default `./campus-content`) |

-## Development Workflow
+La posta del dominio `@insanitylab.it` è ospitata su **Aruba**; l'invio del form usa l'SMTP autenticato Aruba (`smtps.aruba.it:465`). Aruba impone che il mittente sia la casella autenticata, quindi `CONTACT_FROM` deve essere uguale a `SMTP_USER`.

-1. **Avvia il server locale**: `npm run dev`
-2. **Modifica file** in `src/` (hot reload automatico)
-3. **Test**: `npm run test`
-4. **Build**: `npm run build` (verifica errori di build)
-5. **Commit**: Con prefisso `feat:` (feature) o `chore:` (manutenzione)
+## Deploy in produzione

-## Deployment
+Il sito gira in Docker su un VPS, dietro Traefik. Lo stack è in `/opt/docker/insanitylab/` (repo in `src/`, volumi `data/` e `uploads/`). Aggiornamento:

 ```bash
-# Build per production
-npm run build
-
-# Opzionalmente, preview locale
-npm run preview
-
-# In production, il server parte con:
-npm run start
-
-# Variabili ambiente in production vanno impostate sull'hosting
-# (es. Hostinger VPS, Vercel, etc.)
+cd /opt/docker/insanitylab/src
+sudo git -c safe.directory="$PWD" pull origin main    # il repo è di root: serve sudo, con password
+docker compose up -d --build                          # docker gira senza sudo
 ```

-## Riferimenti Tecnici
+Le migrazioni del database (in `src/lib/db.ts`) sono idempotenti e girano all'avvio del container: aggiornano lo schema e i contenuti senza perdere le modifiche fatte dal pannello. Le migrazioni che cambiano un valore sono sempre guardate dal valore precedente, quindi non sovrascrivono ciò che è stato modificato dal pannello — con la conseguenza, da tenere presente, che un contenuto già ritoccato a mano **non** riceve il nuovo default: va corretto dal pannello.

-Per dettagli su architettura, schema database, componenti e specifiche vedi:
- `/docs/superpowers/specs/2026-07-01-insanitylab-website-design.md`
- `/docs/superpowers/plans/2026-07-01-insanitylab-website.md`
+Prima di ogni deploy conviene fare il backup del database, che è in modalità WAL: un `cp` del solo `.db` perderebbe le modifiche non ancora consolidate.

-## Problemi Comuni
+```bash
+sqlite3 -cmd ".timeout 10000" /opt/docker/insanitylab/data/insanitylab.db ".backup '/dest/insanitylab.db'"
+sqlite3 /dest/insanitylab.db "PRAGMA integrity_check;"    # deve rispondere 'ok'
+```

-### `better-sqlite3` fallisce su npm install
+Gli articoli del blog non viaggiano con il codice: per caricarli in produzione, una volta sola, `docker exec insanitylab node scripts/seed-blog-biohacking.mjs`.

-Se `better-sqlite3` non compila, assicurati di avere build tools installati:
- **Linux**: `sudo apt-get install build-essential python3`
- **macOS**: Xcode Command Line Tools (`xcode-select --install`)
- **Windows**: Visual Studio Build Tools o MinGW
+### Dominio e DNS

-### Database locked
+- Dominio ufficiale: **insanitylab.it** (canonico l'apex; `www` fa redirect 301 all'apex tramite Traefik).
+- I record **A** di `@` e `www` puntano al VPS; la **posta resta su Aruba** (MX, SPF, webmail non vengono toccati).
+- TLS Let's Encrypt automatico via Traefik (certresolver `mytlschallenge`).

-Se il database è locato durante i test, verifica che non ci siano processi in background che accedono a `data/insanitylab.db`.
+> Attenzione dietro Traefik: `allowedDomains` in `astro.config.mjs` deve elencare i domini serviti, altrimenti Astro ignora `X-Forwarded-Proto/Host` e il controllo CSRF respinge i POST con 403.
+
+## Problemi comuni
+
+**`better-sqlite3` non compila su `npm install`** — servono i build tools:
+- Linux: `sudo apt-get install build-essential python3`
+- macOS: `xcode-select --install`
+- Windows: Visual Studio Build Tools
+
+**Modifiche allo `<style>` scoped di `[slug].astro` non compaiono in dev** — l'HMR di Astro 7 non sempre ricompila lo stile scoped delle route dinamiche: riavviare il dev server (`astro dev stop` + `npm run dev`).
+
+**Database "locked" durante i test** — assicurarsi che nessun processo stia accedendo a `data/insanitylab.db`.
+
+**Le guide nuove del Campus danno 404 in sviluppo** — `src/lib/campus.ts` tiene l'indice in cache in memoria: dopo `npm run sync-campus` va riavviato il server.
+
+**Il database di produzione sembra non aggiornato dopo il deploy** — `sqlite3 -readonly` non legge il file `-wal`, dove stanno le modifiche non ancora consolidate, e mostra valori vecchi. Per verificare, interrogare il database in lettura‑scrittura oppure — meglio — guardare direttamente le pagine del sito.

 ## Licenza

-Proprietario InsanityLab.
+Proprietà di InsanityLab.
@@ -1,15 +1,26 @@
 import { defineConfig } from 'astro/config';
 import node from '@astrojs/node';

+import react from '@astrojs/react';
+
 export default defineConfig({
-  site: 'https://insanitylab.tielogic.xyz',
+  site: 'https://insanitylab.it',
  output: 'server',
+
  // Dietro Traefik il TLS termina al proxy: senza allowedDomains Astro ignora
  // X-Forwarded-Proto/Host e il checkOrigin CSRF respinge i POST (403).
+  // Dominio ufficiale insanitylab.it (canonico apex); www e il vecchio
+  // sottodominio tielogic.xyz redirigono all'apex a livello Traefik.
  security: {
-    allowedDomains: [{ hostname: 'insanitylab.tielogic.xyz', protocol: 'https' }],
+    allowedDomains: [
+      { hostname: 'insanitylab.it', protocol: 'https' },
+      { hostname: 'www.insanitylab.it', protocol: 'https' },
+      { hostname: 'insanitylab.tielogic.xyz', protocol: 'https' },
+    ],
  },
+
  adapter: node({ mode: 'standalone' }),
+
  // La sezione "Programmi" è stata rinominata "Servizi": redirect permanenti dai vecchi URL.
  redirects: {
    '/programs': { status: 301, destination: '/services' },
@@ -20,4 +31,6 @@ export default defineConfig({
    // "Personal Training" rinominato "One to One" (nuovo slug); Small Group è una pagina a sé.
    '/services/personal-training': { status: 301, destination: '/services/one-to-one' },
  },
+
+  integrations: [react()],
 });
--- a/Show More
+++ b/Show More