InsanityLab-web/.superpowers/sdd/2026-08-22-longevity-interfaccia/progress.md

# SDD ledger — plan: docs/plans/2026-08-22-longevity-interfaccia.md

Spec: docs/specs/2026-08-21-longevity-design.md
Repo: InsanityLab-web — branch `feat/longevity` (main fermo a ecab678)
Piani precedenti eseguiti: strato dati (2026-08-21), motore (2026-08-22)

## Scansione pre-volo

| Task A | Task B | Produce → Consuma | Esito |
|---|---|---|---|
| 1 guscio | 2, 3 | layout `Longevity.astro`, classi `.lg-*` | OK |
| 2 vista.ts | 3 | il file viene creato da 2 ed esteso da 3 | ⚠️ vedi ruling |
| 2 endpoint | 3 | nessuna dipendenza diretta | OK |
| 3 refertoDi | nessuno | ultimo task del piano | OK |

| Task | Coerenza interna | Esito |
|---|---|---|
| 1 | 5 test, tutti su file e contenuto — nessuno esegue una pagina | ⚠️ vedi ruling |
| 2 | 7 test; tre riguardano il consenso, che è il punto del task | OK |
| 3 | 6 test; quello sul congelamento discrimina cambiando i pesi | OK |

## Ruling: `vista.ts` è creato dal Task 2 ed esteso dal Task 3
Non è un conflitto — i task sono sequenziali e nessuno gira in parallelo — ma va detto:
il Task 3 **aggiunge** `refertoDi` a un file che il Task 2 ha già scritto. Chi esegue il 3
non deve riscrivere il file da zero.

## Ruling: i test del Task 1 controllano il sorgente, non il comportamento
Astro non si esegue in vitest senza montare la pipeline di Vite. I test del guscio quindi
leggono i file e ne verificano proprietà — nessun header pubblico, classi prefissate, niente
semaforo. È una rete debole ma vera: intercetta la regressione che conta (qualcuno che
aggiunge un colore «buono»/«cattivo» ai punteggi). Il comportamento vero delle pagine si
vede col piano successivo, quando ci sarà una sessione reale da mostrare.
Costo se sbagliato: una pagina può rompersi senza che un test se ne accorga. Mitigazione:
`npx tsc --noEmit` deve restare pulito, ed è un vincolo globale del piano.

## Modelli scelti
Implementer: sonnet — c'è React, Astro e integrazione con tre moduli esistenti.
Reviewer: sonnet. Review finale: opus.

## Task 1 — il test anti-semaforo protegge il nome, non l'intento (sesta volta)

Il revisore non si è fidato: ha **simulato tre regressioni** sul CSS vero e ha guardato quali
passano.

| Regressione simulata | Il test se ne accorge? |
|---|---|
| `.lg-score--alto { color: #6f8f6a; }` (verde scritto in esadecimale, lo stesso di Stress Index) | **no** |
| `.lg-score--alto { color: var(--lg-buona-salute); }` (variabile con altro nome) | **no** |
| `--lg-verde-scuro: #6f8f6a;` (contiene una delle tre parole vietate) | sì |

Il test cerca tre nomi letterali. Chiunque reintroducesse il semaforo con un colore scritto
direttamente, o con una variabile battezzata diversamente, passerebbe indisturbato — ed è
proprio il modo più naturale di farlo.

📌 **È la sesta volta in questa sessione** che compare lo stesso difetto, e ancora una volta
il test veniva dal brief che ho scritto io. La forma è sempre quella: **proteggo il nome di
una cosa invece della cosa**. Qui: i tre nomi vietati invece del colore.

**Ruling: rendere il controllo strutturale.** Non un elenco di nomi proibiti, ma il verso
opposto — nelle regole che riguardano i punteggi possono comparire **solo** i colori
ammessi (l'accento del sito, il tratteggio, il fuori range). Tutto il resto è una
regressione, che si chiami come si chiami.
Costo se sbagliato: un test più severo può dare falsi allarmi quando il foglio cresce; è
preferibile a una rete che lascia passare esattamente ciò per cui esiste.
Task 1: implementato (commit 34c66ca) + fix round 1/5 (test reso strutturale; commit 2ea822a)
Task 1: verificato in prima persona — iniettando un verde esadecimale su una classe di punteggio il test nuovo diventa rosso, mentre il vecchio lo lasciava passare
Task 1: l'implementer ha tenuto ANCHE il vecchio controllo sui nomi, notando che intercetta un caso che il nuovo non vede: un token dichiarato e mai usato. Osservazione giusta, i due controlli sono complementari.
Task 1: complete (commits 779aef3..2ea822a, review clean dopo 1 round)

## Task 2 — la garanzia di separazione è stata aggirata al PRIMO endpoint

L'implementer ha aggiunto in `db.ts` due funzioni comode, `getLongevityDb()` e
`getIdentityDb()` (stesso pattern del `getDb()` del sito), e l'endpoint del questionario le
importa **entrambe**. È un secondo punto di giunzione fuori da `anagrafica.ts`, cioè
esattamente ciò che la spec §4 vieta.

⚠️ **E il test che dovrebbe impedirlo non se ne accorge**, perché cerca i nomi
`createIdentityDb` e `createLongevityDb`: i nomi nuovi non sono sorvegliati da nessuno.

📌 Era stato **previsto**. La revisione del Task 4 dello strato dati diceva: «il test rileva
solo la violazione più ingenua — chi chiama direttamente le due factory — non quella che
imita il modulo autorizzato». Allora l'avevo parcheggiata come improbabile. Si è avverata al
**primo endpoint scritto**, tre piani dopo.

Va detto che l'uso è corretto nella sostanza: l'endpoint chiama `codicePerUtente`, che sta
in `anagrafica.ts`, quindi la **logica** di giunzione è al posto giusto. È l'**apertura**
delle due connessioni a essere fuori posto — e il rischio non è oggi, è il giorno in cui
qualcuno, da quell'endpoint che già ha entrambe le connessioni in mano, scrive una query che
le incrocia.

**Ruling: due correzioni, e la seconda vale più della prima.**
1. `anagrafica.ts` espone una funzione che risolve il codice cliente aprendo lei ciò che
   serve; l'endpoint apre **solo** longevity.
2. Il test anti-giunzione va esteso ai nomi nuovi — e scritto in modo che **qualunque**
   coppia di accessi ai due database venga vista, non tre nomi elencati a mano. È la stessa
   lezione del semaforo del Task 1: si protegge la cosa, non il nome della cosa.

Costo se sbagliato: una funzione in più in anagrafica.ts. Il costo di non farlo è che la
garanzia centrale del progetto resta scritta nella spec e assente dal codice.
Task 2: implementato (commit f5ca841) + fix round 1/5 (endpoint apre solo longevity, test anti-giunzione strutturale; commit f0629db)
Task 2: verificato in prima persona con una TERZA coppia di nomi, diversa sia dalla vecchia sia dalla nuova: il test la rileva e la nomina. Protegge la cosa, non i nomi.
Task 2: in revisione

## Task 2 — il test anti-giunzione NON basta, e la cura non è un test migliore

Avevo chiesto al revisore: «il vincolo regge perché il test lo sorveglia, o perché nessuno
l'ha ancora usato male?». Risposta: **la seconda**. E l'ha dimostrata, con un pattern che
non ha niente di malizioso: tre file, una connessione riesportata da un modulo e usata
insieme all'altra in un terzo. **Nessuno dei tre contiene entrambe le parole**, quindi il
test resta verde mentre la giunzione esiste davvero.

📌 **Settima volta** che protegge il nome invece della cosa — e stavolta la mia correzione
precedente (cercare le due stringhe invece dei due nomi di funzione) era ancora dello stesso
tipo, solo un gradino più su. Un controllo testuale file per file non può vedere una
giunzione che attraversa due file.

**Ruling: si smette di sorvegliare e si rende impossibile.**

La connessione a `identity` non deve essere ottenibile da nessuna parte tranne che dentro
`anagrafica.ts`. Oggi `db.ts` la espone a chiunque con `getIdentityDb()`: quella funzione
esce da lì e diventa **privata** al modulo autorizzato. Chi ha bisogno di risolvere un
codice cliente chiama una funzione di `anagrafica.ts` — che è già ciò che fa l'endpoint dopo
il fix precedente.

Così il vincolo non dipende più solo da un guardiano aggirabile: la via ovvia — il singleton
condiviso — non è più raggiungibile.

⚠️ **CORREZIONE (revisione finale):** avevo scritto «non esiste il modo di avere entrambe le
connessioni». **È troppo forte, ed è falso.** `createIdentityDb` resta esportata e senza
argomenti apre lo **stesso file** del singleton: il bypass a tre file funziona ancora, compila
e la suite resta verde. L'attrito è aumentato, l'impossibilità no. Va detto com'è. Il test resta come
rete secondaria, con il suo limite scritto accanto.

⚠️ `createIdentityDb` resta esportata: serve ai test per creare database in memoria, e lì la
giunzione è voluta e visibile. È il **singleton condiviso** il problema, non la fabbrica.

Costo se sbagliato: se un domani servisse leggere identity da un altro punto legittimo,
bisognerà aggiungere una funzione ad `anagrafica.ts` invece di aprire una connessione. È
esattamente l'attrito che vogliamo.
Task 2: fix round 2/5 (getIdentityDb privata in anagrafica.ts, try/catch nell'endpoint, campi testuali; commit 8c98075)
Task 2: RIPROVATO io il bypass a tre file che prima passava indisturbato — ora non compila:
        "'db' has no exported member named 'getIdentityDb'". Il test resta verde (e dichiara il
        proprio limite), ma la difesa vera è che il codice che aggira la garanzia non esiste più.
📌 La lezione di tutta la sessione, in una riga: quando una regola conta, non la si sorveglia —
   si costruisce il codice in modo che violarla non sia un'opzione. Stessa forma della soluzione
   nel motore, dove il punteggio insufficiente ha smesso di AVERE un campo valore.
Task 2: complete (commits 2ea822a..8c98075, review clean dopo 2 round)
Task 2: minor (deferred): il test sulla nota di consenso verifica l'esito ma non che vi compaiano versione e data, che il codice scrive comunque

## Task 3 — l'ottava volta, e stavolta l'ha trovata l'implementer

Il test sul congelamento che avevo scritto **non poteva funzionare**, e la ragione è
algebrica, non di programmazione: la mutazione che avevo scelto cambia il peso di
`questionario_lifestyle`, che è l'**unico** sotto-dominio del suo asse. In una media pesata
con un elemento solo il peso si semplifica — `(v × p) / p = v` per il valore, `p / p = 1`
per la copertura — quindi il risultato è identico con qualunque peso, letto o ricalcolato.

Verificato:

    peso 1.00 -> valore 72, copertura 1
    peso 0.99 -> valore 72, copertura 1
    peso 0.50 -> valore 72, copertura 1

Il test passava per un'identità algebrica, non perché il congelamento funzionasse.

L'implementer l'ha scoperto **facendo la prova che gli avevo chiesto**: ha rotto `refertoDi`
perché ricalcolasse invece di leggere, e ha visto il test restare verde. Poi invece di
girarci intorno ha trovato la mutazione che discrimina davvero — il peso di un sotto-dominio
**assente** in un asse a più elementi con copertura parziale — e ha verificato che lì il test
rotto diventa rosso. Ha lasciato il test del brief com'era, perché così diceva l'istruzione,
e ha scritto la falla nel rapporto con la causa esatta.

📌 **Ottava volta**, e la forma è sempre quella: scelgo un caso di prova su cui
l'implementazione giusta e quella sbagliata danno lo stesso risultato. Qui non per
distrazione ma per un motivo che si vede solo facendo il conto — ed è esattamente perché la
prova di rottura va **eseguita**, non immaginata.

**Ruling: si sostituisce la mutazione con quella discriminante.** Il test deve fallire se il
referto ricalcola invece di leggere; oggi non lo fa.
Task 3: implementato (commit 7f01ee0) + fix round 1/5 (mutazione discriminante; commit 6630be7)
Task 3: riprovato io il sabotaggio sul test corretto — forzando il ricalcolo diventa rosso e nomina il problema. Ora protegge.
Task 3: nota tecnica dell'implementer da tenere — `mancano` non poteva venire dalla colonna `asse` del registro, perché lì oggi ci sono solo i 20 campi del questionario e nessuna riga per i sotto-domini fisici. L'ha costruito confrontando i sotto-domini PESATI di un asse con quelli effettivamente misurati.
Task 3: in revisione

## Task 3 — nona volta, ed è colpa della MIA correzione precedente

Il test anti-semaforo, che nel Task 1 avevo fatto irrobustire, filtra le regole CSS su
`lg-score`. Ma questo task ha aggiunto `.lg-radar*` e `.lg-macro*`, che quella stringa non
la contengono: **restano fuori dal controllo**. Il revisore l'ha dimostrato iniettando
`color: #ff0000` in `.lg-radar__voce-nome` — sei test verdi, violazione invisibile.

📌 La forma è sempre la stessa, e stavolta l'ho introdotta io correggendo: sono passato da
**un elenco di nomi vietati** a **un elenco di prefissi da controllare**. Un elenco resta un
elenco, e invecchia appena qualcuno aggiunge una classe.

**Ruling: si gira di nuovo, e stavolta fino in fondo.** Il foglio è interamente prefissato
`lg-` per costruzione — quindi il controllo non deve scegliere *quali* regole guardare, ma
guardarle **tutte** e dichiarare le eccezioni. Una regola nuova entra sotto controllo per il
solo fatto di esistere, invece che per essersi ricordati di aggiungerla a un elenco.

Costo se sbagliato: qualche eccezione da dichiarare quando il foglio crescerà — ed è
l'attrito giusto, perché dichiarare un'eccezione è una decisione visibile, dimenticare di
aggiungere un prefisso non lo è.
Task 3: fix round 2/5 (il controllo guarda tutto il foglio, non un elenco di prefissi; commit a56398e)
Task 3: prova definitiva fatta da me — una classe INVENTATA sul momento, che non esisteva quando il
        test è stato scritto, con un verde dentro: il test la vede e la nomina. Non protegge più un
        elenco, protegge il foglio.
Task 3: complete (commits 8c98075..a56398e, review clean dopo 2 round)
Task 3: minor (deferred): `mancano` usa la MODEL_VERSION corrente invece di quella congelata sulla riga di score — ininfluente oggi (ne esiste una sola), rilevante quando il modello cambierà

TUTTI E TRE I TASK DELL'INTERFACCIA COMPLETI. Suite 327 verdi, typecheck pulito.

## REVISIONE FINALE — verdetto: NO, e il difetto è nel piano che ho scritto io

**Nessuno chiama il motore.** Il Task 2 salva la compilazione, il Task 3 legge i punteggi, e
**fra i due non c'è niente**: il piano non prevedeva il passo che li calcola. Verificato in
prima persona eseguendo il flusso vero con tutte e venti le risposte compilate:

    righe in score dopo la compilazione: 0
    assi che mostrano un numero: 0 su 7

Il cliente compilerebbe venti domande e vedrebbe sette assi vuoti, tre trattini e
«copertura dati 0%». Non è un referto parziale che si spiega: **è una pagina che dichiara il
falso sui dati che ha appena ricevuto**.

📌 È il difetto della composizione allo stato puro: ogni task corretto e revisionato, il
prodotto non funziona. Nessuna revisione per task poteva vederlo, perché i test del Task 3
chiamano `salvaScore` dentro la propria fixture — cioè fanno a mano ciò che in produzione non
fa nessuno.

### Altri quattro test che non proteggono niente (mutazioni eseguite dal revisore)

| # | Mutazione | Esito |
|---|---|---|
| 10 | il `client_code` preso dal corpo della richiesta | **verde** — il test elenca `body.`/`corpo.`, ma il file chiama il corpo `data`: **vacuo per costruzione** |
| 11 | rimossa la registrazione del consenso **accettato** | **verde** — è coperto solo il ramo del rifiuto |
| 12 | una pagina nuova con `SELECT` dentro | **verde** — il test elenca due nomi di file |
| 13 | giunzione a tre file via `createIdentityDb()` | **verde**, e compila |

La #10 è la decima ricorrenza della stessa forma, ed è la peggiore: la regola §8 —
*«il client_code si ricava dalla sessione, mai dalla richiesta»* — **oggi non è sorvegliata
da niente**, e un cliente potrebbe scrivere nel fascicolo di un altro.

### Un canale di re-identificazione aperto proprio da questo piano
`profilo_note` accoglie testo libero, e questo è il primo lavoro in cui **una persona ci
scrive dentro**. Un cliente che scrive «sono Mario Rossi, prendo…» mette il proprio nome in
`longevity.db`, che la §7 dichiara **essere** l'export per le statistiche. Lo strato dati ha
costruito la tabella, l'interfaccia ha aperto il rubinetto: nessuna revisione per task poteva
vederlo.