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, identify the accountable credential owner and the credential type without revealing its value
- 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` | Unassigned | Identificare owner e tipo di credenziale |
| 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: Unassigned
- 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: il survey ha osservato la credenziale durante l'analisi della configurazione
  Nginx relativa al DWH. Non è ancora provato se sia una chiave API, un header condiviso o un altro
  tipo di secret; non va confusa automaticamente con una password PostgreSQL.
- Decision: No decision recorded
- Blockers: owner non identificato; tipo di credenziale non verificato; consumer e supporto alla
  doppia credenziale non inventariati.
- Next step: il proprietario identifica il responsabile della credenziale della route DWH e indica
  se appartiene al team Nginx, Supabase/PostgreSQL o a un altro team.

## 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 |