# User-owned session storage design

## Decisioni vincolanti

- In server mode ThothII usa PostgreSQL diretto, nello schema Supabase privato
  `thoth_sessions`; il browser non accede mai al database.
- In local mode ogni utente usa `~/.thothii` (override esplicito `THT_HOME`),
  senza fallback o sincronizzazione con Supabase.
- Una sessione appartiene al principal `(issuer, subject)`. Nel portale il
  subject è il PK Django; email e username non sono identificatori.
- Il proxy valida la sessione del portale e inietta identità normalizzata; il
  backend richiede `AUTH_MODE=upstream` in produzione e non riceve token raw.
- Gli utenti nel gruppo Authentik `authentik Admins` possono gestire ogni
  sessione. Un accesso non autorizzato restituisce 404.
- Lo schema contiene principals, principal_preferences, sessions,
  session_artifacts, review_decisions e audit_log. Artefatti correnti e
  decision ledger append-only; niente cronologia di artefatti né contenuto
  nell'audit.
- La sicurezza server combina RLS forzata, un runtime role senza BYPASSRLS,
  contesto attore transaction-local e filtri applicativi espliciti.
- Non vengono creati embeddings o vector columns per le sessioni. La memoria
  solved_question esistente resta un flusso separato best-effort.
- Sessioni e preferenze server sono persistite solo nel DB; guasti DB sono
  fail-closed (503). I file temporanei di export sono effimeri.
- Chat e SSE restano memoria runtime, non artefatti persistiti.