Merge visual review into full shell and preserve bilingual layout

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,181 @@
+# Revisione grafica: consegna su worktree e Docker
+
+Stato: **pubblicata per revisione visiva, non integrata in main**.
+
+Aggiornamento 2026-09-13: i sette commit di questa revisione sono ora integrati con
+full/embedded e i18n nel ramo `codex/prototype-administration-pages`, su richiesta
+del proprietario. Per lo stato corrente e il rollback usare il
+[rapporto di integrazione](2026-09-13-visual-shell-integration.md).
+Il seguito conserva la cronologia della consegna isolata originale.
+
+## 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.
+
+## Follow-up: marchio applicativo (2026-09-13)
+
+Su richiesta dell'utente, ripristinato ThothII a 48 px nel Core e ingrandito a 32 px nella
+sidebar destra. Manrope semibold e suffisso II rosso restano coerenti con Impeccable;
+il marchio è un'eccezione esplicita alla scala dei titoli ordinari in DESIGN.md.
+Nessuna modifica funzionale. Build e 7 scenari Playwright superati, con controlli delle
+dimensioni del marchio alle cinque larghezze. Pubblicato nuovamente il solo frontend
+Docker usando il medesimo tag di revisione; immagine di ripristino invariata, nessun merge.
+La nuova immagine sostituisce quella identificata nella prima consegna sotto:
+`sha256:f576ee4882456b4d2d338dbb2228d301f9ffd8d0c7de541842c767bbe8d02dad`.
+
+## Follow-up: indicatori del catalogo (2026-09-13)
+
+Spostati i pallini dopo le etichette Catalog, Operations e Metadata updated, mantenendo
+il rientro del testo e l'allineamento con i valori sottostanti. Spaziatura uniforme e
+centratura verticale secondo Impeccable. I 7 scenari Playwright passano, inclusi nuovi
+controlli geometrici per tutte e tre le etichette alle cinque larghezze responsive.
+Il successivo aggiornamento del medesimo tag frontend include questa correzione;
+il digest del follow-up precedente identifica quindi una versione superata.
+
+## Follow-up: altezza del prompt Core (2026-09-13)
+
+Riprodotto con Playwright il campo schiacciato: altezza inline 0 px, spazio utile 8 px,
+a fronte di 31 px necessari per la prima riga. L'autosizing misurava il Core ancora
+nascosto durante il caricamento del contesto e non reagiva alla successiva apertura.
+Il reset isolato dell'altezza ad auto riportava immediatamente il campo a 31 px.
+
+Il composer ora evita misure nascoste, ricalcola al cambio di larghezza/visibilità e
+al caricamento dei font, conserva un minimo di 32 px e cresce fino a 160 px con scroll.
+Il focus usa il contorno esterno esistente, senza il secondo bordo interno.
+Nessuna modifica all'invio o al workflow. Passati 9 scenari Playwright e 17 test Vitest
+mirati; coperti ingresso dal Core e dall'Admin, Shift+Enter, testo lungo, mobile,
+navigazione con bozza conservata e svuotamento. Build Docker frontend aggiornata;
+branch di revisione isolato, immagine di ripristino invariata.
+
+## Follow-up: griglia di allineamento del catalogo (2026-09-13)
+
+Catalog condivide il margine di Catalog summary; sui layout ampi Metadata updated
+condivide l'asse di Description coverage e Operations occupa il punto medio fra i due.
+Usati margini condivisi e gli stessi cinque riferimenti di colonna dei KPI, senza offset
+assoluti. Sulle larghezze ridotte gli stati continuano a disporsi senza sovrapposizioni.
+Passati 9 scenari Playwright, con assert geometrici sugli allineamenti richiesti.
+Pubblicazione limitata al frontend Docker del worktree di revisione, nessun merge.
+
+## Follow-up: margini esterni e assi interni (2026-09-13)
+
+La verifica geometrica iniziale rilevava 20 px di differenza fra il bordo sinistro
+del riepilogo e quello della tabella. In accordo con Impeccable, introdotti due token:
+margine esterno condiviso di 20 px e padding interno di 16 px. Catalog summary,
+navigazione Databases e tabella hanno bordi sinistro/destro coincidenti; riepilogo,
+Tables, Databases e Workspace databases condividono l'asse testuale a 36 px.
+Header, toolbar azioni e stati seguono lo stesso asse. Conservato l'allineamento
+Metadata updated/Description coverage e Operations al punto medio sui layout ampi.
+Passati 9 scenari Playwright con assert geometrici a 390, 649, 768, 1280 e 1600 px.
+Nessuna modifica funzionale; aggiornamento Docker limitato al frontend di revisione.
+
+## Follow-up: pannello del contesto globale (2026-09-13)
+
+Il pannello espanso Workspace/Model ora usa gli stessi token di margine esterno (20 px)
+e padding interno (16 px) del catalogo, con superficie rientrata e controlli sull'asse
+testuale a 36 px. Allineamento curato con Impeccable e verificato alle cinque larghezze.
+Rimosse la frase sulle ultime scelte e le indicazioni di provenienza sotto i selettori
+(Installation default / Last choice). Logica di selezione, persistenza, default,
+blocchi operativi e messaggi di errore invariati. Passati 9 scenari Playwright con
+controlli sul pannello aperto, sui margini e sull'assenza delle diciture rimosse.
+
+## 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.

docs/reports/2026-09-13-full-shell-implementation.md

@@ -3,6 +3,11 @@
 Data: 2026-09-13. Specifica: [Full shell, integrazione Omics e interfaccia bilingue](../plans/2026-09-13-full-shell-spec.md).
 I cinque ticket e le loro dipendenze sono elencati nel [piano](../plans/2026-09-13-full-shell-and-portal-integration.md).
 
+Correzione della base grafica: la prima build descritta qui non includeva i sette
+commit del ramo `codex/ui-visual-review` già installati sul Mac. Il
+[rapporto di integrazione](2026-09-13-visual-shell-integration.md) documenta il
+recupero di font, allineamenti e layout, mantenendo le funzionalità di questa consegna.
+
 ## Risultato
 
 - Configurazione pubblica generata dal descrittore installato; full ed embedded

docs/reports/2026-09-13-visual-shell-integration.md

@@ -0,0 +1,125 @@
+# Integrazione della revisione grafica con full/embedded
+
+Data: 2026-09-13. Ambito autorizzato: integrazione locale e aggiornamento del Mac,
+senza push, merge in `main` o deploy sul server PSD.
+
+## Causa della regressione
+
+La revisione full/embedded `d8a29bfb` e il ramo `codex/ui-visual-review` partivano
+entrambi da `2d1b714e`. La prima build full è stata eseguita dal primo ramo senza
+integrare i sette commit grafici già presenti nell'immagine installata sul Mac.
+La corrispondenza è verificata anche sulle immagini: il backup
+`thothii-frontend:before-full-shell-20260913` e
+`thothii-frontend:visual-review-20260912` identificano entrambi `7dceaafcd9ee`.
+
+Commit recuperati, in ordine:
+
+| Commit | Modifica |
+| --- | --- |
+| `c8d276dd` | Manrope locale, scala tipografica condivisa, leggibilità delle pagine operative |
+| `eed398e5` | Marchio ThothII a 48 px nel Core e 32 px nella sidebar |
+| `8c819968` | Indicatori del catalogo dopo le rispettive etichette |
+| `803e9e92` | Ricalcolo dell'altezza del campo domanda dopo la riapertura del Core |
+| `e088abd6` | Allineamento degli stati alla griglia del riepilogo |
+| `5af44081` | Margini e assi interni dei blocchi Database |
+| `a59624a6` | Allineamento del pannello del contesto e rimozione delle spiegazioni ridondanti |
+
+## Criteri di riconciliazione
+
+- Conservati traduzioni, protezione delle bozze, autenticazione, gestione delle
+  sessioni e isolamento dell'adapter Omics introdotti dalla revisione full.
+- Recuperati font locale, classi e geometria approvati nel ramo grafico.
+  Impeccable, registro product, ha guidato la verifica della coerenza; nessun
+  ridisegno delle pagine o nuovo accorciamento dei loro titoli.
+- Il reset e i token CSS restano circoscritti al mount di ThothII e ai suoi popup:
+  la revisione grafica non reintroduce un reset del documento del portale.
+- Conservati tema, traduzioni e stato di AG Grid; le colorazioni degli avvisi
+  rimangono leggibili nei due temi.
+- Tradotte le nuove etichette e le spiegazioni introdotte dalla revisione grafica.
+- Il mock di ResizeObserver dei test ora emette le misure degli elementi osservati,
+  come richiesto anche dal ridimensionamento del campo domanda recuperato.
+- I test visuali configurano esplicitamente full oppure embedded. La simulazione
+  embedded fornisce le preferenze del portale e il suo reset del margine del body;
+  ThothII non deve applicare quel reset al documento esterno.
+
+## Verifiche
+
+| Controllo | Esito |
+| --- | --- |
+| Suite frontend completa | 755 test passati, zero fallimenti |
+| Playwright visuale/interazione | 11 scenari passati, zero saltati o instabili |
+| Larghezze della revisione grafica | 390, 649, 768, 1280 e 1600 px |
+| Combinazione lingua/tema/full | EN/IT, chiaro/scuro, persistenza al reload e margini simmetrici a 390 e 1280 px |
+| Caricamento font | Verificata una font face Manrope Variable effettivamente caricata |
+| Embedded | Nessun header ThothII, contenimento sotto header e sidebar del portale simulato |
+| Cataloghi | 1681 messaggi italiani, 1706 riferimenti statici; nessuna chiave mancante o interpolazione incoerente |
+| Typecheck e build | Superati, inclusa la regressione sul CSS compilato prima della build |
+| Documentazione | Build MkDocs strict superata |
+
+Le verifiche Playwright usano dati sintetici e bloccano tutte le richieste API;
+gli scenari non avviano modelli reali né modificano dati dell'installazione.
+Gli screenshot sono in `frontend/test-results/visual-review/`, ignorati da Git.
+Backend, harness e Omics non sono modificati da questa integrazione; le loro
+verifiche precedenti restano nel rapporto full-shell. Non viene rivendicata una
+nuova verifica end-to-end sul portale di produzione.
+
+La verifica indipendente dell'integrazione di CSS, shell e reset non ha segnalato
+rilievi aperti. Il controllo della pagina reale ha inoltre rilevato l'etichetta
+predefinita «Administration» non tradotta: è stata corretta nel componente condiviso
+e coperta dallo scenario EN/IT. Nessun nuovo testo JSX o attributo di accessibilità
+non tradotto è stato introdotto dal merge, secondo il confronto statico con `d8a29bfb`.
+
+## Aggiornamento e rollback locali
+
+Contesto di build: `/Users/mp/projects/ThothII`; launcher dell'installazione:
+`/private/tmp/thothii-memory-preview.sh`. Il launcher termina con l'override
+`/private/tmp/thothii-context-a.compose.yaml`, che seleziona questo checkout.
+Non applicare l'override della precedente revisione isolata: selezionerebbe di nuovo
+il worktree senza l'integrazione full/embedded.
+
+Comandi usati per costruire e sostituire il solo frontend:
+
+```sh
+bash /private/tmp/thothii-memory-preview.sh build frontend
+bash /private/tmp/thothii-memory-preview.sh up -d --no-deps --no-build --wait frontend
+```
+
+Configurazione Mac conservata: modalità `full`, lingua predefinita `en`.
+Aggiornamento completato alle 12:54 UTC: immagine frontend `605a6e6bba68`, container
+`9489a5765f7b`, stato healthy. Core (`3c3c0739b9af`), catalogo (`89755e439dc7`),
+Qdrant (`52ebd5c47955`) ed embedding (`7f690e534eda`) conservano gli stessi container,
+immagini e tempi di avvio rilevati prima dell'aggiornamento; sono tutti healthy.
+Il controllo dal browser usa l'accesso locale già presente, senza logout, modifica
+del catalogo o avvio di una sessione del modello. Sul viewport reale da 771 px:
+titolo Manrope Variable a 24 px, margini full sinistro/destro di 24 px, tre blocchi
+Database con identica posizione x=45 e larghezza 681 px; nessun overflow della pagina.
+Verificati italiano e tema scuro; ripristinati inglese e tema chiaro.
+
+L'immagine prima del merge è conservata come
+`thothii-frontend:before-visual-shell-merge-20260913` (`781650644192`). Per ripristinare
+quella versione full precedente, senza toccare Core o i volumi:
+
+```sh
+bash /private/tmp/thothii-memory-preview.sh \
+  -f /Users/mp/projects/ThothII/deploy/compose.visual-shell-rollback.yaml \
+  up -d --no-deps --no-build --wait frontend
+```
+
+Quel rollback reintroduce volutamente l'aspetto precedente al recupero grafico.
+Per tornare alla versione integrata usare il launcher senza l'override di rollback.
+Le immagini della revisione grafica isolata rimangono disponibili, ma non includono
+le nuove funzionalità full/embedded: non sono il rollback equivalente di questa consegna.
+
+## Conservazione del lavoro locale e prevenzione
+
+Le tre modifiche documentali locali preesistenti sono state protette nello stash
+`436d59225869aa3d93ee04077c566d371bde4099`. I due rapporti erano identici alle versioni
+del ramo grafico; tutte le aggiunte di PROJECT_STATE erano già contenute nel merge.
+Non è stato necessario riapplicarle o sovrascrivere le versioni integrate. Lo stash
+è conservato come ulteriore copia recuperabile.
+
+Prima di un successivo rebuild, confrontare il ramo corrente con gli altri worktree
+attivi e controllare il contesto di build effettivo del launcher. Un'immagine locale
+può provenire da un ramo laterale più recente del checkout principale. Il passaggio
+delle sole suite funzionali non certifica che la build contenga la revisione grafica
+già accettata: verificare anche l'ascendenza Git e i test visuali recuperati qui.