feat(studio): unify studios and text memory

docs-dev/PIANO_CORPUS_TESTUALE_EMBEDDING.md

@@ -0,0 +1,167 @@
+# Corpus testuale, provenienza ed embedding
+
+Piano concordato il 3 ottobre 2026. Non descrive funzioni già implementate.
+Collega il lavoro sulla memoria di traduzione alle issue #227, #391, #382,
+#380, #377, #209, #223 e #381. Sostituisce il piano limitato a una frase con
+più vettori; le tecniche storiche sono un esempio di classificazione futura.
+
+## Decisioni
+
+- Unità testuali di lunghezza variabile: frasi, passaggi, pagine e sezioni.
+  La pagina fisica non coincide necessariamente con un'unità di significato;
+  un passaggio può attraversare pagine o frammenti.
+- Identità e versioni del testo indipendenti da traduzioni, segmentazione,
+  classificazioni e modelli. Originale diplomatico e forme normalizzate restano
+  distinguibili; una correzione a monte non cambia silenziosamente un estratto.
+- Una sola unità può avere traduzioni e più embedding. Aggiungere una misura
+  non duplica il testo né elimina quelle degli altri modelli.
+- Modello, dimensione e input identificato obbligatori per ogni embedding.
+  Nessuna compatibilità con vettori senza modello; dati locali di test da
+  aggiornare con operazione esplicita, senza inferire il modello dalla dimensione.
+- Un modello attivo per workspace. La ricerca confronta solo misure compatibili
+  per modello, dimensione e preparazione dell'input; niente ricerca fra modelli
+  diversi. Cambiare modello non distrugge gli embedding precedenti.
+- Memoria traduttiva, raccolte di studio ed evidenze documentali hanno ruoli
+  distinti e condividono provenienza e infrastruttura. Il corpus può nascere
+  prima della traduzione; una classificazione «tecnica» non è obbligatoria.
+- Per la memoria estratta, il workspace corrente deriva dalla traduzione;
+  spostarla non riscrive la provenienza storica. La ricerca globale esplicita
+  non sposta né collega la frase al workspace che la trova. Non estendere
+  automaticamente questa apertura a ogni corpus futuro.
+
+## Struttura da definire prima del codice
+
+1. **Unità e revisioni**: identità, testo, lingua, versione, relazione con
+   eventuali unità più grandi e selezioni della fonte. Non imporre una lunghezza
+   fissa derivata dal modello attuale.
+2. **Provenienza**: libro/fonte e versione, una o più pagine e posizioni,
+   revisione della trascrizione, traduzione/frammento quando presenti. Conservare
+   il testo selezionato oltre agli ancoraggi. Origine sconosciuta dichiarata,
+   mai ricostruita dal titolo della traduzione per supposizione.
+3. **Traduzioni**: lingua, testo e revisione associati all'unità. La memoria
+   traduttiva seleziona coppie riusabili senza possedere l'intero corpus.
+4. **Embedding**: input/versione, ruolo (originale, normalizzato, traduzione),
+   provider/modello identificato, dimensione, preparazione e data di calcolo.
+   Unicità sul medesimo input e profilo di misura, non sul solo modello:
+   originale e testo con contesto possono usare lo stesso modello.
+5. **Annotazioni**: tag manuali riutilizzabili separati dai metadati della fonte;
+   interpretazioni e proposte automatiche con autore/modello, revisione input,
+   stato proposto/confermato/rifiutato ed eventuale evidenza.
+
+Gli embedding devono riusare i contratti di revisioni, artifact, provenienza e
+job già previsti: evitare un sottosistema isolato o duplicare il registro #378.
+Consultare i moduli Scriptoria pertinenti prima della scelta dello schema,
+registrando quali pattern sono adottati, adattati o scartati (#186/#446).
+
+## Ordine di implementazione
+
+### 1. Contratti e schema
+
+- Mappare tutti i percorsi attuali di scrittura, lettura, ricalcolo, eliminazione
+  e backup, inclusa la cache delle misure del testo sorgente.
+- Definire la base comune minima e separare i vettori dal testo; aggiungere
+  vincoli, relazioni e indici. Schema in `0003_text_corpus.sql`, senza modificare
+  migrazioni già applicate. Il consolidamento prima del merge resta all'utente.
+- Aggiornare controlli di schema, formati di backup/ripristino e relativi
+  contratti; non attribuire retroattivamente modelli ai dati di test.
+
+### 2. Provenienza e revisioni
+
+- Completare la registrazione dell'origine della traduzione: oggi il collegamento
+  è predisposto e letto per lo stato delle opere, ma i percorsi di creazione
+  devono compilarlo per rendere disponibile il libro alle frasi estratte.
+- Collegare i passaggi a fonti e revisioni; mantenere snapshot e posizioni.
+- Conservare origine e tracciamento quando si sposta o elimina una traduzione;
+  concordare la policy di sopravvivenza dei passaggi senza introdurre cancellazioni
+  implicite del corpus.
+
+### 3. Operazioni della memoria
+
+- Nuova coppia: salvare testo, provenienza e misura del modello selezionato.
+- Aggiunta/ricalcolo: creare o aggiornare solo la misura richiesta. Ripetere
+  l'operazione non duplica il testo; testi uguali con origini diverse non sono
+  fusi automaticamente.
+- Correzione della sola traduzione: nessun ricalcolo delle misure dell'originale.
+- Correzione dell'originale: ricalcolare le misure interessate; confermare testi
+  e vettori coerenti insieme, mantenendo il precedente stato se fallisce.
+  Dichiarare il costo delle misure multiple prima dell'operazione.
+- Proteggere da risposte tardive, doppio invio e modifiche concorrenti mediante
+  revisione dell'input e scritture atomiche. Un errore non elimina misure valide.
+- Eliminare una coppia di memoria e le sue misure senza lasciare record orfani;
+  non propagare la cancellazione a evidenze condivise senza policy esplicita.
+
+### 4. Ricerca
+
+- Misurare la query con il modello attivo e confrontare solo input compatibili.
+- Applicare lingue, ambito workspace, soglia e limite prima dei risultati.
+- Una unità appare una volta; mostrare provenienza e misura utilizzata.
+- Unità prive della misura richiesta restano consultabili nel catalogo ma
+  non entrano nella ricerca per somiglianza.
+- Le coppie già salvate nel frammento restano nella sua Memoria; non aggiungerle
+  alla graduatoria semantica come corrispondenze a distanza zero.
+- Cambiare ambito, lingue o profilo invalida i risultati precedenti.
+
+### 5. Interfaccia e tag
+
+- Componenti del design system per provenienza, misure disponibili, aggiunta e
+  ricalcolo espliciti, avanzamento, errori e protezione delle bozze.
+- Tag manuali riutilizzabili sulle unità, senza categorie obbligatorie legate
+  alla scherma; distinguere dati della fonte da interpretazioni.
+- Predisporre selezioni lunghe e relazioni fra unità senza consegnare in questo
+  task l'intera interfaccia di analisi.
+
+## Estensioni successive
+
+- Etichette multilingui, sinonimi e categorie più ampie/specifiche; vocabolari
+  controllati opzionali. Classificazione automatica soggetta a conferma.
+- Porzioni di ricerca associate a unità complete; possibili rappresentazioni
+  contestualizzate esplicitamente identificabili, senza modificare la citazione.
+- Ricerca combinata lessicale, filtri e semantica; valutazione specifica su
+  lingue, grafie e domini medievali, senza presumere qualità dai benchmark generali.
+- Confronti originali/traduzioni, testi normalizzati e testimoni, con input e
+  metriche versionati. Dataset riproducibili e collegamento a evidenze visive.
+- Modelli locali e multimodali tramite gli stessi contratti, senza promettere
+  che finestre di contesto maggiori rendano superflui selezione e verifica.
+
+## Verifica e solidificazione
+
+- Una coppia con small e large resta una coppia; ricalcolare small conserva large.
+- Modello/dimensione/profilo errati non entrano nel confronto; modello assente
+  rifiutato nei percorsi di scrittura e nei dati importati come embedding validi.
+- Ricerca locale/globale esplicita e filtri linguistici; nessun collegamento
+  workspace creato dalla consultazione; nessun doppione nei risultati.
+- Provenienza su più pagine, aggiornamento della fonte, spostamento/eliminazione
+  della traduzione e testi identici di origine diversa.
+- Modifica traduzione senza chiamate di misura; modifica originale con errore,
+  risposta tardiva e doppio invio senza incoerenza o perdita dei dati precedenti.
+- Tag/proposte legati alla versione analizzata; normalizzazione distinta
+  dall'originale; ancoraggi non riattribuiti silenziosamente dopo una correzione.
+- Backup/ripristino di testi, relazioni, tag, revisioni e tutte le misure.
+- Test mirati a fine implementazione, tipi/lint/formattazione e prova dal vivo:
+  estrazione → salvataggio → secondo embedding → ricerca → modifica → riapertura.
+- Guide IT/EN aggiornate quando cambia il comportamento effettivo. Questo piano
+  non deve comparire nell'help come funzione già disponibile.
+
+## Riferimenti verificati
+
+- [W3C Web Annotation](https://www.w3.org/TR/annotation-model/): selezioni per
+  posizione e citazione, provenienza delle annotazioni.
+- [TEI, segmentazione e allineamento](https://tei-c.org/release/doc/tei-p5-doc/it/html/SA.html):
+  annotazioni esterne e relazioni fra porzioni di testo.
+- [W3C SKOS](https://www.w3.org/TR/skos-primer/): concetti, etichette multilingui,
+  sinonimi e relazioni gerarchiche.
+- [Anthropic, Contextual Retrieval](https://www.anthropic.com/engineering/contextual-retrieval):
+  contesto delle porzioni e combinazione di ricerca lessicale/semantica.
+- [Google, Long context](https://ai.google.dev/gemini-api/docs/long-context):
+  capacità attuali e limiti; nessuna previsione certa sull'evoluzione degli LLM.
+
+
+## Implementazione attuale
+
+Base unità/revisioni/misure/tag separata; flussi Memoria su questa base; più modelli
+conservati, ricerca compatibile, correzioni atomiche e provenienza visibile; scelta
+esplicita del libro alla creazione; backup dei dati testuali. La migrazione
+incrementale 0003 conserva i testi esistenti e trasferisce le misure identificate;
+non attribuisce modelli ai vettori anonimi e non ricrea il database.
+Non comprende selettore di pagine/sezioni, analisi del
+corpus, tag automatici, ricerca ibrida o modelli locali: restano nelle issue collegate.

docs-dev/PRODUCT_ARCHITECTURE_2_0.md

@@ -390,6 +390,32 @@ Glossa prepara dataset versionati ed esportabili; l'addestramento resta
 esterno nella 2.0. Modelli o adapter prodotti fuori dall'app possono essere
 registrati, valutati e riusati tramite provider locali come Ollama.
 
+### Base del corpus testuale — decisioni, implementazione da completare
+
+Unità testuali di lunghezza variabile (frasi, passaggi, pagine, sezioni), con
+identità, revisioni e provenienza indipendenti dai modelli. Conservare il testo
+archiviato e la selezione nella fonte, anche attraverso più pagine. Originale,
+normalizzazione e traduzioni sono rappresentazioni distinguibili. Correzioni
+della fonte non riscrivono silenziosamente gli estratti già utilizzati.
+
+Memoria traduttiva, raccolte di studio ed evidenze documentali condividono la
+base; una «tecnica» è un esempio di classificazione, non il tipo obbligatorio
+del corpus. Tag manuali riutilizzabili separati dai metadati della fonte;
+annotazioni automatiche identificano input/versione, modello e conferma umana.
+Vocabolari controllati, gerarchie e classificazione automatica sono estensioni.
+
+Una unità può avere più embedding. Ogni misura dichiara input e revisione,
+ruolo del testo, provider/modello, dimensione e preparazione. Modello obbligatorio,
+senza eccezioni per dati precedenti. Il workspace mantiene un modello attivo;
+aggiungere una misura conserva le altre. Ricerca solo fra misure compatibili,
+senza confronto fra modelli diversi. La ricerca globale esplicita della memoria
+non sposta gli oggetti né estende implicitamente l'ambito di ogni corpus.
+
+Il piano [Corpus testuale, provenienza ed embedding](./PIANO_CORPUS_TESTUALE_EMBEDDING.md)
+definisce ordine, verifiche e solidificazione; issue #227, #391, #382, #380,
+#377, #209, #223 e #381. La base deve integrare revisioni e provenienza già
+esistenti, non creare un registro parallelo scollegato.
+
 ## 10. Scriptoria come riferimento principale
 
 Ogni issue implementativa 2.0 deve indicare quali moduli Scriptoria sono stati

docs-dev/README.md

@@ -24,3 +24,6 @@ ed export. #186 e #446 tracciano adozione e adattamento dei pattern.
 Piani e specifiche implementative completati non restano come documentazione:
 invarianti in architettura, regole visive nel design system, lavoro residuo
 nella roadmap.
+
+Piano aperto: [Corpus testuale, provenienza ed embedding](./PIANO_CORPUS_TESTUALE_EMBEDDING.md).
+Raccoglie le decisioni del 3 ottobre 2026; non descrive funzionalità consegnate.

docs-dev/ROADMAP_2_0.md

@@ -140,7 +140,8 @@ Issue: #183, #187, #397, #459, #462, #413, #471, #472; shell generale #210.
 
 - Verificare i percorsi già presenti e correggere le regressioni prima di
   aggiungere nuove varianti. Revisione UI/UX generale ancora da fare.
-- Rendere visibili log generali, salvataggio e stato dei lavori (#413),
+- Rendere visibili log generali, salvataggio (fatto per traduzioni e
+  trascrizioni, mancano le fonti) e stato dei lavori (#413),
   riusando la coda e i pannelli esistenti.
 - Riallineare capacità dichiarate e reali dei provider (#397). La ricerca
   aggregata (#395) viene dopo la verifica dei singoli provider. I risultati
@@ -221,6 +222,43 @@ e il testo delle pagine vicine come contesto di continuità nel prompt.
 L'immagine inviata (ottimizzata a misura scelta o copia locale così com'è) si
 sceglie in Impostazioni → Trascrizioni e per sessione nella scheda OCR.
 
+**Stato al 1° ottobre 2026 (#485 H e L).** Lo Studio sta nella finestra a
+ogni larghezza; salvataggio manuale di una versione (comando e Ctrl+S). La
+pagina iniziale delle Trascrizioni è un catalogo sul modello della Biblioteca,
+con gli stessi pezzi condivisi (scaffali, ricerca, filtri rapidi, tre viste,
+comandi di riga, barretta di completamento). Anche la pagina iniziale delle
+Traduzioni segue lo stesso modello (#485 N, primo passo: scaffali, filtri
+workspace e lingue, rinomina | elimina, creazione «da zero» con il file).
+**Restano**: strada «da una trascrizione» con copia fissata, legame con opera
+e trascrizione d'origine e, solo allora, i comandi apri l'opera / apri la
+trascrizione, filtri per biblioteca e secolo, raggruppamento per biblioteca;
+Studio di traduzione (#485 N): fatta la disposizione (T1: barra principale
+sempre in vista, riga d'intestazione, una colonna Strumenti a destra) e il
+salvataggio (T2: stato nella barra di stato anche per le trascrizioni,
+dischetto e Ctrl/⌘+S nei fogli, salvataggio prima di uscire) e la verifica (T3: spunta, motivi dei comandi
+spenti; il «da aggiornare» resta solo in memoria per scelta, si perde
+riaprendo) e lo storico (T4: sottolinguetta in Revisione, versioni dal
+dischetto, ripristino; **in futuro**: nomi/puntine sulle versioni, con una
+colonna nuova) e la configurazione della pipeline (T5: finestra a sei linguette
+comuni, sezione Modello e editor dei prompt comuni, niente spiegazioni fisse,
+«Azzera tutte le traduzioni» a icona, velo comune) e il velo oro sul frammento
+in traduzione (T6) e Memoria/risorse linguistiche (T7: scheda del frammento,
+modelli modificabili con filtro OCR, dizionari con ambito visibile, memorie
+con provenienza/modello e filtri, ricerca fra workspace). T7 implementato:
+resta la prova dal vivo. Decisione del 3 ottobre: nessuna retrocompatibilità
+per embedding senza modello; più misure per unità testuale, modello obbligatorio
+e ricerca compatibile. Base corpus implementata: unità/revisioni/misure/tag,
+provenienza e libro esplicito; selezione di pagine/sezioni e analisi restano future.
+Schema aggiornato da `0003_text_corpus.sql`, baseline applicata conservata;
+consolidamento prima del merge riservato all'utente.
+Costi T8 su pannelli comuni; conteggio blocchi confermato dall'utente.
+T9: revisione finale e nove correzioni della review implementate; i due Studio
+sono inclusi nello stesso ramo della PR #488. Restano CI e prova dal vivo;
+la UI/UX non è approvata dall'utente e richiede una nuova revisione visuale.
+quali riepiloghi unire
+nella colonna si decide dopo. Scelta multipla nei cataloghi, non chiesta per
+ora.
+
 Uscita: aprire una fonte reale, trascrivere più pagine — a mano o assistite
 da OCR/HTR —, correggere, riaprire e ritrovare testo, revisioni e riferimenti
 alla fonte.
@@ -233,6 +271,10 @@ Issue: #208, #221, #222, #209, #223, #189, #224; risorse contestuali #227.
 - Creare il progetto di traduzione dal testo approvato senza perdere provenienza.
 - Collegare fonte, trascrizioni e traduzioni dalla scheda dell'opera.
 - Integrare corpus e suggerimenti contestuali con ambito workspace chiaro.
+- Generalizzare #227 a unità testuali di lunghezza variabile, anche passaggi
+  attraverso più pagine; tecniche storiche come esempio di classificazione.
+  Tenere distinti corpus testuale ed evidenze visive #209/#223, collegandone
+  le provenienze. Tag manuali riutilizzabili e versioni del testo nella base.
 
 Uscita: image workbench e corpus di frammenti pronti; passaggio trascrizione
 → traduzione con provenienza conservata, storico ricostruibile.
@@ -267,6 +309,16 @@ L'addestramento resta esterno a Glossa.
 Il loro perimetro minimo per la prima beta completa va deciso sulla base dei
 casi reali: non dichiararli rimossi né prometterli tutti nel prossimo tag.
 
+Fondazione da strutturare ora: testo/versione/provenienza separati dalle misure,
+più embedding con modello/dimensione/input obbligatori; un modello attivo per
+workspace e nessuna cancellazione implicita degli altri. #391 va riallineata
+alla conservazione delle misure; #382 riusa questa base per originali e
+traduzioni. Backup/dataset conservano relazioni e revisioni. Ricerca ibrida,
+tag automatici, vocabolari multilingui e analisi di opere intere restano passi
+successivi, da valutare su testi medievali reali.
+
+Ordine e verifiche: [piano del corpus testuale](./PIANO_CORPUS_TESTUALE_EMBEDDING.md).
+
 ## Riferimenti e lavori trasversali
 
 Scriptoria resta il primo riferimento tecnico per fonti, deposito, lavori,