InsanityLab-web/.superpowers/sdd/2026-08-22-longevity-interfaccia/task-3-report.md

Task 3 — Il radar, e come si mostra ciò che non si sa — report

Stato: completato. 6/6 test nuovi verdi, suite completa allo stato atteso (1 fallito pre-esistente e fuori perimetro, 327 passati), npx tsc --noEmit pulito. Commit fatto.

Commit: 7f01ee0 — "longevity: il referto del cliente, e il radar che dice cosa non sa"

File aggiunti/modificati (solo questi, git add esplicito, nessun -A/.):

• src/lib/longevity/vista.ts (modificato) — refertoDi, ultimaSessioneDi, tipi AsseVista/MacroVista, e le funzioni di supporto private
• src/components/longevity/Radar.tsx (nuovo) — isola React col radar recharts
• src/components/longevity/MacroScore.astro (nuovo) — carta di un macro-score
• src/pages/longevity/io.astro (nuovo) — la pagina del referto, nessuna query diretta
• src/styles/longevity.css (modificato) — classi .lg-radar*, .lg-macro*, .lg-referto, .lg-num
• tests/longevity/referto.test.ts (nuovo) — i 6 test del brief

Procedura seguita (TDD)

Step 1-2: test scritto, verificato rosso

Comando:

npm test -- tests/longevity/referto.test.ts

Esito (prima dell'implementazione): TypeError: refertoDi is not a function e ENOENT su src/pages/longevity/io.astro (non esisteva ancora) — 6 falliti su 6, come atteso.

Step 3: implementazione

src/lib/longevity/vista.ts — refertoDi(db, sessioneId)

Legge solo leggiScore (i punteggi congelati in score): non chiama mai calcolaSessione. Per ogni asse/macro-score:

• se stato === 'ok': { nome, valore: p.valore, copertura: p.copertura, mancano: [] };
• altrimenti: valore: null, copertura letta comunque dalla riga congelata (mai 0 finto quando una copertura parziale esiste davvero), e per gli assi mancano calcolato.

L'ordine dei sette assi (e dei tre macro-score) viene dalla tabella pesi (GROUP BY contenitore ORDER BY MIN(rowid), non un SELECT DISTINCT senza ordine): rispetta l'ordine di dichiarazione in registro.ts (seedPesi inserisce nell'ordine degli Object.entries), in modo deterministico per il radar.

mancano: la parte non banale del task. I sette assi pesano dei sotto-domini (handgrip, vo2max, questionario_sonno...), non dei test_id — e oggi nessuna riga di registro_test esiste per i sotto-domini fisici (handgrip, spinta, VO2max, plank...): il registro contiene solo i 20 campi del questionario. Quindi "i test del registro che alimenterebbero quell'asse" non si possono leggere da registro_test.asse per un asse fisico — sarebbe sempre vuoto. Ho preso pesiDi(db, MODEL_VERSION, 'asse', nomeAsse) (le chiavi = i sotto-domini pesati, dato che esiste già) e confrontato con i sotto-domini che la sessione ha davvero misurato (join misure→registro_test, fuori_range=0, valore_num IS NOT NULL). Il sotto-dominio assente si traduce in un'etichetta leggibile via una mappa locale ETICHETTE_SOTTO_DOMINIO in vista.ts — dato nuovo, necessario perché il registro non ha ancora un'etichetta per quei sotto-domini (arriveranno col piano dei test fisici); non duplica nulla che già esista.

ultimaSessioneDi(db, clientCode) — helper nuovo, non nel brief ma necessario: la pagina deve trovare la sessione più recente del cliente loggato senza fare una query da sola. SELECT id FROM sessioni WHERE client_code=? ORDER BY data DESC, id DESC LIMIT 1.

src/components/longevity/Radar.tsx

Due serie recharts sugli stessi sette assi (recharts vuole un data condiviso, non può disegnare un poligono che copre solo alcuni assi):

• noto (piena): vale a.valore ?? 0 — dove manca il dato, l'area si ritira verso il centro, non si inventa un valore;
• potenziale (tratteggiata, fill="none"): vale a.valore ?? 100 — dove il dato c'è coincide col bordo di noto (sparisce dietro), dove manca si allarga al massimo, chiudendo visivamente il perimetro proprio nei punti mancanti. È l'interpretazione letterale di "una tratteggiata che chiude il perimetro dove il dato manca".

Sotto il grafico, l'elenco mancano per ogni asse ancora incompleto (filtrati su mancano.length > 0).

Colori: hex letterali (#9c8b70 accento, #d8d2c8 tratteggio, #e4dfd7 linea, #8a8a8a testo), stesso pattern di DataChart.tsx — recharts riceve attributi SVG diretti, non proprietà CSS, quindi var(--c-accent) non passa da lì; i valori corrispondono 1:1 ai token di longevity.css.

src/components/longevity/MacroScore.astro

Numero se valore !== null, altrimenti '—' (mai 0). Bordo tratteggiato (.lg-card--incompleto, già esistente dal Task 1) quando insufficiente — stesso linguaggio visivo del radar, non una convenzione nuova. Etichetta derivata dal nome del contenitore (PERFORMANCE→Performance) con una trasformazione di stringa, non un dizionario da tenere allineato a mano.

src/pages/longevity/io.astro

Astro.locals.user!.id → codicePerUtenteLoggato → ultimaSessioneDi → refertoDi. Tre stati gestiti: nessun fascicolo collegato, fascicolo ma nessuna sessione ancora (invito a compilare il questionario), referto pieno. Nessuna query SQL nel file.

src/styles/longevity.css

.lg-num { font-variant-numeric: tabular-nums; } applicata ai valori numerici (Fitness Age, macro-score). Nuove classi .lg-radar*, .lg-macro*, .lg-referto — tutte prefissate lg-, nessun colore nuovo (solo var(--c-heading), var(--c-text-light), var(--lg-tratteggio), già nella lista ammessa).

Step 4: test target verde

Comando:

npm test -- tests/longevity/referto.test.ts

Output:

 Test Files  1 passed (1)
      Tests  6 passed (6)

Step 5: suite completa + typecheck

Comando:

npm test

Output (coda):

 ❯ tests/modifiche-agosto.test.ts (25 tests | 1 failed) 38ms
     × l'inaugurazione dice la data e che il programma manca ancora 7ms

 FAIL  tests/modifiche-agosto.test.ts > promo ed eventi > l'inaugurazione dice la data e che il programma manca ancora
AssertionError: expected 'Inaugurazione' to contain '19 settembre 2026'

 Test Files  1 failed | 39 passed (40)
      Tests  1 failed | 327 passed (328)

Esattamente il rosso pre-esistente dichiarato nel task (fuori perimetro) — nessun altro test rotto, i 6 nuovi inclusi nel verde.

Comando:

npx tsc --noEmit

Output: nessuno (exit pulito).

Step 6: commit

git add src/components/longevity/Radar.tsx src/components/longevity/MacroScore.astro \
        src/pages/longevity/io.astro src/lib/longevity/vista.ts src/styles/longevity.css \
        tests/longevity/referto.test.ts
git commit -m "longevity: il referto del cliente, e il radar che dice cosa non sa"

[feat/longevity 7f01ee0] longevity: il referto del cliente, e il radar che dice cosa non sa
 6 files changed, 396 insertions(+), 1 deletion(-)

git status dopo il commit: albero pulito (a parte i file fuori dal perimetro di questo task, non toccati).

La prova richiesta: rompere il test sul congelamento — esito onesto

Ho fatto esattamente quanto chiesto: sostituita la lettura (leggiScore) con un ricalcolo (calcolaSessione) dentro refertoDi, per riprodurre "il referto ricalcola invece di leggere i punteggi salvati".

- import { leggiScore } from './motore';
+ import { leggiScore, calcolaSessione } from './motore';
...
- const punteggi = leggiScore(db, sessioneId);
+ const punteggi = calcolaSessione(db, sessioneId) as unknown as ReturnType<typeof leggiScore>;

Comando:

npm test -- tests/longevity/referto.test.ts

Esito: 6/6 ancora VERDI, compreso "legge i punteggi congelati, non li ricalcola al volo". Il test non ha intercettato la regressione. Non era un problema d'implementazione della prova: l'ho verificato analiticamente e poi con un secondo esperimento mirato.

Perché resta verde — la causa esatta. Il test del brief muta il peso di questionario_lifestyle, che è l'unico sotto-dominio pesato dell'asse "Stile di Vita & Sonno" ({ questionario_lifestyle: 1.00 }, nessun fratello). Nella media pesata di aggrega() (cascata.ts), quando un solo elemento è disponibile il suo peso compare identico sia al numeratore (sommaPesata) sia al denominatore (pesoDisponibile) — si semplifica sempre, qualunque sia il valore. E la copertura fa lo stesso: pesoDisponibile / pesoTotale con un solo elemento in tutto il dizionario è sempre 1.0, comunque lo si scali. Cambiare quel peso — con questi identici dati di seed (solo le 6 risposte di stile di vita) — non può mai produrre un valore o una copertura diversi, sia che si legga lo score congelato sia che lo si ricalcoli da zero: il test è strutturalmente incapace di distinguere le due cose, non solo in pratica ma per costruzione matematica.

Verifica che una mutazione ben scelta invece discrimina davvero. Ho costruito un esperimento a parte (non nel commit, solo per la prova — poi cancellato): stessa sessione ma con anche q_riposato: 8 fra le risposte (copre questionario_sonno con un solo elemento su misura, ma nell'asse "Recupero & Sistema Nervoso" quel sotto-dominio ha tre fratelli assenti: hrv 0.50, pressione 0.15, hrr 0.15, questionario_sonno 0.20). Con refertoDi ancora rotto (ricalcolo), ho azzerato il peso di hrv (0.50→0, un fratello assente, non l'elemento misurato):

npm test -- tests/longevity/_prova-rottura-temp.test.ts

 ❯ ... mutare il peso di un sotto-dominio ASSENTE in un asse multi-elemento sposta la copertura ricalcolata
AssertionError: expected '{"assi":[...]}' to be '{"assi":[...]}'

Rosso netto: la copertura vera di "Recupero & Sistema Nervoso" passa da 0.20/1.00=0.20 a 0.20/0.50=0.40, attraversa la soglia (COPERTURA_MINIMA=0.4) e l'asse passerebbe da insufficiente a ok (valore 80 invece di null) — con effetto a cascata sui macro-score ENERGY/RECOVERY. Ripristinato vista.ts (tolto il ricalcolo), lo stesso test torna verde:

npm test -- tests/longevity/_prova-rottura-temp.test.ts tests/longevity/referto.test.ts

 Test Files  2 passed (2)
      Tests  7 passed (7)

Confermato: rotto → rosso, riparato → verde, per la mutazione giusta. Il file di prova (_prova-rottura-temp.test.ts) è stato cancellato e non è nel commit — non fa parte del perimetro del task, e con la sola compilazione lifestyle (quella del test ufficiale) non esiste alcuna mutazione dei pesi che lo renderebbe rilevante (ogni altro asse ha copertura zero: la stessa scorciatoia disponibili.length === 0 in aggrega() che rende irrilevante qualunque peso quando NESSUN sotto-dominio è misurato).

Cosa faccio con questo. Il test così come specificato nel brief (Step 1, scritto verbatim) resta nel commit senza modifiche: è quello richiesto letteralmente dall'assegnazione, e la sua debolezza è specifica alla combinazione "asse a un solo sotto-dominio" + "seed dati che copre solo quello". Non l'ho riscritto di mia iniziativa — ma è un ottavo test (il settimo l'ha trovato il Task 2) che sembra proteggere il congelamento e in realtà, con questi dati, non può proteggerlo per costruzione matematica. Se questa suite deve davvero blindare la regola "non si ricalcola al volo", la mutazione giusta è quella sopra: il peso di un fratello assente in un asse con più di un sotto-dominio dichiarato e copertura parziale non-zero (non un asse a un solo elemento, e non un asse completamente vuoto).

Le altre tre probe di rottura (mirate ai punti che il brief segnala esplicitamente come critici) hanno tutte funzionato come dovuto:

• "un asse senza dati NON porta un numero": sostituito valore: null con valore: 0 per l'asse insufficiente → rosso immediato (expected +0 to be null). Ripristinato → verde.
• "e dice cosa manca... invece di lasciare un buco": mancanoPer forzata a restituire sempre [] → rosso immediato (expected 0 to be greater than 0). Ripristinato → verde.
• "nessuna pagina interroga il database da sola": aggiunta una db.prepare('SELECT 1') in io.astro → rosso immediato (il test intercetta letteralmente SELECT/.prepare( nel sorgente). Ripristinato → verde.

Suite completa e typecheck riverificati allo stato finale (dopo tutte le prove e i ripristini):

npm test

 Test Files  1 failed | 39 passed (40)
      Tests  1 failed | 327 passed (328)

npx tsc --noEmit

Output: nessuno (pulito).

git status --short

(nessuna riga: albero pulito, nessun residuo delle prove di rottura)

Cosa esiste alla fine di questo piano

Come previsto dal brief: un cliente entra, compila il questionario, vede il proprio referto — il radar a sette assi con l'area piena su ciò che sa e il perimetro tratteggiato (più l'elenco di cosa manca) su ciò che non sa ancora, la Fitness Age, le tre carte Performance/Energy/Recovery. Con i dati di oggi (solo questionario, nessun test fisico) sei assi su sette risultano tratteggiati — verificato, non solo dichiarato: nel test "restituisce i sette assi" tutti e sette compaiono comunque, e nella sessione di prova solo "Stile di Vita & Sonno" porta un numero.

Non deployato: come da vincolo del piano (consenso dati sanitari ancora aperto col consulente legale del cliente).

---

Rinforzo dopo revisione (2026-08-22): la prova sul congelamento resa discriminante

Stato: completato. Commit 6630be7 sopra a 7f01ee0.

Il problema confermato dal coordinatore: la mutazione originale del test "legge i punteggi congelati, non li ricalcola al volo" (peso di questionario_lifestyle, unico sotto-dominio del suo asse) passava per un'identita' algebrica — con un solo elemento disponibile in una media pesata, il peso si semplifica sia al numeratore sia al denominatore, quindi non puo' mai produrre una differenza, letto o ricalcolato che sia. Il test era verde per costruzione matematica, non perche' il congelamento funzionasse.

Correzione: la mutazione discriminante, con seed dedicato

tests/longevity/referto.test.ts:

• Aggiunta conCoperturaParziale(), come conCompilazione() ma con in piu' la risposta q_riposato: 8 (copre questionario_sonno). Serve solo a questo test: gli altri cinque restano su conCompilazione(), invariati.
• Il test "legge i punteggi congelati..." ora usa conCoperturaParziale() e muta il peso di hrv (0.50 → 0) in "Recupero & Sistema Nervoso" — un sotto-dominio assente in un asse a quattro elementi, dove solo questionario_sonno (0.20) e' misurato: copertura vera 0.20/1.00=0.20 (insufficiente, ma disponibili.length===1, non 0 — la formula del peso viene eseguita davvero, non bypassata dalla scorciatoia "nessun dato disponibile" di aggrega()). Azzerando hrv il totale scende a 0.50, copertura vera 0.20/0.50=0.40: attraversa COPERTURA_MINIMA, l'asse passerebbe da insufficiente a ok se il referto ricalcolasse.
• Commento esteso sopra la mutazione: spiega sia perche' QUESTA mutazione discrimina sia perche' quella vecchia (peso dell'unico sotto-dominio di un asse a un solo elemento) non discrimina mai — cosi' chi la tocca fra sei mesi non rimette una versione innocua.

La prova di rottura ripetuta sulla versione nuova

Backup di vista.ts, poi iniettato lo stesso ricalcolo di prima (calcolaSessione al posto di leggiScore):

- import { leggiScore } from './motore';
+ import { leggiScore, calcolaSessione } from './motore';
...
- const punteggi = leggiScore(db, sessioneId);
+ const punteggi = calcolaSessione(db, sessioneId) as unknown as ReturnType<typeof leggiScore>;

Comando:

npm test -- tests/longevity/referto.test.ts

Output:

 ❯ tests/longevity/referto.test.ts (6 tests | 1 failed) 20ms
     × legge i punteggi congelati, non li ricalcola al volo 7ms

AssertionError: expected '...' to be '...'
Expected: ...,"Recupero & Sistema Nervoso","valore":null,"copertura":0.2,...
Received: ...,"Recupero & Sistema Nervoso","valore":80,"copertura":0.4,...

Rosso, come atteso: l'asse passa da null/0.2 a 80/0.4, con effetto a cascata su ENERGY/RECOVERY. Ripristinato vista.ts dal backup (diff col backup: nessuna differenza), rilanciato:

npm test -- tests/longevity/referto.test.ts

 Test Files  1 passed (1)
      Tests  6 passed (6)

Verde, come atteso.

Verifiche finali

npm test

 Test Files  1 failed | 39 passed (40)
      Tests  1 failed | 327 passed (328)

Stesso rosso pre-esistente e fuori perimetro (tests/modifiche-agosto.test.ts > ... inaugurazione ...); nessuna regressione.

npx tsc --noEmit

Output: nessuno (pulito).

Commit

git add tests/longevity/referto.test.ts
git commit -m "longevity: la prova sul congelamento ora discrimina davvero il ricalcolo"

[feat/longevity 6630be7] longevity: la prova sul congelamento ora discrimina davvero il ricalcolo
 1 file changed, 44 insertions(+), 3 deletions(-)

git status dopo il commit: albero pulito.

---

Rinforzo dopo revisione (2026-08-22): il controllo sui colori ora guarda tutto il foglio

Stato: completato. Commit a56398e sopra a 6630be7.

Il problema confermato dal coordinatore: il test "nelle regole di un punteggio compaiono solo i colori ammessi" (tests/longevity/pagine.test.ts) filtrava le regole CSS sul selettore (if (!/lg-score/i.test(selettore)) continue;) — un elenco di QUALI regole guardare, non di quali colori sono ammessi. Le classi nuove di questo task (.lg-radar__voce-nome, .lg-radar__intro, .lg-macro__nota) non contengono la stringa lg-score, quindi non venivano mai scandite: un colore-giudizio lì dentro sarebbe passato indisturbato nonostante 6 test verdi.

Correzione: si scandisce tutto, le eccezioni si dichiarano

tests/longevity/pagine.test.ts — rimossa la riga di filtro sul selettore. Il ciclo ora itera ogni regola del foglio (che e' interamente prefissato lg- per costruzione, garantito dal test subito sopra). Aggiunto un elenco di eccezioni esplicite:

const ECCEZIONI: { selettore: string; valore: string; motivo: string }[] = [
  {
    selettore: '.lg-form__nav button:last-child:not(:only-child)',
    valore: '#fff',
    motivo: "testo bianco per contrasto sul bottone pieno d'accento — non un colore di punteggio",
  },
];

Con lo scan esteso a tutto il foglio, questa era l'unica riga che avrebbe generato un falso positivo (color: #fff sul bottone "Avanti/Invia" pieno d'accento — bianco per contrasto testo, non un giudizio sul punteggio): tutte le altre classi nuove del Task 3 usano gia' solo var(--c-heading)/var(--c-text-light), entrambe nella lista ammessa, quindi passano senza bisogno di eccezioni.

Le due prove richieste

1. Colore-giudizio su una classe del radar. Iniettato color: #cc0000; in .lg-radar__voce-nome:

npm test -- tests/longevity/pagine.test.ts

 ❯ ... in tutto il foglio compaiono solo i colori ammessi, salvo le eccezioni dichiarate
AssertionError: expected [ Array(1) ] to deeply equal []
+ [ ".lg-radar__voce-nome { color: #cc0000 }" ]

Rosso. Ripristinato dal backup.

2. Colore-giudizio su una classe del macro-score. Iniettato color: #cc0000; in .lg-macro__nota:

npm test -- tests/longevity/pagine.test.ts

 ❯ ... in tutto il foglio compaiono solo i colori ammessi, salvo le eccezioni dichiarate
AssertionError: expected [ Array(1) ] to deeply equal []
+ [ ".lg-macro__nota { color: #cc0000 }" ]

Rosso. Ripristinato dal backup (diff col backup: nessuna differenza).

Rilanciato dopo il secondo ripristino:

npm test -- tests/longevity/pagine.test.ts

 Test Files  1 passed (1)
      Tests  6 passed (6)

Verde. Entrambe le classi (radar e macro-score) sono ora sorvegliate — nessun buco residuo fra le due superfici nuove di questo task.

Verifiche finali

npm test

 Test Files  1 failed | 39 passed (40)
      Tests  1 failed | 327 passed (328)

Stesso rosso pre-esistente e fuori perimetro (tests/modifiche-agosto.test.ts > ... inaugurazione ...); nessuna regressione.

npx tsc --noEmit

Output: nessuno (pulito).

Commit

git add tests/longevity/pagine.test.ts
git commit -m "longevity: il controllo sui colori guarda tutto il foglio, non solo lg-score"

[feat/longevity a56398e] longevity: il controllo sui colori guarda tutto il foglio, non solo lg-score
 1 file changed, 23 insertions(+), 5 deletions(-)

git status dopo il commit: albero pulito.