# Handoff — verifiche estese ThothII / Omics

Aggiornato il 27 settembre 2026. L’utente ha chiesto di affidare a un’attività
successiva le verifiche residue e di pubblicare la documentazione del rilascio.
**Aggiornamento e collaudo funzionale conclusi con successo; matrice estesa aperta.**
Questo documento è il punto di ripresa per le sole prove ancora da registrare.

## Stato acquisito e confini

Leggere [PROJECT_STATE.md](../../PROJECT_STATE.md), il
[report del rilascio](2026-09-26-server-release-execution.md), la
[matrice di accettazione](../testing/authentication-manual-acceptance.md) e il
[contratto upstream](../install/authentication-upstream.md).

Il 26 settembre sono stati distribuiti ThothII `497ab840` e il fix proxy Omics
`928f7e9f`, conservando l’immagine web Omics. Backup verificato e rollback sono
registrati nel report. L’utente ha confermato accesso senza secondo login,
controlli IT/EN, tema, fullscreen/Esc e avvio → interruzione → ripresa di una
sessione. Le prove automatiche di health, proxy anonimo/header falsificati,
asset, TLS locale e preservazione dati/configurazioni sono passate.

Queste sono evidenze del rilascio, non una nuova attestazione dello stato live.
Non ripetere backup/deploy né attivare maintenance per questo collaudo. Usare
account autorizzati e sessioni fittizie; DWH read-only. Non modificare ruoli,
Authentik, credenziali, modelli, archivi o configurazioni per far passare una prova.
Un problema che richieda un nuovo rilascio va prima diagnosticato e pianificato.

## Prima azione alla ripresa

1. Rileggere le conferme nel report: non chiedere all’utente di ripetere il ciclo
   funzionale già riuscito, salvo regressioni o cambio di versione.
2. Verificare in sola lettura revisioni/container e stato dell’installazione.
   Distinguere eventuale drift dalla baseline pubblicata; preservare il lavoro
   e le sessioni in corso. Il `check` dello script di rilascio si aspetta lo stato
   **precedente** al deploy: non usarlo come controllo corrente.
3. Concordare con l’operatore browser e account già disponibili: autorizzato,
   normale, amministratore e, se disponibile, senza capability Datamart Builder.
   Accedere dal normale login Omics; non chiedere password/cookie/token in chat.
   Se manca un profilo, registrare quel caso come non eseguito senza crearne uno.

**Completato quando:** sono registrati data, revisioni effettive, modalità
embedded/upstream, browser e disponibilità dei profili, senza dati personali.
L’agente può proseguire con le letture tecniche mentre attende l’operatore.

## Prove residue

Tutti i casi sotto partono da **non eseguito**. La colonna “chi” indica chi compie
la parte principale; l’agente prepara i controlli tecnici e registra i risultati.

| ID | Chi | Azione concreta | Risultato necessario |
| --- | --- | --- | --- |
| V1 — lingua persistita | Operatore + agente | Creare una sessione fittizia con UI italiana, annotarne `interaction_language` tramite il normale stato sessione, interromperla, cambiare UI in inglese e riprendere **la stessa** sessione. | UI inglese, lingua della sessione ancora italiana; domande/scelte nella lingua persistita, SQL e contenuti authored invariati. La ripresa generica già provata non chiude questo caso. |
| V2 — identità e ruoli | Operatore + agente | Aprire `/datamart-builder/api/me` dalla sessione Omics autenticata; confrontare profilo normale e admin con le capability attese. Provare una richiesta amministrativa di sola lettura con il profilo normale. Se disponibile, provare pagina/API con un account senza capability. | Issuer `portal`, subject Django stabile, ruoli coerenti, `session` e `csrfToken` null. Profilo normale senza accesso amministrativo anche lato server; account senza capability rifiutato. Registrare solo esiti e codici, non identità o payload completi. |
| V3 — logout e riconnessione | Operatore | Aprire due schede Omics/Datamart Builder con una sessione fittizia; fare logout in una, tornare nell’altra e provocare un ricontrollo con reload/riconnessione. Rientrare attraverso Omics. | La nuova richiesta `/me` e le nuove aperture SSE non riusano l’accesso scaduto; UI protetta rimossa al ricontrollo. Non richiedere la chiusura istantanea di uno stream già aperto: non è il contratto. |
| V4 — origine delle scritture | Agente, con login dell’operatore | Preparare una coppia di richieste autenticate equivalenti su una risorsa fittizia autorizzata: prima same-origin, poi con origine estranea, attraversando il proxy pubblico. Confrontare lo stato della risorsa prima/dopo. Usare un harness HTTP locale con credenziali solo in memoria o file protetto; non affidarsi a `fetch` per impostare manualmente `Origin`. | La scrittura same-origin riesce e quella cross-origin è negata senza mutazioni. Dimostrare che la seconda richiesta è autenticata: un 403 dovuto alla sola assenza di cookie non prova la difesa Origin. I test isolati già verdi sono evidenza complementare, non sostituiscono questo caso. |
| V5 — lettura amministrazione | Operatore autorizzato | Aprire Database, Memory ed Evidence e controllare disponibilità dei dati preesistenti, selezione, pannelli e scroll. | Viste leggibili, nessun errore e nessuna scrittura/sincronizzazione necessaria per aprirle. Annotare quale area è stata verificata senza copiare contenuti clinici. |
| V6 — reload e preferenze | Operatore | Con sessione selezionata e Pi fermo, scegliere lingua e tema dal portale e ricaricare. | Preferenze e selezione coerenti; i documenti si riaprono senza avviare automaticamente Pi o una nuova generazione. La lingua persistita della sessione resta quella originale. |
| V7 — HTTPS esterno | Operatore | Confermare se le prove precedenti sono state svolte da una postazione esterna al server. Se non attestato, aprire il portale dal client abituale attraverso il nome pubblico e verificare config, asset e connessione eventi. | Accesso HTTPS senza avvisi di certificato, mixed content o errori di rete. Annotare browser e tipo di accesso, senza IP personali. Il curl locale con CA e risoluzione a 127.0.0.1 non chiude questo caso. |

Per V4 preparare e rendere verificabile il probe prima di eseguirlo: deve agire
solo sulla risorsa di prova concordata e controllare l’assenza di mutazioni nel
caso negato. In assenza di credenziali utilizzabili localmente, lasciare il caso
non eseguito; non estrarre sessioni di altri utenti o cambiare le regole Origin.
I comandi e gli endpoint concreti vanno derivati dalla versione effettivamente
installata, non inventati a partire da questo elenco.

## Registrazione e criterio di chiusura

Aggiornare questa tabella dopo ogni prova, collegando evidenze redatte o una
conferma esplicita dell’operatore. Un caso parziale resta aperto per i profili o
scenari mancanti. In caso di difetto, annotare riproduzione, atteso/ottenuto e
revisione; correggere e riprovare il caso interessato prima di dichiararlo superato.

| Caso | Stato iniziale | Data / versione / evidenza |
| --- | --- | --- |
| V1 | Non eseguito | — |
| V2 | Non eseguito | — |
| V3 | Non eseguito | — |
| V4 | Non eseguito | — |
| V5 | Non eseguito | — |
| V6 | Non eseguito | — |
| V7 | Non eseguito | — |

**Chiusura delle verifiche residue:** ogni caso V1–V7 ha esito e prova registrati;
per dichiarare la matrice estesa superata devono essere tutti verdi. Un rinvio
esplicito o un prerequisito mancante va riportato come tale, non come successo.
Aggiornare quindi report di rilascio, questo handoff e PROJECT_STATE.md.

L’aggiornamento applicativo e il collaudo funzionale già confermati restano conclusi;
questo follow-up non richiede di reinstallare né di ripetere il rilascio.