ThothII/docs/operations/psd-server-sol-orchestration-prompt.md

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:

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.