InsanityLab-web/apps/sito/docs/specs/2026-08-21-longevity-design.md

# IN-SANITY LONGEVITY PROJECT — piattaforma dati cliente

**Data:** 2026-08-21
**Stato:** design approvato, implementazione non iniziata
**Branch:** `feat/longevity` — `main` non viene toccato, nessun deploy
**Committente:** In-Sanity Lab (Nicola Antonelli) — sviluppo Tielogic

---

## 1. Cos'è, e come si chiama

Il nome esiste già e viene dal cliente: **IN-SANITY LONGEVITY PROJECT** è
l'iniziativa — *«servizio premium basato su dati, con monitoraggio
longitudinale»* — e **IN-SANITY LONGEVITY SCORE** è il sistema di punteggio che
ne è il prodotto di punta. Questa piattaforma è l'implementazione software del
primo. Nel codice il nome tecnico è **`longevity`**.

Non è una raccolta di applicazioni separate: è **un fascicolo del cliente**.
Questionario, check-up in sala, Wellness Tower e VALD non sono quattro
sottosistemi, sono **quattro sorgenti che scrivono nello stesso posto**;
dashboard, vista trainer e punteggi sono **viste e funzioni derivate** di quel
posto. È la differenza fra progettare per dati e progettare per schermate, e
determina tutto quello che segue.

## 2. Perimetro

**Dentro:** anagrafica cliente, questionario in pagina, registrazione delle
misure da tutte le sorgenti, motore di calcolo degli score, dashboard cliente,
vista trainer, export per le statistiche.

**Fuori, e per ragioni diverse:**

- **I percentili interni ISL** — non per scelta: la documentazione del cliente
  dichiara che sotto 15 campioni sono inutilizzabili e sotto 30 provvisori.
  Vanno costruiti quando i dati esistono, non prima.
- **Gli 8 indicatori posturali** della Wellness Tower — esistono solo nel PDF
  stampato, non nell'export a 55 colonne. Il cliente li ha già esclusi dallo
  score.
- **Il blocco Trimestre / 2 Mesocicli** — dichiarato aperto dal cliente stesso e
  ancora in analisi da parte sua.
- **Il deploy** — la piattaforma si sviluppa e si prova in locale. Quando mettere
  qualcosa in produzione è una decisione separata, che non appartiene a questo
  documento.

## 3. Collocazione

La piattaforma vive **dentro l'applicazione Astro esistente**, come già fanno
Biohacking Campus e Stress Index. Non è un secondo servizio, non è un secondo
container.

```
src/pages/longevity/         rotte visibili
src/pages/api/longevity/     endpoint
src/lib/longevity/           modello dati, motore, import
tests/longevity/             test
```

Il motivo per cui non è un progetto separato è che l'autenticazione, le sessioni
e l'anagrafica utenti esistono già qui e funzionano in produzione: rifarle altrove
significherebbe mantenerne due.

⚠️ **Il calcolo è in TypeScript, non in Python.** Il motore fornito dal cliente
(`isl_scoring_engine.py`, 537 righe) è aritmetica pura — interpolazioni lineari,
tabelle di soglie, medie pesate — e importa solo `dataclasses` e `typing`: nessuna
libreria numerica. Portarlo in TypeScript costa poco e evita un secondo runtime
dentro un'immagine `node:22-slim` a processo unico. La stessa scelta vale per il
prototipo del questionario, che calcola già in JavaScript: tenere le formule in
due linguaggi è il modo silenzioso di farle divergere.

## 4. I tre database

SQLite, tre file distinti, aperti da connessioni distinte.

| File | Contiene | Non contiene |
|---|---|---|
| `insanitylab.db` | il sito: articoli, contenuti, **utenti e sessioni** | niente di clinico |
| `identity.db` | `client_code` ↔ `user_id`, nome, cognome, nascita, recapiti | nessuna misura |
| `longevity.db` | misure, questionari, punteggi, registro test | **nessun nome, mai** |

La proprietà che ne discende è la richiesta esplicita del cliente del 21/08: *«la
mappatura codice↔nome va tenuta in un posto separato e più ristretto rispetto
all'export usato per le statistiche, così anche chi ha accesso ai dati clinici
non può risalire all'identità»*. Qui l'export per le statistiche **è**
`longevity.db`: già pseudonimizzato per costruzione, senza una funzione di
anonimizzazione che qualcuno debba ricordarsi di chiamare.

**Vincolo di implementazione, verificabile con un test:** esiste **un solo
modulo** che apre insieme `identity` e `longevity`. Nessun altro punto del codice
importa entrambe le connessioni.

## 5. Modello dati

```sql
-- ============ identity.db ============
CREATE TABLE clienti (
  client_code   TEXT PRIMARY KEY,          -- es. 'ISL-0007'
  user_id       INTEGER,                   -- users.id in insanitylab.db (nessuna FK: file diverso)
  nome          TEXT NOT NULL,
  cognome       TEXT NOT NULL,
  data_nascita  TEXT,                      -- ISO; resta QUI, non passa in longevity
  email         TEXT,
  telefono      TEXT,
  created_at    TEXT NOT NULL DEFAULT (datetime('now'))
);
CREATE UNIQUE INDEX idx_clienti_user ON clienti (user_id);

-- ============ longevity.db ============
CREATE TABLE soggetti (
  client_code   TEXT PRIMARY KEY,
  sesso         TEXT NOT NULL CHECK (sesso IN ('M','F')),
  created_at    TEXT NOT NULL DEFAULT (datetime('now'))
);

CREATE TABLE sessioni (
  id            INTEGER PRIMARY KEY AUTOINCREMENT,
  client_code   TEXT NOT NULL REFERENCES soggetti(client_code),
  data          TEXT NOT NULL,
  tipo          TEXT NOT NULL CHECK (tipo IN ('checkup','questionario')),
  eta_alla_data INTEGER,                   -- l'età serve al motore; la data di nascita no
  operatore     TEXT,
  note          TEXT,
  quest_version TEXT,                      -- solo per tipo='questionario'
  created_at    TEXT NOT NULL DEFAULT (datetime('now'))
);
CREATE INDEX idx_sessioni_cliente ON sessioni (client_code, data DESC);

CREATE TABLE misure (
  id            INTEGER PRIMARY KEY AUTOINCREMENT,
  sessione_id   INTEGER NOT NULL REFERENCES sessioni(id) ON DELETE CASCADE,
  client_code   TEXT NOT NULL REFERENCES soggetti(client_code),
  test_id       TEXT NOT NULL REFERENCES registro_test(test_id),
  valore_num    REAL,
  valore_txt    TEXT,                      -- per le risposte non numeriche
  unita         TEXT,
  fonte         TEXT NOT NULL CHECK (fonte IN
                  ('manuale','questionario','wellness_tower','vald','calibre','stress_index')),
  fuori_range   INTEGER NOT NULL DEFAULT 0,
  created_at    TEXT NOT NULL DEFAULT (datetime('now'))
);
CREATE INDEX idx_misure_cliente_test ON misure (client_code, test_id);
CREATE INDEX idx_misure_sessione ON misure (sessione_id);

CREATE TABLE registro_test (
  test_id       TEXT PRIMARY KEY,          -- 'handgrip_dx', 'plank', 'q_sonno_ore'
  etichetta     TEXT NOT NULL,
  unita         TEXT,
  tipo_valore   TEXT NOT NULL CHECK (tipo_valore IN ('num','txt')),
  curva         TEXT,                      -- 'bell','lin_dec','inc_plateau','x10','x10_inv','decstep','incstep'
  params        TEXT,                      -- JSON dei parametri della curva
  asse          TEXT,                      -- uno dei 7 assi; NULL = non entra nello score
  sotto_dominio TEXT,                      -- a QUALE sotto-dominio contribuisce; il peso sta in `pesi`
  range_min     REAL,                      -- atteso, non vincolante: fuori range si marca
  range_max     REAL,
  attivo_da     TEXT NOT NULL,
  attivo_a      TEXT,                      -- NULL = ancora attivo
  note          TEXT
);

CREATE TABLE pesi (
  model_version TEXT NOT NULL,
  livello       TEXT NOT NULL CHECK (livello IN ('asse','macro','fitness_age')),
  contenitore   TEXT NOT NULL,             -- l'asse, il macro-score, o 'fitness_age'
  elemento      TEXT NOT NULL,             -- il sotto-dominio, o l'asse, o la voce isolata
  peso          REAL NOT NULL,
  PRIMARY KEY (model_version, livello, contenitore, elemento)
);

CREATE TABLE profilo_note (
  id            INTEGER PRIMARY KEY AUTOINCREMENT,
  client_code   TEXT NOT NULL REFERENCES soggetti(client_code),
  sessione_id   INTEGER REFERENCES sessioni(id),
  campo_id      TEXT NOT NULL,             -- 'farmaci', 'problematiche_attuali', 'obiettivi'
  testo         TEXT NOT NULL,
  created_at    TEXT NOT NULL DEFAULT (datetime('now'))
);

CREATE TABLE score (
  id            INTEGER PRIMARY KEY AUTOINCREMENT,
  client_code   TEXT NOT NULL REFERENCES soggetti(client_code),
  sessione_id   INTEGER NOT NULL REFERENCES sessioni(id),
  tipo          TEXT NOT NULL CHECK (tipo IN ('asse','macro','fitness_age')),
  elemento      TEXT NOT NULL,             -- 'Forza & Struttura', 'PERFORMANCE', ...
  valore        REAL,                      -- NULL quando stato='insufficiente'
  copertura     REAL NOT NULL,
  stato         TEXT NOT NULL CHECK (stato IN ('ok','insufficiente')),
  quest_version TEXT,
  model_version TEXT NOT NULL,
  calcolato_at  TEXT NOT NULL DEFAULT (datetime('now'))
);
CREATE INDEX idx_score_cliente ON score (client_code, calcolato_at DESC);
```

### Perché l'età e non la data di nascita

Il motore ha bisogno dell'età — `score_handgrip(kg, eta, sex)`,
`score_vo2max(vo2max, eta, sex)`, le bande per decade — ma gli serve **un numero
al momento della misura**, non una data. Sesso ed età non identificano nessuno;
una data di nascita esatta, combinata con pochi altri campi, quasi sì. Costa una
colonna e toglie un quasi-identificatore dal database clinico.

### Perché il peso non sta sulla riga del test

Un sotto-dominio può essere coperto da **test alternativi**: la *spinta* si
misura con i push-up o con il 5RM di panca, a seconda del livello del cliente, e
il peso — 20% dentro *Forza & Struttura* — è del sotto-dominio, non del singolo
test. Se il peso stesse sulla riga del test si ripeterebbe su ogni alternativa,
e prima o poi due copie divergerebbero.

I pesi stanno quindi in una tabella loro, **con la `model_version` nella chiave**.
È ciò che rende reale il congelamento del §6: uno score del passato si può
rileggere con i pesi che erano in vigore quando è stato calcolato, invece che con
quelli di oggi. Senza questo, `model_version` sarebbe un'etichetta senza niente
dietro.

⚠️ Nota per l'implementazione: nel motore Python `plank` compare in **due** assi
— `core` in *Forza & Struttura* (0.15) e `plank` in *Stabilità & Mobilità* (0.20).
È lo stesso doppio conteggio ammesso dal cliente per l'handgrip nella Fitness Age,
ma quello del plank **non è dichiarato da nessuna parte**. Questo schema lo
rappresenta senza problemi (due righe in `pesi`), però va segnalato al cliente
invece che riprodotto in silenzio.

### Perché il registro dei test è dato e non codice

Il cliente ha già i test in forma di registro: un foglio di 30 righe con fonte e
stato per ciascuno. Qui diventa una tabella, e la conseguenza è che **il set dei
test è mobile senza migrazioni**, cosa che è già successa tre volte in un mese:
l'agilità è stata rimossa dallo score, la capacità vitale pure, e l'HRR è passato
dalla finestra a 2' a quella a 1'.

Con questo modello: disattivare un test è valorizzare `attivo_a`; cambiare la
finestra dell'HRR è **un `test_id` nuovo che convive col vecchio**, e le
misurazioni già fatte restano leggibili e restano marcate per quello che sono,
invece di diventare confrontabili per sbaglio con le nuove.

## 6. Versioni e congelamento

Decisione del cliente, 21/08: quando cambia una formula i punteggi storici si
**congelano**, non si ricalcolano. La ragione è di prodotto ed è corretta — se
lo score storico cambia, il cliente non distingue più il proprio miglioramento
da un cambio di matematica, e il confronto nel tempo perde valore.

L'implementazione ha due conseguenze:

1. **Gli score si salvano**, non si ricalcolano a ogni visualizzazione. La
   tabella `score` è la memoria di ciò che il cliente ha visto.
2. **Le misure grezze si salvano tutte**, quindi un ricalcolo con formule nuove
   resta sempre possibile in lettura, per analisi, senza sovrascrivere niente.

**Due versioni, non una.** Ogni score porta `quest_version` (quali domande) e
`model_version` (quali curve e quali pesi). Il cliente ne ha implementata una
sola perché dal suo lato coincidevano, ma i pesi degli assi possono cambiare
senza che cambi una domanda: con una versione sola un punteggio del passato non
saprebbe dire quale delle due cose è cambiata.

⚠️ **Il congelamento sposta il problema del confronto, non lo elimina.** Due
compilazioni con versioni diverse restano non confrontabili anche se nessuno le
ha riscritte. Il grafico della progressione deve quindi **dichiarare
visivamente il cambio di versione**, altrimenti il cliente vede una linea
continua di numeri calcolati con matematiche diverse — che è l'equivoco che la
decisione voleva evitare.

## 7. Flusso dei dati

### Ingresso: un solo varco

```
questionario in pagina  ─┐
gestionale trainer      ─┤
import file (WT, VALD)  ─┼─→  registraMisure(sessione, misure[])  ─→  misure
API (VALD Hub)          ─┘         ↑ valida contro registro_test
```

`registraMisure` è l'unica funzione che scrive in `misure`. Valida ogni riga
contro il registro: **un `test_id` sconosciuto viene rifiutato**, non scritto in
silenzio. Un valore fuori dal range atteso viene invece **scritto e marcato**
(`fuori_range = 1`), perché scartarlo perderebbe un dato vero e clamparlo lo
falserebbe — vedi §9.

### Calcolo

Il motore legge misure e registro, e produce gli score seguendo la cascata a
quattro livelli del cliente: sotto-metrica → asse → macro-score → Fitness Age,
con rinormalizzazione dei pesi disponibili a ogni livello e soglia di copertura
al **40%**.

Il tipo di ritorno impedisce la trappola presente nel motore Python, dove
`aggregate()` restituisce il punteggio pieno **anche quando lo dichiara
insufficiente**:

```ts
type Punteggio =
  | { stato: 'ok'; valore: number; copertura: number }
  | { stato: 'insufficiente'; copertura: number }   // non c'è nessun valore da leggere
```

La regola di prodotto — *«tratteggiato, mai un numero pieno fasullo»* — diventa
così impossibile da violare per distrazione: chi disegna il radar non ha il campo
da cui prendere il numero.

### Uscita

Dashboard cliente (radar a 7 assi, 3 macro-score, Fitness Age), vista trainer, ed
export per le statistiche — che è il contenuto di `longevity.db`, senza passare
da nessuna funzione di anonimizzazione.

## 8. Ruoli e accessi

Il sito ha oggi `admin | superuser | user | piattaforme`, e nessuno di questi è
il cliente finale né il trainer. Se ne aggiungono **due**: `cliente` e `trainer`.

| Rotta | Chi entra |
|---|---|
| `/longevity/io` | `cliente` (solo il proprio fascicolo), `trainer`, `admin` |
| `/longevity/gestionale` | `trainer`, `admin` |
| `/api/longevity/**` | come sopra, verificato lato server |

**Il cliente vede solo i propri dati, e non è una regola di interfaccia:** gli
endpoint ricavano il `client_code` dalla sessione e **mai** dalla richiesta. Un
client_code che arriva dal browser viene ignorato.

## 9. Errori e casi limite

**Misura fuori dal range atteso: si registra e si marca.** Il caso è già
successo — la capacità vitale di 5148 mL su un fondoscala dichiarato di
2000-3000 mL non era una prestazione eccezionale, era il range del fornitore
sbagliato, e clamparla a 100 produceva un dato apparentemente ottimo. Le misure
marcate finiscono in una lista che il trainer vede; non entrano nello score
finché qualcuno non le conferma.

**Scala non comparabile: si esclude dal registro, non si corregge nel codice.**
L'agilità a 548 ms contro i 250 attesi dava 20/100 su Stabilità — falso, e la
causa era il protocollo diverso. Un caso così si risolve disattivando il test nel
registro, non aggiungendo un fattore di correzione da qualche parte.

**Copertura sotto il 40%:** l'elemento è `insufficiente` e non ha un valore.

**Test sconosciuto in ingresso:** errore esplicito, la sessione non viene scritta
a metà.

## 10. Test

Il test principale è il **verificatore contro il motore Python**: gli stessi
ingressi devono produrre gli stessi numeri, e ogni curva va confrontata su tutto
il suo dominio, non su un caso singolo. È l'unico modo per sapere che il porting
non ha spostato niente.

Poi: le regole di copertura e rinormalizzazione, il rifiuto dei test sconosciuti,
la marcatura del fuori range, l'isolamento dei tre database (nessun modulo, a
parte quello designato, apre insieme identity e longevity), e il fatto che un
`client_code` proveniente dalla richiesta non venga mai onorato.

⚠️ **I dati reali di Donata e Nicola non entrano nelle fixture.** Sono dati
sanitari di due persone identificabili, e le fixture stanno in git, dove restano
per sempre e le legge chiunque abbia accesso al repository. I casi di prova si
costruiscono sintetici; i referti veri restano dove sono, per il confronto a mano
quando serve.

## 11. Punti aperti che il codice non risolve

Questi non sono dettagli implementativi: sono decisioni che spettano al cliente,
e finché non arrivano il codice si comporterà come qui dichiarato — non come
capita.

1. **Base giuridica per i dati sanitari (art. 9 GDPR).** Il campo `consenso` del
   questionario riguarda le comunicazioni promozionali, non il trattamento di
   dati di salute, e la finalità statistica è ulteriore rispetto a quella di
   cura. Serve un consenso esplicito dedicato. **Non è un blocco allo sviluppo,
   è un blocco alla messa in produzione con clienti veri.**
2. **Chi è il medico supervisore**, nominato nella specifica del questionario. Se
   è un professionista sanitario, cambia la base giuridica utilizzabile
   (art. 9.2.h), in meglio.
3. **La regola dei buchi nel questionario.** Oggi esiste in due versioni: il
   prototipo annulla un sotto-dominio solo se non c'è **nessuna** risposta, il
   motore usa il 40%. La piattaforma userà **una soglia unica, dichiarata nel
   registro come parametro**, e in attesa della risposta assume il **40%**,
   coerente con la regola dei sette assi.
4. **Il cambio di versione sul grafico** della progressione (§6).
5. **Il registro delle versioni**: cosa cambia a ogni incremento di
   `quest_version` e `model_version`, altrimenti fra sei mesi «v1.3» non dirà
   niente a nessuno.
6. **Nomi dei Livelli 1/2/3** — SPARK/FLUX/APEX o PULSE/FLOW/PEAK, aperti da
   sessioni precedenti del cliente. Il livello è già una colonna del profilo.
7. **Export CSV/API di Stress Index**, l'unico canale la cui automazione non è
   confermata. L'HRV entra nel motore come passthrough, quindi senza quel canale
   va inserito a mano.

## 12-bis. Cosa ha scoperto la costruzione del motore (22/08)

Il motore è stato costruito il 22/08 (ramo `feat/longevity`, 6 task, 308 test). Il porting
è fedele: eseguendo la funzione dimostrativa del cliente sui due motori, i sette assi, i tre
macro-score e la Fitness Age **combaciano numero per numero**.

### Due divergenze deliberate dall'oracolo, entrambe volute

1. **Un punteggio insufficiente non espone un valore.** Nell'originale la funzione di
   aggregazione restituisce il numero anche quando dichiara l'elemento insufficiente; qui il
   tipo non ha proprio il campo. È ciò che rende impossibile mostrare un numero dove i dati
   non bastano.
2. **La Fitness Age esclude gli assi insufficienti**, mentre l'oracolo li include comunque.
   ⚠️ **Cambia il numero, e parecchio**: sullo stesso profilo parziale, 25,0 contro 34,8 —
   quasi dieci anni. Chi confrontasse il nostro referto con il Python del cliente su un
   profilo incompleto concluderebbe che il porting è rotto. **Da dire a Nicola.**

### ⚠️ Le curve dei test fisici non sono collegate, e agganciarle non sarà «solo dati»

Le venti curve dei test misurati sono portate e verificate, ma **irraggiungibili dal
motore**: il vocabolario delle curve del registro non ha nomi per loro, e la funzione che
applica una curva non può ricevere età e sesso, che quasi tutte richiedono.

📌 Questo contraddice la §5, dove il registro è presentato come dato che si estende senza
toccare il codice. **È vero per il questionario, non per i test fisici**: agganciarli
richiede di estendere il vocabolario e la firma. Il piano degli import deve saperlo, perché
oggi crede di trovare la presa già montata.

### Il confine dove la barriera finisce

Il tipo protegge il codice; la tabella `score` ha ora anche un vincolo che rifiuta un valore
scritto sotto uno stato che lo nega. ⚠️ Ma quel vincolo entra solo nei database **creati da
qui in avanti**: lo schema gira con `CREATE TABLE IF NOT EXISTS`, che su un file esistente
non fa nulla. Oggi nessun database esiste ancora — diventa un problema il giorno del primo
deploy, ed è quello il momento di ricordarsene.

### La storia dei punteggi si tiene

Un ricalcolo **aggiunge** righe invece di sovrascriverle, coerentemente col congelamento del
§6: sovrascrivere cancellerebbe proprio ciò che il congelamento protegge. La lettura passa da
una funzione tipata che restituisce l'ultimo calcolo per sessione — la dashboard non deve
inventarsi una query sua.

### 🔲 Una domanda per Nicola, sulla voce più pesante del modello

`hrv` pesa **0,50 su due assi** — *Recupero* ed *Energia* — ed è la singola voce più pesante
di tutto il modello. Nel motore è un dato solo, condiviso. Ma nella funzione dimostrativa
dell'oracolo i due assi ricevono **numeri diversi sotto lo stesso nome** (68 e 65).
O è la stessa misura riusata su due assi — come il plank, che Nicola ha già confermato — e i
due numeri sono illustrativi; oppure sono due metriche distinte, e allora le stiamo fondendo
per sbaglio. Diventa concreto appena si collega Stress Index, che è la sorgente di quel dato.

---

## 12. Cosa l'implementazione ha scoperto — da chiudere prima del motore

Lo strato dati è stato costruito il 21/08 (ramo `feat/longevity`, 19 commit, 241 test).
Costruirlo ha fatto emergere sei punti che questo documento non aveva previsto o su cui
si contraddiceva. **Nessuno è bloccante per lo strato dati; tutti lo diventano per il
motore di calcolo.**

1. **La conferma delle misure fuori range non ha dove stare.** La §9 dice che una misura
   marcata «non entra nello score finché qualcuno non la conferma», ma lo schema della §5
   non prevede nessuna colonna che registri quella conferma. Le due sezioni si
   contraddicono: va aggiunta la colonna o riscritta la regola.
2. **`registraMisure` valida l'esistenza del test, non il valore.** Oggi accetta una
   misura senza nessun valore, un testo dove il registro dichiara un numero, e un `NaN`
   (che viene scritto come nullo e **non** marcato fuori range, perché ogni confronto con
   NaN è falso). Una riga vuota conta come «test presente» ai fini della copertura del 40%.
3. **`seedRegistro` rilanciato disfa il registro.** Usa `INSERT OR REPLACE` e riazzera
   `attivo_a` e le note: disattivare un test e poi rilanciare il seed lo riattiva. È
   esattamente l'opposto della promessa della §5, dove disattivare un test è valorizzare
   `attivo_a`.
4. **`MODEL_VERSION` non esiste.** `QUEST_VERSION` sta in `questionario.ts`; la gemella
   che versiona curve e pesi non è dichiarata da nessuna parte, e `seedPesi` la riceve
   come parametro che solo i test valorizzano. Finché non esiste, il congelamento del §6
   ha metà del suo significato.
5. **La soglia del 40% è una costante di codice**, non un parametro nel registro come
   chiede la §11.3 — e nessuno la consuma ancora.
6. **Registro e pesi sono disallineati per costruzione.** Il registro contiene oggi i 20
   campi del questionario; i pesi citano handgrip, vo2max, plank, flamingo — sotto-domini
   che nessun test ancora alimenta. Con i dati attuali sei assi su sette resterebbero
   permanentemente «insufficiente». È atteso, perché i test fisici arrivano col piano degli
   import, ma va saputo: il primo che lancia il motore lo legge come un difetto.

⚠️ **Una trappola già armata per il piano delle API.** Nelle regole di accesso, tutto ciò
che sta sotto `/api/longevity/` e non sotto `/api/longevity/gestionale/` è raggiungibile da
**ogni** cliente. Oggi è innocuo perché non esiste nessun endpoint, ma significa che la
scelta dei nomi delle rotte è una questione di sicurezza, non di stile: un domani
`/api/longevity/clienti` sarebbe l'elenco di tutti, aperto a tutti.

⚠️ **Due limiti noti dell'anagrafica**, accettati con cognizione: se fallisse anche la
cancellazione compensativa su identity, l'errore diagnostico verrebbe mascherato e
resterebbe un cliente senza pendant clinico; e i codici sono ordinati come stringhe,
quindi oltre `ISL-9999` l'ordinamento sbaglia e un codice potrebbe essere riusato.

📌 **Da dire a Nicola, non ancora detto:** il plank pesa su due assi — `core` in *Forza &
Struttura* (0.15) e `plank` in *Stabilità & Mobilità* (0.20). È lo stesso doppio conteggio
che lui dichiara per l'handgrip nella Fitness Age, ma questo non è dichiarato da nessuna
parte.

---

## 12. Decisioni prese, e da chi

| Decisione | Chi | Quando |
|---|---|---|
| Un record per compilazione + export Excel | Nicola | 21/08 |
| Versione del questionario su ogni record | Nicola | 21/08 |
| Formula cambiata → punteggi storici congelati | Nicola | 21/08 |
| Export pseudonimizzato, mappatura separata e ristretta | Nicola | 21/08 |
| Curva alcol 0-7 = 100 (soglia NIAAA/WHO), voluta | Nicola | 21/08 |
| La piattaforma vive dentro il sito, area riservata | Adriano | 13/08 |
| Ramo separato, nessun deploy | Adriano | 21/08 |
| Tre database separati | Adriano | 21/08 |
| Registro di misure invece di colonne fisse | Adriano | 21/08 |
| Il progetto è unico: un framework sui dati del cliente | Adriano | 21/08 |
| Calcolo in TypeScript, non Python | Tielogic (verificato sul codice) | 21/08 |