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
- La preparazione statica di Project A privato è autorizzata; stop del legacy e start del nuovo
  restano vietati fino a `SURVEY_GO_PROJECT_A_PRIVATE` e a un consenso di mutazione separato
- Project B remains forbidden fino ai PASS automatico, umano e del proprietario per Project A

## Current activity and resume point

- Current activity: `2`
- Title: Identify accountable owners for the private Project A scope
- Resume from: Activity 2, assign owner/authority for legacy rollback, direct DWH, workspace and Pi/LLM
- Discussion rule: una sola attività può essere `IN_DISCUSSION`
- Allowed states: `PENDING`, `IN_DISCUSSION`, `DEFERRED_PRE_PROJECT_B`, `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 | `DEFERRED_PRE_PROJECT_B` | Proprietario del progetto | Chiusura obbligatoria prima di Project B |
| 2 | Assegnazione dei responsabili dei componenti condivisi | `IN_DISCUSSION` | Proprietario del progetto | Owner privati A e shared B distinti |
| 3 | Risoluzione del dominio pubblico `.it` oppure `.com` | `BLOCKED` | Unassigned | Necessario per Project B, non per A privato |
| 4 | Topologia e responsabilità del load balancer | `BLOCKED` | Unassigned | Necessario per Project B/route opzionale |
| 5 | Accesso read-only protetto ad Authentik | `BLOCKED` | Unassigned | Necessario per Project B, non per A privato |
| 6 | Accesso catalog-only protetto a PostgreSQL | `BLOCKED` | Unassigned | DWH direct read-only ancora da provare |
| 7 | Confine temporaneo e cleanup del vecchio ThothII | `PASS` | Proprietario del progetto | Retain fino a Project B PASS; cleanup esatto separato |
| 8 | Accesso Git read-only al workspace PSD | `BLOCKED` | Curator da confermare | Checkout/deploy key server mancanti |
| 9 | Metadati Pi e LLM verificabili | `BLOCKED` | Unassigned | Policy e reachability redatte mancanti |
| 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: `DEFERRED_PRE_PROJECT_B`
- 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 proprietario ha revisionato e approvato la specifica scritta. Il piano eseguibile è in
    `docs/superpowers/plans/2026-08-20-dwh-rest-per-installation-auth.md`; separa sviluppo e
    verifica del componente dai due gate espliciti di mutazione PSD;
  - la credenziale condivisa corrente, priva del nuovo identificativo pubblico, sarà l’unico record
    temporaneo `legacy_raw` con ID `legacy-shared`. Dopo la revoca non saranno accettate chiavi
    prive del formato versionato per installazione.
- 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.
- Owner amendment 2026-08-21: Gate A e dual-key Gate B sono eseguiti; il Mac live test, le 48 ore
  comprendenti due cicli ETL delle 03:00 e la revoca di `legacy-shared` sono rinviati al gate
  obbligatorio prima di Project B. Il rinvio non equivale a PASS.
- Blockers: per chiudere Activity 1 restano il collaudo Mac, l'osservazione completa, la revoca,
  v1 positivo post-revoca e legacy `401`.
- Next step: continuare Activity 2–10 per lo scope Project A privato; riaprire Activity 1 prima di
  congelare il candidato Project B.

## Activity 2: Identify accountable owners for shared components

- Status: `IN_DISCUSSION`
- 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 ora la matrice distinguendo componenti necessari a Project A privato e
  componenti shared/pubblici rinviabili a Project B.

## Activity 3: Resolve the authoritative public origin

- Status: `BLOCKED`
- 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: `BLOCKED`
- 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: `BLOCKED`
- 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: `BLOCKED`
- 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: il wrapper ETL `ConnectionFactory` ha aperto una sessione dichiarata
  read-only e ha eseguito sole query aggregate a `pg_catalog`. Il database è PostgreSQL 15.8;
  l'identità disponibile è `postgres`, owner dello schema `datawarehouse`, con `USAGE` e
  `CREATE`. Su tutte le 163 relazioni catalogate possiede SELECT e anche tutti i privilegi di
  scrittura/DDL tabellari verificati. Nessun nome tabella o dato clinico è stato raccolto.
- Decision: il meccanismo esistente è valido per il survey catalogico, ma è vietato come identità
  runtime del nuovo core perché non è least-privilege né read-only.
- Blockers: il DBA deve fornire un ruolo dedicato con soli USAGE/SELECT e una route diretta
  certificabile dal nuovo core. Il PostgREST DWH è loopback host su 127.0.0.1:3001 e non prova il
  percorso PostgreSQL diretto richiesto da Project A.
- Next step: definire con il DBA ruolo, secret-file protetto, TLS/rete e query di grant da ripetere;
  non creare il ruolo durante il survey.

## Activity 7: Bind the disposable legacy boundary and cleanup exclusions

- Status: `PASS`
- Accountable owner: Proprietario del progetto (confermato dall'utente)
- Objective: mantenere il vecchio ThothII solo come confine temporaneo di cutover e rimuovere
  esclusivamente le sue risorse dopo il PASS reale di Aritmolab.
- Why this is required: Aritmolab usa oggi i container legacy, ma il proprietario ha dichiarato
  sacrificabili sessioni, configurazione e dati del vecchio ThothII.
- Ordered actions:
  1. inventariare nuovamente container, image ID, source e data immediatamente prima dello stop;
  2. preservare invariati i due network condivisi e l'Evidence ETL esterna;
  3. chiudere la route e fermare solo i container legacy nel gate Project A autorizzato;
  4. conservare container, immagini, source e data fino al PASS automatico, umano e owner di B;
  5. rimuovere poi soltanto gli exact target sotto un'autorizzazione cleanup separata.
- Required redacted evidence: inventario esatto, owner, restart recipe, esclusioni shared, decisioni
  Project A/B e manifest finale di cleanup; nessun contenuto di secret.
- Discussion notes: il legacy stack è ancora attivo e invariato. Compose project `thothii` usa
  `/home/chirone/ThothII/compose.yaml`; i servizi sono `core` e `frontend`, senza named volume.
  Il solo bind applicativo RW è `/home/chirone/thothii-data` (con i bind Pi annidati); Evidence è
  un bind RO esterno. Una lettura tar verso `/dev/null` di source e data ha dato
  `legacy_backup_readability=PASS`. Il source è circa 1.05 GB e il data bind circa 1.9 MB.
  I dry-run Compose passano solo fornendo il path non segreto
  `PI_AUTH_FILE=/home/chirone/thothii-data/pi-config/agent/auth.json` insieme a
  `--env-file deploy/thothii.env -p thothii -f compose.yaml`; stop individua entrambi i container
  e start è sintatticamente valido (non trova container arrestati mentre lo stack è ancora attivo).
- Decision: nessun backup legacy è richiesto. I container, immagini, source e data già presenti
  restano il solo rollback temporaneo fino al PASS Project B; non si crea alcun utente host. Le
  risorse esclusive potranno essere cancellate dopo il collaudo Aritmolab, mentre network shared,
  ETL Evidence, Omics, LocalLLM, DWH, `dwh-auth`, Supabase, Authentik e Superset sono esclusi.
- Blockers: nessuno per questa decisione survey. Stop/start, route change e cleanup restano tre
  autorizzazioni di mutazione separate e non sono autorizzati da questo PASS.
- Next step: usare il design e piano clean-replacement approvati; non eseguire ancora mutazioni.

## Activity 8: Provide read-only PSD workspace Git access

- Status: `BLOCKED`
- 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: `BLOCKED`
- 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. Una lettura whitelist di `settings.json` ha rilevato Pi 0.80.3,
  provider `deepseek`, modello `deepseek-v4-pro` e thinking `high`, senza leggere
  `auth.json`. Un singolo probe senza tool, contesto o sessione ha prodotto solo
  `pi_reachability=FAIL`. Il catalogo custom dichiara inoltre il solo provider `local-qwen`.
- Decision: i metadati sono verificati, ma reachability e coerenza default/catalogo non passano.
- Blockers: diagnosticare il FAIL senza esporre la credenziale e confermare il provider/modello
  approvato per Project A; il mismatch NVML/GPU resta rischio separato, non un motivo per assumere
  che il percorso CPU funzioni.
- Next step: eseguire un controllo assistito e sanitizzato della configurazione provider, quindi
  ripetere una sola reachability probe bounded.

## Read-only resume — 2026-08-21

- Host/source: Linux x86_64, Docker 29.1.1, Compose 2.40.3, application worktree clean at
  `7118950416b3008a8182825de027c7f8b235de57`; Qdrant/Ollama images are local, while the required
  embedding image/model is not yet proved local.
- Capacity: approximately 1.1 TB free on `/home` and 36 GB on `/`; several loopback candidate
  ports are currently free. These facts do not reserve a path or port.
- Legacy: project `thothii` is still running and unchanged. Source is
  `/home/chirone/ThothII` at `6ca4275`; the only RW application bind is
  `/home/chirone/thothii-data`, plus the nested Pi binds. The source is about 1.05 GB and the data
  bind about 1.9 MB. No backup was created.
- Recovery decision: legacy state is disposable; no backup is required. Existing stopped
  containers, images, source and data remain only as the temporary Project A/B rollback boundary.
- Identity decision: neither UID nor GID 10001 maps to a host account. No host identity will be
  created. The new image retains numeric `10001:10001`, confined to its distinct writable roots;
  the existing operator owns source/configuration. Recheck both `getent` lookups before creating
  paths and stop on any new mapping.
- Shared exclusion: never remove the Omics/LocalLLM networks or external ETL Evidence bind.
- Candidate paths: documented examples `/srv/thothii` and `/srv/thothii-backups` are absent and
  therefore only candidates; they have not been created. `127.0.0.1:18080` è il candidato
  frontend e risultava libero al momento del survey, ma non è riservato e va ricontrollato prima
  dello start. Existing `/home/chirone/thothii-data` must not be reused.
- Workspace: the canonical private remote is documented as
  `git@github.com:mptyl/tht-workspace-psd.git`; a non-interactive read-only remote query resolved
  `main` at `bfbabf9f2defcf861a3225296eaff8c6d44c0ac9`. No server checkout or dedicated deploy-key
  reference is present at the documented local paths, and the credential's inability to push is
  not yet proved.
- Pi/LLM: legacy Pi version `0.80.3` is visible, but provider/model/thinking/credential reference
  and bounded reachability remain unknown.
- Shared scope: `.it` resolves locally and `.com` does not, Nginx is valid/active, Authentik
  2026.2.1 and Supabase components are running. Owner, LB contract, Authentik inventory and
  PostgreSQL catalog grants remain unproved and are not inferred.
- Decision: `SURVEY_NO_GO` for Project A private remains. The bounded work authorized now is
  limited to planning/static preparation; no source clone, protected tree, backup, stop or start
  has been performed.

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

Un nuovo `SURVEY_GO_PROJECT_A_PRIVATE` richiede:

- owner e autorità di stop/start/rollback identificati per il legacy e Project A;
- accessi read-only PostgreSQL, workspace Git e Pi/LLM verificati;
- identità DWH dimostrata read-only;
- inventario, restart recipe e cleanup exclusions legacy verificabili;
- risorse e percorsi della nuova installazione approvati;
- report redatto, secret-scan valido e checksum verificato;
- approvazione esplicita del proprietario.

`SURVEY_GO_PROJECT_B` richiede inoltre:

- collaudo Mac `rest_api` con chiave per installazione;
- 48 ore di osservazione comprendenti due cicli ETL delle 03:00;
- credenziale `legacy-shared` revocata, v1 positiva e legacy `401`;
- owner e autorità di modifica/rollback per tutti i componenti shared;
- origine pubblica unica e load-balancer contract provati;
- accesso read-only Authentik e inventario della release installata;
- ogni altro blocker pubblico/shared delle Activity 2–9 chiuso.

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 |
| 2026-08-21 | Sequencing amendment | Activity 1 deferred pre-B; survey ripreso read-only; Project A private resta NO-GO | Owner/Sol |
| 2026-08-21 | Clean replacement | Activity 7 PASS; legacy disposable dopo B; nessun account host 10001 | Owner/Sol |