{"ok":true,"format":"markdown","manual":"# Manuale operativo Portal360\n\n## La risposta corta\n\nNon scegliere ogni volta Work, Cowork, Codex o Hermes. Entra in Portal360 e dai\nl'obiettivo. Paperclip conserva il lavoro; Hermes lo esegue; Codex viene usato\nsolo quando servono codice, repository, server, test o rollback.\n\n## Il lato sinistro\n\n1. **Vista Cristian** — dove siamo e cosa richiede te.\n2. **Obiettivi** — una frase, prova di fine, owner e tenant.\n3. **In esecuzione** — lease attivi e prossimo checkpoint.\n4. **Ricevute** — comandi, esiti, artefatti e rollback.\n5. **Gate umani** — segreti/login/MFA, spesa/pagamenti, azioni distruttive,\n   deploy/restart/DNS live e traffico cliente reale.\n6. **Tenant e portali** — apre la superficie corretta senza duplicarla.\n7. **Sistemi** — Paperclip, Hermes, Repair360 e worker.\n8. **Manuale** — questa pagina.\n\n## Cosa succede quando detti un obiettivo\n\n1. Maya/Aurora lo riscrive come fatto verificabile.\n2. Paperclip crea una issue unica e assegna tenant, budget e lease.\n3. Hermes apre una sessione e chiama il worker con le sole capability ammesse.\n4. Il worker opera nel data plane corretto.\n5. Hermes consegna una ricevuta; Paperclip la conserva.\n6. Un giudice diverso dall'esecutore emette `PASS`, `FAIL` o `NON_DIMOSTRATO`.\n7. Portal360 mostra risultato, rollback e unico prossimo gate.\n\n## I ruoli\n\n- **Maya/Aurora**: assistente personale e orchestratore leggibile di Cristian.\n- **Sonia Core**: customer manager per dealer e tenant autorizzati.\n- **Chiara Core**: customer manager per TEC Perugia.\n- **Paperclip**: unica regia persistente.\n- **Hermes**: motore di esecuzione.\n- **Codex Assistant**: worker per codice e server, non regia.\n\n## Reperibilita 3:00\n\nNon e' un problema Maya o di dettatura. E' un ruolo di stress-test: alle tre di\nnotte devono essere evidenti cosa si e' rotto, cosa e' stato tentato, se il\nrollback e' disponibile e quale gate umano manca.\n\n## Dove girano i componenti\n\n- `portal360.tech`: nuova Control Room e gateway dei portali.\n- runtime WAIPRO: unico Paperclip e unico Hermes gia' esistenti.\n- Repair360: Core e memoria operativa tenant-scoped.\n\nNon va installato un secondo Paperclip o Hermes sul nuovo KVM. Il gate reale e'\ncollegare Portal360 ai runtime esistenti con identita minima e ricevuta E2E. Un\neventuale trasferimento futuro e' un cutover governato, non una duplicazione.\n\n## Memoria e tenant\n\nUna richiesta senza tenant fallisce chiusa. Sonia non legge TEC se il lease non\nlo autorizza; Chiara non esce da TEC. La memoria personale Maya/Aurora resta\nseparata dai dati cliente. Portal360 non copia nessuna di queste memorie.\n\n## Onboarding rivendibile\n\nPer un cliente nuovo si crea configurazione, non un nuovo Core:\n\n1. tenant e host nel registry Repair360;\n2. profilo Customer Manager con grant minimi;\n3. portale Dealer/B2C universale configurato per host;\n4. profilo Paperclip company-scoped;\n5. lease e budget iniziali a zero;\n6. E2E sintetico senza dati cliente;\n7. onboarding reale dopo DNS, identita provider/vault e contratto verificati.\n\n## Immagini riusate\n\nGli asset in `web/assets/` provengono dal repository Repair360 e sono copiati\ncon hash in `docs/assets.json`. Servono a documentare superfici esistenti, non a\nprovare che siano live oggi.\n\n## Verifica locale/server\n\n```bash\n./scripts/check.sh\npython3 run.py --host 127.0.0.1 --port 8787\ncurl -s http://127.0.0.1:8787/health\n```\n\nOutput minimo: test verdi e `/health` con `state=CANDIDATO`. `CANDIDATO` non\nsignifica `LIVE`.\n\n## Setup e re-setup automatico\n\n`scripts/reconcile.sh` e' l'unico entrypoint. `--check` non modifica nulla;\n`--prepare` assembla una release immutabile e genera/acquisisce credenziali\ncifrate con `systemd-creds`; `--activate` installa la unit, abilita/restarta e\nrichiede `/health` 200. `--re-setup` riconcilia lo stesso percorso in modo\nidempotente. Il repository non ha dipendenze applicative: la build e' il\npacchetto `git archive`, e il check reale resta `scripts/check.sh`.\n\nIl token API interno viene generato con `openssl` oppure acquisito dal comando\nprovider indicato da `PORTAL360_API_TOKEN_PROVIDER`. L'email non ha ancora un\nprovider scelto: quando esiste, `PORTAL360_EMAIL_TOKEN_PROVIDER` deve emettere il\nsegreto su stdout direttamente nella pipe cifrata; il valore non viene loggato.\n\n## Prompt Gauntlet breve\n\n```text\nGauntlet Portal360: riprendi il primo outcome libero.\n```\n\nL'entrypoint espande questa frase leggendo `AGENTS.md`, `CORSIA.md`,\n`DA-FARE.md`, `GAUNTLET-PORTAL360.md` e la specifica pertinente. Paperclip\nmantiene goal/lease/budget zero, Hermes invoca il worker, Codex costruisce e un\ngiudice separato certifica test, receipt e rollback.\n\n## Prerequisiti tecnici per andare live\n\n- DNS e TLS di `portal360.tech`;\n- Paperclip esistente raggiungibile e autenticato dal KVM Portal360;\n- Hermes esistente raggiungibile dal KVM con restart e retry E2E testati;\n- Codex Assistant installato sul KVM e avviabile da Hermes;\n- collegamento Repair360 in sola proiezione tenant-scoped;\n- backup e restore verificati;\n- deploy/restart automatizzato con rollback;\n- un E2E sintetico completo e poi un canary reale con receipt.\n\nRestano sempre gate umani: segreti/login/MFA, spesa/pagamenti, azioni\ndistruttive, deploy/restart/DNS live e traffico cliente reale. Il run termina\n`BLOCCATO` indicando il gate o provider esatto, senza chiedere di copiare\nsegreti in chat.\n"}