longevity: aprire e correggere un check-up passato #12
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
COSA: il trainer apre un check-up passato (dettaglio con tutte le misure) e lo corregge.
PERCHÉ: richiesta di Nicola (call 27/09, min 18:45): «se hai un check-up vecchio non riesci ad aprirlo e modificarlo, se per caso ho sbagliato a scrivere». Oggi le righe della tabella Sessioni in pages/longevity/gestionale/cliente/[code].astro non sono cliccabili; salvaCheckup (lib/longevity/gestionale.ts) apre solo sessioni nuove; l'unica correzione è Conferma/Scarta dei fuori range (#7).
COME: pagina /longevity/gestionale/cliente/[code]/sessione/[id] con le misure; "Modifica" riapre il modulo precompilato; al salvataggio si ricalcolano e ricongelano quella sessione e le successive (stesso meccanismo del ricalcolo di #7).
DECISIONE APERTA (Adriano): sovrascrivere il valore o tenere lo storico della correzione (chi, quando, valore vecchio). Consigliato lo storico: dati sanitari. Una correzione può anche finire nel giornale di bordo del cliente (issue dedicata).
FATTO QUANDO: una misura corretta cambia il referto di quella sessione e delle successive; test sul ricalcolo a cascata; lo storico (se deciso) si vede nel dettaglio.
FONTE: call Adriano–Nicola 27/09/2026, trascrizione e allegati in wasabi:adp-work/AI-OS/projects/azienda/clienti/Insanity_Lab/Longevity_Project/docs/2026-09-27_call/
DECISIONE (Adriano, 27/09/2026): la correzione SOVRASCRIVE il valore, nessuno storico. Salvando si riscrivono le misure della sessione e si ricalcolano quella sessione e le successive.
🔵 daitarn — preso in carico 2026-09-27T20:02:05Z
ramo:
lavoro/daitarn· capacità: build-windows, gpuANALISI (passo 1, Opus) — gitea:Adriano/InsanityLab-web#12
RAMO: lavoro/daitarn da origin/main
880c928. Cartella: apps/platforms.DECISIONE: correzione = sovrascrittura, nessuno storico delle misure (Adriano 27/09).
COSA NON VA: sessioni passate non apribili (righe della tabella Sessioni in src/pages/longevity/gestionale/cliente/[code].astro senza link); salvaCheckup (src/lib/longevity/gestionale.ts:67) apre solo sessioni nuove.
MODIFICHE
a.
misureDellaSessione(db, sessioneId)→ { id, client_code, data, tipo, operatore, misure: [{ id, test_id, etichetta, valore_num, valore_txt, unita, fonte, fuori_range, verifica }] } | null. Etichetta dal registro (JOIN registro_test). Ordine: come campiDelCheckup.b.
correggiCheckup(db, { sessioneId, data, eta, operatore, misure: MisuraIn[] })→ EsitoCheckup. Validazioni come salvaCheckup (nessuna misura → errore; solo f_*; test nel registro) + la sessione esiste ed è tipo 'checkup' (un questionario non si corregge qui → errore). In UNA transazione:· invariato → la riga resta com'è (mantiene verifica/verificata_*);
· cambiato → UPDATE valore_num, unita, fuori_range ricalcolato col range del registro, verifica/verificata_da/verificata_at = NULL, fonte invariata;
· tolto dal form (campo vuoto) → DELETE della riga;
· nuovo → INSERT come registraMisure (fonte 'manuale'). Se serve, estrarre in misure.ts un helper per il calcolo di fuori_range invece di duplicarlo; registraMisure resta l'unico INSERT.
sessione_id→ correggiCheckup, altrimenti salvaCheckup come oggi. client_code per il redirect letto dalla sessione nel DB, mai dal form (stesso principio di verifica.ts); se il client_code del form non coincide con quello della sessione → errore. Redirect: scheda cliente con?corretto=<id>(+fuori=se ce ne sono). Riusa misureDalForm.?sessione=<id>diventa modifica: titolo «Modifica check-up», data e campi precompilati, hiddensessione_id, campi attivi alla data della sessione. Senza parametro: invariato.?corretto=.Accesso: le rotte nuove stanno sotto /longevity/gestionale e /api/longevity/gestionale, già riservate ad admin+trainer (src/lib/auth.ts:74-75). Il cliente non vede niente di nuovo.
TEST (tests/longevity/, vitest, stile di gestionale.test.ts e verifica-misure.test.ts)
NON TOCCARE: motore (src/lib/longevity/motore/*), registro, schema DB (nessuna colonna nuova: serve solo UPDATE/DELETE), verificaMisura, questionario, anagrafica/identity, pagine cliente (/longevity/io, /longevity/progressione).
PROVA: npx vitest run in apps/platforms; npx tsc --noEmit (o astro check come da README); npm run build. Baseline su Windows (daitarn): 257 verdi, 4 rossi per motivi di piattaforma (tests/campus-lib.test.ts resolveAsset, anagrafica.test.ts separatori di percorso, EPERM su cartelle temporanee in gestionale.test.ts e questionario-pagina.test.ts). Nessun rosso nuovo.
ESITO: fatto sul ramo, non in main né in produzione
RIF: gitea:Adriano/InsanityLab-web#12
COSA: controllo finale (passo 3, Opus) del codice Sonnet: il diff fa quello che dice l'analisi e solo quello.
COMMIT (ramo lavoro/daitarn):
19035e6libreria correggiCheckup/misureDellaSessione + fuoriRangeDi;9e566adAPI checkup con sessione_id;6bbfcd8pagina dettaglio sessione, modulo in modifica, link dalla tabella Sessioni.PROVA: apps/platforms
npx vitest run→ 264 verdi, 4 rossi = baseline Windows (campus-lib resolveAsset; anagrafica.test.ts separatori\, segnala solo anagrafica.ts e db.ts già esclusi; EPERM cartelle temporanee x2);npx tsc --noEmit→ 0 errori;npm run build→ ok.VERIFICATO A OCCHIO: ricalcolo da min(data vecchia, data nuova) con id >= sessione corretto in entrambi i versi; client_code per il redirect letto dalla sessione nel DB; pagina di dettaglio 404 per sessione di altro cliente; questionario solo lettura.
LIMITE NOTO: una misura di un test non più attivo alla data della sessione non compare nel modulo e, salvando la correzione, viene cancellata. Oggi non succede (una sola versione del registro); da tenere presente in #13 se si dismettono test (pressione, saturazione): dismettere con data di validità, non cancellare dal registro.
MANCA: via di Adriano per merge su main e deploy (backup DB prima, nessuna migrazione: solo UPDATE/DELETE su tabelle esistenti).
Soluzione
ESITO: fatto, in produzione
RIF: gitea:Adriano/InsanityLab-web#12
COSA: il trainer apre il dettaglio di una sessione (link sulla data nella tabella Sessioni) e corregge un check-up con "Modifica": sovrascrittura senza storico, verifica azzerata sui valori cambiati, campo svuotato = misura cancellata, ricalcolo dei punteggi della sessione e delle successive (anche con cambio data). Questionario in sola lettura.
FILE: apps/platforms/src/lib/longevity/gestionale.ts (misureDellaSessione, correggiCheckup), misure.ts (fuoriRangeDi), pages/api/longevity/gestionale/checkup.ts (sessione_id), pages/longevity/gestionale/cliente/[code]/sessione/[id].astro (nuova), [code]/checkup.astro (modifica), [code].astro (link); test in tests/longevity/gestionale.test.ts e correzione-checkup-api.test.ts.
COMMIT:
19035e6,9e566ad,6bbfcd8— main6bbfcd8.DEPLOY: 27/09/2026 20:17 UTC, /opt/docker/insanitylab-apps pull + docker compose up -d --build. Backup prima: /opt/docker/insanitylab-platforms/backup/20260927T201648Z-pre-12/ (3 DB, integrity ok). Nessuna migrazione.
PROVA: vitest 264 verdi + 4 rossi baseline Windows; tsc 0; build ok; in produzione /login 200, /longevity/gestionale/cliente/ISL-0005/sessione/1 e checkup?sessione=1 → 302 al login (rotte presenti e protette); chunk con correggiCheckup nel container.
NON VERIFICATO: prova da browser loggato (password di trainer-prova solo ad Adriano).
LIMITE: una misura di un test non attivo alla data della sessione si cancella correggendo: in #13 dismettere i test con data di validità.