style: unify workbench typography and prepare isolated visual review

docs/reports/2026-09-12-admin-issues-28-31.md

@@ -52,7 +52,7 @@ projecting the host platform, and shortening navigation labels.
   initially exposed horizontal page overflow at 390 pixels; constrained grid children
   and narrow definition lists corrected it. Database QA used an empty synthetic catalog;
   the unit suites exercise populated tables, columns, edits and operation guards.
-- Docker and real-stack Playwright acceptance were not run for this follow-up.
+- Docker and real-stack Playwright acceptance were not run during initial implementation.
   The preview is synthetic and read-only, not a deployment or provider smoke test.
 
 ## Standards
@@ -73,5 +73,24 @@ The independent follow-up review confirmed both findings resolved, with no new r
 Review summary: Standards 2 findings resolved, 0 outstanding; Spec 2 findings resolved,
 0 outstanding. Both reviews were read-only, relative to the user-approved baseline.
 
-Docker has not been rebuilt for this follow-up; the read-only QA preview uses the changed source.
+## Local Docker deployment
+
+At the owner's request, core and frontend were rebuilt from this checkout and recreated
+on 2026-09-12 at 18:31 UTC using `/private/tmp/thothii-memory-preview.sh`, with
+`--no-deps --force-recreate --wait`. Both are healthy. Database, Qdrant and embedding
+containers retained their original IDs; no persistent volumes were deleted or recreated.
+
+The normal model projection generator was run on this Mac before recreation; the running
+core now receives `THT_HOST_PLATFORM=darwin`. The authored installation configuration and
+credentials were unchanged. Before the update, images were retained as
+`thothii-core:before-admin-28-31-20260912` and
+`thothii-frontend:before-admin-28-31-20260912`; the prior projection directory was copied to
+`/private/tmp/thoth-admin-28-31-docker.5ebAo8/generated`.
+
+HTTP checks for the real UI (`http://127.0.0.1:8080/`), its `/api/health` proxy, and
+the core `/health` returned 200. Served bundle `/index-Bsz7otBx.js` contains Workspace
+areas and Pi configuration, and no longer contains the preparation footer or persisted
+Database child-screen key. Authenticated end-to-end operator workflows were not rerun.
+
+The Vite preview remains separate from Docker. Remote server deployment was not performed.
 No Gitea issue state or remote branch was changed.

docs/reports/2026-09-12-ui-survey-and-graphic-revision-plan.md

@@ -0,0 +1,191 @@
+# ThothII: survey e piano di revisione grafica
+
+Data: 12 settembre 2026. Stato: **proposta, da approvare; nessuna modifica all'interfaccia**.
+
+## Sintesi e direzione consigliata
+
+L'incoerenza segnalata è confermata. Non dipende soltanto da dettagli sfuggiti nelle singole pagine: il design system attuale prescrive tre registri tipografici, ai quali alcuni componenti aggiungono un secondo stack serif. Titoli, etichette operative, documenti e istruzioni finiscono così per sembrare parti di prodotti diversi.
+
+Propongo una direzione unica: **interfaccia operativa interamente sans-serif, rosso istituzionale come accento, colori aggiuntivi soltanto quando comunicano uno stato, maggiore coerenza senza impoverire le informazioni**. Non serve una nuova impaginazione del Core né una nuova collocazione delle sessioni.
+
+Ho usato **Impeccable**, nel registro product, per orientare la valutazione di gerarchia, tipografia, densità, colore e microcopy. La varietà visiva dovrà venire da spaziatura, pesi e organizzazione, non dall'alternanza di famiglie tipografiche. Le grazie non sono intrinsecamente incompatibili con un prodotto tecnologico, ma qui contrastano con la direzione richiesta e non svolgono una funzione necessaria: le eliminerei dalla UI, compresi i lettori di documenti.
+
+## 1. Metodo, copertura e limiti
+
+Verifica tramite Playwright nel browser dell'app, con screenshot, navigazione e lettura degli stili CSS calcolati. La survey principale riguarda la **versione Docker reale su `http://127.0.0.1:8080/`**, autenticata con l'account autorizzato. Una precedente esplorazione dell'anteprima sintetica non è usata come prova dei dati o del funzionamento del Docker.
+
+| Area | Verifica sulla versione reale |
+| --- | --- |
+| Workspace | Preparation, Specific actions, About, Authentication |
+| Database | Elenco database, navigazione alle tabelle e alle colonne |
+| Memory | Elenco vuoto e apertura del form New card, chiuso senza modifiche |
+| Evidence | Fonti/importazione, elenco, dettaglio di un documento |
+| Pi | Runtime e Host maintenance, scheda macOS |
+| Core | Stato iniziale, compositore e controlli presenti senza avviare una domanda |
+| Sessioni | My sessions, All sessions, archivio e lettura di una sessione archiviata |
+| Navigazione | Drawer responsive, accessi Admin e contesto globale |
+
+Non ho salvato form, lanciato elaborazioni, ripreso sessioni, importato documenti o modificato configurazioni. Il controllo del Core attivo, delle fasi, dei gate e del log è limitato alla lettura del codice: non è stato eseguito un ciclo LLM per una survey grafica.
+
+Il viewport misurato nel pannello browser era **649 × 1091 CSS px**. Questo offre evidenza concreta del comportamento a larghezza ridotta, ma non sostituisce una matrice desktop/mobile. Tema scuro, contrasto numerico, navigazione completa da tastiera, zoom e integrazione effettiva in Omics Portal restano da verificare. Non è una certificazione WCAG né un audit automatizzato completo. Le famiglie riportate sono gli stack CSS calcolati, non una verifica del font effettivamente caricato dal sistema.
+
+## 2. Problemi riscontrati
+
+### Tipografia: quattro stack e gerarchie variabili
+
+| Esempio osservato | Trattamento attuale | Problema |
+| --- | --- | --- |
+| Titoli delle pagine Admin | Fraunces/serif, 30 px | Registro editoriale molto più marcato del resto dell'app |
+| Sources and imports; titolo del form Memory | Altro stack `ui-serif`, 18–20 px | Nemmeno i titoli serif usano tutti la stessa famiglia |
+| Evidence library; Original question; Revised question | Monospace, 11 px | Etichette ordinarie trattate come identificatori tecnici |
+| Working context | Monospace maiuscolo, 10 px | Informazione globale importante resa molto piccola |
+| Guida Pi Host maintenance | Testo 12 px, interlinea 16 px; titoletti serif 12 px | Istruzioni lunghe troppo dense e gerarchia debole |
+| Sessione archiviata | Titolo sessione serif 14 px; titolo nel documento serif 23,2 px | Il contenuto sovrasta il contesto del pannello |
+
+La causa è documentata in `DESIGN.md`, nella regola dei tre registri. Nel codice, `frontend/src/index.css` assegna globalmente il font heading a `h1`–`h6` e ai titoli della prosa; Memory ed Evidence aggiungono classi `font-serif`. Il problema ricompare quindi anche quando un componente non richiede esplicitamente un titolo decorativo.
+
+### Colore: troppi significati impliciti
+
+- In Database il tipo di connessione REST e la data di aggiornamento ricevono accenti blu pur essendo informazioni ordinarie.
+- La guida ordinaria di manutenzione Pi è racchiusa in una cornice ambra, visivamente simile a un avviso. Il colore non distingue un pericolo concreto.
+- Gli stati Ready in Pi usano anche testo verde molto chiaro: è un rischio di leggibilità da misurare, non una violazione numericamente accertata in questa survey.
+- Stato operativo, azione primaria, contenitore informativo e semplice categoria non seguono una grammatica cromatica sufficientemente riconoscibile.
+
+Non eliminerei invece indiscriminatamente verde e ambra: successo, errore, attesa di revisione e avvertimento devono restare distinguibili, sempre anche tramite testo o icona.
+
+### Spazio e linguaggio
+
+| Area | Evidenza | Intervento proposto |
+| --- | --- | --- |
+| Workspace | Identità e descrizioni ripetute fra contesto, selezione e intestazioni; molte gerarchie prima delle azioni | Mantenere le quattro schede, ridurre ripetizioni e uniformare sezioni e azioni |
+| Database | Intestazione, stato, cronologia, Fleet summary, breadcrumb e toolbar precedono i dati; a 649 px il riepilogo occupa più righe | Compattare il riepilogo, dare priorità alla griglia; sostituire il gergo Fleet con un nome corrispondente al suo ambito |
+| Memory | Stato vuoto formulato come assenza di risultati filtrati anche senza carte; ampie aree vuote e paginazione disabilitata | Distinguere libreria vuota da ricerca senza risultati; stesso linguaggio visivo di toolbar e form del resto dell'Admin |
+| Evidence | Percorso tecnico e istruzioni di importazione dominano la parte superiore; ricerca compressa rispetto agli altri filtri | Istruzioni brevi con dettagli espandibili; percorso secondario ma copiabile; filtri che si dispongono su più righe prima di diventare illeggibili |
+| Pi | Guida molto lunga e piccola; spiegazioni dell'architettura mescolate con istruzioni all'operatore | Separare stato, azioni e guida; rendere la guida leggibile e consultabile per attività |
+| Sessioni | Molti registri tipografici; a 649 px il pannello documenti è stretto e tronca il titolo | Coerenza dei titoli e dei documenti; adeguare il pannello alla larghezza disponibile senza cambiare la gestione delle sessioni |
+| Core e navigazione | Branding ripetuto, microetichette e controlli di taglie diverse | Riallineare la gerarchia e i componenti condivisi, conservando struttura e comportamento |
+
+Gli stili comunicativi oscillano fra introduzione promozionale nel Core, manuale tecnico in Pi/Evidence e terminologia da dashboard infrastrutturale in Database. La soluzione è un tono operativo unico, non la rimozione delle informazioni tecniche necessarie.
+
+## 3. Regole del sistema visivo proposto
+
+### Una famiglia UI, cinque ruoli dimensionali
+
+Consiglio di **mantenere Manrope**, già adottato per l'interazione, e usarlo per tutta la UI. Non aggiungerei una nuova famiglia per il solo gusto di cambiare. Pesi ordinari 400, 500 e 600; monospace soltanto per SQL, codice, percorsi e identificatori quando serve riconoscerli o copiarli.
+
+| Ruolo | Dimensione proposta | Uso |
+| --- | --- | --- |
+| Titolo pagina | 24 px / 1,5 rem, peso 600 | Core/Admin, senza effetto copertina |
+| Titolo sezione | 20 px / 1,25 rem, peso 600 | Sezioni principali e pannelli di lettura |
+| Lettura | 16 px / 1 rem, peso 400 | Risposte, documenti, istruzioni articolate; interlinea circa 1,5 |
+| Interazione e dati | 14 px / 0,875 rem, peso 400–600 | Form, tab, pulsanti, griglie; sottosezioni compatte in peso 600 |
+| Metadati secondari | 12 px / 0,75 rem, peso 400–500 | Timestamp, conteggi e indicazioni accessorie |
+
+Sono ruoli, non l'obbligo di rendere ogni titolo di sezione grande: una sottosezione compatta può usare il ruolo da 14 px in semibold. Niente ridimensionamento fluido che faccia oscillare continuamente i caratteri con la larghezza. Prima si riorganizza il layout, poi si valutano eccezioni documentate.
+
+Ulteriori regole:
+
+- Eliminare Fraunces e le classi serif dall'interfaccia e dalla resa dei documenti. Non riscrivere il contenuto dei documenti.
+- Usare etichette sans-serif in sentence case; limitare maiuscole e spaziatura espansa.
+- Nessun testo operativo ordinario sotto 12 px; non far stare più contenuto riducendolo a 8–11 px.
+- Numeri tabulari nelle colonne numeriche; testo libero proporzionale; codice monospace leggibile.
+- Distribuire il font con l'app, evitando che Google Fonts sia necessario alla coerenza della UI in un ambiente intranet. Verificare fallback e caricamento, senza presumere che oggi il font remoto non funzioni.
+
+### Palette: neutri e rosso, con eccezioni semantiche
+
+| Ruolo | Regola |
+| --- | --- |
+| Superfici | Bianco e pochi grigi neutri, bordi leggeri; niente colorazione per ogni sezione |
+| Testo | Grafite per testo principale, grigio leggibile per secondario |
+| Rosso istituzionale | Azione primaria, selezione e focus; tonalità coerente con il tema Omics, da verificare nell'integrazione |
+| Successo | Indicatore verde sobrio con testo sufficientemente scuro; non interi paragrafi verde pallido |
+| Avvertimento/attesa umana | Ambra soltanto quando occorre attenzione, con motivazione esplicita |
+| Errore/distruzione | Trattamento distinto tramite icona, etichetta e conferma dove prevista; non affidarsi al solo rosso condiviso con il brand |
+| Informazioni ordinarie | Neutre: timestamp, protocollo, conteggi, guide e configurazione non sono automaticamente stati colorati |
+
+SQL, grafici e visualizzazioni possono mantenere colori utili alla comprensione dei dati. Questa revisione non impone un monocromo indiscriminato. Gli stati del workflow conserveranno il loro significato; ogni modifica cromatica dovrà avere una mappatura esplicita.
+
+### Componenti e testi condivisi
+
+- Un'unica famiglia di intestazioni Admin, toolbar, tab, campi, pulsanti, badge e messaggi.
+- Scala di spaziatura comune basata su multipli di 4 px, con distinzione chiara fra spazio dentro un gruppo e spazio fra gruppi.
+- Una primaria per il compito locale; azioni secondarie neutre, pericolose riconoscibili senza rendere tutto rosso.
+- Tab allo stesso livello con lo stesso trattamento. Le schede OS di una guida possono essere più compatte, ma non appartenere a un altro sistema grafico.
+- Istruzione essenziale accanto all'azione; procedure e dettagli di implementazione in una sezione di aiuto espandibile.
+- Testi UI in inglese; documenti e dati conservano la propria lingua. I titoli italiani di Evidence e sessioni non sono un errore di uniformità.
+
+Esempi di microcopy da affinare nell'implementazione:
+
+| Attuale | Proposta |
+| --- | --- |
+| Fleet summary | Catalog summary, se confermato l'ambito del riepilogo |
+| No cards match these filters… in una libreria vuota | No memory cards yet. Create a card to add reusable knowledge. |
+| Session models in Pi | Available models, con indicazione dell'effettiva idoneità Core/Admin |
+| Spiegazione che la pagina “never creates a second model default” | Installation default, con breve indicazione di dove modificarlo e dettagli tecnici separati |
+
+Il pulsante che prova il default d'installazione deve continuare a dichiarare **quale modello testa**: non va confuso con il modello selezionato nel contesto globale. Anche la distinzione fra importazione, revisione e consolidamento Evidence deve rimanere esplicita.
+
+## 4. Vincoli funzionali e integrazione
+
+La revisione deve conservare:
+
+1. Core originale: domanda/risposta, otto fasi in alto, gate di revisione, log sul lato sinistro e controlli esistenti.
+2. Sessioni nella navigazione destra con **My sessions / All sessions**, archivio e azioni attuali. Nessuna sezione sostitutiva in fondo alla pagina.
+3. Contesto globale A espandibile in alto: workspace e modello unici per tutta l'app; scelte ricordate indipendentemente e default esistenti.
+4. Blocco delle attività senza contesto valido e del cambio contesto durante un'elaborazione; protezione delle modifiche Admin non salvate.
+5. Cinque pagine Admin, preprocessing in Workspace Preparation e gestione database/tabelle/campi/relazioni in Database.
+6. Unificazione già realizzata della configurazione LLM, senza introdurre selettori o default alternativi.
+7. Prototipi precedenti conservati e recuperabili.
+
+**Omics Portal possiede header rosso e sidebar sinistra.** ThothII non deve duplicarli. Le regole globali attuali su `:root`, `body` e titoli richiedono una verifica di isolamento: se l'integrazione avviene nello stesso DOM, gli stili vanno circoscritti alla radice ThothII; se avviene in iframe, vanno verificati dimensionamento, tema e scrolling. È un rischio di integrazione da verificare, non una sovrapposizione già osservata sul portale.
+
+A larghezze ridotte pannelli e filtri devono adattarsi alla larghezza del contenitore reale, non soltanto della finestra. Nel lettore della sessione il testo non dovrebbe restare confinato in una colonna di circa 195 px come nello screenshot a 649 px: prevedere un pannello più ampio o sovrapposto nella modalità compatta, mantenendo accessi e funzione originali.
+
+## 5. Sequenza di lavoro proposta
+
+### Fase 1: regole e campione rappresentativo
+
+Dopo approvazione, aggiornare `DESIGN.md` eliminando la regola dei tre registri e allineando gli eventuali riferimenti superati ai modelli e alla navigazione. Definire token tipografici, colori semantici e componenti comuni.
+
+Applicare un primo campione a **Workspace e Pi**: insieme verificano form, stato operativo, selezioni, istruzioni lunghe e codice. Mostrare il confronto prima/dopo mantenendo stessi contenuti e viewport. Non servono tre nuovi design alternativi: serve validare un sistema coerente.
+
+### Fase 2: shell e tutte le pagine Admin
+
+Uniformare contesto globale, navigazione, titoli, tab e controlli; estendere il sistema a Database, Memory ed Evidence. Compattare riepiloghi e istruzioni senza eliminare funzionalità. Correggere stati vuoti, larghezze dei filtri e formattazione dei blocchi di codice nella guida Pi.
+
+### Fase 3: Core, documenti e sessioni
+
+Applicare gli stessi token a compositore, fasi, log, widget di revisione, documenti e navigazione sessioni. Nessuna nuova struttura del workflow. Controllare separatamente liste, documento aperto, sessione attiva e pannelli nella modalità compatta.
+
+### Fase 4: verifica e consegna
+
+Eseguire typecheck, test dei componenti interessati e regressione Playwright con dati di test, senza consumare chiamate LLM reali soltanto per verificare gli stili. Includere prove di flusso per navigazione con modifiche non salvate e blocco del contesto durante un'operazione.
+
+Preparare screenshot comparabili e verifiche a 390, 649, 768, 1280 e 1600 px, oltre alla larghezza effettiva assegnata da Omics con sidebar presente. Verificare tema chiaro/scuro, zoom 200%, tastiera, focus, testo lungo, stato vuoto/errore/caricamento e griglie larghe. L'integrazione finale nel server resta una fase distinta, secondo le decisioni già prese.
+
+## 6. Criteri di accettazione
+
+- Una sola famiglia sans per la UI; monospace solo per contenuto tecnico. Nessuna classe serif residua nei componenti operativi o nei lettori.
+- Dimensioni e pesi derivati dai ruoli condivisi; ogni eccezione ha un motivo documentato.
+- Colori dei componenti da token semantici; nessun blu decorativo per date o protocolli e nessuna cornice di warning intorno a una guida ordinaria.
+- Contrasto del testo almeno 4,5:1, salvo le eccezioni previste per testo grande e altri casi specifici; non assumere che ogni semibold sia testo grande. Riferimento: [W3C, Contrast Minimum](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html).
+- Contrasto almeno 3:1 per informazioni visive necessarie a identificare controlli e stati, nei casi applicabili; non è un obbligo per ogni bordo decorativo. Riferimento: [W3C, Non-text Contrast](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html).
+- Stato e azione distinguibili anche senza colore; focus visibile e controlli utilizzabili da tastiera.
+- Nessuna sovrapposizione o scroll orizzontale dell'intera pagina ai viewport concordati; scroll locale consentito per tabelle e codice quando necessario.
+- Nessuna regressione funzionale di Core, sessioni, Admin, selezione globale o salvataggio; test dei flussi critici invariati o rafforzati.
+- Nessuna modifica del contenuto scientifico, dei default LLM, delle autorizzazioni o delle procedure di manutenzione mascherata da intervento grafico.
+
+## 7. Punti principali del codice interessati in una futura implementazione
+
+- `DESIGN.md`: regole tipografiche e cromatiche.
+- `frontend/index.html`: caricamento delle famiglie di caratteri.
+- `frontend/src/index.css`: token, titoli globali, etichette e prosa.
+- `frontend/src/shell/WorkingContextShelf.css`: contesto globale e microtipografia.
+- `frontend/src/shell/administration/AdministrationPage.css`: intestazioni comuni.
+- `frontend/src/shell/WorkspaceManager.css`: gerarchie e densità Workspace.
+- `frontend/src/shell/database-management/FleetLedgerShell.css`: riepiloghi, toolbar e griglie.
+- Componenti Memory/Evidence: override serif di titoli e form.
+- Componenti Pi: guida, stati, tab OS e microcopy operativo.
+- Componenti Core/sessioni: fasi, lettura documenti, log, navigazione e pannelli responsive.
+
+**Decisione richiesta:** approvare questa direzione visiva e il campione Workspace/Pi prima di estenderla. Questa survey non crea ticket, non aggiorna il design normativo e non ricostruisce Docker.

docs/reports/2026-09-12-ui-visual-review-delivery.md

@@ -0,0 +1,109 @@
+# Revisione grafica: consegna su worktree e Docker
+
+Stato: **pubblicata per revisione visiva, non integrata in main**.
+
+## Dove provarla
+
+- Docker locale: <http://127.0.0.1:8080/>.
+- Worktree: `/Users/mp/projects/ThothII-visual-review`.
+- Ramo: `codex/ui-visual-review`.
+- Base preservata: `2d1b714ebe31419d712e9c3324a5e171d5f0317d`.
+- Checkout originale: `/Users/mp/projects/ThothII`, ramo `codex/prototype-administration-pages`, lasciato intatto, incluse le note non ancora committate e i prototipi.
+
+Non è stato eseguito alcun merge, push o aggiornamento di Gitea. Questa consegna richiede la revisione ottica del proprietario prima dell'adozione.
+
+## Interventi
+
+Impeccable, registro product, ha guidato le scelte: Manrope sans-serif locale per tutta la UI; niente serif nei componenti o nei documenti; cinque ruoli tipografici condivisi; monospace conservato per contenuto tecnico. I font non dipendono più da Google Fonts.
+
+Le etichette ordinarie non usano più monospace maiuscolo. Le piccole dimensioni arbitrarie dei componenti sono state ricondotte a 12, 14 o 16 px. Titoli Admin a 24 px; intestazioni, controlli e prosa sono coerenti fra superfici.
+
+Il rosso resta l'accento principale. Date e protocolli sono neutri. Verde e ambra usano token semantici leggibili anche in tema scuro. La guida Pi non è più presentata come un grande avviso ambra. Il tema delle utility segue il tema dell'app/portale, non autonomamente quello del sistema operativo. Placeholder e focus sono più leggibili.
+
+Interventi specifici:
+
+- Workspace: tipografia e stati uniformati, mantenute quattro schede e preprocessing.
+- Database: riepilogo più compatto, Catalog summary al posto di Fleet summary, intestazioni delle griglie senza monospace maiuscolo, selezioni compatibili con il tema scuro.
+- Memory: titoli e form sans-serif; messaggio distinto per libreria vuota e nessun risultato filtrato; paginazione mostrata quando serve.
+- Evidence: istruzioni tecniche espandibili, percorso host sempre disponibile e copiabile nella relativa sezione, filtri responsive con ricerca di larghezza utile.
+- Pi: guida leggibile a 16 px, codice correttamente su più righe, tab OS coerenti, testo che distingue default d'installazione e modello selezionato, Available models.
+- Core/sessioni: uniformazione estetica senza modifiche al workflow; otto fasi, gate, log, input e gestione sessioni conservati. Nei layout compatti il lettore documenti usa lo spazio disponibile anziché una colonna illeggibile.
+
+Il modello globale, i default, le autorizzazioni e i blocchi di navigazione non sono stati ridisegnati. Non sono state eseguite elaborazioni LLM o mutate informazioni applicative per questa verifica.
+
+## Verifica
+
+| Verifica | Esito |
+| --- | --- |
+| Frontend, suite Vitest | 679 test passati |
+| TypeScript + build produzione | Passati |
+| Playwright dedicato | 7 scenari passati, nessun retry |
+| Larghezze | 390, 649, 768, 1280, 1600 CSS px |
+| Superfici Playwright | Cinque Admin, guida Pi, Core iniziale, My/All sessions e lettore archivio |
+| Interazioni | Tab OS da tastiera, modifica Memory trattenuta durante tentativo di navigazione, ritorno al Core dopo annullamento |
+| Tema | Chiaro indipendente dal tema OS; scuro tramite attributo del portale |
+| Spazio host | Simulazione di 240 px riservati al menu sinistro e 72 px all'header, con utility concorrente |
+| Docker reale | Accesso e navigazione fra le cinque pagine Admin; titolo sans-serif 24 px e nessun overflow dell'intera pagina nel viewport verificato |
+
+I test visuali usano fixture e intercettano tutte le richieste API prima che possano raggiungere un'installazione. Nessuna scrittura è ammessa: ogni scenario controlla che non ne siano state tentate. Gli screenshot sono negli output locali ignorati da Git, `frontend/test-results/visual-review/`.
+
+Comandi di verifica nel worktree:
+
+```sh
+cd /Users/mp/projects/ThothII-visual-review/frontend
+npm test -- --maxWorkers=2 --minWorkers=1
+npm run build
+npx playwright test --config playwright.visual.config.ts
+```
+
+Contrasti calcolati sulle coppie di token opachi di riferimento, non su ogni possibile composizione/hover:
+
+| Coppia | Chiaro | Scuro |
+| --- | --- | --- |
+| Testo principale / card | 15,16:1 | 13,61:1 |
+| Testo secondario / card | 5,67:1 | 8,40:1 |
+| Successo / card | 6,76:1 | 8,69:1 |
+| Avvertimento / card | 6,64:1 | 9,44:1 |
+| Bordo input / card | 3,36:1 | 4,56:1 |
+| Testo pulsante primario / riempimento | 5,03:1 | 6,83:1 |
+
+Limiti: non è una certificazione WCAG completa; non è stata eseguita una nuova sessione LLM sul Docker reale. La prova con geometria host non equivale all'integrazione nel vero Omics Portal. Lo zoom browser 200% e tutte le combinazioni di hover/trasparenza non sono stati verificati esaustivamente. I test funzionali già esistenti coprono fasi, sessioni e protezioni; le modifiche non cambiano la loro logica.
+
+## Docker e ripristino
+
+Progetto Compose: `thothii-18998cca7b0a`. È stato ricreato **solo frontend** con `--no-deps --no-build` dopo una build esplicita dal nuovo worktree.
+
+| Elemento | Valore verificato |
+| --- | --- |
+| Immagine nuova | `thothii-frontend:visual-review-20260912` |
+| Digest immagine nuova | `sha256:eeccb28f5c5cd78da08fd007e259e3fb88f26b4f1415a825a3b5829061f79ed3` |
+| Immagine precedente conservata | `thothii-frontend:before-visual-review-20260912` |
+| Digest precedente | `sha256:635f25477f11a476034052e87b2129ae26a9a049c4bedde0ada3a1d65e4ee924` |
+| Container frontend nuovo | `50dd012cd400`, healthy |
+| Core invariato | `0dcce917be0c`, healthy |
+| Catalog DB invariato | `89755e439dc7`, healthy |
+| Qdrant invariato | `52ebd5c47955`, healthy |
+| Embedding invariato | `7f690e534eda`, healthy |
+| Bundle servito | `/index-Cd-Ma0ye.js`, `/index-CptC2K6s.css` |
+
+Per tornare al look precedente, senza rebuild e senza modificare dati o Core:
+
+```sh
+bash /private/tmp/thothii-memory-preview.sh \
+  -f /Users/mp/projects/ThothII-visual-review/deploy/compose.visual-review-rollback.yaml \
+  up -d --no-deps --no-build frontend
+```
+
+Per ripubblicare il look di revisione già costruito:
+
+```sh
+bash /private/tmp/thothii-memory-preview.sh \
+  -f /Users/mp/projects/ThothII-visual-review/deploy/compose.visual-review.yaml \
+  up -d --no-deps --no-build frontend
+```
+
+Questi override sono deliberatamente locali e usano il launcher dell'installazione già presente; non vanno applicati sul server PSD. Il launcher in `/private/tmp` dipende dai profili locali esistenti: se rimosso, ricostruire l'invocazione dai profili dell'installazione, senza sostituire configurazioni o volumi. Le immagini di review e rollback restano taggate: non eseguire una pulizia delle immagini prima della decisione.
+
+## Decisione successiva
+
+Il proprietario valuta il look su Docker. Solo dopo approvazione si procederà con l'integrazione su `main`, verificando anche l'eventuale differenza fra `main` e il ramo di partenza. Un rifiuto della revisione richiede soltanto il ripristino frontend sopra indicato; codice e prototipi precedenti sono preservati.