159 Commits

Author SHA1 Message Date
Adriano 59dff13e22 Consulenza: bottone nel menu in alto su ogni pagina, voce nel menu mobile (#22)
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-30 05:19:40 +00:00
Adriano 5c39b04c31 Consulenza: la nota sta sotto il suo bottone, non sotto Contattaci (#22)
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:39:15 +00:00
Adriano ae98c4b889 Consulenza: nota sotto i bottoni con lo stile giusto (:global sul componente T) (#22)
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:32:54 +00:00
Adriano c65effb0ed Consulenza: sotto il bottone la sede, via Leandro Alberti 76 (#22)
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:32:07 +00:00
Adriano 67dc554810 Reformer Class: bottone consulenza conoscitiva gratuita (#22)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-09-29 20:30:09 +00:00
Adriano 9126af28ce Reformer Class: bottone calendario taupe, meno scuro (#19)
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 19:50:48 +00:00
Adriano 3fff3cd2f8 Il repo resta al sito: app in radice, piattaforme nel loro repo
apps/sito passa in radice, apps/platforms si toglie: vive in
gitea:Adriano/InsanityLab-platforms, con la storia del repo comune. I piani e
le specifiche di Longevity e Campus lasciano docs/ e seguono le piattaforme.
README e compose: deploy da /opt/docker/insanitylab/src; al primo deploy .env
va spostato da apps/sito/.env alla radice.

Refs #20

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 14:25:12 +00:00
Adriano 9efd9a7680 Reformer Class: bottone Contattaci e calendario evidenziato
Refs #19

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 14:06:40 +00:00
Adriano 680224e773 longevity: #15 bersagli touch >=44px per radio, pulsanti e link-pulsante
Tablet del centro: label di radio (lg-field--consenso, alternative del
check-up), button di lg-form__nav e lg-btn a min-height 44px, senza
cambiare l'aspetto desktop.

Refs #15
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-28 08:21:36 +02:00
Adriano 8aeb25f930 longevity: #15 pagine del flusso guidato: consulenza, check-up, scheda cliente
Nuova pagina consulenza.astro (radio per livello e obiettivo, niente
select). checkup.astro mostra "Passo 3 di 4" e porta avanti flusso=nuovo,
con «Salta» verso la scheda. La scheda cliente ([code].astro) mostra la
sezione "Prima consulenza" (letta, Modifica/Compila) e, con
flusso=questionario, il riquadro "Passo 4 di 4" che rimanda a "Crea
accesso" se il cliente non lo ha ancora.

Refs #15
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-28 08:21:33 +02:00
Adriano 575a3988b7 longevity: #15 API della prima consulenza e flusso guidato nel check-up
Nuova API consulenza.ts (POST, autore da locals.user, redirect a
checkup?flusso=nuovo o alla scheda cliente). clienti.ts ora apre il flusso
guidato verso /consulenza?flusso=nuovo invece della scheda. checkup.ts:
un check-up NUOVO con flusso=nuovo prosegue con flusso=questionario; una
correzione lo ignora sempre.

Refs #15
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-28 08:21:28 +02:00
Adriano 498395dddb longevity: #15 libreria e schema della prima consulenza, con test
Tabella consulenza (client_code, UPSERT, nessuno storico) e modulo
lib/longevity/consulenza.ts: consulenzaDi, salvaConsulenza con validazioni
(livello 1-3, obiettivo nell'elenco chiuso, data AAAA-MM-GG, disponibilita
0-7, testo max 5000). 22 test: modulo, schema, API consulenza.ts e
checkup.ts (flusso guidato), redirect di clienti.ts, nessuna pagina cliente
importa consulenza.

Refs #15
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-28 08:21:24 +02:00
Adriano b0f30f9e4c longevity: correzioni passo 3 su #13 unità B — scarto alternative e nota
testIdScartatiDalleAlternative: una sezione senza scelta in `scelte` (radio
assente dal form) non scarta più nulla, invece di ripiegare in silenzio
sulla prima alternativa (perdeva campi come f_plank_sec senza alt_core).

API checkup.ts: la nota operatore si valida (lunghezza max 5000, TESTO_MAX
esportato da giornale.ts) PRIMA di salvare il check-up, non più dopo — una
nota troppo lunga non faceva più fallire aggiungiVoce in silenzio ma
perdeva comunque la nota col check-up già scritto. maxlength sulla
textarea in checkup.astro.

Suite: 314 verdi, 4 rossi di piattaforma (baseline, invariati). tsc e
build puliti.

Refs #13
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 22:59:19 +02:00
Adriano 81021d18f3 longevity: test unità B — struttura modulo, alternative, nota su giornale (#13)
gestionale-modulo-checkup.test.ts: ordine sezioni, pressione/SpO2 esclusi,
dismesso in «Altre misure» su data vecchia, dettagli MUTT, preselezione
alternativa (prima/più recente/ultimo check-up). checkup-alternative-api.test.ts:
API scarta i campi dell'alternativa non scelta (radio inviata o assente),
nota operatore aggiunge voce di giornale (data check-up, autore operatore),
nota vuota o assente (correzione) non aggiunge nulla.

Suite completa: 313 verdi, 4 rossi di piattaforma (baseline, invariati).
tsc --noEmit e npm run build puliti.

Refs #13
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 22:57:02 +02:00
Adriano c8187ce4db longevity: modulo check-up con sezioni e alternative del manuale (#13)
strutturaCheckup in gestionale.ts (ordine Pre-test..Strumenti, sezioni ad
alternative con soglia testuale, «Altre misure» per i test dismessi in
correzione, pressione/SpO2 esclusi); checkup.astro con radio button e
fieldset (niente <select>); API checkup.ts scarta i campi delle
alternative non scelte e aggiunge una voce di giornale dalla nota
operatore sul check-up nuovo.

Refs #13
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 22:54:26 +02:00
Adriano cffb0a624d longevity: correzione etichette sit-to-stand e push-up (unità A)
sit-to-stand era descritto come 30 secondi, il test dura 1 minuto;
push-up non diceva che le donne lo fanno sulle ginocchia.

Refs #13
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 22:49:24 +02:00
Adriano f57a07a964 longevity: test unitari e di sessione per la regola dei gruppi (#13)
motore-fisici-gruppi.test.ts (nuovo): un caso per ogni alternativa che da
punteggio (handgrip/spinta/arti_inferiori/vo2max/hrr/flamingo/back_scratch,
media dx/sx e storico), un lato solo -> nessun punteggio, recenza fra
alternative (pushup/panca in entrambe le direzioni), alternativa piu recente
ma incompleta esclusa (sit-to-stand senza altezza), i test "solo registrati"
non producono chiavi.

motore-fisici-sessione.test.ts: due nuovi casi end-to-end su DB (due sessioni,
due test diversi per la stessa sotto-metrica) che confermano che lo score usa
il test piu recente, in entrambe le direzioni.

Refs #13

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 22:48:07 +02:00
Adriano abd0626ab0 longevity: registro e motore per la nuova batteria test (manuale Nicola 27/09)
Nuovi test_id nel registro (altezza, FC riposo, handgrip/back scratch/flamingo
dx-sx, panca manubri/bilanciere, trazioni, sit-to-stand, plank ginocchia,
6MWT, 2km walk UKK, MILFIT, MUTT FC max/1'/2'/step) con attivo_da, e i quattro
test_id storici sostituiti (handgrip_kg, back_scratch_cm, flamingo_cadute,
hrr_1min_bpm) marcati attivo_a 2026-09-28 senza cancellarli.

motore/index.ts: nuova recenzaValideAlla (posizione di recenza per test_id,
stesso ORDER BY di misureValideAlla, fattorizzata la query condivisa).

motore/fisici.ts: regola dei gruppi in sottoDominiFisici (recenza opzionale) -
per ogni sotto-metrica con piu' test alternativi si sceglie l'alternativa
COMPLETA la cui misura piu' recente vince; senza recenza resta l'ordine di
priorita' di oggi. Handgrip/back_scratch/flamingo ora mediano dx/sx; spinta e
arti_inferiori aggiungono panca bilanciere e sit-to-stand; vo2max aggiunge
MILFIT e 2km walk alla cascata esistente.

Refs #13

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 22:45:26 +02:00
Adriano 2231a476c7 longevity: sezione Giornale di bordo nella scheda cliente
Form (data, nota) ed elenco voci dopo Anagrafica, cancella visibile solo ad
autore o admin, messaggi per ?giornale=aggiunta|cancellata.
Refs #16

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 22:24:22 +02:00
Adriano cef08aaf9f longevity: API giornale di bordo per cliente (aggiungi/cancella)
POST unico con campo azione, autore e ruolo sempre da locals.user, redirect
303 alla scheda cliente #giornale.
Refs #16

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 22:23:03 +02:00
Adriano 37b1a316d8 longevity: test unitari giornale di bordo per cliente
Aggiunta/lettura, rifiuti di aggiungiVoce, cancellaVoce (autore/admin/altro
trainer/id inesistente), schema idempotente, nessuna pagina cliente importa
giornale.ts.
Refs #16

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 22:22:40 +02:00
Adriano 00ecfe86c3 longevity: schema e libreria giornale di bordo per cliente
Tabella giornale in longevity.db (solo client_code) e giornale.ts:
vociDelGiornale, aggiungiVoce (validazioni), cancellaVoce (autore o admin).
Refs #16

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-27 22:22:07 +02:00
Adriano 6bbfcd8f3c longevity: pagina dettaglio sessione e modifica check-up dalla scheda (#12)
Nuova pagina .../sessione/[id].astro: dettaglio misure per asse, con
link "Modifica" per un checkup. checkup.astro diventa correzione con
?sessione=<id> (campi precompilati, attivi alla data della sessione).
La scheda cliente linka ogni sessione e mostra l'esito della correzione.

Refs #12

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TkWhSnSLvAyRCoWBuCpXvp
2026-09-27 22:13:41 +02:00
Adriano 9e566ad7b1 longevity: API checkup accetta sessione_id per correggere (#12)
Un sessione_id nel form fa passare da correggiCheckup invece di
salvaCheckup, stesso endpoint. Il client_code per validazioni e
redirect si legge sempre dalla sessione nel DB, mai dal form.

Refs #12

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TkWhSnSLvAyRCoWBuCpXvp
2026-09-27 22:12:00 +02:00
Adriano 19035e67b0 longevity: correggiCheckup e misureDellaSessione, sovrascrittura misure
Aggiunge la correzione di un check-up gia' salvato: aggiorna sessione e
misure (cambiate/tolte/nuove), azzera la verifica sulle misure cambiate,
ricalcola i punteggi della sessione e delle successive. Estratto
fuoriRangeDi in misure.ts per non duplicare il calcolo min/max.

Refs #12

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TkWhSnSLvAyRCoWBuCpXvp
2026-09-27 22:09:15 +02:00
Adriano 880c928f43 docs: README e spec Longevity al 26/09
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-26 14:02:23 +00:00
Adriano 558def3d52 docs: README piattaforme e spec Longevity aggiornati al gestionale in produzione
README: host piattaforme.tielogic.xyz, conteggio test, sezione Longevity (ruoli,
pagine, regola della misura valida più recente), procedura di aggiornamento con
backup, dati nel volume, apertura pigra del DB, trappole dei test e node_modules.
Spec: §13 con i punti di §11/§12 chiusi da #1 #2 #5 #6 #7 #8 e quelli ancora aperti;
decisioni del 03/09 e 26/09.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-26 14:02:22 +00:00
Adriano 8f95a385d9 Longevity: nessuna pagina senza uscita (#10)
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-26 13:48:42 +00:00
Adriano 22a400b854 longevity: nessuna pagina senza uscita, "Il mio referto" solo a chi ha un fascicolo
Refs #10

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 13:48:03 +00:00
Adriano 12b2e91503 Longevity: gestionale trainer, test fisici, progressione, verifica misure, accesso cliente (#1 #2 #5 #7 #8 #9)
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-26 13:15:29 +00:00
Adriano e74266f9a0 node_modules fuori da git: il symlink tracciato puntava al checkout di produzione
Il pattern 'node_modules/' ignora solo le cartelle, non i symlink: un symlink
apps/platforms/node_modules -> /opt/docker/insanitylab-apps/... era finito in
git (13d8cdd). Nei cloni npm ci passava dal symlink e svuotava la cartella del
checkout di produzione; nel checkout di produzione il symlink punterebbe a se'
stesso. Ora il pattern e' 'node_modules' (cartelle e symlink).

Fixes #9

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-26 13:15:24 +00:00
Adriano 2c9a74f849 longevity: verifica misure fuori range in scheda cliente, link a crea accesso
Scheda cliente ([code].astro): sezione "Misure da verificare" da
misureDaVerificare (id, range) al posto di misureFuoriRange (nessun id,
nessuna azione); ogni riga ha due form verso /api/longevity/gestionale/verifica
(conferma/scarta), messaggio dopo la decisione, e link "Crea accesso al
referto" quando il cliente non ha ancora un accesso.

gestionale.ts: rimossa misureFuoriRange (e il tipo MisuraFuoriRange), sostituita
ovunque da misureDaVerificare (misure.ts), l'unica con id e range utile alle
azioni. accesso.astro: link "Torna alla scheda" in tutti gli stati.

Refs #7
Refs #8

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 13:11:38 +00:00
Adriano 6cbb205064 Merge branch 'lavoro/goldrake-i8' into lavoro/goldrake 2026-09-26 13:06:22 +00:00
Adriano 8579199115 Merge branch 'lavoro/goldrake-i7' into lavoro/goldrake 2026-09-26 13:06:22 +00:00
Adriano d2b508e8ac Merge branch 'lavoro/goldrake-i5' into lavoro/goldrake 2026-09-26 13:06:22 +00:00
Adriano 948068b312 longevity: index.astro smista per ruolo, test del gestionale
pages/longevity/index.astro: trainer e admin → /longevity/gestionale, cliente →
/longevity/io come prima (l'assert esistente sul redirect a /longevity/io resta
valido, il ramo cliente lo chiama ancora testualmente).
tests/longevity/pagine.test.ts: le quattro pagine del gestionale esistono, usano
variante="gestionale", non toccano il DB direttamente e non nominano il database
anagrafico riservato; index.astro smista per ruolo.

Refs #2
2026-09-26 13:05:52 +00:00
Adriano 9375a0380d longevity: pagina del gestionale — modulo di check-up manuale
pages/longevity/gestionale/cliente/[code]/checkup.astro: campi da campiDelCheckup,
raggruppati per asse, etichetta e unità, input inputmode="decimal" tutti facoltativi
(la virgola decimale e i campi vuoti li gestisce l'endpoint). Invio verso
/api/longevity/gestionale/checkup.

Refs #2
2026-09-26 13:05:47 +00:00
Adriano 179aeb442a longevity: pagina del gestionale — scheda cliente (referto, sessioni, fuori range)
pages/longevity/gestionale/cliente/[code].astro: anagrafica, il referto dell'ultima
sessione (stesso Radar/MacroScore di io.astro, qui per il trainer), la tabella delle
sessioni e le misure fuori range (colore --lg-fuori-range). Un codice inesistente è
404. Gli esiti ?salvato/?fuori/?errore dell'API di check-up sono mostrati qui.

Refs #2
2026-09-26 13:05:42 +00:00
Adriano fd56afdf44 longevity: pagine del gestionale — elenco clienti e apertura fascicolo
pages/longevity/gestionale/index.astro: tabella clienti (codice, cognome nome, età,
accesso, data e tipo dell'ultima sessione via sessioniDi per cliente — va bene finché
i fascicoli sono pochi, non pensata per scalare).
pages/longevity/gestionale/nuovo.astro: form verso /api/longevity/gestionale/clienti,
sesso a radio (non <select>: la parola inglese avrebbe fatto scattare il controllo
anti-SQL di referto.test.ts, che cerca \bSELECT\b senza distinguere l'HTML).

Refs #2
2026-09-26 13:05:38 +00:00
Adriano 8ee2c8a2b4 longevity: layout e stile del gestionale — barra laterale, tabelle, bottone d'azione
Variante "gestionale" di Longevity.astro (finora dichiarata e non implementata):
barra laterale sul modello di StressIndex.astro, con le voci Clienti, Nuovo cliente
e un link "Il mio referto". CSS nuovo in longevity.css, solo classi lg-* e solo i
colori già ammessi (nessun colore letterale nuovo: il bianco del testo sul bottone
pieno riusa var(--lg-surface), non un #fff aggiuntivo).

Refs #2
2026-09-26 13:05:32 +00:00
Adriano 5dc6b85d52 longevity: pagina /longevity/progressione, grafico e tabella dell'andamento
Progressione.tsx: una linea per macro-score (connectNulls=false: un dato
mancante è un buco, non una linea inventata), tratteggio e spessore a
distinguere le serie invece di un colore nuovo, riga verticale tratteggiata
sui cambi di versione; sotto, la tabella per asse. Colori identici a
Radar.tsx, nessuno nuovo.

progressione.astro: stesso modello di io.astro (codicePerUtenteLoggato,
nessuna query diretta); sotto i due punti mostra il messaggio che ne serve
almeno uno in più. io.astro linka la pagina nuova.

Refs #5

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 13:02:57 +00:00
Adriano 4cd911098d longevity: progressioneDi, l'andamento nel tempo letto da score, mai un ricalcolo
Una sessione per punto (solo quelle con righe in score), i punteggi congelati
da leggiScore, e cambioVersione quando model_version o quest_version (non
nullo) cambiano rispetto al punto precedente — un check-up in mezzo, con
quest_version NULL, non innesca né nasconde un cambio.

Refs #5

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 13:02:50 +00:00
Adriano 922ab40eb2 longevity: verificaMisura, misureDaVerificare, endpoint di verifica dal gestionale
misure.ts: misureDaVerificare(db, clientCode) legge le misure fuori range mai
verificate; verificaMisura(db, {misuraId, esito, operatore}) conferma o scarta.
La conferma ricalcola e ricongela lo score (salvaScore + calcolaSessione) per
la sessione della misura e ogni sessione successiva dello stesso cliente, che
puo' averla ereditata via misureValideAlla; lo scarto non tocca score. Rifiuta
misura inesistente, gia' nel range, o gia' verificata.

pages/api/longevity/gestionale/verifica.ts: POST da form (misura_id, esito),
operatore dalla sessione (locals.user.username). Il client_code del redirect
si legge dalla misura nel database, mai dal form.

tests/longevity/verifica-misure.test.ts: migrazione (ALTER TABLE su un
longevity.db vecchio, idempotente), conferma che ricalcola la sessione e le
successive con sessioniRicalcolate, scarto che non scrive in score, i rifiuti
(doppia verifica, misura nel range, id inesistente), canAccessPath per
cliente/trainer sulla nuova rotta.

Suite: 219 passed (212 + 7 nuovi). tsc --noEmit: 0 errori.

Refs #7

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 13:02:16 +00:00
Adriano 77829b2d12 longevity: crea l'accesso al sito per un cliente che ha già il fascicolo
accessoDi/collegaAccesso in anagrafica.ts (e le varianti sul singleton
accessoDelCliente/collegaAccessoCliente) leggono e scrivono il legame
clienti.user_id restando l'unico punto che apre identity. accesso.ts
aggiunge creaAccessoCliente: crea l'utente cliente, lo collega, e se il
collegamento fallisce cancella l'utente appena creato (compensazione,
due database, stesso schema di creaCliente). Nuova pagina del
gestionale pages/longevity/gestionale/cliente/[code]/accesso.astro:
genera username e password una volta sola, niente redirect, no-store.

Refs #8
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 13:00:48 +00:00
Adriano f096807ed6 longevity: schema misure con verifica/verificata_da/verificata_at + migrazione
Aggiunge le tre colonne allo schema (db.ts) e una funzione migra() idempotente
che le aggiunge via ALTER TABLE a un longevity.db esistente (PRAGMA table_info
per capire cosa manca): CREATE TABLE IF NOT EXISTS non tocca una tabella gia'
creata, e in produzione un longevity.db esiste dal 03/09/2026.

misureValideAlla (motore/index.ts) lascia entrare anche le misure fuori range
confermate (verifica = 'confermata'), non solo quelle nel range.

Refs #7

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 12:58:25 +00:00
Adriano 95ffa08197 longevity: API del gestionale (clienti, check-up) e test dell'unità 2a
pages/api/longevity/gestionale/clienti.ts: POST del nuovo fascicolo (nome,
cognome, sesso obbligatori; data di nascita/email/telefono facoltativi) →
apriFascicolo → 303 alla scheda cliente, o 303 al modulo con ?errore=.
pages/api/longevity/gestionale/checkup.ts: POST del check-up manuale, con
misureDalForm (funzione pura, esportata e testata) per il parsing del form —
virgola decimale accettata, campo vuoto = non misurato, valore non numerico
ferma tutto, chiavi che non sono campi f_* attivi ignorate. operatore sempre
da locals.user (mai dal corpo, stesso principio del client_code in
questionario.ts); eta da etaDelCliente. Entrambi riservati a admin+trainer da
RULES in auth.ts (già in vigore, verificato dal test su canAccessPath).

tests/longevity/gestionale.test.ts: 17 test — salvaCheckup e il congelamento
dei punteggi, il referto che combina check-up e questionario di sessioni
diverse (#1), i rifiuti prima della scrittura, le misure fuori range, le
versioni parametrizzate dell'anagrafica, apriFascicolo sul singleton (stesso
trucco env-var di questionario-pagina.test.ts), misureDalForm, canAccessPath.

vitest: 229 passed (212 di partenza + 17). tsc --noEmit: 0 errori.

Refs #2
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 12:53:46 +00:00
Adriano 758463bd26 longevity: gestionale.ts — check-up manuale, sessioni e misure fuori range
campiDelCheckup raggruppa i test fisici attivi per asse nell'ordine dei pesi
(letto dal dato, come contenitoriDi in vista.ts). salvaCheckup segue lo stesso
schema di salvaDalForm: valida tutto (misure presenti, solo test f_*, cliente
esistente) prima di aprire qualunque cosa, poi un'unica transazione — apertura
sessione tipo 'checkup', registraMisure fonte 'manuale', calcolaSessione +
salvaScore — perché il congelamento dei punteggi è parte del salvataggio, non
un passo lasciato a chi legge dopo. sessioniDi e misureFuoriRange sono le due
letture per la scheda cliente del gestionale.

Refs #2
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 12:53:35 +00:00
Adriano 8e0b9e4647 longevity: anagrafica del gestionale — elenco, dettaglio, età, apertura fascicolo
elencoClienti/clienteDaCodice/etaDelCliente/apriFascicolo (versione operativa,
sul singleton) affiancate alle rispettive versioni parametrizzate
(elencoClientiParam/clienteDaCodiceParam/etaDelClienteParam), sullo stesso
schema di codicePerUtente/codicePerUtenteLoggato: la parametrizzata resta
testabile su un DB :memory:, l'operativa è quella che pagine ed endpoint del
gestionale importano. apriFascicolo apre sempre senza user_id — l'accesso è #8,
non questa unità — per costruzione del tipo di `dati`, non per convenzione.

Refs #2
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 12:53:27 +00:00
Adriano af8afebba8 longevity: misureValideAlla, spareggio sulla riga e nota sulla conferma dei fuori range
Refs #1
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 12:40:31 +00:00
Adriano 4968b75472 longevity: collega i test fisici a calcolaSessione, misure valide fra sessioni
Un check-up e un questionario sono sessioni separate: prima di questo
commit calcolaSessione leggeva solo le misure della sessione corrente,
quindi l'una non vedeva mai i dati dell'altra. misureValideAlla (nuova,
motore/index.ts) legge invece, per ogni test_id, la misura valida piu'
recente del cliente fra tutte le sue sessioni fino a quella data.
sottoDominiDellaSessione unisce sotto-domini da curva (questionario) e
sotto-domini fisici (sottoDominiFisici) in un'unica mappa, usata sia da
calcolaSessione (livello 1) sia da vista.ts (sottoDominiPresenti, per
"cosa manca" nel referto — non piu' una query separata sulla tabella
misure). Aggiornati i commenti di seed-demo.ts (il registro ora contiene
anche le voci f_*, anche se questa demo non le compila).

Test nuovi in motore-fisici-sessione.test.ts: il caso demo() dell'oracolo
end-to-end, un ingresso mancante o l'eta assente che lascia il
sotto-dominio fuori, la combinazione fra sessioni (check-up dopo il
questionario, sessione precedente che non vede il futuro, misura fuori
range sostituita dalla precedente valida). 202 test esistenti restano
verdi, 9 nuovi: 211 totali. tsc --noEmit: 0 errori (0 anche su 13d8cdd).

Refs #1
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 12:38:34 +00:00
Adriano 48910d84ba longevity: registro dei test fisici e sottoDominiFisici (porting dell'oracolo)
Aggiunge le 24 voci f_* al registro (misure grezze del check-up, senza
curva/sotto_dominio: il calcolo non passa da applicaCurva) e
motore/fisici.ts (sottoDominiFisici), che chiama le funzioni gia'
verificate di test-fisici.ts con eta e sesso per produrre i punteggi di
sotto-dominio. Un ingresso mancante lascia il sotto-dominio assente, mai
un ripiego. Non ancora collegato a calcolaSessione (prossimo commit).

Refs #1
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 12:38:01 +00:00
Adriano Dal Pastro 13d8cdd137 Il sito lascia le piattaforme: separazione fusa in main
Fuso `feat/split-apps` (fermo dal 03/09 e mai portato in main, mentre il container
delle piattaforme girava gia' da li'): il sito e le piattaforme erano online in due
copie, con database diversi e ruoli divergenti — `nicola` era `admin` di la' e
`piattaforme` di qua, e la promozione di ieri valeva solo su una delle due.

Adesso `insanitylab.it/campus`, `/piattaforme` e `/login` fanno 404: le aree
riservate stanno solo su `piattaforme.tielogic.xyz`. Il pannello `/admin` resta.
Nel database del sito restano `admin` ed `editor`; `nicola` e `adriano` sono usciti.

Il lavoro di oggi e' passato intatto: edizione `settembre-2026` coi cinque
pacchetti, i 73 tag, il countdown al 19/09 e la correzione del sabato. Verificato
sull'immagine nuova prima di metterla, chiedendo la pagina a quattro date.

Tre cose che lo split del 03/09 aveva lasciato indietro, trovate eseguendo:

- **`Dockerfile` del sito copiava ancora `campus-content`**, spostato sotto
  `apps/platforms`: il build falliva. Nel sito non c'era piu' un solo riferimento a
  quella cartella - solo la riga del Dockerfile. Rimossa.
- **`migra-utenti.mjs --togli-dal-sito` era un no-op silenzioso**: il `continue`
  sugli utenti gia' presenti a destinazione saltava anche la cancellazione
  dall'origine. Siccome copiare e ripulire sono due passi separati apposta, l'opzione
  non funzionava proprio nel caso per cui esiste. Ora chi e' gia' di la' esce di qua
  lo stesso, e il riepilogo dice quanti ne ha tolti.
- **`.env` non e' in git**, quindi il merge non lo ha spostato sotto `apps/sito/`.
  L'`up` e' fallito dopo che il `down` aveva gia' tolto il container: **9,7 secondi
  di sito giu'**, misurati. La prova con `docker run` non lo aveva visto perche' non
  legge `env_file`. Il rimedio - `docker compose config` prima dello swap - e' scritto
  nel README del sito, che prima non diceva come si fa un deploy.

Sito 149 test verdi, piattaforme 202.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FPKFABRT3y26dFNMquF3CS
2026-09-04 10:18:00 +00:00
Adriano Dal Pastro 33091be802 Merge remote-tracking branch 'origin/feat/split-apps' into merge-split
# Conflicts:
#	apps/sito/compose.yaml
2026-09-04 10:09:29 +00:00
Adriano Dal Pastro faf7647a5f La promo di settembre entra in produzione prima della mezzanotte
Gli Opening Bundles scadono stasera alle 23:59:59 e dopo di loro l'elenco delle
edizioni era vuoto: senza questo merge, dal 5 mattina la pagina avrebbe mostrato
"Nessuna promozione in corso" con le promo del cliente vive.

Merge autorizzato da Adriano il 04/09/2026 dopo aver visto l'anteprima.

Lo scambio a mezzanotte non richiede altri interventi: la pagina legge l'edizione
valida nell'istante della richiesta, e il nuovo container va in produzione adesso
con dentro entrambe le edizioni.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FPKFABRT3y26dFNMquF3CS
2026-09-04 09:35:14 +00:00
Adriano Dal Pastro 2b71cbb49e L'inaugurazione e' di sabato, e la fascia morta fra 700 e 701 px
Due rilievi della revisione, uno dei quali fuori dalla promo.

**`eventi.astro`: "venerdi' 19 settembre 2026"**, ma il 19/09/2026 e' **sabato**
(`calendari.ts:136` lo diceva gia' giusto). E' la meta description della pagina
dell'inaugurazione: e' cio' che si legge nell'anteprima di un link su WhatsApp,
che e' il canale con cui questo cliente parla ai suoi. Una riga, ma pubblica e
falsa.

**`.cards-5` fra 700 e 701 px non era coperta da nessuna regola**: la fascia
intermedia aveva `and (min-width: 701px)`, e a larghezze frazionarie - uno zoom
del browser dà 700,5 px - non valeva ne' quella ne' il blocco <=700, quindi le
cinque card tornavano a sei colonne dentro ~570 px. Tolto il `min-width`: ci
pensa il blocco <=700, che viene dopo e a pari specificita' vince.

Tolta anche la riga ridondante `.cards-5 { 1fr }` nel blocco <=700: `.lp .cards`
copre gia' tutte le griglie a una colonna, ed e' lo stesso meccanismo per cui
`.cards-3` funziona senza una regola sua.

Restano non toccati, perche' verificati corretti: la virgola di "composizione
corporea, e analisi HRV" e' **nella creativa** (a fine riga, nel layout su tre
righe), e le code esplicative delle card 1 e 2 vengono dai testi di agosto
gia' approvati dal cliente, non dalle creative compresse per il formato social.

186 test verdi.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FPKFABRT3y26dFNMquF3CS
2026-09-04 06:53:30 +00:00
Adriano Dal Pastro f914d0699a La promo di settembre subentra ai bundle il 5, cinque pacchetti
Gli Opening Bundles scadono il 04/09 alle 23:59:59 e dopo di loro non c'era
nessuna edizione: dal 5 il sito avrebbe mostrato "Nessuna promozione in corso"
mentre le promo erano vive. Adriano ha consegnato le sei creative il 03/09.

Edizione `settembre-2026` (5 -> 19 settembre, chiude il giorno
dell'inaugurazione): tornano i pacchetti da 5 incontri, con in piu' il
Check-up avanzato, che e' una valutazione singola e per questo dice
"1 valutazione" invece di "5 incontri". Prezzi 250/150/130/80/70.

Due cose che la struttura non prevedeva:

- **Nessun prezzo barrato.** Le creative danno il solo prezzo promo, e i
  listini pieni di agosto (300/220/140/100) sono numeri che nessuno ha
  riconfermato - riportarli accanto ai nuovi sarebbe stato inventarli.
  `price-old` diventa opzionale nella CardSpec (`priceOld`) invece di essere
  un tag vuoto: cosi' la spec dichiara che quella card non ne ha, e il test
  lo pretende solo dove c'e'. Agosto e i bundle sono marcati `priceOld: true`,
  quindi restano sotto controllo come prima.

- **Cinque card non stanno in una griglia da due o da tre** senza lasciare un
  buco in fondo. `.cards-5` va a sei colonne con span due, cosi' le ultime due
  si spostano al centro; a due card per riga sotto i 1000px, a una sotto i 700.

Testi ripresi dall'edizione di agosto, gia' approvata dal cliente, cambiando
solo cio' che le date rendevano falso: la FAQ delle class diceva "gli orari
saranno pubblicati entro Settembre" e adesso e' settembre, quindi rimanda al
calendario che esiste. La FAQ 7 sul Check-up e' nuova e va fatta leggere a
Nicola prima della pubblicazione.

186 test verdi, `astro check` invariato (i 3 errori della pagina promo sono
preesistenti e non toccati).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FPKFABRT3y26dFNMquF3CS
2026-09-04 06:43:50 +00:00
AdrianoDev a59b4e0c0e crea-fascicolo: aprire il fascicolo di chi ha gia' un account
"Anche un admin deve avere il suo referto" (Adriano). Il codice lo permetteva
gia': il referto si aggancia all'utente, non al ruolo. Mancava il modo di
creare la riga che lega utente e fascicolo senza passare da seed-demo, che
inventa anche la persona e le risposte.

Non indovina niente: --sesso e' obbligatorio perche' entra nelle curve dei
punteggi, la data di nascita si puo' omettere e allora l'eta' resta vuota -
meglio un campo vuoto di una data plausibile e falsa. Si ferma se quell'utente
ha gia' un fascicolo: due fascicoli per la stessa persona sono due storie
parallele, e nessuna e' quella giusta.

Il fascicolo nasce vuoto: il referto dice "non hai ancora compilato il
questionario" finche' la persona non lo compila, che e' il percorso vero.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EndnceRA5WnA6rvA5iV9WL
2026-09-03 13:02:54 +00:00
AdrianoDev c8a6b318cb Dopo il login si atterra sulla scelta della piattaforma
Chiesto da Adriano: si entra e si sceglie dove andare, anche quando la scelta
e' una sola. Prima ogni ruolo saltava dritto nella sua sezione.

Non basta cambiare landingFor: /piattaforme era riservato ai ruoli admin e
piattaforme, quindi mandarci un cliente avrebbe prodotto un CICLO di redirect
- il middleware nega la pagina, rimanda a landingFor, landingFor rimanda dove
il middleware nega. L'indice diventa la casa comune (aperto a ogni ruolo),
mentre Stress Index, che sta sotto lo stesso percorso, resta riservato: la sua
regola viene prima, perche' vince la prima che combacia.

L'indice mostra a ognuno solo le sezioni che puo' aprire, quindi la scelta non
espone mai una porta chiusa.

Un test nuovo presidia l'invariante che rende impossibile il ciclo: la
destinazione di landingFor deve essere accessibile a TUTTI i ruoli.

Verificato in produzione: il cliente demo atterra sulla scelta e vede la sola
card Longevity, adriano vede Campus e Stress Index, e da li' il percorso
prosegue fino al referto.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EndnceRA5WnA6rvA5iV9WL
2026-09-03 12:53:32 +00:00
AdrianoDev 62b19b21d9 Il link del sito all'area riservata punta all'host che esiste
Era rimasto apps.insanitylab.it, che e' l'indirizzo definitivo ma non ha
ancora un record su Aruba: alla fusione il menu del sito avrebbe portato a un
errore di DNS, e nessun test se ne sarebbe accorto perche' il link esce dal
dominio e non lo serve nessuna rotta interna.

Ora punta a piattaforme.tielogic.xyz, con un test che lo presidia.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EndnceRA5WnA6rvA5iV9WL
2026-09-03 12:45:17 +00:00
AdrianoDev 89d2186e69 Il vecchio sottodominio esce anche dal compose del ramo
insanitylab.tielogic.xyz e' stato tolto dal DNS: una regola Traefik che lo
nomina fa fallire una sfida ACME a ogni tentativo, ed e' cio' che Let's
Encrypt limita. Resta il redirect di www.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EndnceRA5WnA6rvA5iV9WL
2026-09-03 12:41:53 +00:00
AdrianoDev f5fac89c1b Via dal router il vecchio sottodominio, tolto dal DNS
Adriano ha rimosso il record insanitylab.tielogic.xyz il 03/09/2026. Una
regola Traefik che nomina un host inesistente non e' inerte: il router chiede
un certificato per i nomi della sua regola, e la sfida ACME su un nome che
non risolve fallisce a ogni tentativo - proprio cio' che Let's Encrypt limita.

Resta il redirect di www verso l'apex, che e' l'unico ancora vero.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EndnceRA5WnA6rvA5iV9WL
2026-09-03 12:41:52 +00:00
AdrianoDev 15dbe6a397 Le aree riservate hanno il loro host: piattaforme.tielogic.xyz
Creato da Adriano sulla zona tielogic.xyz (Hostinger). Sostituisce il prestito
di insanitylab.tielogic.xyz, durato un'ora: quell'host e' tornato al suo 308
verso l'apex e il sito e' di nuovo esattamente com'era.

allowedDomains, router del container e router di redirect del sito cambiano
insieme: e' la terna che decide di chi e' un host, e sfasarla lascia un
indirizzo senza padrone o un login che risponde 403.

Verificato in HTTPS: certificato emesso per il nome nuovo, login e referto
funzionanti, insanitylab.it 200 e i due redirect al loro posto.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EndnceRA5WnA6rvA5iV9WL
2026-09-03 12:39:29 +00:00
AdrianoDev 665c598462 Il vecchio sottodominio torna al suo redirect
Adriano ha creato piattaforme.tielogic.xyz, che e' il nome giusto per le aree
riservate: il prestito di insanitylab.tielogic.xyz e' durato un'ora e finisce
qui. Il sito torna esattamente come stamattina - apex, www e vecchio
sottodominio - e le piattaforme stanno su un host loro.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EndnceRA5WnA6rvA5iV9WL
2026-09-03 12:39:29 +00:00
AdrianoDev a7b81e2ff4 Le aree riservate partono da insanitylab.tielogic.xyz
Deciso da Adriano il 03/09/2026: il dominio del cliente resta su Aruba e non
si tocca, le piattaforme partono da un sottodominio nostro. Scelto l'host che
risolveva gia' e aveva gia' il certificato - fino a oggi faceva 308 verso
l'apex del sito - invece di aspettare un record DNS nuovo.

Tre modifiche coordinate, che vanno insieme o l'host resta senza padrone:
- allowedDomains dell'app: aggiunto l'host temporaneo accanto a quello
  definitivo. Senza, dietro Traefik il CSRF di Astro respinge ogni POST con
  403 e il login sembra rifiutare le credenziali.
- router del container: Host(insanitylab.tielogic.xyz)
- compose del sito: quell'host esce dal router di redirect (www continua)

Quando il record A "apps" esistera' su Aruba si tengono doppi per un po',
invece di spostare di netto un indirizzo che qualcuno ha gia' salvato.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EndnceRA5WnA6rvA5iV9WL
2026-09-03 12:36:33 +00:00
AdrianoDev 4103376eb1 Il vecchio sottodominio esce dal redirect: serve alle aree riservate
insanitylab.tielogic.xyz faceva 308 verso l'apex dal 12/07. Dal 03/09/2026
ospita le aree riservate (Campus, Stress Index, Longevity) mentre si aspetta
il record A di apps.insanitylab.it su Aruba: il dominio del cliente resta
dov'e', le piattaforme partono da un sottodominio nostro.

www.insanitylab.it continua a reindirizzare come prima.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EndnceRA5WnA6rvA5iV9WL
2026-09-03 12:34:59 +00:00
AdrianoDev 18b0877026 Longevity: il registro si semina da solo, e un cliente demo con un referto vero
seedRegistro/seedPesi esistevano dal 22/08 ed erano chiamati SOLO dai test: su
un database nuovo il registro restava vuoto, campiDelQuestionario non trovava
niente e la pagina del questionario si apriva SENZA DOMANDE. Non era un problema
della demo, era il primo avvio in produzione - lo stesso difetto gia' visto in
questo ramo (una funzione corretta che nessuno chiama), con la stessa
correzione: agganciarla dove non si puo' dimenticare, cioe' alla creazione del
database. Entrambe le semine sono INSERT OR REPLACE, quindi rilanciarle e' a
vuoto, e i punteggi gia' emessi non cambiano (sono congelati nella tabella
"score", che e' quello che il referto legge). Quattro test lo presidiano.

scripts/seed-demo.ts crea l'utente con ruolo "cliente", il fascicolo (passando
da creaCliente, l'unico varco fra identity e longevity) e compila il
questionario attraverso salvaDalForm - lo stesso percorso della pagina vera,
consenso compreso - cosi' i punteggi vengono calcolati e congelati come in
produzione. Si ferma se l'utente esiste gia': rifare la demo su dati esistenti
vuol dire duplicare o cancellare un fascicolo, e non e' una decisione da script.

Verificato girando l'app: Energy 74,5/100 con copertura 50%, Performance e
Recovery dichiarati insufficienti (5% e 35%) con l'elenco di cosa manca, Fitness
Age assente. E' la regola di Nicola all'opera - annullare invece di stimare - ed
e' lo stato vero del prodotto: nel registro ci sono solo le 20 domande del
questionario, i test fisici arrivano col gestionale trainer.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EndnceRA5WnA6rvA5iV9WL
2026-09-03 12:27:48 +00:00
AdrianoDev 6301f521fd Separazione: le aree riservate diventano un'app propria (apps/platforms)
Campus, Stress Index e Longevity escono dal sito e diventano
apps.insanitylab.it, con utenti, sessioni, login e database propri.
Deciso da Adriano il 03/09/2026: una repo sola, due applicazioni
autosufficienti, cosi' che ognuna resti estraibile.

Misura che ha guidato il taglio: le tre aree condividevano col sito
SOLO l'identita' - ~170 righe fra auth.ts, middleware.ts e safe-next.ts.
Layout, librerie e dati erano gia' disgiunti.

Lato piattaforme:
- ruoli piattaforme/cliente/trainer/admin, senza quelli redazionali
- canAccessPath con default CHIUSO (nel sito era aperto: li' le rotte non
  elencate erano di chiunque fosse loggato, qui ogni sezione e' di qualcuno)
- tutta l'app protetta, si elencano le eccezioni invece dei prefissi protetti
- /api risponde 401/403, non un redirect verso una pagina di login
- tre database distinti: utenti, dati clinici senza nomi, mappatura coi nomi

Lato sito:
- ROLES tornano i tre redazionali; via le regole e il login pubblico
- il login del pannello RESPINGE un account emigrato invece di aprirgli una
  sessione: senza, landingFor lo mandava su /admin, il middleware glielo
  negava, e si formava un ciclo di redirect che sembra un guasto del sito
- l'header non mostra piu' un menu delle piattaforme: un link che esce

Verificato: sito 20 file / 146 test, piattaforme 26 file / 197 test, entrambi
i build passano, e l'app girata davvero in locale - il ruolo piattaforme entra
in Campus e viene rimbalzato da Longevity, il cliente il contrario.

Non ancora in produzione: manca il record DNS di apps.insanitylab.it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EndnceRA5WnA6rvA5iV9WL
2026-09-03 11:21:12 +00:00
AdrianoDev 510d7ca4ec Struttura: il sito esistente si sposta sotto apps/sito
Primo passo della separazione sito / piattaforme decisa da Adriano il 03/09:
due applicazioni autosufficienti, senza workspace di root, cosi' che ognuna
resti un progetto Astro completo ed estraibile.

Qui non cambia niente del codice: solo la radice. I pattern del .gitignore
che avevano una barra erano ancorati alla radice e dopo lo spostamento non
avrebbero piu' coperto niente (data/*.db*, uploads/*): resi validi a
qualunque profondita'.

Suite: 45 file, 347 test verdi prima e dopo lo spostamento.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EndnceRA5WnA6rvA5iV9WL
2026-09-03 11:05:54 +00:00
AdrianoDev c03edccd8e Merge remote-tracking branch 'origin/main' into feat/split-apps
# Conflicts:
#	.gitignore
2026-09-03 11:03:09 +00:00
Adriano Dal Pastro b75e12de86 Calendario: alzato il min-width a 780px, che il layout fisso rende necessario
Coda della modifica precedente, e senza questa quella era una regressione sul
telefono. A colonne uguali la piu' stretta deve contenere la parola piu'
lunga; in layout automatico il browser allargava da solo le colonne piene e
stringeva quelle vuote, quindi il problema non si vedeva.

Il conto, misurato sul Montserrat 400 che il sito serve davvero (non
stimato): REFORMER a .7rem con letter-spacing .1em e' 75,4 px, mentre la
colonna a 720px ne offriva 72,7 di spazio utile — 2,7 in meno. La parola
sarebbe uscita dalla cella proprio dove il minimo si vede, cioe' sul
telefono, che quella tabella la fa scorrere in orizzontale apposta.

A 780px la colonna da' 81,3 px, ~6 di margine. In stampa il conto era gia'
buono (corpo .62rem e padding ridotto: 66,8 px in 77,9).

Il conto e' scritto nel CSS accanto alla regola: chi tocca padding, corpo o
spaziatura deve rifarlo.

185 test verdi.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-01 08:57:41 +00:00
Adriano Dal Pastro 718ca499c4 Calendario: le sette colonne dei giorni tutte della stessa larghezza
Chiesto da Adriano. La tabella era in layout automatico, quindi il browser
dimensionava ogni colonna sul contenuto: il sabato, che porta la nota «solo
il 12 settembre», veniva largo quasi il doppio, e i giorni senza class si
stringevano. Una griglia oraria con le colonne di misure diverse si legge
male proprio dove serve — nell'incrocio fra un giorno e un'ora.

`table-layout: fixed` piu' una larghezza sulla sola colonna delle ore
(64px): tutto il resto viene diviso in parti uguali fra le sette dei giorni.

E' lo stesso criterio che il PDF applica da sempre — la' le colonne sono
`(larghezzaUtile - larghezzaOra) / GIORNI.length` — quindi adesso le due
versioni dello stesso foglio si somigliano invece di divergere.

La colonna delle ore resta piu' stretta dei giorni, come nel PDF: ci sta
dentro «12.15» e nient'altro.

185 test verdi.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-01 08:55:14 +00:00
Adriano Dal Pastro 4f031cf571 Calendario: niente class il venerdi' dall'1 al 18 settembre
Chiesto da Adriano l'01/09. Tolte le tre celle del venerdi' dal calendario
'settembre-1-18': MOBILITY alle 8.30, REFORMER alle 9.15 e alle 10.00.

Erano tutte di mattina, quindi in quel periodo il venerdi' resta una colonna
completamente vuota. Resta VUOTA e non barrata: togliere le class non vuol
dire che la sala sia chiusa, e nessuno l'ha detto — il dato distingue le due
cose apposta (`chiusi`), e sceglierne una che non ci e' stata comunicata
sarebbe inventare un'informazione.

⚠️ L'edit e' confinato al primo calendario. Le tre righe del venerdi' sono
IDENTICHE, carattere per carattere, in 'settembre-21-in-poi' — dove il
venerdi' deve restare — quindi una sostituzione sul file intero ne avrebbe
prese sei invece di tre. Verificato dopo: dal 21 settembre il venerdi' ha
ancora PILATES 7.45, MOBILITY 8.30, REFORMER 9.15 e 10.00.

Aggiunto un commento nel dato, perche' confrontando le due griglie il buco
sembra una trascrizione monca e il prossimo che passa lo "corregge".

185 test verdi.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-01 08:51:13 +00:00
Adriano 6ba8794770 Fuori dal versionamento la cache di Python
Nel repo ora c'e' anche Python — lo script che rigenera la locandina, e i
riferimenti dei test longevity — e ogni esecuzione lascia dietro __pycache__.
Comparivano come file non tracciati a ogni git status, senza essere codice.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-28 13:16:29 +02:00
Adriano Dal Pastro 0ea1cb5e77 Eventi: la citazione di chiusura fra virgolette e piu' grande
Caporali «» attorno alla frase — sono le virgolette italiane, e su un corsivo
di quel corpo reggono meglio delle doppie curve.

Corpo da clamp(1.05rem, 2.4vw, 1.3rem) a clamp(1.35rem, 3.4vw, 1.9rem): ~+45%
sia sul minimo che sul massimo, quindi cresce anche su mobile. Interlinea da
1.8 a 1.5, altrimenti a quel corpo le due righe galleggiavano.

Il <br /> che spezza la frase in due versi resta dov'era.
2026-08-28 11:12:33 +00:00
Adriano 7f96b95e04 Eventi: via il piano dai blocchi, la locandina scende in fondo
Tre ritocchi chiesti dal cliente: il "Primo piano" sotto "Prova i nostri
servizi" spariva il messaggio piu' che aiutare, il download della locandina
sta meglio a fine lettura che nell'apertura, e il titolo del programma va
a capo dopo "Come si svolge".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-28 11:55:14 +02:00
Adriano 13d73f90a8 Eventi: i test seguono la data separata e l'URL stampato nel QR
Il test dell'inaugurazione cercava la data dentro il titolo, ma i due sono
stati separati in tag distinti il 19 agosto: era rosso da allora, anche in
produzione.

Il nuovo test tiene insieme le tre cose che devono restare d'accordo, perche'
il QR delle locandine affisse non si corregge piu': la rotta servita dal sito,
l'URL cucito nel codice e il PDF che la pagina offre in download.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-28 11:43:13 +02:00
Adriano 7fd3961469 Eventi: la landing dell'In-Sanity Hour, con la locandina da scaricare
La pagina dell'inaugurazione del 19 settembre: il programma completo della
giornata, gli slot di prova del mattino e del pomeriggio, la festa serale.

Il blocco del titolo è il ritaglio della locandina vera, non una sua
riproduzione: i caratteri originali non li abbiamo, e ricostruirli a occhio
è già stato provato senza riuscirci. Il resto della pagina usa la tipografia
del sito e i colori campionati dalla locandina, così volantino e schermo si
riconoscono come la stessa cosa.

La locandina scaricabile è ricalcata in vettoriale dallo stesso JPEG — tre
colori piatti, quindi ogni forma diventa un tracciato — e monta il QR code
definitivo verso questa pagina, un filo più piccolo dell'originale per
lasciargli attorno il margine muto che lo standard richiede.

I testi non passano più dal pannello contenuti: la pagina è in codice.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-28 11:41:47 +02:00
Adriano 1d6bdd0b3d longevity: revisione finale — il motore ora si calcola, il consenso è atomico, il codice cliente è tipato fuori dal corpo
Sei correzioni dalla revisione finale del 22/08, ognuna con test scritto prima:

1. salvaDalForm calcolava mai i punteggi (calcolaSessione/salvaScore) dopo il
   salvataggio: un cliente compilava venti domande e vedeva un referto vuoto.
   Ora avviene nella stessa transazione del salvataggio.
2. Il corpo della richiesta dell'endpoint questionario è tipato
   (CorpoQuestionario): client_code non esiste in quel tipo, non è più
   prendibile per errore. Il vecchio test a lista di nomi vietati era vacuo
   (cercava body./corpo., il file usa data.) — sostituito con un test
   comportamentale end-to-end sull'endpoint vero.
3. Il consenso: aggiunto il test sul ramo affermativo (non coperto, vacuo
   quanto il punto 2); la nota di consenso ora è nella stessa transazione dei
   dati sanitari; ha una versione propria (CONSENT_VERSION) invece di quella
   del questionario.
4. La prima apertura del referto ora spiega invece di sembrare rotta: Fitness
   Age con nota quando manca, spiegazione del radar prima del grafico,
   copertura sempre visibile, invito a fare i test in sala col trainer,
   numeri formattati all'italiana.
5. Aggiunto il link per ricompilare il questionario nella pagina del referto
   (prima spariva appena esisteva una compilazione).
6. Il test anti-query ora scandisce tutte le pagine sotto src/pages/longevity/,
   non due nomi a mano. Il test anti-giunzione identity/longevity resta con lo
   stesso limite di sempre (createIdentityDb è esportata per creaCliente) —
   corretto solo il commento perché lo dichiari onestamente.

Report con comandi e output letterali:
.superpowers/sdd/2026-08-22-longevity-interfaccia/review-finale-report.md
2026-08-22 15:17:47 +02:00
Adriano a56398ea02 longevity: il controllo sui colori guarda tutto il foglio, non solo lg-score
Filtrava le regole sul selettore ("solo quelle con lg-score nel nome"): un elenco
di quali regole guardare invecchia appena nasce una classe nuova, ed e' successo
subito con .lg-radar__voce-nome, .lg-radar__intro, .lg-macro__nota (Task 3), mai
controllate perche' non contengono quella stringa. Tolto il filtro sul selettore:
ora si scandisce ogni regola del foglio (che e' interamente prefissato lg- per
costruzione), con un elenco di eccezioni dichiarate (selettore + valore + motivo)
per gli usi legittimi di un colore fuori lista (il #fff del testo sul bottone
pieno d'accento). Verificato rosso con un colore-giudizio iniettato sia su una
classe del radar sia su una del macro-score, verde ripristinato in entrambi i casi.
2026-08-22 14:43:57 +02:00
Adriano 6630be7a02 longevity: la prova sul congelamento ora discrimina davvero il ricalcolo
Il peso mutato prima era l'unico sotto-dominio del suo asse (questionario_lifestyle,
1.00 in Stile di Vita & Sonno): in una media pesata a un solo elemento disponibile
il peso si semplifica sia al numeratore sia al denominatore, quindi il test restava
verde anche se refertoDi avesse ricalcolato invece di leggere gli score congelati.
Sostituita con il peso di un sotto-dominio ASSENTE in un asse a piu' elementi con
copertura parziale non nulla (hrv in Recupero & Sistema Nervoso): li' un ricalcolo
sposta davvero la copertura oltre soglia. Verificato rosso col ricalcolo forzato,
verde ripristinato.
2026-08-22 14:32:43 +02:00
Adriano 7f01ee0b45 longevity: il referto del cliente, e il radar che dice cosa non sa 2026-08-22 14:28:29 +02:00
Adriano 8c980750c0 longevity: la connessione a identity non e' piu' raggiungibile fuori da anagrafica.ts
Il revisore ha dimostrato che il test anti-giunzione si aggira senza malizia:
tre file (uno riesporta la connessione a identity, uno quella a longevity, un
terzo le importa da entrambi e le usa insieme) e nessuno dei tre contiene
singolarmente le due parole cercate. Un controllo testuale file-per-file non
puo' vedere una giunzione che attraversa piu' file - quindi la risposta non
e' un test piu' furbo, e' rendere la cosa impossibile invece di sorvegliarla.

- db.ts: rimossa l'esportazione di getIdentityDb. Resta solo getLongevityDb
  (il database senza nomi, puo' usarlo chiunque) e createIdentityDb (serve ai
  test per aprire database in memoria - li' la giunzione e' voluta ed
  evidente, il problema era il singleton condiviso, non la fabbrica).
- anagrafica.ts: getIdentityDb torna dentro, privata (non esportata) e usata
  solo da codicePerUtenteLoggato. Verificato che il bypass a tre file del
  revisore ora fallisce gia' a tsc --noEmit ('has no exported member named
  getIdentityDb'), non solo a un test che lo sorveglia.
- tests/longevity/anagrafica.test.ts: il test anti-giunzione resta come rete
  secondaria, con un commento che dichiara onestamente cosa non vede (una
  giunzione via re-export su piu' file) invece di promettere una garanzia che
  non mantiene.

Due correzioni minori dalla stessa revisione:
- api/longevity/questionario.ts: salvaDalForm (via salvaCompilazione) lancia
  se una risposta porta un test_id sconosciuto al registro; ora e' avvolta in
  try/catch e risponde 400 pulito invece di un 500 generico, come gia' fa
  src/pages/api/contact.ts per l'invio email.
- components/longevity/Questionario.tsx: un campo con tipo_valore='txt' nel
  registro ora rende un input testuale (non piu' sempre "number"), e in
  invio i campi testuali non vengono convertiti in NaN e scartati in
  silenzio - restano fuori esplicitamente, con un commento che dice perche'.
2026-08-22 14:12:43 +02:00
Adriano f0629db3c4 longevity: l'endpoint del questionario apre solo longevity, e il test anti-giunzione diventa strutturale
L'endpoint /api/longevity/questionario apriva anche identity (getIdentityDb)
per risolvere il client_code, violando la garanzia della spec (§4): un solo
modulo, anagrafica.ts, tiene insieme le due connessioni. La logica di
giunzione era gia' al posto giusto (chiamava codicePerUtente, che sta in
anagrafica.ts) ma l'APERTURA delle connessioni no.

- anagrafica.ts: nuova codicePerUtenteLoggato(userId), apre lei stessa
  identity via getIdentityDb() (e' il modulo autorizzato) e delega a
  codicePerUtente. L'endpoint chiama solo questa: apre esclusivamente
  longevity, per salvare.
- tests/longevity/anagrafica.test.ts: il test anti-giunzione cercava due nomi
  letterali (createIdentityDb/createLongevityDb) e non vedeva getIdentityDb/
  getLongevityDb, nati dopo di lui - la stessa lezione del semaforo nel Task 1
  (proteggere il nome invece della cosa). Ora e' strutturale: segnala
  qualunque file (esclusi anagrafica.ts e db.ts) che contenga sia "Identity"
  sia "Longevity", in qualunque forma. Verificato con un file finto sotto
  src/ che apriva entrambe con i nomi nuovi: il test diventa rosso, poi
  torna verde dopo la cancellazione.
2026-08-22 14:01:33 +02:00
Adriano f5ca841d92 longevity: il questionario in pagina, e il consenso che si puo negare davvero
Sostituisce il prototipo del cliente (salvava anche con "No" al consenso
sanitario, perche' controllava solo che il campo non fosse vuoto). Qui il
consenso si verifica PRIMA di scrivere qualunque dato: se non e' affermativo
non si apre nessuna sessione, e la risposta lo dice. Il rifiuto si registra
comunque fra le note di profilo, con esito e versione del questionario: va
dimostrato tanto quanto un assenso.

- src/lib/longevity/vista.ts: campiDelQuestionario (dal registro, non da una
  lista nel codice) e salvaDalForm (consenso prima di tutto, poi delega a
  salvaCompilazione).
- src/pages/api/longevity/questionario.ts: il client_code arriva SEMPRE da
  codicePerUtente sulla sessione, mai dal corpo della richiesta.
- src/lib/longevity/db.ts: getLongevityDb/getIdentityDb, connessioni singole
  per processo (come getDb() del sito), cosi' l'endpoint non apre una nuova
  connessione a ogni richiesta.
- src/components/longevity/Questionario.tsx + pages/longevity/questionario.astro:
  isola React a quattro blocchi (le tre aree di domande + note/consenso), la
  pagina non interroga mai il database da sola.
2026-08-22 13:55:16 +02:00
Adriano 2ea822a84d longevity: test anti-semaforo strutturale (colori ammessi, non nomi vietati) e rotta verificata sul contenuto 2026-08-22 13:43:09 +02:00
Adriano 34c66ca438 longevity: il guscio della piattaforma, senza semaforo sui punteggi 2026-08-22 13:33:21 +02:00
Adriano 779aef32e6 docs: piano dell'interfaccia — questionario e referto del cliente 2026-08-22 13:29:54 +02:00
Adriano 0e9b081a79 spec: cosa ha scoperto la costruzione del motore 2026-08-22 11:02:26 +02:00
Adriano 42a039ae6b schema: il limite del vincolo e' la migrazione che non c'e', non SQLite 2026-08-22 11:01:45 +02:00
Adriano 82a4cd2000 test: chiude l'errore di tipi pre-esistente in middleware.test.ts
Cast di FakeContext a onRequest via 'unknown' invece che diretto: i
due tipi non si sovrappongono abbastanza per tsc (FakeContext è un
doppio minimale, non un APIContext completo). Il typecheck è il
meccanismo di sicurezza di questo motore: uno rosso in permanenza è un
cancello che nessuno guarda più.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XhLbMQ1q7wHwJSykgXRwQF
2026-08-22 10:49:42 +02:00
Adriano c1c868622f test: le sei tabelle dei sollevamenti sorvegliate, e il caso misto
- motore-fisici.test.ts confrontava i tiers letti dal file di
  riferimento, non le costanti TIERS_* del codice: ventiquattro numeri
  senza custode. Ora identifica la tabella dagli argomenti
  dell'oracolo ma usa le costanti vere per calcolare, quindi una
  costante alterata non combacia più con nessun caso.
- motore-caso-reale.test.ts: aggiunto il caso end-to-end mancante, un
  asse valido (Composizione Corporea, via due righe aggiunte al
  registro) e sei insufficienti — oggi la suite copriva solo "tutto
  insufficiente".
- test-fisici.ts: commento in testa che dichiara le venti curve non
  collegate al motore (vocabolario delle curve senza nomi per loro,
  applicaCurva senza modo di ricevere età/sesso) — aggancio è lavoro
  del piano degli import, non "una modifica ai dati" come la spec
  lascia intendere.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XhLbMQ1q7wHwJSykgXRwQF
2026-08-22 10:49:35 +02:00
Adriano 469251366e motore: chiude i tre buchi laterali della barriera dell'insufficiente
- eta_alla_data NULL non usa più il ripiego a zero: senza età la
  Fitness Age è null, non un'età di forma negativa dichiarata valida.
  Gli assi e i macro-score restano calcolabili (non dipendono dall'età).
- applicaCurva valida i parametri richiesti da ciascuna curva prima di
  applicarla: un registro con params vuoti/incompleti dà null, mai il
  punteggio pieno che dava lerp con estremi indefiniti.
- calcolaSessione esclude le misure fuori_range=1 (§9 della spec): non
  entrano nello score finché non esiste la colonna di conferma (§12,
  punto aperto).
- leggiScore(db, sessioneId): legge la tabella score ritipata come
  Punteggio, con l'ultimo calcolo per tipo+elemento esplicito nella
  query (MAX(id)), non l'ordine naturale delle righe — salvaScore non
  sovrascrive di proposito (la storia degli score si tiene, discende
  dal congelamento della §6).
- documentata la seconda divergenza dall'oracolo, mai scritta finora:
  la Fitness Age esclude gli assi insufficienti, l'oracolo li include
  comunque. Comportamento giusto, ma cambia il numero (25,0 contro
  34,8 sullo stesso profilo parziale).
- nuovo test che prova che i pesi di due model_version diverse restano
  separati (pesiDi filtra su model_version, non li fonde).

Ogni fix verificato in TDD (test rosso prima, verde dopo) e ri-rotto a
mano per confermare che discrimina davvero (vedi report).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XhLbMQ1q7wHwJSykgXRwQF
2026-08-22 10:49:25 +02:00
Adriano c4524e3a73 schema: la tabella score rifiuta un valore sotto uno stato che lo nega
CHECK ((stato='ok' AND valore NOT NULL) OR (stato='insufficiente' AND
valore NULL)): il tipo Punteggio protegge il codice, non la tabella, e
l'interfaccia leggerà 'score' direttamente. Idempotente sui database
nuovi (CREATE TABLE IF NOT EXISTS); un longevity.db già esistente NON
riceve il vincolo, SQLite non lo permette via ALTER TABLE.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XhLbMQ1q7wHwJSykgXRwQF
2026-08-22 10:49:12 +02:00
Adriano d22f88ad71 longevity: la prova sul profilo con una sola area misurata
Task 6 - la prova sul caso reale documentato dal cliente (dati sintetici,
nessuna persona reale). Il test smontava un difetto nel task 5: RisultatoSessione
esponeva fitnessAge come Punteggio invece che number|null (come lo produce
calcolaFitnessAge in cascata.ts), quindi un fitnessAge insufficiente non era mai
`null`. Corretto in motore/index.ts, con fitnessAgeCopertura a fianco per non
perdere l'informazione che salvaScore scrive in `score`.
2026-08-22 10:07:28 +02:00
Adriano ac8b377f84 longevity test: motivazione corretta per il caso 'test disattivato', e media verificata numericamente
Il commento del test 'un test disattivato non entra nel calcolo' diceva
che q_attivita fosse l'unica voce del sotto-dominio questionario_lifestyle:
falso, ne ha sei (q_attivita, q_alimentazione, q_sigarette, q_alcol_life,
q_luce, q_schermi). Il motivo vero per cui il test funziona e' che il
fixture ne compila solo una delle sei, quindi disattivarla svuota il
sotto-dominio. Corretto il commento a dire il motivo vero, con nota su
cosa succederebbe se il fixture cambiasse.

Aggiunto anche il test mancante sulla regola della media: q_attivita(3)=65
e q_alimentazione(6)=60, stesso sotto-dominio, verificano che il valore
dell'asse "Stile di Vita & Sonno" sia la loro media (62.5), diversa sia
dalla somma (125) sia da ciascun addendo (65, 60) — nessun test esistente
controllava il VALORE della media, solo lo stato.
2026-08-22 10:02:59 +02:00
Adriano f238984828 longevity: il motore legge curve e pesi dal registro, e congela i punteggi
Task 5: applicaCurva smista sulla curva dichiarata in registro_test (non
scritta nel codice); calcolaSessione aggrega le misure attive per
sotto-dominio (media quando piu' test contribuiscono allo stesso
sotto-dominio) e usa cascata.ts coi pesi letti da pesi (pesiDi) per i
sette assi, i tre macro-score e la Fitness Age; salvaScore congela il
risultato in score, con valore a null quando lo stato e' insufficiente.

Corretto anche un refuso nel test del brief ('un test disattivato non
entra nel calcolo'): disattivava q_ore_sonno, ma quella voce sta nel
sotto-dominio questionario_sonno (peso 0.20 su Recupero & Sistema
Nervoso, sempre sotto COPERTURA_MINIMA=0.4 finche' hrv/pressione/hrr non
hanno una voce nel registro), quindi l'asse restava insufficiente prima
e dopo e il JSON risultava identico (verificato: il test falliva con le
due stringhe uguali). Corretto usando q_attivita, l'unica voce del
sotto-dominio questionario_lifestyle che pesa 1.00 su Stile di Vita &
Sonno: disattivarla fa cadere la copertura da 1.00 a 0 e lo stato passa
da ok a insufficiente, una differenza vera.
2026-08-22 09:53:17 +02:00
Adriano 93ecc3d367 longevity: la copertura si confronta grezza, non arrotondata
Bug in aggrega(): la soglia veniva confrontata con la copertura gia'
arrotondata a due decimali, quindi 0.396 (< 0.40) passava per 'ok' perche'
arrotondava a 0.40. Confronto ora sulla copertura grezza; l'arrotondamento
resta solo sul valore esposto. Generalizzata arrotonda1 in curve.ts a un
numero qualsiasi di decimali (bit-exact, banker's rounding) e riusata qui a
due decimali, invece di tenere una seconda logica di arrotondamento nel
motore.
2026-08-22 09:39:58 +02:00
Adriano 98a633b3e1 longevity: la cascata a quattro livelli, con il tipo che chiude la trappola dell insufficiente 2026-08-22 09:28:40 +02:00
Adriano f029820a14 longevity: il test delle funzioni escluse copre anche score_generic_range_local
Il test controllava solo l'assenza dell'agilita (scoreAgilita/scoreAgilityMs)
e non della seconda funzione esclusa dal brief, score_generic_range_local:
se qualcuno la reintroducesse un domani nessun test se ne accorgerebbe.
Aggiunta l'assertion con lo stesso criterio, rinominato il test perche' ora
copre entrambe le esclusioni.
2026-08-22 09:24:42 +02:00
Adriano 4d76030839 longevity: unico arrotondamento al pari nel motore, esatto sul valore binario
Sposta arrotonda1 (round-half-to-even come Python) da test-fisici.ts a
curve.ts, esportata, cosi' entrambi i moduli condividono la stessa funzione
invece di due copie che sui pareggi potrebbero divergere.

Nel farlo, la versione precedente (moltiplica per 10, tolleranza 1e-9 sul
pareggio) si e' rivelata sbagliata su un caso reale: 86.35 non e' un
pareggio nel double che lo rappresenta (vale 86.34999999999999431...,
Python arrotonda a 86.3 senza ambiguita'), ma 86.35*10 arrotonda ESATTAMENTE
a 863.5 in virgola mobile, un pareggio fasullo creato dalla moltiplicazione.
La versione naive dava 86.4. Sostituita con un confronto esatto: scompone il
double in mantissa/esponente (bit IEEE 754) e confronta con aritmetica
razionale su BigInt, senza mai passare per una moltiplicazione che possa
introdurre o cancellare un pareggio.

Aggiunti in motore-curve.test.ts i casi che dimostrano il pareggio vero
(86.25 -> 86.2, 86.75 -> 86.8) e quello fasullo (86.35 -> 86.3, non 86.4:
blocca la regressione appena descritta).
2026-08-22 09:16:31 +02:00
Adriano 6f926e3197 longevity: le curve dei test fisici, verificate contro l oracolo 2026-08-22 09:09:23 +02:00
Adriano c63bb1fe80 longevity: chiude i tre buchi nei test delle curve — ramo crescente di curvaGradini mai esercitato, test zeroVal non discriminante, cardinalita mancante su due confronti con l oracolo 2026-08-22 09:02:20 +02:00
Adriano 36a2cf3fb6 longevity: le cinque curve del questionario, verificate contro l oracolo 2026-08-22 08:51:27 +02:00
Adriano 11ecc8305b piano: il codice sta nel repo, non anche nel piano 2026-08-22 08:48:26 +02:00
Adriano 236cdce076 longevity: rigenera riferimento.json con la griglia corretta (plateau offset, 2km walk multi-punto, confini plank) 2026-08-22 08:42:29 +02:00
Adriano c5249255f0 piano: rimette i commenti della griglia al posto giusto 2026-08-22 08:39:06 +02:00
Adriano 998487ed62 piano: infittita la griglia dove non aveva capacita diagnostica 2026-08-22 08:38:54 +02:00
Adriano 7cb49c6a49 longevity: l'oracolo del motore e la griglia di riferimento 2026-08-22 08:29:53 +02:00
Adriano bc9d31e193 docs: piano del motore di calcolo, verificato contro l'oracolo del cliente 2026-08-22 08:27:51 +02:00
Adriano 59b453c67e longevity: annotate le conferme di Nicola del 22/08 (plank su due assi, soglia unica al 40%) 2026-08-22 08:02:20 +02:00
Adriano 52ff28b69d spec: i sei punti emersi costruendo lo strato dati, piu' la curva x10_inv che mancava 2026-08-21 20:34:49 +02:00
Adriano 763e5611e6 longevity: revisione finale - codice cliente non riusabile, ruoli allineati, middleware verificato
- creaCliente: il codice si deduce dal massimo fra identity E longevity (non piu' solo
  identity), cosi' un client_code cancellato dall'anagrafica non torna mai disponibile
  e non si attribuiscono le misure di un vecchio cliente a uno nuovo. Compensazione se
  la scrittura su longevity fallisce dopo quella su identity.
- ROLES unica fonte in auth.ts (Role e isRole derivati); users.astro e users/new.astro
  usano quella lista invece di array scritti a mano che dimenticavano cliente/trainer.
- Commento falso su cosa protegge il middleware, riscritto: rimanda a isProtectedPath.
- vitest.config.ts: alias per astro:middleware (stesso bersaglio della pipeline vite di
  Astro), cosi' src/middleware.ts e' finalmente importabile e testabile in isolamento -
  prima nessun test lo caricava davvero.
- export.test.ts: asserzione posizionale per colonna, non piu' solo intestazioni scritte
  a mano; intercetta un riordino della SELECT che disallinea etichette e valori.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-21 20:30:23 +02:00
Adriano e6c2ac9148 longevity: test atomicità corretto - verifica rollback anche dei campi liberi 2026-08-21 20:08:12 +02:00
Adriano 2024c32965 longevity: export pseudonimizzato per costruzione 2026-08-21 20:05:19 +02:00
Adriano 91e6487da3 longevity: atomicità compilazione questionario con transazione unica 2026-08-21 20:02:23 +02:00
Adriano f21b64fcc5 longevity: salvataggio compilazione questionario, versionata 2026-08-21 19:57:35 +02:00
Adriano d3abbf9bf7 task-5 fix: isRole, login redirect, create-user script per cliente e trainer 2026-08-21 19:53:12 +02:00
Adriano 473c0d8c36 fix: isProtectedPath nel middleware, landingFor per cliente e trainer 2026-08-21 19:44:08 +02:00
Adriano 502ccb1585 longevity: ruoli cliente e trainer con le rispettive rotte 2026-08-21 19:41:45 +02:00
Adriano b7ceece4ed test(anagrafica): allarga la scansione a tutto src/ per rilevare giunzioni non autorizzate
Rafforza il test che verifica l'isolamento tra identity e longevity.
Invece di scandire solo src/lib/longevity/, ora scandisce ricorsivamente
tutto src/ inclusi .astro e .ts, saltando node_modules e dist.

Preserva le due sole esclusioni autorizzate: anagrafica.ts (il modulo
autorizzato) e db.ts (dove le factory sono definite).

In questo modo il test rileva violazioni anche da route API e pagine
Astro, non solo da moduli della cartella longevity.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-21 19:38:56 +02:00
Adriano 9943312071 longevity: anagrafica, unico punto di giunzione fra identita e clinica
Implementa il modulo che unisce i due database (identity e longevity)
rispettando la separazione richiesta dal cliente: pseudonimizzazione
dei dati clinici. Il modulo esporta tre funzioni:

- creaCliente: registra un soggetto con il suo codice progressivo ISL-NNNN
- codicePerUtente: risale dal user_id del sito al client_code
- etaAllaData: calcola l'eta' al momento della misura (non la data di nascita)

Un test verifica che nessun altro modulo apra entrambe le connessioni,
preservando il firewall fra dati clinici e identita'.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-21 19:33:23 +02:00
Adriano 7779c6b830 test: verifica che fuoriRange non trunca il valore numerico 2026-08-21 19:31:15 +02:00
Adriano a18bb7c02f longevity: registraMisure, unico varco con validazione sul registro 2026-08-21 19:27:41 +02:00
Adriano 370dcbda56 longevity: registro dei test e pesi versionati come dato 2026-08-21 19:22:32 +02:00
Adriano 1821a0a8d4 spec: score.nome diventa score.elemento, coerente con la tabella pesi 2026-08-21 19:17:42 +02:00
Adriano ad2fc0d510 fix: rinomina score.nome in score.elemento per coerenza con tabella pesi 2026-08-21 19:17:03 +02:00
Adriano f16012c8bd longevity: schema dei due database, identity separato da longevity 2026-08-21 19:15:17 +02:00
Adriano bdc44dd3c5 chore: ignora gli artefatti di lavoro dei subagenti in .superpowers/ 2026-08-21 19:11:44 +02:00
Adriano 534833c767 docs: piano di implementazione dello strato dati longevity
Sette task in TDD: schema dei due database, registro test e pesi versionati,
registraMisure come unico varco, anagrafica che tiene separata identita' e
clinica, ruoli cliente/trainer, salvataggio del questionario, export.

Alla fine esiste una libreria testata e nessuna pagina: il motore di calcolo
e le schermate sono i due piani successivi.
2026-08-21 19:05:07 +02:00
Adriano 02d0224e5a docs: design della piattaforma IN-SANITY LONGEVITY PROJECT
Fascicolo unico del cliente dentro il sito esistente, ramo separato e nessun
deploy. Tre database: sito, identity (codice <-> nome) e longevity (misure,
mai un nome) - cosi' l'export per le statistiche e' gia' pseudonimizzato per
costruzione, come chiesto da Nicola il 21/08.

Le misure sono un registro (una riga per valore) e i test sono dato, non
codice: togliere l'agilita' o passare l'HRR da 2' a 1' non e' una migrazione.
I pesi stanno in tabella versionata, cosi' il congelamento degli score
storici ha davvero qualcosa dietro.

Punteggi congelati con due versioni distinte (domande e modello di calcolo).
Il tipo di ritorno del motore rende impossibile mostrare un numero pieno dove
la regola vuole il tratteggio.
2026-08-21 18:41:06 +02:00
Adriano ecab67805b Data dell'inaugurazione piu' grande 2026-08-19 10:34:38 +02:00
Adriano cdfbf194c2 Eventi: la data dell'inaugurazione si legge da lontano
Chiesto da Adriano il 19/08: era 0,82rem sotto un titolo che arriva a 2,6rem, e
sembrava una didascalia. Ora cresce con la finestra come il titolo, restando un
gradino sotto.
2026-08-19 10:34:12 +02:00
Adriano 76adef3fc7 Titolo e data dell'inaugurazione su due righe 2026-08-19 10:31:49 +02:00
Adriano d079019dcf Eventi: titolo e data dell'inaugurazione su due righe
Chiesto da Adriano il 19/08. Sono due tag e non un testo con un a capo dentro:
la data si cambia da sola se l'evento si sposta, e un ritorno a capo dentro un
valore di testo non sopravvive all'editor del pannello.

Il titolo vive anche nel database: in produzione va aggiornato
eventi.inaugurazione.title a "Inaugurazione", altrimenti resta la riga unica.
Il tag nuovo (.date) non e' in tabella e viene dal seed.
2026-08-19 10:30:07 +02:00
Adriano 48909e8c8b Foto del team senza logo, e la foto di Eva torna nel repo 2026-08-19 10:25:18 +02:00
Adriano cc6945c3d1 Eva: la foto della pagina About torna nel repo, senza logo
La foto di Eva in pagina non veniva dal repo ma da un file caricato dal
pannello il 12/07 (tag team.eva.image-about): lo scatto giusto, ritagliato piu'
largo, ma con il logo ancora nell'angolo. Il file del repo era l'altro ritaglio,
piu' stretto, e non lo vedeva nessuno.

Ora team-eva-dark.jpg E' quella foto, col logo rimosso: maschera dei pixel del
logo allargata di 4 px per prendere i bordi sfumati, ricostruzione biharmonic
(scikit-image) e grana del tessuto ripresa dalla stoffa 80 px piu' in alto —
una toppa liscia si sarebbe notata.

Cosi' tutte le foto stanno in un posto solo e passano dall'ottimizzazione della
build (54 KB webp invece di 177 KB jpeg servito com'e'). In produzione va
svuotato il tag team.eva.image-about, altrimenti continua a vincere il file
caricato. Originale col logo su
wasabi://.../foto-team/team-eva-dark-ORIGINALE-col-logo.jpeg; il file su
uploads/ resta dov'e'.

Il ritaglio e' 864x1240 (0.697) invece di 1547x1920 (0.806): le card ritagliano
a 3:4, quindi qui si perde qualcosa sopra e sotto invece che ai lati. Verificato
sulla card renderizzata.
2026-08-19 10:24:13 +02:00
Adriano f7a9ae47d1 Foto del team senza il logo nell'angolo
Adriano ha tolto un piccolo logo dall'angolo in basso a destra delle sette foto
scure della pagina About: alessandro, alice, donata, eleonora, eva, giulia,
nicola. Originali in wasabi://.../Sito_Web/foto-team-originali-20260819.zip.

Stesso formato di prima (JPEG 1547x1920, RGB): l'unica differenza e' un riquadro
di ~80x80 px nell'angolo, verificato confrontando le immagini. I file pesano il
doppio perche' risalvati a qualita' piu' alta, ma in pagina non cambia nulla: la
build li ricomprime in webp attorno agli 85 KB.

Nota: la foto di Eva in pagina NON e' questa, e' un ritaglio piu' largo dello
stesso scatto caricato dal pannello il 12/07 (tag team.eva.image-about), che il
logo ce l'ha ancora.
2026-08-19 10:16:29 +02:00
Adriano 9772b3a3f6 Il titolo della pagina About us 2026-08-19 09:43:49 +02:00
Adriano 32c8a510bb About us: il titolo in cima alla pagina dice About us, non Insanitylab
Segnalato da Adriano il 19/08. Il valore vive anche nel database dei contenuti,
dove viene letto per primo: il seed da solo non avrebbe cambiato la pagina, e
l'aggiornamento del tag about.hero.title va fatto in produzione.
2026-08-19 08:59:44 +02:00
Adriano 20f0c2120b Piu' aria fra l'immagine e il titolo Check-up Avanzato 2026-08-19 08:54:46 +02:00
Adriano 6e002d4dc1 Check-up: il titolo della sezione Avanzato si stacca dall'immagine
Segnalato da Adriano il 19/08: "Check-up Avanzato" era appiccicato alla foto
sopra e si leggeva come una didascalia invece che come l'inizio di una parte
nuova.

Lo stacco e' un padding e non un margine: sopra c'e' gia' il margine
dell'immagine, e due margini verticali adiacenti collassano fra loro — con
margin-top lo spazio sarebbe rimasto quello di prima.
2026-08-19 08:49:55 +02:00
Adriano 3790d6d506 Check-up senza la domanda "Che cosa comprende?" 2026-08-19 08:46:19 +02:00
Adriano e315887964 Check-up: via la domanda "Che cosa comprende?" in fondo alla scheda
Chiesta da Adriano il 19/08. Restava in coda alle FAQ e ripeteva, in versione
piu' povera, cio' che la sezione Check-up Avanzato racconta per esteso.

In pagina resta una sola domanda. I due tag del pannello
(service.profilazione.faq.2.q e .a) non sono piu' letti da nessuno.
2026-08-19 08:45:35 +02:00
Adriano 0cbaf66a5b Pubblica le modifiche di agosto: calendario delle class, promo a edizioni e le richieste del 17/08 2026-08-18 17:06:53 +02:00
Adriano 3741ce34ac Modifiche chieste dal cliente il 17 agosto
Il documento MODIFICHE_PER_SITO.pdf porta cinque cose.

1. "Small Group" si chiama "Personalized Training Group". Il nome vive anche
   nel database dei contenuti, dove `resolveContent` legge prima della copia
   nel codice: `scripts/testi-17-agosto.mjs` aggiorna le 19 righe rimaste,
   una volta sola, correggendo anche gli articoli ("Lo Small Group" -> "Il
   Personalized Training Group"). Lo slug della scheda resta `small-group`:
   cambiarlo romperebbe i link gia' girati su WhatsApp.

2. Dalla pagina Servizi le card instradano dove serve. "One to One" apre la
   vista Training con One to One, Personalized Training Group e Rehab;
   "Class" quella con Holistic e Reformer. Le viste sono `/training/<vista>`;
   una vista inventata e' 404, non l'elenco intero, altrimenti un indirizzo
   rotto continuerebbe a sembrare buono.

3. La Performance Class non si eroga piu': la scheda che la spiegava
   risponde 404, la card "Class" resta in griglia. Con la scheda e' caduta la
   tabella prezzi, che era solo sua.

4. Il Check-up racconta Base e Avanzato: trafiletto nuovo nella card e
   sezione "Check-up Avanzato" nella scheda, con la Wellness Tower e i cinque
   punti. Il calendario delle class si apre ora anche dalla card Class in
   griglia e dalla scheda Reformer, oltre che da Holistic.

5. "Promo ed eventi" diventa una pagina di scelta: le promozioni restano su
   /promo-eventi/promo, l'inaugurazione del 19 settembre sta su
   /promo-eventi/eventi. Il testo dice che il programma della giornata manca
   ancora, ed e' editabile dal pannello.

Corretti due link del footer che portavano a schede inesistenti
(`/services/personal-training` non e' mai stato uno slug).

181 test verdi (157 + 24 nuovi), build ok, `astro check` invariato.
2026-08-18 17:06:05 +02:00
Adriano 69bd17a296 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>
2026-08-17 17:22:22 +02:00
Adriano d03c62641e Calendario: il 19 e il 20 settembre non sono un buco, sono un evento e una chiusura
Quei due giorni non stanno in nessuna delle due griglie perche' non hanno class:
il 19 c'e' la presentazione della nuova apertura, il 20 si sta chiusi. Scritto
come avviso con la sua finestra, il vuoto smette di sembrare una trascrizione
incompleta e diventa un'informazione.

Gli avvisi compaiono in cima al popup e in fondo al PDF - e' il file che gira su
WhatsApp, e chi lo riceve non ha la pagina davanti. Spariscono da soli quando
sono passati: un avviso scaduto dice che il centro e' chiuso in un giorno gia'
trascorso, e chi legge non sa piu' se valga per quest'anno o per il prossimo.

Lo spazio riservato in fondo alla pagina cresce con gli avvisi, altrimenti la
griglia si allunga fino a spingerli su una seconda pagina.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-17 17:07:24 +02:00
Adriano 928de34c55 Calendario: mercoledi 17.30 e 18.15 sono vuote per davvero
Le due celle coperte dal riquadro di Excel nel foglio dal 21 settembre: Adriano
conferma che non c'e' nulla. Il dato non cambia, cambia il commento - quel vuoto
adesso e' una risposta, non una lettura mancata.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-17 16:44:19 +02:00
Adriano 5be0fa787c Calendario: il PDF e' un file vero, generato dal server
"Scarica in PDF" non apre piu' la stampa del browser: e' un link a
/calendario/<id>.pdf che restituisce un documento disegnato dal dato con PDFKit,
con Content-Disposition attachment. Serve perche' il calendario si gira su
WhatsApp, ed e' cosi' che questo centro parla coi clienti: chi lo riceve non ha
il sito aperto davanti.

Niente browser headless: Chromium in un container da 2 vCPU costa centinaia di
megabyte e un processo per richiesta, per una griglia di sette colonne.

Le linee della griglia si tracciano in una passata a parte, dopo i riempimenti:
disegnandole riga per riga, il riempimento della riga seguente copriva quella
appena fatta e due lezioni uguali in fasce consecutive si leggevano come un
blocco unico lungo il doppio.

Quattro test: intestazione %PDF- e coda %%EOF (un documento non chiuso arriva
monco e il browser mostra una pagina bianca invece di un errore), una pagina
sola, nomi di file distinti. Un id sconosciuto e' 404, non un PDF vuoto.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-17 16:14:02 +02:00
Adriano 01f49ab6d2 Calendario delle class: popup a pieno schermo dalle pagine Performance e Holistic
Le due griglie fornite dal cliente (1-18 settembre, dal 21 in poi) sono
trascritte come dato e ridisegnate nello stile del sito: si leggono da telefono,
si stampano in PDF e per correggere una cella non serve rifare uno screenshot.

Quale griglia compare lo decide la data, come per le edizioni della promo: quella
in vigore, oppure - se nessuna lo e' ancora - la prossima, dichiarando da quando
entra. Serve perche' il link esiste da subito e ad agosto un "nessun calendario"
non direbbe niente a chi vuole gli orari di settembre.

Il popup e' un <dialog> nativo: fondale, Esc e trappola del focus senza
librerie. "Scarica in PDF" stampa la sola griglia, gia' impaginata in orizzontale
dal CSS di stampa. Le discipline hanno una barra colorata a sinistra oltre al
fondo, cosi' restano distinguibili anche quando il browser stampa senza sfondi.

Quattordici test sul dato: confini al secondo in ora italiana, fasce orarie
uniche e in ordine, nessuna lezione in un giorno di chiusura, e il buco vero fra
il 19 e il 20 settembre resta dichiarato invece che nascosto.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-17 15:58:47 +02:00
Adriano a18a505254 Servizi: foto e "Per saperne di piu'" della stessa card portano allo stesso posto
Erano due espressioni diverse per lo stesso link e sono divergute: su One to One e
Performance Class la foto apriva la scheda del servizio mentre il testo mandava a
/training, quindi la destinazione dipendeva da dove capitava il dito. Adesso
l'indirizzo lo calcola una funzione sola, usata da entrambi. Verificato sulla
pagina renderizzata: sei card, zero link discordanti.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-17 15:38:03 +02:00
Adriano cbcb533e57 Promo: un'anteprima non applicata lo dice, invece di mostrare oggi in silenzio
Senza login (o con una data illeggibile) il parametro veniva ignorato e la pagina
rispondeva con l'edizione corrente: due date diverse davano lo stesso risultato,
e si legge come una funzione rotta invece che come un accesso mancante. Ora una
barra rossa dichiara il motivo e come rimediare.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-17 12:32:57 +02:00
Adriano 0b5d9f4106 Promo: le edizioni si scambiano da sole alla data stabilita
La pagina non mostra piu' una promozione sola scritta nel codice: sceglie
l'edizione la cui finestra contiene l'istante della richiesta. Il 20 agosto alle
00:00 la promo agosto lascia il posto agli Opening Bundles senza deploy, e dopo
il 4 settembre la pagina dichiara che non c'e' nessuna promozione invece di
lasciare online prezzi scaduti.

Le edizioni sono dato (data/promo-edizioni.ts): finestra, quante card, quali
campi ha ciascuna. I testi restano tag modificabili dal pannello, col prefisso
dell'edizione. I bundle aggiungono domanda, descrizione e riquadro del periodo
di utilizzo, presi dal volantino del cliente.

Le date portano l'offset esplicito: il server gira in UTC e senza offset lo
scambio avverrebbe due ore prima di quanto scritto sul sito. La pagina esce con
Cache-Control: no-store, perche' una copia in cache la congelerebbe all'edizione
vecchia.

Dieci test: le finestre non si sovrappongono e non lasciano buchi, il countdown
scade quando finisce l'edizione, e ogni tag richiesto esiste nel seed - un tag
mancante non romperebbe la pagina, lascerebbe una card senza prezzo.

Anteprima con ?anteprima=<data>, solo per chi e' loggato.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-17 12:27:31 +02:00
Adriano cd73906c08 Migliora il layout mobile delle sezioni home
MethodSteps passa a una sola colonna con step in orizzontale, PartnersStrip
riduce loghi e spaziature, TrainingCards ridimensiona testi e padding.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-15 19:17:15 +02:00
Adriano Dal Pastro d6c6597d0a Ignora i backup .env.bak*
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-01 13:26:43 +00:00
Adriano 97bf270906 Lista articoli del blog per revisione cliente (md + pdf)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-01 14:58:13 +02:00
Adriano 63417fb8ea FAQ promo eventi: rimando WhatsApp e riscrittura FAQ 1 e 2
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-01 14:51:30 +02:00
Adriano 9000c78a22 Aggiunge FAQ acquisto pacchetti in cima alla promo eventi
Nuovo tag promo.faq.0 (q/a) numerato 0 per evitare di rinumerare le FAQ
esistenti: il seed è INSERT OR IGNORE e non riscriverebbe i tag già
presenti nei DB, causando disallineamento tra domanda e risposta.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-01 13:24:32 +02:00
Adriano 12f6b088de README aggiornato: piattaforme, Stress Index, cestino del blog e note di deploy
Documenta il ruolo piattaforme al posto di campus, la piattaforma Stress
Index con le scelte fatte sullo stile e sulle isole React, il cestino
degli articoli e il caricamento degli articoli via script, oltre alle
trappole incontrate: il percorso nuovo del progetto Campus, la cache
dell'indice in sviluppo e la lettura del database in WAL dopo il deploy.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-31 22:03:52 +02:00
361 changed files with 3424 additions and 42984 deletions
+13 -5
View File
@@ -1,8 +1,16 @@
node_modules/ node_modules
dist/ dist/
.astro/ .astro/
.env .env
data/*.db* .env.bak*
uploads/* **/data/*.db*
!uploads/.gitkeep **/uploads/*
assets-src/ !**/uploads/.gitkeep
**/assets-src/
# Artefatti di lavoro dei subagenti (ledger, brief, review package)
.superpowers/
# Cache di Python generata rieseguendo l'oracolo
__pycache__/
*.pyc
-2
View File
@@ -14,8 +14,6 @@ COPY package.json package-lock.json ./
RUN npm ci --omit=dev && npm cache clean --force RUN npm ci --omit=dev && npm cache clean --force
COPY --from=build /app/dist ./dist COPY --from=build /app/dist ./dist
COPY scripts ./scripts 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 \ ENV HOST=0.0.0.0 \
PORT=4321 \ PORT=4321 \
+90 -20
View File
@@ -1,11 +1,13 @@
# InsanityLab Website # InsanityLab Website
Sito ufficiale di InsanityLab: vetrina aziendale, blog integrato, form di contatti e sistema di contenuti modificabili senza toccare il codice. In produzione su **https://insanitylab.it**. 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 ## Descrizione
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. 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.
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.
## Stack tecnologico ## Stack tecnologico
- **Framework**: Astro 7 (output `server`, `prerender = false` sulle pagine dinamiche) - **Framework**: Astro 7 (output `server`, `prerender = false` sulle pagine dinamiche)
@@ -14,6 +16,8 @@ Il sito è costruito su **Astro 7** in modalità server (SSR) con adapter **Node
- **Autenticazione**: sessioni con password hashate (`bcryptjs`) - **Autenticazione**: sessioni con password hashate (`bcryptjs`)
- **Email**: Nodemailer (SMTP) - **Email**: Nodemailer (SMTP)
- **Editor articoli**: TipTap (rich text) - **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 - **Font**: `@fontsource` (Montserrat, Open Sans) — nessun CDN esterno
- **Sitemap**: endpoint runtime `/sitemap.xml` (route vetrina + articoli pubblicati) - **Sitemap**: endpoint runtime `/sitemap.xml` (route vetrina + articoli pubblicati)
- **Test**: Vitest - **Test**: Vitest
@@ -25,9 +29,10 @@ Il sito è costruito su **Astro 7** in modalità server (SSR) con adapter **Node
- **Vetrina**: home, chi siamo, training, servizi (con schede di dettaglio), blog, contatti, landing "Promo ed eventi". - **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. - **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. - **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 e proprietà degli articoli per ruolo. - **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.
- **Gestione utenti** con quattro ruoli (`admin`, `superuser`, `user`, `campus`). - **Cestino degli articoli**: l'eliminazione sposta in `/admin/cestino`, da dove si ripristina o si cancella in via definitiva.
- **Campus**: sezione riservata con le guide di studio del corso Biohacking Campus, accessibile solo dopo il login e con navigazione autonoma. - **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. - **Form contatti** con validazione, honeypot anti‑spam, rate‑limit e invio email via SMTP.
## Installazione (sviluppo) ## Installazione (sviluppo)
@@ -54,8 +59,9 @@ Il database `data/insanitylab.db` viene creato al primo avvio ed è popolato aut
| `npm run preview` | Anteprima locale della build | | `npm run preview` | Anteprima locale della build |
| `npm run start` | Server di produzione (`node --env-file=.env`) | | `npm run start` | Server di produzione (`node --env-file=.env`) |
| `npm run test` | Test con Vitest | | `npm run test` | Test con Vitest |
| `npm run create-user` | Crea/aggiorna utente: `-- <nome> <password> [admin\|superuser\|user\|campus]` | | `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 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
@@ -69,43 +75,65 @@ Il seed dei contenuti è in `src/data/content-seed.ts`; le variazioni sui conten
> 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)`). > 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 ## Ruoli e accessi
Quattro ruoli, con autorizzazione a matrice di prefissi in `src/lib/auth.ts`: Quattro ruoli, con autorizzazione a matrice di prefissi in `src/lib/auth.ts`:
| Ruolo | Può fare | | Ruolo | Può fare |
|-------|----------| |-------|----------|
| `admin` | Tutto: contenuti, blog, upload, **gestione utenti** (`/admin/users`), Campus | | `admin` | Tutto: contenuti, blog, upload, **gestione utenti** (`/admin/users`), piattaforme |
| `superuser` | Pannello contenuti + blog | | `superuser` | Pannello contenuti + blog |
| `user` | Solo i **propri** articoli del blog | | `user` | Solo i **propri** articoli del blog |
| `campus` | Solo la sezione riservata `/campus`; nessun accesso al pannello | | `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, il Campus per il ruolo omonimo. La gestione utenti (`/admin/users`, solo admin) consente creazione, reset password una‑tantum, cambio ruolo ed eliminazione, con guardie contro l'auto‑eliminazione e la rimozione dell'ultimo admin. 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.
## Campus (sezione riservata) > 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.
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 alla home — ma usano i font, i colori e il CSS globale di InsanityLab. ## 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`. 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. 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 ## Struttura del progetto
``` ```
insanitylab-website/ insanitylab-website/
├── src/ ├── src/
│ ├── pages/ # Route Astro (vetrina, /admin, /api, /campus) │ ├── pages/ # Route Astro (vetrina, /admin, /api, /campus, /piattaforme)
│ ├── components/ # Componenti (home/, content/, Header, Footer, …) │ ├── components/ # Componenti (home/, content/, stress-index/, Header, Footer, …)
│ ├── layouts/ # Layout Base, Admin, Campus │ ├── layouts/ # Layout Base, Admin, Campus, StressIndex
│ ├── data/ # Dati statici + seed contenuti (services, trainings, site, content-seed) │ ├── data/ # Dati statici + seed contenuti (services, trainings, site, piattaforme, content-seed)
│ ├── lib/ # db, auth, content, mailer, rate-limit, safe-next, env │ ├── lib/ # db, auth, content, mailer, rate-limit, safe-next, env, stress-index/
│ ├── assets/img/ # Immagini ottimizzate da Astro │ ├── assets/img/ # Immagini ottimizzate da Astro
│ └── styles/ # global.css │ └── styles/ # global.css, stress-index.css
├── data/ # SQLite (volume in produzione) ├── data/ # SQLite (volume in produzione)
├── uploads/ # Upload immagini (volume in produzione) ├── uploads/ # Upload immagini (volume in produzione)
├── campus-content/ # Contenuti del Campus generati da sync-campus ├── campus-content/ # Contenuti del Campus generati da sync-campus
├── scripts/ # create-user, sync-campus, smoke test ├── scripts/ # create-user, sync-campus, seed-blog-biohacking, smoke test
├── astro.config.mjs # Config Astro (site, allowedDomains, redirects) ├── astro.config.mjs # Config Astro (site, allowedDomains, redirects)
├── compose.yaml # Stack Docker + label Traefik ├── compose.yaml # Stack Docker + label Traefik
├── Dockerfile # Build multi-stage ├── Dockerfile # Build multi-stage
@@ -137,11 +165,20 @@ Il sito gira in Docker su un VPS, dietro Traefik. Lo stack è in `/opt/docker/in
```bash ```bash
cd /opt/docker/insanitylab/src cd /opt/docker/insanitylab/src
git pull sudo git -c safe.directory="$PWD" pull origin main # il repo è di root: serve sudo, con password
docker compose up -d --build docker compose up -d --build # docker gira senza sudo
``` ```
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 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.
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.
```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'
```
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`.
### Dominio e DNS ### Dominio e DNS
@@ -162,6 +199,39 @@ Le migrazioni del database (in `src/lib/db.ts`) sono idempotenti e girano all'av
**Database "locked" durante i test** — assicurarsi che nessun processo stia accedendo a `data/insanitylab.db`. **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 ## Licenza
Proprietà di InsanityLab. Proprietà di InsanityLab.
## Deploy (dopo la separazione del 03/09/2026 e i due repo del 29/09/2026)
Dal 29/09/2026 questo repo contiene **solo il sito**, in radice. Le aree riservate hanno il
loro repo, `gitea:Adriano/InsanityLab-platforms` (issue #20); fino ad allora le due app erano
`apps/sito` e `apps/platforms` dello stesso repo.
Il progetto compose si chiama **`insanitylab`** (`name:` esplicito nel compose), non piu'
`src` come quando la cartella era `/opt/docker/insanitylab/src`.
```
cd /opt/docker/insanitylab/src
docker compose build # il sito resta in piedi: non tocca il container
docker compose up -d # sostituisce il container
```
⚠️ **`.env` non e' in git** (e non deve esserlo): resta dov'e' ed e' l'unico file che un
`git merge` non porta con se'. Il 04/09/2026 lo spostamento sotto `apps/sito/` ha lasciato
`.env` alla vecchia radice, l'`up` e' fallito **dopo** che il `down` aveva gia' tolto il
container, e il sito e' rimasto giu' **9,7 secondi**. ⚠️ Il 29/09/2026 il sito torna in radice:
al primo deploy dopo quel cambio `.env` va spostato a mano da `apps/sito/.env` a `.env`.
Prima di ogni swap:
```
docker compose config >/dev/null # legge env_file e fallisce SUBITO se manca qualcosa
```
⚠️ Un `docker run` sull'immagine **non** e' una prova sufficiente del deploy: non legge
`env_file`, quindi passa anche quando il compose fallirebbe.
Binary file not shown.

Before

Width:  |  Height:  |  Size: 370 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 230 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 165 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 229 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 255 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 276 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 255 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 222 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 390 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 581 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 2.6 MiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 362 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 115 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 117 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 551 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 480 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 170 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 380 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 676 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 542 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 384 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 363 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 98 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 85 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 560 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 73 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 247 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 632 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 452 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 374 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 575 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 410 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 347 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 357 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 258 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 837 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 268 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 323 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 350 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 212 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 405 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 283 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 408 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 765 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 370 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 439 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 224 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 531 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 791 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 408 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 702 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 551 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 308 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 196 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 257 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 300 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 229 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 294 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 394 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 397 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 172 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 377 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 230 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 247 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 256 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 231 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 939 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 55 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 365 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 329 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 489 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 397 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 654 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 494 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 413 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 371 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 476 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 550 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 639 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 388 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 400 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 654 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 611 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 593 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 149 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 202 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 162 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 443 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 393 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 284 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 157 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 203 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 353 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 400 KiB

File diff suppressed because it is too large Load Diff
@@ -1,136 +0,0 @@
<h2>In sintesi</h2>
<p>Questo primo Accelerator inaugura un format mensile dedicato non alla parte tecnica del biohacking, ma allo sviluppo di business: come trasformare una competenza sull&#39;ottimizzazione fisica in un&#39;attività che genera reddito. Massimo Filippi chiarisce subito la filosofia dell&#39;incontro: gli studenti del campus devono ottenere risultati anche economici, perché nel mondo della salute i professionisti accumulano corsi e valore tecnico senza però riuscire a capitalizzarlo. Il filo conduttore della serata è uno solo, declinato caso per caso: partire dal bisogno profondo del cliente, non da ciò che si è o si sa fare. Rispondendo alle domande dei partecipanti, Massimo affronta la definizione della nicchia e della buyer persona, i tre bisogni che davvero muovono le persone (stanchezza, sonno, disturbi intestinali) più la leva del dolore per i terapisti manuali, la costruzione del &quot;meccanismo della soluzione&quot;, la scelta tra avviamento online e offline, l&#39;uso di lead magnet e open day, il tasso di no show e l&#39;importanza del follow-up. Passa poi alla comunicazione a due livelli (front-end orientato al problema, back-end orientato alla spiegazione tecnica), alla struttura e al prezzo della consulenza, alla logica di investire tempo oppure denaro, alla differenza tra un evento pensato per monetizzare e uno pensato per acquisire clienti, e alla regola di portare avanti un solo progetto alla volta. Il messaggio operativo ricorrente: comunicare il problema, non la tecnica; costruire sempre un&#39;offerta successiva; stare dietro alle persone; e testare tutto sui numeri.</p>
<h2>Concetti chiave</h2>
<ul>
<li><strong>Accelerator (hot seat)</strong>: format mensile in cui si analizza il progetto operativo di uno o più partecipanti, dando linee guida di business. Non è un momento tecnico (quello resta a lezioni, workshop e &quot;Tana del biohacker&quot;), ma un confronto continuativo nel tempo, in cui mese dopo mese si porta un aggiornamento e si riceve un feedback.</li>
<li><strong>Nicchia di mercato / buyer persona</strong>: la definizione precisa di chi è il cliente — età, professione, ambizioni, ma soprattutto il bisogno principale che lo spinge a muoversi. Il 90% dei partecipanti, secondo Massimo, non ha chiaro questo target ed è il primo errore da correggere.</li>
<li><strong>Comunicare il bisogno, non la tecnica</strong>: le persone non vogliono sapere che cosa fai (né capiscono termini come &quot;biohacker&quot; o &quot;coach del sonno&quot;), vogliono sapere come risolvi il loro problema. Va usato il linguaggio del problema percepito (&quot;ti aiuto a non svegliarti alle tre di notte&quot;), non quello tecnico-scientifico.</li>
<li><strong>Dolore o ispirazione</strong>: le persone agiscono per due motivi, ma chi si muove per ispirazione è meno del 10%. La maggioranza si muove per dolore: i contenuti e le offerte che convertono partono dal problema, non dai &quot;5 consigli per dormire meglio&quot;.</li>
<li><strong>Meccanismo della soluzione</strong>: un metodo di lavoro riconoscibile e diverso da tutto ciò che il cliente ha già provato (&quot;ho provato tutto, ma questo no&quot;). È ciò che dà valore percepito all&#39;offerta.</li>
<li><strong>Online vs offline</strong>: l&#39;online attira di più ma è lento, richiede competenze e quasi sempre budget pubblicitario; l&#39;offline è più veloce nell&#39;avviamento, richiede meno esperienza (ma più &quot;alzarsi e andare a parlare con le persone&quot;) ed è meno scalabile. Per partire da zero senza competenze digitali, Massimo consiglia l&#39;offline.</li>
<li><strong>Lead magnet</strong>: sistema di acquisizione gratuito (open day, primo check-up gratuito, analisi dello stress) che serve ad attrarre il contatto, sapendo già quale offerta proporre subito dopo.</li>
<li><strong>Front-end e back-end</strong>: due livelli di comunicazione. Il front-end è la prima cosa che il cliente vede, parla solo del problema e ha l&#39;unico scopo di portare a un&#39;azione (la call to action). Il back-end arriva dopo, nel rapporto uno-a-uno, e spiega in modo più tecnico come funziona il metodo.</li>
<li><strong>No show e follow-up</strong>: in un&#39;attività nuova il tasso di persone che prenotano e non si presentano supera il 30%. Le persone vanno &quot;seguite&quot; (chiamate, ricordate, accompagnate): senza questo lavoro di attrazione e presidio nessuno si muove.</li>
<li><strong>Componenti del prezzo</strong>: il prezzo nasce da tre fattori — emotivo (la motivazione all&#39;acquisto, la parte più forte), funzionale (l&#39;utilità concreta percepita) e opzionale (quante cose/opzioni si ricevono). Va trovato lo &quot;sweet spot&quot; testando più prezzi.</li>
<li><strong>Tempo o denaro</strong>: due strade per avviare. Poche risorse economiche = tanto tempo investito (girare, comunicare, produrre contenuti); poco tempo = uso di acceleratori a pagamento (advertising, una segretaria che fissa gli appuntamenti). L&#39;equilibrio dipende dalla situazione di partenza.</li>
<li><strong>Obiettivo dell&#39;evento</strong>: un evento a pagamento monetizza e profila i partecipanti; un evento gratuito è un investimento sull&#39;acquisizione. Sbagliare a definire l&#39;obiettivo iniziale porta a valutare male il risultato.</li>
<li><strong>Un progetto alla volta</strong>: chi lavora e ha tempo limitato dovrebbe avviarne uno solo, portarlo a regime e delegarlo, poi passare al secondo.</li>
</ul>
<h2>Sviluppo della sessione</h2>
<h3>Apertura: che cos&#39;è l&#39;Accelerator e le regole della casa</h3>
<p>Massimo apre spiegando la natura di questo nuovo ciclo di incontri. L&#39;Accelerator è un appuntamento mensile — molto probabilmente il martedì sera alle 20:30, con la possibilità di aggiungerne altri o farne anche di mattutini se servirà — in cui si analizza il progetto di business di uno o più iscritti e si dà una linea guida operativa. La base è la sua esperienza da imprenditore nel settore della salute e da fondatore di start-up (è alla quarta). Ci tiene a un punto: vuole che l&#39;Accelerator diventi un confronto dinamico e continuativo, in cui i partecipanti portano un aggiornamento, ricevono un&#39;indicazione, la applicano e il mese successivo tornano con il feedback. Racconta che questo stesso modello è stato ciò che lo ha aiutato di più quando è partito nel 2020: una volta al mese si confrontava con dieci-quindici persone (è lì che conobbe una persona di cui riporta l&#39;aneddoto), portava quello che aveva fatto e riceveva consigli; piccoli dettagli — come alzare l&#39;investimento pubblicitario su Facebook da 20 a 200 euro al giorno visti i risultati — hanno fatto la differenza.</p>
<p>Le regole della casa: qui si parla solo di business e sviluppo di progettualità, mai di parte tecnica; ognuno ha un paio di minuti per non monopolizzare la sessione; chi vuole un confronto privato può richiedere una consulenza a parte. Il senso ultimo dell&#39;incontro è dichiarato senza giri di parole: nel mondo della salute i professionisti sono spinti a fare corsi su corsi che aumentano il loro valore tecnico, ma questo valore non è proporzionale al valore economico percepito. Massimo non vuole che l&#39;accademia di biohacking diventi &quot;l&#39;ennesimo bellissimo corso tecnico&quot; che porta valore ma che nessuno capitalizza.</p>
<h3>La prima domanda: partire da zero (target e nicchia)</h3>
<p>Un partecipante chiede come raggiungere i clienti, online e sul territorio, partendo da zero e avendo già una professione attuale che non riguarda la salute. Massimo individua due ostacoli: la mancanza di autorevolezza in un settore nuovo e la mancanza di chiarezza sui primi passi. La risposta apre subito il tema centrale della serata. La prima domanda a cui rispondere è: a quale target ci si rivolge? Il primo problema del 90% dei partecipanti — dice, guardandoli online — è non avere chiaro il target specifico, inteso come il bisogno principale che spinge il cliente a rivolgersi a loro. Serve definire la nicchia (chi è il cliente, quanti anni ha, qual è il suo bisogno), cioè la buyer persona.</p>
<p>Da qui, alcuni miti da sfatare. Primo: &quot;biohacker&quot; non è una professione compresa dalle persone; dirlo non comunica nulla. Secondo: le persone non vogliono che tu parli di che cosa fai, vogliono che parli di come risolvi il loro problema. Chi si presenta come &quot;coach del sonno&quot; non viene capito; chi dice &quot;aiuto le persone a risolvere l&#39;insonnia, ad addormentarsi, a non svegliarsi ogni notte alle tre&quot; viene capito immediatamente.</p>
<h3>I bisogni che davvero muovono le persone</h3>
<p>Massimo fornisce una mappa dei bisogni su cui un esperto di ottimizzazione fisica può costruire. Il più grande è la <strong>stanchezza</strong>: la maggior parte delle persone la percepisce, cronica o no, come calo di energia con l&#39;avanzare dell&#39;età, ed è uno dei sintomi che più spinge a intraprendere un percorso. Il secondo è il <strong>sonno</strong>: tema molto sentito e ottimo per farsi conoscere, ma difficile da monetizzare perché in pochi sono disposti a spendere per sistemarlo. Il terzo è quello dei <strong>problemi intestinali</strong> (gonfiore, disbiosi, stitichezza): non serve essere medici per parlarne, e c&#39;è tutto un tema olistico collegato — nervo vago, stress — affrontabile senza atti medici.</p>
<p>Attenzione a due bisogni &quot;insidiosi&quot;. Lo <strong>stress</strong> non è percepito direttamente: le persone o si dichiarano stressate senza sapere cosa significhi, o negano di esserlo pur vivendo uno stress cronico; è quindi difficile da usare come leva comunicativa diretta. Il <strong>dolore</strong>, invece, è la leva più potente in assoluto, ed è il grande vantaggio di chi ha un&#39;attività manuale (fisioterapisti, osteopati, massaggiatori): il dolore muove le persone come nient&#39;altro. Da qui la regola: le persone agiscono per dolore o per ispirazione, ma chi si muove per ispirazione è meno del 10%. Ecco perché i contenuti &quot;ispirazionali&quot; (i 5 consigli per dormire meglio) non convertono, mentre &quot;come ti risolvo il risveglio notturno&quot; sì.</p>
<h3>Il meccanismo della soluzione</h3>
<p>Definito il target, si crea un metodo di lavoro proprio — una consulenza, un modello digitale, una visita iniziale con pacchetto di consulenze — ma soprattutto quello che Massimo chiama il <strong>meccanismo della soluzione</strong>: un modello che nella testa del cliente suoni come &quot;ho provato di tutto, ma questa cosa no&quot;. L&#39;esempio: chi non dorme ha provato pastiglie e rimedi vari, ma non ha provato &quot;quel metodo lì&quot;; oppure chi ha fatto tutte le diete possibili e si sente proporre una dieta a cui non aveva pensato. Il meccanismo della soluzione è ciò che rende l&#39;offerta diversa e credibile, e a quel meccanismo deve corrispondere una reale risoluzione del problema.</p>
<h3>Online o offline: da dove partire</h3>
<p>Ci sono due modelli per divulgare il proprio meccanismo. L&#39;<strong>online</strong> attira di più ed è più facile da iniziare (bastano un po&#39; di spigliatezza e qualche video), ma è lento se non ci si mette budget, richiede competenze specifiche di comunicazione e advertising, e funziona molto meglio se si mette la faccia (il personal brand è sempre più forte di un nome inventato). Massimo porta l&#39;esempio dello studio odontoiatrico della moglie (profilo Instagram citato come &quot;gmsmile&quot;): pubblica ogni giorno con costanza, ma dalla sola pubblicazione organica sono arrivate due persone; i 35 nuovi appuntamenti del mese vengono dal traffico a pagamento gestito da lui. Fare advertising bene richiede expertise: budget definito (nell&#39;esempio, circa 750 euro al mese), azioni note, ritorno misurato, KPI sotto controllo. Chi parte online non deve aspettarsi risultati in 1-3 mesi senza una strategia organica e pubblicitaria ben costruita (pubblicare ogni giorno, fare storie, avere una logica di call to action).</p>
<p>Per questo Massimo consiglia quasi sempre di iniziare <strong>offline</strong>: più veloce nell&#39;avviamento, richiede meno esperienza (a parte &quot;alzarsi e andare a parlare con le persone&quot;) e un minimo di strategia organizzativa; è meno scalabile, ma permette di avviare l&#39;attività. Prima però va definito cosa significa &quot;avviare&quot;: guadagnare 500 euro al mese o 2000? Bisogna darsi un tetto iniziale e un obiettivo di sopravvivenza (ad esempio 1500 euro al mese per un certo numero di mesi). Per raggiungere in fretta quella cifra, partendo da zero e senza competenze online, la via più rapida è l&#39;offline. Il punto vale per chiunque lanci un progetto nuovo, anche il chirurgo più famoso: Massimo cita la propria consulenza per una storica struttura alberghiera di lusso, che pur non avendo problemi di clientela fatica a sviluppare il biohacking al suo interno, semplicemente perché ogni progetto nuovo è di fatto una start-up e richiede un certo tipo di &quot;trazione&quot;.</p>
<h3>Acquisizione offline: lead magnet, open day, HRV</h3>
<p>Muoversi offline significa partire dal target scelto e andare da chi ha già un contatto con le persone: nutrizionisti, personal trainer, fisioterapisti, medici di medicina funzionale, erboristerie, farmacie, palestre, centri estetici. Ci si presenta con una brochure o una presentazione e un&#39;offerta d&#39;ingresso, che di solito deve essere gratuita: il <strong>lead magnet</strong> — un open day, un primo check-up gratuito, un&#39;analisi dello stress gratuita — consapevoli che dopo quella cosa deve succedere qualcos&#39;altro (una prima offerta). Evitando la parola &quot;biohacking&quot; (che non viene capita) e parlando invece di ottimizzazione fisica, benessere, problemi di sonno.</p>
<p>Un esempio concreto: proporsi in palestra con un open day di crioterapia. Non basta portare la vasca e &quot;fare la crio&quot;. Serve un modulo di iscrizione con nome e numero; prima della crio si fa sempre l&#39;HRV, che Massimo ribattezza &quot;stress test&quot; perché &quot;HRV&quot; non dice nulla al cliente; se lo stress test rileva uno stress cronico, si fissa già una consulenza gratuita di approfondimento (&quot;ti spiego meglio questa analisi, sono uscite delle cose&quot;). Dopo la crio si raccoglie il feedback e si porta la persona in consulenza — non serve che paghi subito, all&#39;inizio conta avviare. E in consulenza bisogna sapere già cosa proporre: un check-up, un percorso pratico a X euro, un percorso mensile, un ibrido. Nel suo centro, quando arriva una persona, Massimo sa già cosa proporre (crioterapia, un pacchetto interno, un mese di percorso). L&#39;errore più frequente è fare la serata per &quot;parlare&quot; senza nemmeno raccogliere i contatti e senza un&#39;offerta successiva: &quot;una volta era così, adesso non funziona più&quot;.</p>
<h3>No show e follow-up: seguire le persone</h3>
<p>Massimo insiste su un dato di mercato: in un&#39;attività nuova il tasso di no show (persone che prenotano e non si presentano) supera quasi il 30% — uno su tre. Accade in tutti i settori della salute, e in forme minori ovunque: le compagnie aeree hanno circa il 12% di no show (per questo fanno overbooking), gli eventi il 18% (al proprio Biohackers World hanno venduto quasi il 20% di biglietti in più rispetto ai posti). La conseguenza operativa: le persone vanno seguite, in senso buono — accompagnate, ricordate, aiutate a capire il valore del percorso. Chi organizza qualcosa deve starci dietro: chiamare il giorno dopo, fissare, richiamare. È il lavoro di attrazione e presidio che nel 2025 (e sempre di più) determina il successo.</p>
<h3>Bisogno prima del target: il caso della coach del respiro</h3>
<p>Una partecipante, personal trainer che vuole attivarsi come &quot;coach del respiro&quot;, chiede se debba scegliere un target specifico (atleti amatoriali, agonisti, imprenditori) o possa tenerli insieme. Massimo rovescia la domanda: non &quot;chi è il tuo cliente&quot; per categoria, ma &quot;che problema risolvi&quot;. Emerge che il bisogno comune è migliorare concentrazione ed energia — per l&#39;atleta come per l&#39;imprenditore. La sintesi proposta: &quot;aiuto le persone ad aumentare la loro concentrazione ogni giorno, tramite il respiro e l&#39;allenamento&quot;, racchiuso in un metodo proprio (allenamento + tecniche di respirazione + coaching). Il principio: è più facile lavorare sul bisogno che sul target, perché il target giusto (anche la signora che non è imprenditrice ma vuole più attenzione) si avvicina di conseguenza. La scrematura del cliente si fa dopo — con la visita iniziale, e correggendo eventualmente le parole e il tono della comunicazione — non verticalizzando troppo dall&#39;inizio, perché più si restringe il target più cresce l&#39;investimento richiesto di tempo, denaro e attenzione. &quot;Sono X, aiuto le persone ad avere più energia&quot; costa molto meno di &quot;aiuto gli imprenditori a...&quot;.</p>
<h3>Front-end e back-end: il caso del centro estetico</h3>
<p>Una partecipante ha inserito le proprie consulenze in un centro estetico (e sulla piattaforma di prenotazione di servizi estetici Treatwell) usando un linguaggio troppo tecnico-scientifico: nomi come &quot;consulenza di longevità estetica&quot;, &quot;detox cellulare&quot;, &quot;gestione dello stress&quot;, descrizioni fitte di termini come &quot;rigenerazione cellulare, equilibrio ormonale, gestione infiammatoria&quot;. Massimo corregge: il problema non è che sia &quot;troppo scientifico&quot;, è che non dice cosa risolve. Nessuno cerca &quot;detox cellulare&quot; o &quot;longevità estetica&quot;: la persona sente di essere gonfia, stanca, di avere la pelle spenta, di essersi &quot;scrofanata&quot; e di aver bisogno di &quot;pulirsi&quot;. La comunicazione va agganciata a quel vissuto: &quot;hai notato che negli ultimi cinque anni la tua pelle è cambiata? Potrebbe essere un invecchiamento precoce che non dipende solo da ciò che metti fuori, ma da ciò che succede dentro. Con la nostra consulenza andiamo a capire l&#39;origine&quot;.</p>
<p>Da qui la distinzione dei due livelli. La <strong>comunicazione di front-end</strong> è la prima cosa che il cliente vede: parla solo del problema e di ciò che le persone vogliono, e ha l&#39;unico scopo di portare a un&#39;azione — la classica call to action (prenotare una consulenza, scaricare un ebook, acquistare). La <strong>comunicazione di back-end</strong> arriva dopo, quando si è instaurato un rapporto uno-a-uno: solo lì si spiega, con un linguaggio un po&#39; più tecnico, come funziona il metodo, come lavora il corpo, perché è comparso quel problema. Nel front-end non si parla di detox né di meccanismi cellulari: si parla solo del problema.</p>
<h3>La consulenza: struttura, durata, vendita</h3>
<p>Sulla stessa domanda Massimo apre il tema della consulenza. La sua posizione: qualsiasi azione di front-end deve essere rivolta a un&#39;azione di vendita successiva; una consulenza fatta &quot;solo per incuriosire&quot; è una perdita di tempo (per incuriosire basta regalare un ebook). Se la consulenza è finalizzata a una vendita, per esperienza sotto i 45 minuti non si riesce, perché ci sono flussi di ragionamento da fare con la persona; lui si tiene sui 45 minuti-un&#39;ora (fino a un&#39;ora e un quarto se include test e spiegazione delle analisi), alcuni collaboratori arrivano a un&#39;ora e mezza-due ore. L&#39;azione resta tutta orientata a proporre qualcosa alla fine — restando etici: se il cliente non è &quot;educato&quot;/pronto non si forza la vendita, ma lo si indirizza comunque a un&#39;azione successiva.</p>
<p>Alla partecipante che aveva impostato consulenze da 30 minuti a 20 euro senza dare protocollo, Massimo consiglia di allungare i tempi e già indirizzare verso un&#39;offerta. Non c&#39;è una regola assoluta (far pagare o no la prima consulenza, dare o meno un mini-protocollo): va testato sul proprio mercato, ad esempio su 20 persone a pagamento e 20 gratuite, guardando cosa converte meglio — &quot;sono sempre i numeri che parlano&quot;. Aggiunge un metodo che usa lui stesso: ogni tanto fa pubblicità come fisioterapista senza usare il proprio brand, per capire come ragionano le persone e cosa converte senza sfruttare la propria autorevolezza. Nota anche il trade-off del pagamento: chi paga la prima consulenza è più propenso a riacquistare, ma se non si ha massa critica si rischiano numeri troppo bassi; il gratuito porta più persone ma con tasso di conversione più basso e più effort.</p>
<h3>Come si costruisce il prezzo</h3>
<p>Un partecipante chiede se una consulenza a 20 euro venga percepita come meno seria di una a 50. Massimo risponde che il tema prezzi è più complesso di quanto sembri, perché il prezzo dipende da tre componenti. Il <strong>valore emotivo</strong>: quanta motivazione ha l&#39;acquisto per la persona — ed è la ragione per cui insiste tanto sul partire dai problemi, perché lì si concentra la maggior parte del valore percepito. Il <strong>valore funzionale</strong>: l&#39;utilità concreta della cosa, che nelle consulenze è spesso bassa e va migliorata. Il <strong>valore opzionale</strong>: quante cose/opzioni si ricevono con l&#39;acquisto (l&#39;analisi della pelle, ulteriori valutazioni, ecc.). Nel personal brand l&#39;emotività è legata alla persona stessa. Occorre lavorare su tutte e tre le componenti e trovare lo sweet spot testando più prezzi e osservando come risponde il mercato.</p>
<h3>Tempo o denaro: su cosa investire</h3>
<p>A chi chiede su cosa investire all&#39;inizio, in tempo ed economicamente, Massimo indica due strade dipendenti dalla situazione di partenza. Chi non vuole investire denaro può farlo, ma deve investire tanto tempo: girare, parlare, comunicare, produrre contenuti, con una scaletta di programmazione chiara. Chi ha qualche migliaio di euro può usare <strong>acceleratori</strong>: la pubblicità su Facebook, oppure una segretaria che chiama e fissa gli appuntamenti. Va comunque valutato come si investe il tempo: se l&#39;advertising porta dieci lead al giorno, qualcuno deve richiamarli (un paio d&#39;ore al giorno), altrimenti serve una persona in più, che è un altro costo. È tutto un discorso di budgeting.</p>
<p>Massimo mostra la matematica dell&#39;online. Con un target ben definito e una buona comunicazione, un lead (una persona che &quot;alza la mano&quot;) costa in media circa 10 euro per un principiante (dai 3 ai 15; con più esperienza anche 2). Investendo 100 euro al giorno arrivano circa 10 contatti: 5 non rispondono, ai 5 rimanenti si propone qualcosa, se ne fissano 3, se ne converte 1. Se a quell&#39;uno si vende una visita da 100 euro, l&#39;acquisizione è costata quanto l&#39;investimento (spesa netta zero) ma si è ottenuto un cliente che potrà tornare a pagare. Il &quot;giochino&quot; però comporta 10 chiamate, cioè circa un&#39;ora-un&#39;ora e mezza al giorno di lavoro all&#39;inizio. Il consiglio pratico: trovare una collaborazione che permetta di sopravvivere e iniziare a giocare, poi reinvestire progressivamente anche sull&#39;online.</p>
<h3>Eventi: monetizzare o acquisire</h3>
<p>Una partecipante racconta due eventi organizzati con una collega (uno su &quot;sonno e recupero&quot; a 37 euro, uno di crioterapia a 97 euro per coprire i costi di vasche e ghiaccio), lamentando poche iscrizioni finora. Massimo dà diversi consigli. Primo: è normale, perché le persone si iscrivono negli ultimi tre-quattro giorni prima dell&#39;evento; da due iscritti si arriverà probabilmente a quindici-venti, ma vanno ricordati e sollecitati. Secondo: l&#39;evento va comunicato in modo pratico e poco &quot;teorico&quot; — non &quot;parliamo di recupero&quot; ma &quot;vieni che ti insegno una tecnica di respirazione per velocizzare il recupero&quot;; la gente non si muove per ascoltare una relazione teorica, si muove per imparare/fare qualcosa, e la parte teorica la si dà comunque una volta che le persone sono lì.</p>
<p>Il punto centrale, però, è l&#39;obiettivo dell&#39;evento. Se l&#39;obiettivo è <strong>monetizzare</strong> l&#39;evento stesso (e creare un format replicabile sul territorio, che costruisce brand), allora far pagare il biglietto è corretto e per di più profila i partecipanti, selezionando persone più in linea e interessate. Se invece l&#39;obiettivo è <strong>acquisire clienti</strong> per vendere dopo un percorso, allora l&#39;evento andava reso gratuito, come investimento sull&#39;acquisizione, mettendo a budget la spesa (esempio: 1000 euro per portare 30 persone, di cui convertirne 10 a 100 euro per recuperare l&#39;investimento). Sbagliare a definire l&#39;obiettivo iniziale porta a valutare male il risultato: &quot;saranno i numeri a dirci se è fatto bene&quot;. Massimo suggerisce anche di sfruttare il primo evento per creare riprova sociale — invitare amici per mostrare affluenza, raccogliere immagini e recensioni specifiche da usare nella pubblicità futura — trattandolo però come asset secondario rispetto all&#39;obiettivo primario di costruire autorevolezza. Alla partecipante che teme una sala vuota suggerisce, come rete di sicurezza, di regalare il biglietto ad alcuni clienti pochi giorni prima se le iscrizioni non decollano.</p>
<h3>Vendere percorsi, non singole sedute: il terapista manuale</h3>
<p>Un partecipante, terapista manuale, ha creato un protocollo (massaggio più fotobiomodulazione integrato con strategie che ha chiamato &quot;di ottimizzazione&quot; invece che &quot;biohacking&quot;), rivolto a chi vuole risolvere stanchezza, dolore e rigidità muscolari negli over 40, ma &quot;non lo caga nessuno&quot;: le persone prenotano solo il massaggio e nessuno è interessato al percorso. Massimo individua due nodi. Primo, la fonte da cui arrivano i clienti: se vengono da una comunicazione centrata sul massaggio, non ci si può aspettare che conoscano la parte del percorso; e proprio perché non sa da dove originano i suoi dati, non può dire se il metodo &quot;non funziona&quot; — l&#39;unico modo è testarlo con traffico a pagamento sui video specifici che parlano dello stile di vita e del percorso, per capire da dove viene davvero il cliente.</p>
<p>Secondo, il modello di vendita. Si tratta di vendita telefonica (quando la persona prenota) e di vendita in presenza (quando arriva). Già in fase di prenotazione deve essere chiaro che il terapista lavora in un certo modo; l&#39;ideale, per i terapisti manuali, è creare prima del primo massaggio una consulenza iniziale (&quot;io non lavoro così, prima faccio un&#39;analisi completa dello stile di vita&quot;). Se il cliente vuole solo il massaggio contratturante, è una scelta legittima accettarlo o rifiutarlo. Un modello che a Massimo funziona bene testandolo su di sé: fare il primo massaggio, poi regalare un ritorno per i soli test (&quot;sei molto stressata, ho un&#39;analisi dello stress che ti fa capire il sistema&quot;), e da lì proporre un percorso più strutturato. In un altro approccio, prima ancora di iniziare a massaggiare, offre due opzioni: un massaggio che finisce lì (magari se ne fanno 3-4), oppure andare all&#39;origine del problema lavorando su abitudini, stile di vita e infiammazione sistemica — con circa uno su tre che sceglie il percorso di biohacking, sempre partendo da una consulenza iniziale (l&#39;anamnesi).</p>
<h3>Un progetto alla volta: il caso dell&#39;osteopata</h3>
<p>Un partecipante osteopata descrive due progetti paralleli: da un lato un luogo fisico dove svolgere attività in presenza (che richiede trovare la sede e costruire un team), dall&#39;altro un format — che pensa di chiamare &quot;osteo-coaching&quot; — rivolto agli osteopati, con percorsi di monitoraggio e biohacking per ottimizzarne qualità della vita e prestazioni lavorative; quest&#39;ultimo potenzialmente anche interamente online. Massimo, appurato che il partecipante lavora e ha tempo limitato, è netto: sceglierne uno solo, partire con quello, portarlo a regime e poi passare al secondo. Farne due insieme significa farli male. Nel dettaglio, poiché il luogo fisico è già in parte avviato (ci sono già clienti e location), conviene partire ottimizzando quello — creando deleghe, procedure e team fino a poterlo delegare, riducendo così il proprio carico — e solo dopo lanciare l&#39;osteo-coaching, che ha più senso avviare dopo aver dimostrato che il metodo funziona sui clienti (un enorme vantaggio nel proporlo poi ai professionisti). In ogni caso, una cosa alla volta.</p>
<h3>Il target demografico reale del settore</h3>
<p>Rispondendo a una curiosità sul proprio target, Massimo lo descrive: cliente tra i 35 e i 55 anni, principalmente donna, libera professionista o autonoma, con tema principale la stanchezza, la percezione di un corpo cambiato/invecchiato e, molto sentito, la &quot;nebbia mentale&quot; (più che un calo di attenzione, una difficoltà a pensare con lucidità). Nota però una dinamica di mercato interessante: i servizi e i percorsi consulenziali attraggono più le donne, mentre i percorsi formativi (come l&#39;accademia di biohacking) e gli eventi tecnici attraggono più gli uomini. La proporzione varia molto con la comunicazione: parlando di invecchiamento il pubblico era prevalentemente femminile; aprendo l&#39;accademia è diventato più maschile. Il tipo di offerta e di comunicazione, quindi, determina il target che si attrae; chi parte deve scegliere un&#39;unica nicchia e una comunicazione coerente.</p>
<h2>Protocolli e azioni pratiche</h2>
<ul>
<li><strong>Definisci la nicchia e la buyer persona</strong> prima di ogni altra cosa: chi è il cliente, che età ha, e soprattutto qual è il bisogno principale che lo muove.</li>
<li><strong>Comunica il problema, non la tecnica</strong>: sostituisci termini come &quot;biohacker&quot;, &quot;coach del sonno&quot;, &quot;detox cellulare&quot;, &quot;longevità estetica&quot; con il vissuto del cliente (&quot;non ti svegli più alle tre&quot;, &quot;ti senti gonfio e stanco&quot;, &quot;la pelle è cambiata negli ultimi anni&quot;).</li>
<li><strong>Parti dal dolore o dal bisogno percepito</strong>, non dall&#39;ispirazione: i contenuti che convertono risolvono un problema specifico, non danno &quot;5 consigli&quot;.</li>
<li><strong>Costruisci un meccanismo della soluzione</strong> riconoscibile e diverso da ciò che il cliente ha già provato.</li>
<li><strong>Se parti da zero senza competenze digitali, inizia offline</strong>: presentazione/brochure, giro tra palestre, nutrizionisti, fisioterapisti, farmacie, erboristerie, centri estetici.</li>
<li><strong>Usa un lead magnet gratuito</strong> (open day, primo check-up, analisi dello stress) sapendo già quale offerta proporre subito dopo.</li>
<li><strong>Ribattezza i termini tecnici in chiave cliente</strong>: l&#39;HRV diventa &quot;stress test&quot;.</li>
<li><strong>Raccogli sempre i contatti</strong> a ogni evento/serata e abbi pronta un&#39;offerta successiva: senza, non si muove nessuno.</li>
<li><strong>Metti in conto un no show &gt;30%</strong> in un&#39;attività nuova e organizza il follow-up (chiamare, ricordare, richiamare).</li>
<li><strong>Separa la comunicazione front-end (solo problema → call to action) dal back-end</strong> (spiegazione tecnica nel rapporto uno-a-uno).</li>
<li><strong>Progetta la consulenza per portare a un&#39;azione di vendita</strong>; se è finalizzata alla vendita, prevedi almeno 45-60 minuti.</li>
<li><strong>Testa tutto sui numeri</strong>: prezzo (20 vs 50 euro), gratuito vs a pagamento, mini-protocollo sì/no, su campioni di persone; decidi in base alla conversione.</li>
<li><strong>Ragiona il prezzo su tre leve</strong>: emotiva, funzionale, opzionale; trova lo sweet spot testando.</li>
<li><strong>Scegli la strada tempo o denaro</strong> in base alla tua situazione: molto tempo e zero budget, oppure budget su acceleratori (advertising, segretaria) con meno tempo.</li>
<li><strong>Definisci l&#39;obiettivo di ogni evento prima di farlo</strong>: monetizzare (biglietto a pagamento, che profila) oppure acquisire (gratuito, investimento con budget e obiettivo di conversione).</li>
<li><strong>Sfrutta il primo evento per riprova sociale</strong>: affluenza, immagini, recensioni specifiche da usare nella pubblicità.</li>
<li><strong>Per i terapisti manuali</strong>: metti una consulenza iniziale prima del primo massaggio, o proponi due opzioni (singola seduta vs percorso), e rendi chiaro il tuo modo di lavorare già in fase di prenotazione.</li>
<li><strong>Non dire &quot;non funziona&quot; senza dati</strong>: testa con traffico a pagamento sui contenuti specifici per capire da dove arriva davvero il cliente.</li>
<li><strong>Porta avanti un solo progetto alla volta</strong>: avvialo, portalo a regime, delegalo, poi passa al secondo.</li>
<li><strong>Parti dal progetto già più avanzato</strong> e, se possibile, valida il metodo sui clienti prima di proporlo ai professionisti.</li>
</ul>
<h2>Glossario</h2>
<ul>
<li><strong>Accelerator (hot seat)</strong>: sessione mensile di coaching di business in cui si analizza il progetto di un partecipante e si danno linee guida operative.</li>
<li><strong>Buyer persona</strong>: descrizione dettagliata del cliente ideale (età, professione, bisogni, ambizioni) usata per orientare comunicazione e offerta.</li>
<li><strong>Nicchia di mercato</strong>: segmento specifico di clienti a cui ci si rivolge, definito soprattutto dal bisogno principale che li muove.</li>
<li><strong>Meccanismo della soluzione</strong>: il metodo/modello riconoscibile e differenziante che rende l&#39;offerta diversa da ciò che il cliente ha già provato.</li>
<li><strong>Lead</strong>: contatto interessato, una persona che &quot;alza la mano&quot; chiedendo di saperne di più.</li>
<li><strong>Lead magnet</strong>: sistema di acquisizione gratuito (open day, check-up gratuito, analisi dello stress) che attira il contatto in vista di un&#39;offerta successiva.</li>
<li><strong>Call to action</strong>: l&#39;azione che la comunicazione chiede di compiere (prenotare, scaricare, acquistare).</li>
<li><strong>Front-end (comunicazione)</strong>: primo livello comunicativo, centrato sul problema, il cui unico scopo è portare a un&#39;azione.</li>
<li><strong>Back-end (comunicazione)</strong>: secondo livello, nel rapporto uno-a-uno, in cui si spiega in modo più tecnico come funziona il metodo.</li>
<li><strong>No show</strong>: percentuale di persone che prenotano un appuntamento/evento e non si presentano.</li>
<li><strong>KPI (Key Performance Indicator)</strong>: indicatori numerici usati per misurare il ritorno delle azioni (es. costo per lead, tasso di conversione).</li>
<li><strong>Advertising / traffico a pagamento</strong>: pubblicità a pagamento (es. Facebook/Instagram) usata per generare lead in modo rapido e misurabile.</li>
<li><strong>Personal brand</strong>: identità professionale costruita sulla persona; secondo Massimo converte più di un nome/marchio inventato.</li>
<li><strong>HRV (Heart Rate Variability)</strong>: variabilità della frequenza cardiaca, indicatore dello stato di stress; comunicata al cliente come &quot;stress test&quot;.</li>
<li><strong>Sweet spot (di prezzo)</strong>: il livello di prezzo che massimizza valore percepito e conversione, individuato testando.</li>
<li><strong>Valore emotivo / funzionale / opzionale</strong>: le tre componenti che determinano il prezzo — motivazione all&#39;acquisto, utilità concreta, numero di opzioni ricevute.</li>
<li><strong>Acceleratore (di business)</strong>: leva che velocizza l&#39;avviamento a fronte di un costo (advertising, una figura che fissa gli appuntamenti).</li>
<li><strong>Fotobiomodulazione</strong>: tecnica basata sull&#39;uso della luce a fini terapeutici, citata come componente di un protocollo di trattamento.</li>
<li><strong>Riprova sociale</strong>: prova (affluenza, recensioni, immagini) che altre persone hanno già scelto/apprezzato il servizio, usata per aumentare la credibilità.</li>
<li><strong>Legge 4/2013</strong>: normativa italiana sulle professioni non organizzate in ordini o collegi, richiamata nell&#39;inquadramento della figura dell&#39;operatore del benessere.</li>
<li><strong>Osteo-coaching</strong>: format ipotizzato da un partecipante, percorso di monitoraggio e biohacking rivolto agli osteopati.</li>
</ul>
<h2>Domande affrontate</h2>
<ul>
<li>Come raggiungere i clienti, online e sul territorio, partendo da zero e con una professione attuale che non riguarda la salute?</li>
<li>Un personal trainer che si attiva come &quot;coach del respiro&quot; deve scegliere un target specifico (atleti, imprenditori) o concentrarsi sul bisogno? Come descriversi in una frase?</li>
<li>In un centro estetico, il linguaggio delle mie consulenze (&quot;longevità estetica&quot;, &quot;detox cellulare&quot;) è troppo scientifico? Come vanno rinominate e descritte?</li>
<li>La consulenza iniziale va fatta gratuita o a pagamento, e per quanto tempo? 30 minuti a 20 euro sono sufficienti?</li>
<li>Una consulenza a 20 euro viene percepita come meno seria di una a 50? Il prezzo cambia la percezione di valore?</li>
<li>Su cosa conviene investire all&#39;inizio, tempo o denaro?</li>
<li>Un evento (sonno/recupero a 37 euro, crioterapia a 97 euro) con poche iscrizioni: cosa non sta funzionando e conveniva farlo a pagamento o gratuito?</li>
<li>Un protocollo di massaggio + percorso di ottimizzazione non vende: le persone prenotano solo la singola seduta. Come portarle al percorso?</li>
<li>Avendo due progetti in parallelo (un luogo fisico e un format di osteo-coaching) e poco tempo, da quale partire?</li>
<li>Qual è il target reale del settore e perché servizi ed eventi attraggono generi diversi?</li>
</ul>
<h2>Da approfondire</h2>
<ul>
<li><strong>Buyer persona e definizione della nicchia</strong>: metodologie per profilare il cliente ideale a partire dal bisogno prima che dalla demografia.</li>
<li><strong>Meccanismo della soluzione (unique mechanism)</strong>: concetto di marketing a risposta diretta; approfondire come costruirne uno credibile e differenziante.</li>
<li><strong>Front-end / back-end e funnel di acquisizione</strong>: strutturare il percorso dal primo contatto (call to action) alla vendita del percorso.</li>
<li><strong>Advertising su Meta (Facebook/Instagram)</strong>: costruire una strategia organica + a pagamento, definire budget, misurare costo per lead e KPI (temi che Massimo rimanda a sessioni successive).</li>
<li><strong>Costruzione del prezzo (value-based pricing)</strong>: le tre leve emotiva/funzionale/opzionale e il test di più fasce di prezzo per trovare lo sweet spot.</li>
<li><strong>Gestione del no show e follow-up</strong>: tecniche di sollecito, promemoria e overbooking mutuate da settori con no show noto (aerei, eventi).</li>
<li><strong>Lead magnet e open day nel settore benessere</strong>: format di acquisizione gratuiti (check-up, analisi dello stress/HRV) e collegamento con l&#39;offerta successiva.</li>
<li><strong>HRV come strumento commerciale e di monitoraggio</strong>: uso dell&#39;analisi della variabilità cardiaca come &quot;stress test&quot; nell&#39;imbuto di vendita.</li>
<li><strong>Modelli di vendita per terapisti manuali</strong>: consulenza iniziale pre-trattamento e proposta a due opzioni (singola seduta vs percorso).</li>
<li><strong>Costruzione di un team e delega</strong>: procedure, deleghe e ottimizzazione di un&#39;attività fisica prima di avviarne una seconda.</li>
<li><strong>Legge 4/2013</strong>: inquadramento normativo della figura di operatore del benessere/consulente non sanitario.</li>
<li><strong>Riprova sociale e raccolta recensioni</strong>: strategie per generare materiale pubblicitario dai primi eventi.</li>
</ul>

Some files were not shown because too many files have changed in this diff Show More