# Correzione input sessione embedded e Memory vuota

## Stato

Correzioni implementate e immagini candidate costruite; **rilascio operativo non
ancora eseguito**. Il runbook `docs/operations/server-codex-handoff.md` richiede
conferma della finestra prima della ricreazione dei servizi operativi.

## Cause e correzioni

- La nuova `.thot-host` usa `100dvh`; Omics limita invece `#root` allo spazio
  sotto il topbar e ne nasconde l'overflow. La prova browser riproduce controlli
  che terminano a 821 px con il contenitore che termina a 782 px. La shell
  embedded ora ha `max-height: 100%`, così rispetta il contenitore; il fallback
  alla viewport e il contratto `--thoth-app-height` restano utilizzabili.
- Nell'installazione reale PostgreSQL contiene zero Memory Card e la collection
  `psd-clinical-memory` zero punti, senza vettore sparse BM25. Il workflow
  interrogava comunque embedding/Qdrant e trasformava `BM25 collection
  configuration mismatch` in `memory_unavailable`, status 503. Il recupero ora
  restituisce `[]` dopo aver verificato in PostgreSQL che l'archivio è vuoto.
  Gli errori dell'archivio autorevole continuano a propagarsi. `memory rules`
  calcola il vettore soltanto se serve e lo condivide fra le due famiglie.

Nessuna migrazione, modifica di card, indice, DWH o autenticazione è necessaria.

## Verifiche eseguite

- Riproduzione live: `tht memory search` restituisceva 503.
- Confronto delle immagini attuale/candidata, con PostgreSQL e Qdrant reali e
  montaggi read-only: attuale exit 1/status 503; candidata exit 0/`[]`. La
  configurazione diagnostica non contiene credenziali DWH e non interroga il DWH.
- 54 test Memory superati, 1 skipped, 2 deselected secondo la configurazione
  pytest; inclusi test PostgreSQL/Qdrant reali e regressione CLI archivio vuoto.
- 90 test frontend superati: shell host, composer, creazione e gestione sessioni.
- 5 scenari Playwright superati: sessione attiva embedded a 390/1280 px con
  input multilinea e apertura del dialogo di arresto; composer full dopo
  navigazione amministrativa; geometria host con header/rail.
- TypeScript, build frontend, Ruff sui file Python modificati, `git diff --check`
  e scansione layout superati. Entrambe le build Docker completate;
  smoke della configurazione frontend superato.
- Screenshot verificati in `frontend/test-results/visual-review/`.

## Consegna candidata

Base operativa verificata e pulita: `49333a2d35664b7237c3ddc2a9f10a605dcc84ce`.
La patch `/tmp/thoth-session-memory-fix.patch` supera `git apply --check`
contro `/srv/thothii-v2/source/ThothII`.

| Immagine candidata | ID |
| --- | --- |
| `thothii-v2-core:49333a2d-session-memory-fix` | `sha256:ff4c435abd67c57e1e91e6e560dae73e67350ca499a5aedca3ffa517b9f59ee0` |
| `thothii-v2-frontend:49333a2d-session-memory-fix` | `sha256:35933317769f3e12953f3b144d51f8fc2e7e9f7c4830eba80cc626f757f5bf0d` |

Copie protette di operator.env, descriptor e override sono già in
`/srv/thothii-v2/backups/20260914-session-memory-fix` (directory 0700).
Le immagini correnti sono conservate anche con tag
`before-session-memory-fix-20260914`. Non è stato fatto un nuovo backup dei dati:
questa preparazione non ha modificato dati e non sostituisce un backup coerente
nella finestra operativa, se richiesto dal runbook di rilascio.

## Comandi risolti per la finestra da confermare

Verificare nuovamente lo stato delle sessioni e gestire quelle attive prima del
riavvio. Il seguente launcher conserva progetto, env file e ordine degli override:

```bash
thoth_fix_compose() {
  sudo docker compose --project-name thothii-7f901b48fe35 \
    --project-directory /srv/thothii-v2/source/ThothII \
    --env-file /srv/thothii-v2/operator/operator.env \
    -f /srv/thothii-v2/source/ThothII/compose.yaml \
    -f /srv/thothii-v2/source/ThothII/deploy/compose.server.yaml \
    -f /srv/thothii-v2/source/ThothII/deploy/compose.git-ssh.yaml \
    -f /srv/thothii-v2/operator/compose.portal-upstream.yaml \
    -f /srv/thothii-v2/source/ThothII/deploy/psd-server-v2/generated/compose.models.yaml "$@"
}
thoth_fix_compose exec -T core node /app/backend/dist/operator-command.js maintenance-activate
thoth_fix_compose exec -T core node /app/backend/dist/operator-command.js maintenance-status
sudo git -C /srv/thothii-v2/source/ThothII apply /tmp/thoth-session-memory-fix.patch
```

Dopo gestione delle sessioni e backup nella finestra, aggiornare esclusivamente
`THTII_RELEASE_IMAGE_TAG` in `/srv/thothii-v2/operator/operator.env` al valore
`49333a2d-session-memory-fix`, preservando gli altri valori e i permessi.
Quindi:

```bash
thoth_fix_compose up -d --no-deps --no-build core frontend
sudo docker exec omics_portal-nginx-1 nginx -t
sudo docker exec omics_portal-nginx-1 nginx -s reload
sudo tht --installation /srv/thothii-v2/source/ThothII/deploy/psd-server-v2/thothii-installation.yaml status
sudo tht --installation /srv/thothii-v2/source/ThothII/deploy/psd-server-v2/thothii-installation.yaml doctor --json
```

Attendere il TTL di 30 secondi del manifest Django, verificare asset/config e
Memory; provare input/arresto nel portale prima della riapertura:

```bash
thoth_fix_compose exec -T core node /app/backend/dist/operator-command.js maintenance-deactivate
```

Rollback applicativo: ripristinare l'operator.env protetto, ricreare solo
core/frontend con lo stesso launcher, verificare e ricaricare nginx. Per riallineare
anche i sorgenti usare `git apply --reverse --check` e poi `git apply --reverse`
sulla sola patch preparata, senza reset di altre modifiche. Non occorre ripristinare
PostgreSQL o indici per un rollback di queste due correzioni.