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