ThothII/docs/operations/psd-server-survey-remediation-checklist.md

PSD Server Survey — Remediation Checklist

Purpose and authority

Questo documento permette al proprietario e a Sol di discutere, decidere e chiudere uno alla volta i blocker emersi dal survey read-only del server PSD. È il punto di ripresa operativo tra sessioni: registra soltanto fatti sanitizzati, decisioni, responsabili e riferimenti a evidenze protette.

Fonti normative:

• docs/operations/psd-server-sol-orchestration-prompt.md
• docs/plans/2026-08-20-psd-server-deployment-program.md
• docs/plans/2026-08-20-psd-server-survey.md
• docs/superpowers/specs/2026-08-20-psd-survey-remediation-checklist-design.md

Questo documento non autorizza modifiche a server, servizi, database, Nginx, load balancer, Authentik, Aritmolab o repository esterni.

Program gate

• Program result: SURVEY_NO_GO
• Survey report: /var/tmp/thothii-psd-survey.fJh7DS/survey-report.md
• Survey report SHA-256: 36461b6c7d1e44d055f24d6919e892b7017352ac9eb99ac67b9ae62f0614f8e7
• Legacy stack: deve restare acceso e invariato durante la discussione di questa lista
• Project A remains forbidden fino a un nuovo SURVEY_GO e all'approvazione esplicita del proprietario
• Project B remains forbidden fino ai PASS automatico, umano e del proprietario per Project A

Current activity and resume point

• Current activity: 1
• Title: Rotate or revoke the exposed DWH credential safely
• Resume from: Activity 1, review the written per-installation authentication design, then prepare its executable implementation and rotation plan
• Discussion rule: una sola attività può essere IN_DISCUSSION
• Allowed states: PENDING, IN_DISCUSSION, BLOCKED, PASS

How to use this checklist

1. Leggere Current activity e Resume from.
2. Discutere soltanto l'attività corrente.
3. Non inserire password, token, cookie, chiavi private, stringhe di connessione, claim grezzi o valori di secret.
4. Registrare solo percorsi protetti, owner, mode, timestamp, nomi o ID di oggetti, checksum ed esiti sanitizzati.
5. Alla fine della discussione aggiornare stato, note, decisione, evidenze, blocker e prossimo passo.
6. Spostare Current activity solo quando il gate dell'attività corrente è soddisfatto oppure il proprietario decide esplicitamente di parcheggiarla come BLOCKED.
7. Non riaprire un'attività PASS salvo nuova evidenza che ne invalidi la decisione.

Activity summary

ID	Attività	Stato	Responsabile	Prossimo gate
1	Rotazione controllata della credenziale DWH esposta	IN_DISCUSSION	Proprietario del progetto	Revisionare la specifica scritta e approvare il piano eseguibile
2	Assegnazione dei responsabili dei componenti condivisi	PENDING	Unassigned	Elenco owner confermato
3	Risoluzione del dominio pubblico .it oppure .com	PENDING	Unassigned	Origine autorevole documentata
4	Topologia e responsabilità del load balancer	PENDING	Unassigned	Route, health, TLS, rollback e allowlist verificati
5	Accesso read-only protetto ad Authentik	PENDING	Unassigned	Inventario API autorizzato e redatto
6	Accesso catalog-only protetto a PostgreSQL	PENDING	Unassigned	Catalogo, grant e PostgREST verificati
7	Backup e rollback del vecchio ThothII	PENDING	Unassigned	Backup verificabile e restart recipe completa
8	Accesso Git read-only al workspace PSD	PENDING	Unassigned	SHA, descriptor e deploy key verificati
9	Metadati Pi e LLM verificabili	PENDING	Unassigned	Versione, policy e reachability redatte
10	Conservazione evidenze e nuovo survey bounded	PENDING	Unassigned	Nuovo report e decisione proprietario

Activity 1: Rotate or revoke the exposed DWH credential safely

• Status: IN_DISCUSSION
• Accountable owner: Proprietario del progetto (confermato dall'utente)
• Objective: sostituire o revocare in modo controllato la credenziale DWH comparsa nell'output interno del survey, senza interrompere consumer legittimi e senza esporne nuovamente il valore.
• Why this is required: la credenziale deve essere considerata compromessa; non può essere usata come base affidabile per completare il survey o iniziare Project A.
• Ordered actions:
  1. identificare il team che gestisce la route DWH, il suo meccanismo di autenticazione e la custodia del secret;
  2. determinare il tipo di credenziale senza leggerla o copiarla in questa checklist;
  3. inventariare i consumer tramite riferimenti di configurazione e secret object;
  4. scegliere una transizione a doppia credenziale oppure una finestra atomica con rollback;
  5. generare e distribuire il nuovo secret attraverso il meccanismo protetto approvato;
  6. verificare i consumer autorizzati, l'assenza del nuovo valore nei log e la continuità del vecchio stack;
  7. revocare la vecchia credenziale e provare che non venga più accettata;
  8. registrare soltanto evidenze redatte.
• Required redacted evidence:
  • owner e autorizzazione della rotazione;
  • tipo e identificatore non sensibile della credenziale;
  • percorso protetto o secret object, senza contenuto;
  • elenco dei consumer aggiornati;
  • timestamp e risultati dei test positivi e negativi;
  • conferma di revoca della credenziale precedente;
  • procedura di rollback e relativo esito.
• Discussion notes:
  • la credenziale osservata è stata identificata, senza rileggerne il valore, come chiave statica X-API-Key applicata da Nginx alla route DWH REST /dwh/; è distinta dalle password PostgreSQL;
  • /home/chirone/chirone/etl documenta PostgREST come integrazione HTTP esterna, mentre i processi ETL e Superset usano PostgreSQL diretto;
  • il vecchio ThothII e Chirone WP3 usano PostgreSQL diretto nei profili locali/server; Supabase Studio è un pannello amministrativo e non appartiene al data-plane applicativo;
  • il design approvato resta invariato: il Mac usa rest_api, il nuovo ThothII sul server PSD usa postgres_direct con ruolo DWH dedicato e realmente read-only;
  • la ricognizione dei repository ha rilevato materiale sensibile hardcoded in file tracciati, senza riportarne i valori. La bonifica e la rotazione dei segreti coinvolti restano obbligatorie.
  • il censimento statico non trova consumer /dwh/ in ETL, Superset o nel Chirone WP3 attivo: usano PostgreSQL diretto. Il vecchio container thothii-core-1 è configurato con transport: direct; i due ThothII restano comunque tecnicamente capaci di usare REST;
  • i log Nginx redatti provano 18.523 richieste /dwh/ dal 23 luglio al 19 agosto 2026: 18.481 hanno user-agent classificato python-requests e gli endpoint RPC corrispondono prevalentemente a introspezione e campionamento Thoth. La sorgente è una sola, privata e compatibile con un proxy/load balancer; non prova che esista un solo client finale;
  • l'ipotesi che il traffico sia generato dal job ETL delle 03:00 è smentita: nella finestra 02:30–03:30 Europe/Rome non compare nessuna richiesta /dwh/. Il 99,37% del traffico è concentrato il 13 agosto tra le 17:38 e le 20:03;
  • la firma del 13 agosto corrisponde a undici preprocessing Thoth: undici list_tables, e per ciascuna esecuzione 163 chiamate a ognuno dei tre RPC per-tabella più 1.180 top_values, cioè 1.670 richieste per ciclo. PROJECT_STATE.md registra proprio il preprocessing PSD live del 13 agosto su 163 tabelle, con più rerun e correzioni emerse durante l'esecuzione;
  • il DAG ETL nightly_etl_orchestrator è schedulato con 0 3 * * *, ma scrive il DWH tramite PostgreSQL/psycopg2 diretto. Nel codice tracciato non chiama /dwh/, gli RPC Thoth o tht workspace preprocess, né emerge un trigger indiretto verso Thoth;
  • la configurazione Nginx nominalmente attiva accetta una sola chiave tramite confronto letterale in un endpoint auth_request. Non esiste una mappa a più chiavi: la doppia credenziale richiede un refactor, backup, nginx -t, reload e rollback in una fase di mutazione autorizzata.
  • il proprietario conferma che il ThothII sul Mac deve continuare a usare REST e che sono previste molte altre installazioni remote, senza tunnel SSH verso Supabase. /dwh/ è quindi un'interfaccia remota stabile e multi-client, non una compatibilità temporanea.
  • il proprietario decide di mantenere il certificato TLS corrente. L'endpoint esterno REST presenta lo stesso certificato self-issued di Nginx, valido fino al 21 giugno 2027 e con SAN per supabase-aritmolab.policlinicosandonato.it; non copre un eventuale dominio .com;
  • il manuale di installazione deve trattare TLS_CA_FILE come necessario per ogni client che non abbia già quel certificato nel proprio trust store, spiegando consegna affidabile, verifica del fingerprint, rinnovo e aggiornamento coordinato delle installazioni;
  • non esiste un ambiente di test. La rotazione dovrà quindi usare una verifica production-safe: backup, finestra dual-key, RPC ping senza dati clinici, test positivo/negativo e rollback.
  • il proprietario approva un componente dwh-auth riutilizzabile ma opzionale, incluso nel repository senza modificare il protocollo dei client portabili o il CLI tht;
  • su PSD dwh-auth avrà un lifecycle systemd indipendente dallo stack ThothII e comunicherà con Nginx tramite socket Unix. Lo stop o la sostituzione di ThothII non dovrà interrompere i client REST;
  • il registro sarà composto da file protetti, versionati e aggiornati atomicamente, con un file per generazione della chiave. Conterrà digest SHA-256 di segreti casuali da almeno 256 bit e metadati non sensibili, senza SQLite o nuove dipendenze runtime;
  • le chiavi saranno assegnate alle installazioni, non alle persone. Saranno prive di scadenza predefinita, con scadenza opzionale e revoca manuale;
  • creazione e import leggeranno o scriveranno soltanto file protetti. Nessun segreto sarà accettato come argomento, stampato o inserito in log, JSON, documenti o repository;
  • la gestione sarà fail-closed: credenziali non valide riceveranno 401, mentre guasti del servizio o del registro saranno mappati a 503 senza fallback permissivo;
  • il proprietario conferma che le sessioni, gli indici e le cache del vecchio ThothII erano solo test e non richiedono migrazione o attività di salvaguardia dedicate. Restano necessari il rollback della route DWH condivisa e il rispetto del gate esplicito prima di fermare lo stack;
  • il design approvato è scritto in docs/superpowers/specs/2026-08-20-dwh-rest-per-installation-auth-design.md e richiede una revisione del proprietario prima del piano di implementazione.
• Decision: il nuovo ThothII server userà PostgreSQL diretto; il Mac e le future installazioni remote useranno REST. La chiave condivisa corrente non è un modello finale accettabile: la rotazione esposta userà una transizione a doppia credenziale e l'architettura target assegnerà un'identità revocabile distinta a ogni installazione. Supabase Studio non sarà usato come trasporto. Il proprietario del progetto è accountable per coordinare la rotazione. Il meccanismo target è il servizio server-only dwh-auth, indipendente dallo stack ThothII, con registro a file e una chiave revocabile per installazione.
• Blockers: la specifica scritta attende la revisione del proprietario; mancano ancora il piano eseguibile, la sorgente protetta per importare la chiave legacy, la procedura realizzata di aggiornamento/verifica del Mac, la documentazione TLS completa, l'autorizzazione alla mutazione e la revoca provata della vecchia chiave.
• Next step: dopo l'approvazione della specifica scritta, preparare il piano eseguibile di implementazione e rotazione dual-key con test automatici, aggiornamento Mac, prova positiva/negativa e rollback. Nessuna modifica Nginx avviene durante questa discussione.

Activity 2: Identify accountable owners for shared components

• Status: PENDING
• Accountable owner: Unassigned
• Objective: associare ogni componente condiviso a una persona o a un team con autorità di lettura, modifica, approvazione e rollback.
• Why this is required: la leggibilità di una configurazione non implica autorità a modificarla.
• Ordered actions:
  1. identificare gli owner di DNS/load balancer, Nginx/certificati, Authentik, Supabase/PostgreSQL, Aritmolab, workspace Git e backup legacy;
  2. registrare il canale di approvazione e la procedura di escalation;
  3. confermare separatamente chi può autorizzare Project A e Project B.
• Required redacted evidence: nomi dei team, ruoli, canali operativi e conferme di responsabilità; nessun contatto personale sensibile.
• Discussion notes: Not discussed
• Decision: No decision recorded
• Blockers: nessun owner condiviso è stato ancora formalmente confermato.
• Next step: compilare la matrice owner/componente dopo la chiusura dell'Activity 1.

Activity 3: Resolve the authoritative public origin

• Status: PENDING
• Accountable owner: Unassigned
• Objective: scegliere sulla base di evidenze l'unica origine pubblica finale tra il dominio .it osservato e il dominio .com riportato nel piano.
• Why this is required: callback OIDC, certificato, cookie, Nginx, load balancer e sidebar devono concordare sulla stessa origine HTTPS.
• Ordered actions:
  1. ottenere la dichiarazione autorevole dell'owner DNS/load balancer;
  2. verificare record DNS, route, backend, certificato e redirect;
  3. confrontare l'origine con la configurazione e la sidebar di Aritmolab;
  4. registrare l'origine approvata e le discrepanze da correggere in Project B.
• Required redacted evidence: hostname finale, record/route sanitizzati, SAN del certificato, destinazione sidebar e approvazione dell'owner.
• Discussion notes: il survey ha osservato .it; il piano cita .com. La discrepanza è aperta.
• Decision: No decision recorded
• Blockers: owner DNS/load balancer non identificato e origine browser-visible non provata.
• Next step: ottenere la dichiarazione autorevole dopo l'assegnazione degli owner.

Activity 4: Establish the load-balancer contract

• Status: PENDING
• Accountable owner: Unassigned
• Objective: documentare il confine effettivo del load balancer e la procedura reversibile per le route temporanea e finale.
• Why this is required: il survey locale non ha potuto provare owner, backend, health check, TLS, source range o allowlist.
• Ordered actions:
  1. identificare superficie di configurazione e owner;
  2. registrare backend, porta, health check, punto TLS e source range verso Nginx;
  3. documentare deploy, validazione e rollback;
  4. stabilire se una route temporanea può essere limitata agli operatori;
  5. definire una prova positiva e una negativa dell'allowlist senza creare ancora la route.
• Required redacted evidence: nomi/ID delle route, backend e health check sanitizzati, ownership, capacità di allowlist e procedura di rollback.
• Discussion notes: Not discussed
• Decision: No decision recorded
• Blockers: il load balancer non è ispezionabile dalla superficie locale autorizzata.
• Next step: coinvolgere l'owner identificato nell'Activity 2.

Activity 5: Provide protected read-only Authentik survey access

• Status: PENDING
• Accountable owner: Unassigned
• Objective: permettere un inventario Authentik bounded e read-only della versione installata.
• Why this is required: applicazioni, provider, flow, mapping, gruppi, service account, permessi API e procedura di export non sono stati verificati.
• Ordered actions:
  1. identificare l'owner Authentik e la procedura di backup/export;
  2. predisporre una credenziale read-only o un'esecuzione assistita dall'owner;
  3. comunicare solo percorso, owner, mode e usabilità del secret;
  4. inventariare nomi/ID e convenzioni senza recuperare secret write-only;
  5. confrontare il comportamento con OpenAPI e documentazione della release installata.
• Required redacted evidence: versione, nomi/ID degli oggetti, permission set della credenziale, riferimento all'export e risultati sanitizzati.
• Discussion notes: Not discussed
• Decision: No decision recorded
• Blockers: nessuna credenziale amministrativa/API utilizzabile è stata stabilita.
• Next step: ottenere dall'owner un meccanismo protetto post-rotazione.

Activity 6: Provide protected catalog-only PostgreSQL survey access

• Status: PENDING
• Accountable owner: Unassigned
• Objective: verificare database, schemi, ruoli, grant, migrazioni e PostgREST con sole query di catalogo.
• Why this is required: il runtime DWH read-only, lo stato di thoth_sessions e i confini Supabase non sono provati.
• Ordered actions:
  1. identificare DBA e procedura protetta di connessione;
  2. verificare database, utente corrente, schemi e owner;
  3. verificare i grant sullo schema datawarehouse senza write probe clinici;
  4. verificare stato di thoth_sessions e migration records;
  5. verificare gli schemi esposti da PostgREST;
  6. registrare TLS/CA, backup e convenzioni per ruoli migrator/runtime.
• Required redacted evidence: risultati catalogici bounded, nomi dei ruoli, attributi e grant, schemi PostgREST, riferimento a backup e TLS; nessuna stringa di connessione.
• Discussion notes: Not discussed
• Decision: No decision recorded
• Blockers: non esiste ancora un meccanismo psql approvato post-rotazione.
• Next step: far predisporre dal DBA l'accesso catalog-only.

Activity 7: Prove legacy backup and rollback

• Status: PENDING
• Accountable owner: Unassigned
• Objective: dimostrare che il vecchio ThothII possa essere preservato e ripristinato prima di qualsiasi stop.
• Why this is required: source, container, bind e network sono inventariati, ma backup verificato, controller e restart recipe non sono disponibili.
• Ordered actions:
  1. identificare owner e meccanismo lifecycle compatibile;
  2. confermare assenza di lavoro utente da preservare;
  3. definire contenuti, destinazione e protezione del backup;
  4. definire checksum e verifica di leggibilità;
  5. scrivere comandi esatti di stop/start e ordine di chiusura/ripristino route;
  6. eseguire il backup soltanto nella successiva fase autorizzata, prima dello stop.
• Required redacted evidence: inventario, percorso backup, checksum, owner, restart recipe e rollback route; nessun contenuto di secret.
• Discussion notes: il legacy stack è ancora attivo e invariato.
• Decision: No decision recorded
• Blockers: lifecycle supportato, backup owner e comandi esatti non stabiliti.
• Next step: approvare la procedura senza eseguirla durante la discussione.

Activity 8: Provide read-only PSD workspace Git access

• Status: PENDING
• Accountable owner: Unassigned
• Objective: verificare il repository remoto condiviso e il suo stato corrente dal server senza capacità di push.
• Why this is required: SHA, descriptor, trasporti, Evidence, annotazioni e scope della deploy key non sono stati osservati dal server.
• Ordered actions:
  1. identificare curator e owner della deploy key;
  2. fornire un riferimento protetto alla chiave server read-only;
  3. verificare remote, branch e SHA con modalità non interattiva;
  4. verificare catalogo, schema v3, trasporti, Evidence e annotazioni;
  5. provare che la credenziale server non possa effettuare push.
• Required redacted evidence: remote, branch, SHA, descriptor blob, stato Evidence/annotations e attestazione read-only della deploy key.
• Discussion notes: Not discussed
• Decision: No decision recorded
• Blockers: nessun checkout workspace o deploy credential utilizzabile è stato localizzato.
• Next step: coinvolgere il curator e predisporre l'accesso server read-only.

Activity 9: Make Pi and LLM metadata verifiable

• Status: PENDING
• Accountable owner: Unassigned
• Objective: verificare versione Pi, provider, modello, thinking level, riferimento credenziale e reachability LLM senza esporre il secret.
• Why this is required: la root Pi legacy non è attraversabile dall'operatore del survey e i default del nuovo source non provano la configurazione in esecuzione.
• Ordered actions:
  1. identificare owner della configurazione Pi/LLM;
  2. scegliere tra esecuzione assistita dall'owner e accesso read-only allowlisted;
  3. estrarre esclusivamente metadati non sensibili;
  4. eseguire un controllo bounded di reachability senza stampare credenziali;
  5. registrare anche il mismatch NVML/GPU come rischio separato, non come blocker CPU.
• Required redacted evidence: versione, provider, model ID, thinking level, endpoint sanitizzato, percorso/mode della credenziale e risultato di reachability.
• Discussion notes: host x86_64; due GPU NVIDIA osservate, ma nvidia-smi non è utilizzabile per mismatch driver/libreria NVML. Il deployment CPU resta da valutare con le immagini pinned.
• Decision: No decision recorded
• Blockers: configurazione Pi protetta non leggibile e nessun endpoint LLM credential-free noto.
• Next step: ottenere un controllo assistito o permessi read-only mirati.

Activity 10: Retain evidence and run the missing bounded survey checks

• Status: PENDING
• Accountable owner: Unassigned
• Objective: conservare le evidenze protette, ripetere soltanto i controlli mancanti e produrre una nuova decisione verificabile.
• Why this is required: il report corrente è SURVEY_NO_GO e non può essere promosso per inferenza.
• Ordered actions:
  1. scegliere il protected evidence root definitivo;
  2. trasferire la directory del survey senza modificarne i contenuti e verificare il digest;
  3. confermare che le Activity 1–9 siano PASS oppure abbiano una risoluzione proprietario esplicitamente accettata;
  4. eseguire solo i controlli bounded mancanti del piano survey;
  5. aggiornare il report e verificarne checksum e secret hygiene;
  6. chiedere la decisione esplicita del proprietario.
• Required redacted evidence: percorso finale, digest, matrice Activity 1–9, nuovi risultati bounded, report aggiornato e decisione firmata.
• Discussion notes: Not discussed
• Decision: No decision recorded
• Blockers: dipende dalla chiusura delle Activity 1–9 e dall'approvazione del retention root.
• Next step: avviare soltanto dopo la chiusura dei blocker precedenti.

Fresh survey and owner gate

Un nuovo SURVEY_GO richiede contemporaneamente:

• credenziale DWH precedente revocata e rotazione verificata;
• owner e autorità di modifica/rollback identificati;
• origine pubblica unica e load-balancer contract provati;
• accessi read-only Authentik, PostgreSQL, workspace Git e Pi/LLM verificati;
• identità DWH dimostrata read-only;
• backup e restart recipe legacy verificabili;
• risorse e percorsi della nuova installazione approvati;
• report redatto, secret-scan valido e checksum verificato;
• approvazione esplicita del proprietario.

Il PASS tecnico del survey non autorizza automaticamente Project A. L'autorizzazione deve essere registrata separatamente.

Change log

Data	Attività	Modifica	Autore
2026-08-20	Initial	Creata checklist; Activity 1 aperta, Activity 2–10 pending	Sol