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 |