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>
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>
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>
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>
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
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
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
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>
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>
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>
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
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
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
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
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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
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
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
"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
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
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
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
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
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
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
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
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
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
Adriano
Adriano Dal Pastro