ThothII/docs/reports/2026-09-27-server-acceptance-handoff.md

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, il report del rilascio, la matrice di accettazione e il contratto upstream.

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.