7.6 KiB
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,FAILoPENDING, con una nota breve e non sensibile. - Un solo
FAILobbligatorio 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
Prima del gate manuale di avvio, per una descriptor server con runtime projection eseguire solo il
controllo redatto sudo tht --installation "$INSTALLATION" auth status --json. Il risultato deve
dire ready ed equal: true. Se è blocked, mancante o diverso dal canonical root, non avviare:
Sol può eseguire sudo tht --installation "$INSTALLATION" auth publish e ripetere il controllo,
senza copiare YAML, hash, password, token o environment nel rapporto. Questo documento non
autorizza l'avvio; Project A resta soggetto a un'esplicita autorizzazione separata.
Eseguire:
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:
"$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 | DEFERRED_PRE_PROJECT_B; in quel gate deve confermare rest_api |
||
| Qdrant | 1024 dimensioni, cosine, indici payload richiesti | ||
| Ollama | qwen3-embedding:0.6b |
||
| Evidence | corpus Git attivo alla stessa revisione |
Per l'emendamento del proprietario del 2026-08-21, solo la riga Workspace Mac può restare
DEFERRED_PRE_PROJECT_B nella chiusura privata di Project A. Non equivale a PASS e deve essere
eseguita prima di Project B insieme all'osservazione dual-key e alla revoca legacy.
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 | NO finché il gate Mac/osservazione/revoca non è PASS |
Decisione finale: PROJECT_A_PRIVATE_PASS / PROJECT_A_FAIL / PROJECT_A_PENDING
Revisore e data: ______________________________________
Motivazione sintetica: ______________________________________