docs: plan PSD server deployment program
This commit is contained in:
@@ -0,0 +1,166 @@
|
||||
# Progetto A PSD — collaudo manuale
|
||||
|
||||
Questo documento guida il collaudo umano del nuovo ThothII sul server con autenticazione locale.
|
||||
Non sostituisce i controlli automatici del piano. Compilarlo soltanto dopo che Sol ha dichiarato
|
||||
verdi installazione, workspace, DWH, Qdrant, Ollama e preprocessing.
|
||||
|
||||
## Regole
|
||||
|
||||
- Eseguire i comandi dal terminale locale del server; non usare tunnel SSH.
|
||||
- Non copiare nel rapporto password, cookie, token, chiavi, hash, stringhe di connessione o righe di
|
||||
log che li contengano.
|
||||
- Usare un amministratore locale e un utente ordinario creati appositamente.
|
||||
- Non effettuare più tentativi di password errata del necessario: il login applica rate limiting.
|
||||
- Per ogni prova segnare `PASS`, `FAIL` o `PENDING`, con una nota breve e non sensibile.
|
||||
- Un solo `FAIL` obbligatorio impedisce di avviare il Progetto B.
|
||||
|
||||
## Dati iniziali
|
||||
|
||||
| Campo | Valore redatto |
|
||||
|---|---|
|
||||
| Data/ora UTC | |
|
||||
| SHA ThothII | |
|
||||
| SHA workspace | |
|
||||
| Installation descriptor | percorso protetto, senza contenuto |
|
||||
| Origine di test | loopback oppure hostname privato |
|
||||
| Endpoint temporaneo usato | sì/no |
|
||||
| ID domanda di prova approvata | |
|
||||
| Operatore | |
|
||||
|
||||
## 1. Stato generale
|
||||
|
||||
Eseguire:
|
||||
|
||||
```bash
|
||||
THT_BIN=<percorso-tht>
|
||||
INSTALLATION=<percorso-assoluto-thothii-installation.yaml>
|
||||
"$THT_BIN" --installation "$INSTALLATION" status
|
||||
"$THT_BIN" --installation "$INSTALLATION" doctor --json
|
||||
"$THT_BIN" --installation "$INSTALLATION" auth check --json
|
||||
"$THT_BIN" --installation "$INSTALLATION" pi test
|
||||
```
|
||||
|
||||
| Prova | Risultato atteso | Esito | Note |
|
||||
|---|---|---|---|
|
||||
| Stato servizi | frontend, core, qdrant ed embedding sani; initializer completato | | |
|
||||
| Doctor | tutti i controlli obbligatori passano | | |
|
||||
| Autenticazione | modalità `local`, configurazione pronta | | |
|
||||
| Pi | provider e modello rispondono | | |
|
||||
| Secret hygiene | nessun secret nell’output | | |
|
||||
|
||||
## 2. Confine di rete
|
||||
|
||||
Dal terminale controllare i listener e la configurazione renderizzata secondo il piano.
|
||||
|
||||
| Prova | Risultato atteso | Esito | Note |
|
||||
|---|---|---|---|
|
||||
| Frontend | pubblicato solo su loopback o tramite endpoint privato approvato | | |
|
||||
| Core | nessuna porta host pubblica | | |
|
||||
| Qdrant | nessuna porta host pubblica nel profilo server | | |
|
||||
| Ollama | nessuna porta host pubblica | | |
|
||||
| URL produzione | non raggiunge il nuovo stack | | |
|
||||
| Endpoint privato, se usato | sorgente autorizzata ammessa | | |
|
||||
| Endpoint privato, se usato | sorgente non autorizzata respinta prima di ThothII | | |
|
||||
|
||||
Se non esiste un endpoint privato, usare il browser headless/API sul server. Non segnare come
|
||||
eseguite prove browser che non sono state realmente svolte.
|
||||
|
||||
## 3. Autenticazione locale
|
||||
|
||||
Eseguire tramite frontend/browser quando disponibile; altrimenti usare richieste same-origin dal
|
||||
terminale, conservando cookie e password soltanto in file temporanei mode `0600`, poi eliminandoli.
|
||||
|
||||
| Prova | Azione | Risultato atteso | Esito | Note |
|
||||
|---|---|---|---|---|
|
||||
| Accesso anonimo | aprire pagina/API protetta | appare login oppure HTTP 401 | | |
|
||||
| Password errata | un tentativo con utente valido | errore generico; nessun dettaglio account | | |
|
||||
| Utente ordinario | login corretto | accesso alle sessioni | | |
|
||||
| Confine ruoli | aprire Pi Management/amministrazione | negato o non visibile | | |
|
||||
| Logout | uscire e ricaricare | sessione rifiutata, nuovo login richiesto | | |
|
||||
| Amministratore | login corretto | funzioni amministrative previste disponibili | | |
|
||||
| Disabilitazione | Sol disabilita l’utente di prova | login rifiutato genericamente | | |
|
||||
| Riabilitazione | Sol riabilita l’utente | login nuovamente possibile | | |
|
||||
| Invalidazione | cambio password/ruolo o `logout-all` | vecchia sessione non più valida | | |
|
||||
| Remember me | login persistente, riavvio core | sessione ancora valida entro TTL | | |
|
||||
| CSRF | mutazione senza token corretto | richiesta respinta | | |
|
||||
|
||||
Non disabilitare o demansionare l’ultimo amministratore abilitato.
|
||||
|
||||
## 4. Workspace e DWH
|
||||
|
||||
Eseguire:
|
||||
|
||||
```bash
|
||||
"$THT_BIN" --installation "$INSTALLATION" \
|
||||
workspace inspect --workspace psd-clinical --json
|
||||
"$THT_BIN" --installation "$INSTALLATION" \
|
||||
workspace vector inspect --workspace psd-clinical --json
|
||||
```
|
||||
|
||||
| Prova | Risultato atteso | Esito | Note |
|
||||
|---|---|---|---|
|
||||
| Revisione Git | coincide con lo SHA approvato | | |
|
||||
| Trasporto server | `postgres_direct` | | |
|
||||
| Database/schema | database Supabase rilevato, schema `datawarehouse` | | |
|
||||
| Utente DWH | read-only dimostrato dai grant | | |
|
||||
| Workspace Mac | prova separata conferma ancora `rest_api` | | |
|
||||
| Qdrant | 1024 dimensioni, cosine, indici payload richiesti | | |
|
||||
| Ollama | `qwen3-embedding:0.6b` | | |
|
||||
| Evidence | corpus Git attivo alla stessa revisione | | |
|
||||
|
||||
## 5. Preprocessing e idempotenza
|
||||
|
||||
Esaminare i due risultati consecutivi del preprocessing prodotti da Sol.
|
||||
|
||||
| Prova | Risultato atteso | Esito | Note |
|
||||
|---|---|---|---|
|
||||
| Introspezione DWH | completata senza scritture cliniche | | |
|
||||
| Annotazioni FK | revisione umana registrata e legata al digest corretto | | |
|
||||
| Schema index | record presenti con workspace revision | | |
|
||||
| Evidence index | documenti/chunk presenti con workspace revision | | |
|
||||
| Seconda esecuzione | nessun duplicato; contenuti invariati riconosciuti | | |
|
||||
| Identità effettiva | invariata tra i due run | | |
|
||||
|
||||
## 6. Sessione completa F1–F8
|
||||
|
||||
Usare una domanda innocua approvata, senza identificativi reali di pazienti.
|
||||
|
||||
| Fase | Controllo manuale | Esito | Note |
|
||||
|---|---|---|---|
|
||||
| F1 | domanda compresa/disambiguata correttamente | | |
|
||||
| F2 | concetti e contesto coerenti | | |
|
||||
| F3 | tabelle candidate ragionevoli | | |
|
||||
| F4 | colonne/join curati e confermati | | |
|
||||
| F5 | piano CTE comprensibile | | |
|
||||
| F6 | ogni CTE testata e approvata | | |
|
||||
| F7 | SQL finale read-only e validato | | |
|
||||
| F8 | conclusione, memoria e riepilogo coerenti | | |
|
||||
|
||||
Durante una fase intermedia chiudere/riprendere la sessione una volta. Il resume deve tornare
|
||||
all’ultima fase incompleta senza creare una nuova domanda.
|
||||
|
||||
Verificare infine:
|
||||
|
||||
| Prova | Risultato atteso | Esito | Note |
|
||||
|---|---|---|---|
|
||||
| Stato | sessione `finalized` | | |
|
||||
| SQL | solo lettura; validazione DWH verde | | |
|
||||
| Artefatti | manifest, question, schema linking, Evidence, CTE, SQL, validation presenti | | |
|
||||
| Decisioni | gate registrati nel ledger | | |
|
||||
| Persistenza | artefatti leggibili dopo riavvio | | |
|
||||
| Chat/SSE | non richiesti come persistenza | | |
|
||||
|
||||
## 7. Decisione
|
||||
|
||||
| Gate | Esito |
|
||||
|---|---|
|
||||
| Tutti i controlli obbligatori PASS | |
|
||||
| Nessun secret raccolto | |
|
||||
| Rollback vecchio stack ancora disponibile | |
|
||||
| Progetto B autorizzabile | |
|
||||
|
||||
Decisione finale: `PROJECT_A_PASS` / `PROJECT_A_FAIL` / `PROJECT_A_PENDING`
|
||||
|
||||
Revisore e data: ______________________________________
|
||||
|
||||
Motivazione sintetica: ______________________________________
|
||||
Reference in New Issue
Block a user