docs: focus public documentation on product usage
This commit is contained in:
@@ -1,43 +0,0 @@
|
||||
# PSD — rollout controllato DWH REST
|
||||
|
||||
Questo runbook completa il [piano di accettazione autenticazione](../plans/2026-08-18-thothii-authentication-acceptance-and-psd-deployment.md) e il [programma di deployment PSD](../plans/2026-08-20-psd-server-deployment-program.md). Gate A e la parte dual-key di Gate B sono stati eseguiti con autorizzazioni separate. L'emendamento del proprietario del 2026-08-21 rinvia collaudo Mac, osservazione e revoca a prima di Project B; non autorizza ulteriori mutazioni.
|
||||
|
||||
## Invarianti
|
||||
|
||||
- ThothII sul server PSD: `postgres_direct` read-only, senza chiave `dwh-auth`.
|
||||
- Mac PSD e client remoti: `rest_api`, una chiave per installazione, HTTPS `.it` verificato.
|
||||
- `dwh-auth` è `systemd` indipendente, non Compose; non fermare o sostituire il vecchio stack ora.
|
||||
- Sessioni legacy, indici Qdrant e cache Ollama sono dati test: nessuna migrazione o backup per il cutover. Il vecchio stack resta comunque fino a cutover/rollback approvati.
|
||||
- Usare solo `/dwh/rpc/ping`, mai risultati clinici o catture Nginx grezze.
|
||||
|
||||
## Gate A — Task 9, servizio locale senza Nginx pubblico
|
||||
|
||||
Richiedere prima autorizzazione per SHA congelato, target, rollback e impatto legacy. Senza consenso, fermarsi e registrare solo `IN_DISCUSSION`.
|
||||
|
||||
1. Verificare in sola lettura architettura, gruppo `www-data`, nomi liberi, systemd, `nginx -t`, ping attuale e file legacy regolare `root:root` `0600`; non leggerlo, stamparlo o calcolarne hash.
|
||||
2. Costruire con `bash scripts/build-dwh-auth.sh --output /tmp/dwh-auth-release`; registrare solo SHA sorgente e checksum binario.
|
||||
3. Installare binario/unit/tmpfiles come nella [guida server](../install/dwh-auth-server.md): registry `root:dwh-auth` `2750`, lock/record `0640`, socket `dwh-auth:www-data` `0660`.
|
||||
4. Importare una sola legacy `legacy-shared` dal file protetto e creare `psd-mac-primary` in nuovo file `0600` sotto `/root/dwh-auth-provision/`; mai segreti in argv, ambiente, log o evidenze.
|
||||
5. Eseguire `dwh-auth check`, `systemd-analyze verify`, avviare l'unità e testare sul socket Unix con file header curl protetti `0600`: v1=204, legacy=204, casuale=401, assente=401.
|
||||
6. Salvare solo ID pubblici, owner/mode, stato unit/socket, timestamp, checksum binario/config e rollback. Non modificare Nginx in questo gate.
|
||||
|
||||
## Gate B — Task 10, Nginx e client
|
||||
|
||||
Serve un secondo consenso: presentare file, backup, canale consegna Mac, osservazione ed esiti 2xx/401/503.
|
||||
|
||||
1. Creare copie timestampate `root:root` `0600` di `/etc/nginx/sites-available/policlinicosandonato` e file coinvolti; non allegare configurazioni Nginx grezze alle evidenze.
|
||||
2. Aggiungere solo `/etc/nginx/conf.d/dwh-auth-rate-limit.conf` e route DWH; preservare upstream `http://127.0.0.1:3001/`, mantenere byte-identiche le location vector e rimuovere la chiave prima di PostgREST.
|
||||
3. Eseguire checker strutturale, scansione segreti con solo `PASS/FAIL` e metadati, installare candidati e `sudo nginx -t`. No raw diff: non eseguire o conservare raw diff, `nginx -T` o dump: il file legacy può contenere la chiave. Se uno fallisce, ripristinare backup prima di reload e registrare FAIL sanitizzato.
|
||||
4. Dopo consenso fare reload, poi HTTPS `.it` con CA e file header curl protetti 0600: v1=2xx, legacy=2xx, casuale=401, assente=401 su `/dwh/rpc/ping`; guasto autenticatore=503, mai accesso permissivo.
|
||||
5. **Deferred pre-Project-B:** consegnare al Mac chiave e CA separatamente, verificare fingerprint fuori banda, configurare vault GUI o `API_KEY_FILE`, poi **Validate workspace source** e **Test workspace connections**.
|
||||
6. **Deferred pre-Project-B:** completare 48 ore di osservazione comprendenti due cicli ETL delle 03:00, quindi revocare `legacy-shared` con ragione `shared-credential-rotation`; v1=2xx post-revoca, legacy=401 post-revoca e journal limitato senza chiavi/digest.
|
||||
|
||||
## Rollback e chiusura
|
||||
|
||||
Durante dual-key il rollback ripristina solo route/servizio revisionati, verifica `nginx -t` e fa reload autorizzato. Non ripristina chiavi revocate, PostgreSQL, dati legacy o stack. Scatta per TLS, risposte inattese, salute degradata o assenza di consenso.
|
||||
|
||||
Activity 1 resta `DEFERRED_PRE_PROJECT_B`: dual-key è attivo, ma PASS richiede ancora v1=2xx
|
||||
post-revoca, legacy=401 post-revoca, servizio/Nginx validi, log sanitizzati, rollback leggibile e
|
||||
accettazione owner. Il rinvio non blocca il survey e Project A privato; blocca Project B. Compilare
|
||||
[evidenza](../testing/evidence/psd-dwh-auth-rollout-report-template.md) e
|
||||
[collaudo](../testing/dwh-auth-manual-acceptance.md).
|
||||
@@ -1,92 +0,0 @@
|
||||
# Prompt operativo per Sol — deploy ThothII su PSD
|
||||
|
||||
## Ruolo
|
||||
|
||||
Sei l'orchestratore del deploy di ThothII sul server PSD. Devi guidare il lavoro
|
||||
in modo incrementale, verificabile e reversibile. Non assumere che una fase sia
|
||||
completata: richiedi evidenze e applica i gate descritti nei piani.
|
||||
|
||||
## Documenti normativi
|
||||
|
||||
Leggi prima questi file, in quest'ordine:
|
||||
|
||||
1. `AGENTS.md`
|
||||
2. `PROJECT_STATE.md`
|
||||
3. `docs/plans/2026-08-20-psd-server-deployment-program-design.md`
|
||||
4. `docs/plans/2026-08-20-psd-server-deployment-program.md`
|
||||
5. `docs/plans/2026-08-20-psd-server-survey.md`
|
||||
6. `docs/plans/2026-08-20-psd-server-project-a-standalone.md`
|
||||
7. `docs/plans/2026-08-20-psd-server-project-b-authentik.md`
|
||||
8. `docs/testing/psd-server-project-a-manual.md`
|
||||
9. `docs/testing/psd-server-project-b-manual.md`
|
||||
10. `docs/testing/evidence/psd-server-survey-report-template.md`
|
||||
11. `docs/testing/evidence/psd-server-project-a-report-template.md`
|
||||
12. `docs/testing/evidence/psd-server-project-b-report-template.md`
|
||||
|
||||
In caso di conflitto, prevalgono `AGENTS.md`, `PROJECT_STATE.md` e i piani
|
||||
specifici delle fasi nell'ordine Survey, Project A, Project B.
|
||||
|
||||
## Modelli e delega multi-agent
|
||||
|
||||
Verifica quali modelli e quali primitive multi-agent sono realmente disponibili
|
||||
nell'ambiente. Se disponibili:
|
||||
|
||||
- **Sol** mantiene il controllo del piano, dei gate, delle decisioni architetturali,
|
||||
della sicurezza, di Authentik, Nginx, Supabase e del rollback.
|
||||
- **Terra** esegue esclusivamente survey e controlli read-only: host, Docker,
|
||||
checkout, Compose, Nginx, TLS, Aritmolab, Authentik e PostgreSQL.
|
||||
- **Luna** esegue comandi bounded e verifiche ripetibili: build, compose, `tht`
|
||||
(`status`, `doctor`, `pi`), smoke test, preprocessing e migrazioni già
|
||||
autorizzate dal piano.
|
||||
|
||||
Se Terra o Luna non sono disponibili, lavora in sequenza con il modello
|
||||
disponibile. Non simulare agenti inesistenti.
|
||||
|
||||
Per ogni incarico delegato specifica sempre: obiettivo, comandi consentiti,
|
||||
operazioni vietate, evidenze da raccogliere e formato della risposta:
|
||||
|
||||
```text
|
||||
status: PASS | FAIL | BLOCKED
|
||||
facts: fatti osservati
|
||||
commands: comandi eseguiti (senza segreti)
|
||||
evidence: file o output redatti
|
||||
risks: rischi residui
|
||||
blockers: impedimenti
|
||||
```
|
||||
|
||||
Non riportare password, token, cookie, client secret o variabili d'ambiente
|
||||
sensibili nei log o nei report.
|
||||
|
||||
Le attività read-only indipendenti possono essere eseguite in parallelo. Tutte
|
||||
le mutazioni devono essere sequenziali, con checkpoint e verifica prima della
|
||||
fase successiva. Non parallelizzare stop/start dello stack, build/recreate,
|
||||
migrazioni, modifiche ad Authentik, Nginx o al bilanciatore.
|
||||
|
||||
## Regole inderogabili
|
||||
|
||||
1. Inizia soltanto con il survey read-only.
|
||||
2. Non spegnere, modificare o rimuovere il vecchio ThothII prima del survey e
|
||||
del backup verificabile.
|
||||
3. Non procedere a Project A senza un report Survey `PASS`.
|
||||
4. Project A usa autenticazione locale e deve essere provato completamente prima
|
||||
di iniziare Project B.
|
||||
5. Project B con Authentik parte solo dopo il `PASS` esplicito di Project A.
|
||||
6. Il database Supabase esistente va riusato tramite schemi dedicati; non creare
|
||||
un nuovo database per isolare il dataset.
|
||||
7. Il workspace remoto `tht-workspace-psd` resta unico: REST sul Mac e
|
||||
PostgreSQL diretto sul server. I segreti non vanno in Git.
|
||||
8. Il link dalla sidebar di Aritmolab deve restare funzionante e il percorso
|
||||
pubblico finale deve passare dal balancer e da Nginx.
|
||||
9. Conserva sempre un rollback verso il vecchio stack e verso l'autenticazione
|
||||
locale finché il cutover non è approvato.
|
||||
|
||||
## Prima azione richiesta
|
||||
|
||||
Leggi tutti i documenti normativi. Poi avvia **solo Task 1 — Survey** del piano
|
||||
generale. Produci un report consolidato usando il relativo template, con esito
|
||||
`GO` o `NO-GO`, senza eseguire modifiche persistenti. Fermati e segnala ogni
|
||||
credenziale Authentik mancante, permesso insufficiente, ambiguità sul balancer o
|
||||
discrepanza tra dominio osservato e configurazione di Aritmolab.
|
||||
|
||||
Dopo il survey attendi l'approvazione del proprietario prima di eseguire
|
||||
Project A.
|
||||
@@ -1,455 +0,0 @@
|
||||
# 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/plans/2026-08-20-psd-server-deployment-program-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 runbook eseguibile è in
|
||||
`docs/operations/psd-dwh-auth-rollout.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 |
|
||||
Reference in New Issue
Block a user