ThothII/docs/reports/2026-09-26-server-release-handoff.md

Handoff — rilascio coordinato ThothII / Omics

Rilasciato il 26 settembre 2026; accettazione automatica superata alle 19:35 Europe/Rome. Per riprendere, leggere il report di esecuzione: servizi avviati, maintenance inattiva, backup verificato e rollback disponibile. La finestra era stata confermata esplicitamente dall’utente; non richiederla di nuovo per completare il collaudo già autorizzato. Il 27 settembre l’utente ha confermato accesso, controlli dell’interfaccia e avvio/interruzione/ripresa di una sessione: collaudo funzionale positivo. Per le verifiche residue usare il nuovo handoff del 27 settembre, con passi e registro delle prove. L’utente le ha affidate a un’attività successiva.

Usare lo script corretto documentato nel report: durante il rilascio è stata corretta soltanto la lettura degli header Cache-Control ripetuti nel controllo. Non rieseguire le fasi pre-deploy sullo stato già rilasciato.

Snapshot storico della sospensione delle 17:40

Il resto di questo file conserva lo stato precedente alla ripresa e al rilascio. Il report di esecuzione sostituisce le indicazioni operative e le attività residue qui sotto; il piano approvato descrive le scelte.

Prima azione alla ripresa

Leggere questo handoff, quindi AGENTS.md, PROJECT_STATE.md, docs/operations/server-codex-handoff.md, docs/install/authentication-upstream.md e docs/testing/authentication-manual-acceptance.md. Per l'inventario completo e i digest delle immagini operative, leggere docs/reports/2026-09-26-server-release-preflight.md. Quel preflight è storico: la correzione proxy allora mancante è ora preparata e testata soltanto in isolamento, come descritto sotto.

La prossima attività è revisionare e completare lo script di rilascio in bozza, validare il piano senza mutazioni operative e presentarlo all'utente con backup e rollback. Solo dopo la sua conferma eseguire le fasi operative e il collaudo.

Richiesta dell'utente e confini

• Aggiornare ThothII e Omics secondo il runbook, preservando dati, workspace, Pi, provider, modelli e credenziali già presenti sul server.
• Usare main ThothII includente 497ab84031e285464fdbb73e6e0ce9252687e3ab; conservare i progressi server Omics successivi alla consegna GitHub fca10901….
• Conservare checkout sporchi e file locali. Nessun reset, force push, rimozione volumi o tht setup --complete; non usare codex/guided-standalone-install.
• L'utente ha autorizzato preparazione, correzione e test isolati. Prima del fermo/proxy/migrazioni/recreate operativi vuole vedere il piano risolto e confermare la finestra. Il suo «procediamo, fai la tua parte» ha avviato la preparazione, non approvato uno script ancora inesistente/incompleto.
• L'utente può fare il collaudo da browser: avvisarlo quando sarà il momento e fornire prove precise. Non chiedergli password in chat.
• Ha autorizzato a cercare credenziali di akadmin / mpancotti: trovata solo la presenza di AUTHENTIK_BOOTSTRAP_PASSWORD in /home/chirone/chirone-authentik/docker/.env. Valore non mostrato, non copiato, nessun login tentato e validità attuale non verificata. Nessuna password mpancotti trovata. I due utenti sono locali Authentik, non LDAP.

Stato operativo, invariato

• Checkout di lavoro /home/chirone/Thoth: main 497ab840…, allineata Gitea; il report 2026-09-14-server-embedded-omics-release.md era già non tracciato. Sono stati aggiunti solo i report locali di questa attività.
• Checkout ThothII operativo /srv/thothii-v2/source/ThothII: main b1723c34c467980d007094af078d966d460cde2b, 30 file modificati + due non tracciati, preservato integralmente. Le modifiche sono già recepite dalla nuova main, che contiene anche le correzioni successive.
• Omics operativo /home/chirone/omics_portal: master pulito 1cf7ea90a669a26bf3bc51749eab4d07981da472. Comprende la consegna shell GitHub fca10901a73666ca257d8f4cc4b77066295c400a e la correzione Superset successiva. Non ripetere l'integrazione e non tornare a fca10901.
• Core ancora thothii-v2-core:49333a2d-session-memory-fix; frontend ancora thothii-v2-frontend:b1723c34-session-dialogs-20260914; Omics web ancora omics_portal-web image ID sha256:27aa100690b110bf596322b1b0a31acc178ca9d1c709bc10382cbeecbfb5aeca.
• Ultimo controllo: zero processi Pi RPC, maintenance active=false, admissions 0. Ricontrollare alla ripresa e prima del fermo.
• Backup nuovo /srv/thothii-v2/backups/20260926-coordinated-release non esiste. Backup storico 14 settembre verificato (14 checksum, tar e indici dump), non un backup dello stato odierno, nessuna prova di restore eseguita.

Installazione e preservazione comprovata

Descrittore effettivo, il cui percorso va mantenuto per preservare project identity: /srv/thothii-v2/source/ThothII/deploy/psd-server-v2/thothii-installation.yaml. Project thothii-7f901b48fe35, schema 2, profile server, embedded/en/omics-portal, upstream, session storage local, THOTH_PUBLIC_EXPOSURE=false già preesistente. Non cambiare modalità auth o disattivare controlli per far partire l'app.

Preservati e confrontati:

• default interaction zai/glm-5.3;
• deepseek/deepseek-v4-pro, deepseek/deepseek-v4-flash;
• local-qwen/qwen3.6-35b-a3b;
• embedding ollama/qwen3-embedding:0.6b, dimensione 1024;
• catalog.json, pi/models.json, pi/settings.json, frontend/config.js: proiezioni nuove identiche byte per byte a quelle operative;
• Compose candidato: environment, reti, porte, secret/config mount e mount persistenti uguali. Solo due bind di script versionati identici cambiano percorso seguendo il nuovo checkout (catalog-db-init.sql, embedding-model-init.sh).

Il CLI rifiuta correttamente i segreti se eseguito da UID diverso da 10001. Per diagnostica usare UID 10001 con gruppi operator/Docker e DOCKER_CONFIG leggibile; non cambiare ownership dei segreti. Esempio verificato:

sudo -n setpriv --reuid=10001 --regid=10001 --groups=1014,988 \
  env DOCKER_CONFIG=/srv/thothii-v2/operator/releases/20260926-coordinated/docker-config \
  /usr/local/bin/tht \
  --installation /srv/thothii-v2/source/ThothII/deploy/psd-server-v2/thothii-installation.yaml \
  doctor --json

Correzione proxy pronta, non applicata

Il proxy operativo è ancora vulnerabile: senza cookie, /datamart-builder/assets/api/me con header X-Thoth-Trusted-* inventati restituisce 200 e principal sintetico. API canonica restituisce 403. Confermato anche via nginx HTTPS host con CA verificata e DNS locale. Il test ha usato un soggetto inesistente, nessun dato reale o scrittura.

Causa: il prefisso pubblico degli asset inoltra alla radice del frontend, che espone /api/ e converte gli header Trusted in principal del core.

Correzione candidata Omics:

• branch codex/thothii-assets-proxy-isolation;
• commit locale 928f7e9fff2aba895416776fecf5668ee957d237;
• parte da 1cf7ea90…, nessun push eseguito;
• checkout stabile pulito: /srv/thothii-v2/releases/omics-928f7e9fff2aba895416776fecf5668ee957d237;
• clone di lavoro: /tmp/thothii-release-20260926/omics-source;
• sei file cambiati: nginx, test statico, tre file di test dinamico, docs integrazione.

Il filtro accetta solo file Vite con hash ed estensioni previste, alla radice o sotto assets/ per compatibilità. Le route pubbliche config/asset rimuovono Cookie, Authorization e tutte le famiglie di header identità; solo GET/HEAD. Il frontend attuale emette file alla radice, non tutti in assets/: il primo filtro eccessivamente stretto è stato corretto grazie al test reale.

Test completati:

• test dinamico nuovo riproduceva il difetto prima della correzione;
• 6/6 test della catena nginx Omics → nginx frontend reale → core/Django sintetici, rete Docker interna, senza porte host o volumi operativi;
• verificati traversal codificati, canonical auth, Origin esatta, config, tutti i file del manifest reale, diniego scritture alle route statiche;
• gli stessi 6/6 passano anche con l'immagine frontend precedente: il rollback può e deve mantenere la correzione del proxy;
• suite Omics shell/auth/nginx/Superset 28/28 dopo la modifica;
• nessun container/rete omics-proxy-check-* rimasto al momento della sospensione.

Esecuzione test ripetibile, solo se necessaria per nuove modifiche:

cd /srv/thothii-v2/releases/omics-928f7e9fff2aba895416776fecf5668ee957d237
THOTHII_TEST_FRONTEND_IMAGE=thothii-v2-frontend:497ab840-preflight \
OMICS_TEST_IMAGE=omics-portal:proxy-isolation-tests \
OMICS_TEST_NGINX_IMAGE=sha256:b3c656d55d7ad751196f21b7fd2e8d4da9cb430e32f646adcf92441b72f82b14 \
python3 test_support/thothii/run_proxy_integration.py

Artefatti pronti e bozza da revisionare

Directory stabile: /srv/thothii-v2/operator/releases/20260926-coordinated. Contiene:

• descriptor.next.yaml: cambia soltanto projectDirectory verso la nuova main e il percorso del suo overlay git-ssh; modelCatalog/auth/shell/workspace invariati.
• operator.next.env: cambia soltanto tag immagini in 497ab840-preflight.
• compose.portal-upstream.next.yaml: aggiorna anche il tag frontend letterale, che non seguiva la variabile del core.
• baseline.json: hash protetti dei file operativi per rilevare drift prima della finestra; non contiene valori segreti.
• compose-preservation.json: esito positivo del confronto Compose candidato.
• tht.next: nuovo binario non installato; SHA256 0d39a93fb0a3b2147541a746c75832db20302f3a604bf6510da69d3731bcd783.
• nginx.safe.conf: copia della configurazione candidata testata.
• proxy-green.log, proxy-rollback-test.log, omics-proxy-tests.log.
• release.DRAFT.py: bozza appena scritta, non revisionata, non compilata, non eseguita neppure in modalità check. Non lanciarla prima di una revisione completa e della conferma della finestra per le fasi mutanti.

Originale della bozza: /tmp/thothii-release-20260926/release.py. Non trattare il flag --window-confirmed come un'approvazione dell'utente.

Sorgenti ThothII pronti, main pulita e fetch Gitea con divergenza 0/0: /srv/thothii-v2/releases/497ab84031e285464fdbb73e6e0ce9252687e3ab. Vecchio checkout dirty lasciato al suo posto per rollback.

Immagini candidate già costruite, non distribuite:

• core thothii-v2-core:497ab840-preflight, sha256:182f4e0d63404cb7ed6a0e272441e9c55ed27e2bb16fdbf4d7162f892ac76dc7;
• frontend thothii-v2-frontend:497ab840-preflight, sha256:5f5a4f81139432d0ac41025c3006edaf1258b623ce388242700b1b20fcce6421.

Test ThothII già superati: 782 frontend, 152 backend su Node 24.16, 31 browser, build/typecheck core/frontend, build CLI e generazione isolata, doctor attuale 13/13. Log in /tmp/thothii-release-20260926. La sottodirectory generation contiene copie sensibili protette root:root 0600 sotto directory 0700: non pubblicarla.

Lavoro residuo e criteri per avanzare

1. Revalidare solo ciò che può essere cambiato durante la pausa: immagini, SHA/stato checkout operativo, configurazioni contro baseline, processi Pi, migrazioni Omics pendenti e raggiungibilità. Se c'è drift, preservarlo e aggiornare il piano prima di proseguire.
2. Revisionare lo script DRAFT, inclusi escaping del controllo processi Pi, gestione errori/parzialità backup, health/readiness reale Omics (il suo healthcheck verifica solo catalogo, non Gunicorn), generazione con UID corretto, digest image vs container, conservazione proprietari e dati, rollout/rollback della correzione proxy. Validare sintassi e fase read-only solo dopo revisione. Aggiungere prove HTTPS locali, risoluzione alias dopo recreate e controllo log redatto: la bozza non copre ancora integralmente il runbook.
3. Finalizzare scelta lifecycle Omics. La bozza mantiene l'esatta immagine web operativa perché l'unica modifica applicabile è nginx (shell/Superset già presenti); fa fast-forward del checkout al fix, stop/start web per backup consistente e recreate nginx. Lo start riesegue il suo entrypoint, compresi migrate/compilemessages/collectstatic. Spiegare questa scelta nel piano finale. Se si decide di ricostruire web, il suo .dockerignore è minimale: creare un contesto pulito, aggiungere il catalogo Superset reale valido, escludere segreti.
4. Finalizzare backup odierno. La bozza salva immagini/code/config, ferma ingressi e applicativi dopo maintenance e controllo Pi, crea dump catalogo e PostgreSQL Omics condiviso, ferma supporti ThothII per snapshot raw coerenti, archivia bind/volumi e verifica checksum/tar/indici dump. Valutare spazio e interruzioni; il vecchio backup verificato non basta. Il DB Omics è condiviso (postgres su supabase-db, app in kokoro, metadata in chirone_meta): un restore dell'intero DB non fa parte del rollback ordinario.
5. Presentare piano risolto, comandi, backup e rollback all'utente, chiedendo conferma della finestra. Solo allora installare CLI/config, generare proiezioni, ricreare le app e applicare nginx. Nessuna migrazione nuova rilevata finora.
6. Collaudare e poi coinvolgere l'utente. Login unico, /me e ruoli, IT/EN, tema/fullscreen, logout/seconda scheda, sessione fittizia con Pi/SSE, stop/save/ripresa e lingua immutabile, diniego cross-origin autenticato, Database/Memory/Evidence e accesso HTTPS da postazione esterna.

Rollback: ripristinare immagini ThothII, CLI, descriptor/env/override e proiezioni salvati; preservare dati e mantenere il fix proxy, già testato col frontend precedente. Ripristinare il vecchio nginx riaprirebbe il bypass. Nessun restore dati automatico, reset Git o eliminazione volumi.

Ambiente strumenti

La sandbox exec fallisce prima dell'avvio (bwrap: loopback … Operation not permitted): i comandi sono stati eseguiti con require_escalated e motivazione. Auto-review li ha consentiti; nessun rifiuto pendente. Non sono stati usati subagenti. Skill applicate: diagnosing-bugs, writing-for-agents per questo handoff. Nessun goal formale attivo. Per lo stato successivo alla ripresa, usare il piano revisionato collegato in apertura.