ThothII/docs/plans/2026-09-08-evidence-management.md

Progetto: Evidence management

Data: 2026-09-08. Stato: archivio locale Markdown, editor esterni e consolidamento manuale con commit/push dell'operatore accettati per la release 0; restanti semplificazioni confermate, con chiarimenti su impatto core e controllo Git; E1, E2, E3 e il collegamento ai gate X1 implementati il 2026-09-09. Il contratto X1 è in Session corrections. Risultati e limiti in E1 — validazione e E2 — validazione e E3 — validazione.

La revisione di semplicità registra il riesame di Q1–Q15. Il flusso principale è draft scritta dallo specialista indipendentemente dall'installazione, raffinamento da parte del sistema e conservazione locale per uso e manutenzione. La proposta tecnica aggiornata distingue le fonti esterne dall'archivio canonico locale, evita PostgreSQL per le Evidence e toglie commit/push dal normale CRUD. La contemporaneità con attività core durante l'amministrazione non è più un requisito da supportare.

Il progetto rende consultabili le Evidence dall'applicazione e modificabili nei file locali tramite l'editor scelto dall'operatore. Segue le decisioni comuni di Administration ed è consegnabile separatamente da Memory management.

Risultato richiesto

Un amministratore apre Evidence management direttamente da Administration, cerca e filtra le Evidence registrate, consulta il documento completo e trova il percorso del file Markdown da modificare con un editor esterno. La voce segue Memory management e si trova allo stesso livello di Database management, senza appartenere alle sue funzionalità.

La consultazione è indipendente da una sessione e dalla disponibilità dell'indice semantico. Mostra le Evidence Unit complete, senza limitarsi ai frammenti o ai risultati più simili restituiti dal recall.

Accesso e modifica nella release 0

Il proprietario richiede file facilmente raggiungibili e modificabili anche da uno specialista non tecnico, con Markdown come formato di lavoro e senza JSONL per la gestione delle Evidence. Ha scelto editor esterni per la release 0: l'editor preferito sul Mac o PC, oppure vim, nano o equivalenti sul server. Questa scelta sostituisce la proposta di editor e form di contenuto dentro Evidence management. Non si integra un prodotto di editing né si costruisce un editor applicativo.

Evidence management mantiene elenco, ricerca, filtri e dettaglio. Mostra il percorso assoluto della cartella del workspace e di ciascun file, con possibilità di copiarlo, risolto dalla configurazione effettiva dell'installazione. Indica su quale host si trova: per Docker occorre il percorso persistente accessibile sull'host, non soltanto quello interno al container. Le istruzioni distinguono draft originali e file delle Evidence raffinate da manutenere; includono un esempio Markdown per crearne una.

Chi lavora sul server modifica direttamente i file; chi lavora su una copia sul Mac o PC la riporta nello stesso archivio con i propri strumenti. Non è richiesto costruire upload/download nell'applicazione o predisporre una cartella condivisa. Un percorso sul server non viene presentato come un file apribile dal browser locale.

Dopo aver salvato, aggiunto o rimosso i file, l'operatore controlla lo stato Git, esegue il consolidamento ed esegue commit e push; il normale diff Git è disponibile per approfondire le modifiche. La pagina mostra le istruzioni e i comandi con i percorsi effettivi. La richiesta più recente sostituisce la proposta intermedia del pulsante Apply file changes: non sono necessari un pulsante di esecuzione, watcher o operazioni Git automatiche. Il semplice salvataggio nell'editor, o di una copia fuori dall'archivio, non aggiorna il recall. Il consolidamento e il seguito Git sono descritti sotto.

Il Markdown canonico attuale non è già un formato di editing libero: il parser controlla marker e corrispondenza fra testo canonico e presentazione. Per le regole di dominio il testo codificato viene letto prima di verificare il rendering; cambiare la sola frase visibile può produrre un errore di canonicalità. E1 deve quindi rendere il Markdown locale realmente editabile: il testo leggibile è autorevole, i campi richiesti sono documentati e i metadati derivati sono aggiornati dal sistema. Non si chiede all'operatore di correggere marker, hash o una copia codificata del testo. Non si introduce un secondo archivio di scambio da sincronizzare.

Funzioni

• Elenco paginato e ordinabile; ricerca per testo, titolo e identificatore stabile.
• Filtri combinabili per workspace, kind, purpose, concetti, tabelle/colonne, Source Evidence, Review item e stato di pubblicazione.
• Dettaglio leggibile della card: contenuto tipizzato, ambito di applicazione, Supporting excerpt, provenienza e accesso alla Source Evidence disponibile.
• Creazione e modifica tramite file Markdown ed editor esterno, con esempio dei campi richiesti per kind. In assenza di documento esterno, l'applicazione registra una dichiarazione manuale come fonte quando acquisisce la modifica.
• Risoluzione dei Review item e gestione delle unità orfane o da ritirare.
• Cancellazione tramite rimozione del file, riconosciuta dal consolidamento nell'archivio locale verificato come accessibile; un errore di lettura non prova una cancellazione. La rimozione dal corpus e dall'indice è persistente.
• Un comando manuale di consolidamento per acquisire e validare le modifiche locali e renderle disponibili al core, con esito esplicito e possibilità di riesecuzione.
• Istruzioni per controllo del diff, commit e push dei file Evidence e dei relativi metadati necessari, eseguiti dall'operatore nel repository indicato.

Il servizio acquisisce il Markdown editabile e aggiorna la rappresentazione tipizzata e i metadati derivati, preservando gli identificatori delle unità esistenti. La cancellazione di una Evidence Unit non elimina automaticamente la sua Source Evidence o altre unità derivate dalla stessa fonte.

Salvataggio — Q12 semplificata

Il proprietario rifiuta la separazione ordinaria fra salvataggio della bozza e pubblicazione: le modifiche durante una sessione sono considerate rare e non giustificano un workflow editoriale separato. La scelta successiva dell'editor esterno sostituisce il Save della form con il salvataggio del file e un comando manuale di consolidamento. Questo acquisisce, valida e attiva insieme aggiunte, modifiche e cancellazioni, senza un successivo Publish o un secondo revisore. Commit e push sono il seguito manuale per versionare e trasferire il lavoro nel repository. L'operatore autorizza l'attivazione con il consolidamento. Le correzioni approvate nei gate chiamano direttamente lo stesso servizio e non richiedono un editor esterno.

L'ultimo chiarimento del proprietario sostituisce il requisito iniziale di aggiornare le sessioni aperte mentre un amministratore modifica le Evidence. Si assume che il core sia fermo o si ignora la contemporaneità: non servono aggiornamenti a caldo, notifiche, ricalcoli, attese delle sessioni o una modalità manutenzione dedicata. Il risultato di una modifica completata è usato nelle successive elaborazioni.

Restano le correzioni deliberate dalla sessione stessa secondo Q4: chiamano lo stesso servizio, attendono l'esito e permettono alla sessione di usare la correzione approvata. Il collegamento fra configurazione della ricerca e contenuto locale deve quindi funzionare senza richiedere un nuovo commit della fonte per ogni modifica; non richiede un sistema generale di aggiornamento delle altre sessioni.

Nel seguito, salvataggio applicativo indica questa acquisizione delle modifiche o la scrittura deliberata dal core. Il feedback ordinario è operazione in corso, completata oppure errore. Un successo completo significa che il contenuto è disponibile al core; se la persistenza riesce ma l'aggiornamento del corpus o dell'indice fallisce, l'esito deve dirlo e indicare come rieseguire il comando. Un errore tecnico non diventa una bozza che attende una nuova decisione editoriale di pubblicazione. Dopo un errore o un riavvio, un corpus parziale non deve essere dichiarato pronto per la successiva elaborazione.

Le decisioni Q11–Q15 e il successivo chiarimento sui vincoli sono registrati nell'ADR 0019.

Consolidamento manuale e seguito Git — release 0

Il proprietario richiede un flusso KISS affidato alla disciplina dell'operatore. Il comando proposto è tht evidence consolidate <workspace-root> nel harness: è da implementare, non è un comando già disponibile. Riutilizza parser, validazione e indicizzazione esistenti, adattati al Markdown editabile. La documentazione operativa e la pagina mostreranno l'invocazione effettiva per l'installazione, compreso l'accesso al core se il comando gira in Docker.

Il consolidamento svolge in sequenza questi passaggi:

1. Legge l'archivio locale e confronta aggiunte, modifiche e rimozioni con l'ultimo contenuto consolidato. Se l'archivio non è accessibile, si ferma: non interpreta il problema come cancellazione delle Evidence.
2. Verifica struttura e sezioni previste per kind, campi obbligatori, identificatori univoci, tipi, riferimenti e provenienza coerenti. Segnala file, campo o sezione, problema e correzione richiesta. Non valuta automaticamente la verità del contenuto e non riscrive il significato delle regole con un nuovo raffinamento del modello.
3. Se ci sono errori, termina con esito non riuscito prima dell'attivazione; lascia all'operatore i file da correggere e il comando da rieseguire. Se i controlli passano, aggiorna metadati derivati e manifest, inclusa la protezione delle correzioni e delle cancellazioni, poi prepara e verifica il candidato completo prima di renderlo attivo nel corpus e nell'indice Evidence locale.
4. Riporta un riepilogo testuale breve di file aggiunti, modificati e cancellati, l'esito locale, gli eventuali errori di indicizzazione e i file primari da includere nel commit. Dopo un errore tecnico si riesegue lo stesso comando, senza duplicare unità o perdere il contenuto modificato. Non dichiara pronto un aggiornamento incompleto e non avvia commit, push, pull o merge.

Il core legge soltanto il contenuto consolidato attivo, mai direttamente i file in corso di modifica. Una modifica salvata ma non consolidata, o un tentativo fallito, non deve mescolare testo nuovo e vecchi risultati di ricerca. Si conserva l'ultimo corpus valido; se un errore tecnico non permette di garantirne l'integrità, si segnala l'indisponibilità invece di usare uno stato parziale. Si riusa il percorso esistente di preparazione del candidato e attivazione, senza creare un secondo archivio autorevole o un sistema di coordinamento delle sessioni.

L'archivio mantenuto è una working tree persistente, versionabile nel repository che contiene quelle Evidence; può riusare il repository del workspace. Draft e unità curate restano contenuti distinti anche se ospitati nello stesso repository. Non si modifica una materializzazione temporanea o uno snapshot runtime ricreato dal preprocessing. Setup e pagina indicano working tree, cartella delle Evidence, branch e remoto configurati; non si creano automaticamente repository o remoti.

Il seguito manuale, documentato come sequenza da eseguire nel repository corretto, è:

git -C <repository-root> status --short
tht evidence consolidate <workspace-root>    # comando previsto, da implementare
git -C <repository-root> add -- <file-evidence-e-metadati-indicati>
git -C <repository-root> commit -m "Update Evidence"
git -C <repository-root> push

Il controllo umano usa i normali comandi Git nel terminale. git status --short mostra quali file sono cambiati; git diff HEAD permette, quando serve, di vedere le righe cambiate prima del consolidamento. git diff --cached è disponibile per controllare ciò che si sta per committare. Non sono richiesti un visualizzatore nell'applicazione, uno strumento grafico, due revisioni obbligatorie o un nuovo gate. I controlli strutturali del consolidamento vengono invece sempre eseguiti.

Si includono aggiunte, modifiche e cancellazioni dei dati primari necessari alla ricostruzione, compresi manifest e informazioni di cura manuale quando cambiano. Indici, cache, sessioni e segreti non fanno parte del commit Evidence. L'operatore controlla aggiunte, modifiche e cancellazioni prima di consolidare; i file nuovi segnalati da status vanno letti, perché non compaiono ancora nel diff dei file tracciati. L'output del consolidamento indica anche i metadati generati da includere nel commit. Errori Git, credenziali, branch senza upstream e conflitti vengono risolti con i normali strumenti Git, senza retry o risoluzioni automatiche.

L'ordine ha una conseguenza esplicita: un consolidamento riuscito aggiorna il core locale prima di commit e push. Se il push manca o fallisce, la modifica rimane locale e non è ancora trasferita al remoto; l'operatore completa il seguito Git. Un push riuscito, da solo, non aggiorna altre installazioni. Nessun processo sorveglia i file o impone che l'operatore abbia completato la sequenza prima di riprendere il lavoro.

Persistenza e contratto da evolvere

Il proprietario ha approvato la risoluzione persistente dei conflitti fra Memory ed Evidence nel round Q4 della discussione Memory. Quando la decisione richiede correggere un'Evidence, il core prepara una proposta che identifica l'unità e mostra il testo o l'ambito risultante. La correzione passa attraverso l'authoring e la pubblicazione di questo modulo, con le relative autorizzazioni e validazioni. L'accettazione della correzione da parte di un utente autorizzato avvia lo stesso salvataggio con attivazione automatica. L'interfaccia distingue una proposta da approvare, un aggiornamento in corso o fallito e una correzione già attiva; non basta risolvere soltanto la domanda corrente. È sempre possibile dichiarare inadeguate le opzioni proposte.

Oggi il lifecycle Evidence attribuisce l'authoring al repository del workspace: ThothII non lo modifica, non crea commit e non esegue push. Il contratto Workspace Evidence v3 lega la pubblicazione a una revisione coerente del workspace. La manutenzione dei file locali richiede un'evoluzione esplicita di questo percorso e del formato editabile.

Q11, riesaminata e accettata per l'archivio locale: la draft dello specialista deve restare producibile e consegnabile senza accesso al PostgreSQL o alla stessa installazione. La scelta aggiornata conserva le fonti in file/repository esterni e le Evidence raffinate in un archivio locale persistente su file Markdown, gestito dal sistema. Il CRUD modifica tale archivio e aggiorna l'indice senza commit/push verso le fonti. L'alternativa di rendere PostgreSQL autorevole anche per Evidence, suggerita nella prima parte della revisione, è ritirata. PostgreSQL rimane l'archivio delle Memory.

I file locali curati sono dati primari: sopravvivono a Clear e reindicizzazione e devono essere inclusi nelle copie di sicurezza dell'installazione. Una loro modifica non aggiorna automaticamente i documenti dello specialista o altre installazioni; un eventuale trasferimento dei file resta esplicito, senza sincronizzazione bidirezionale.

Il comportamento deve coprire le origini supportate dal prodotto: filesystem/Git, HTTP e S3. Nella proposta riveduta sono origini di acquisizione delle fonti e dei contenuti già disponibili. Servono importazione e provenienza coerenti; le unità raffinate e le modifiche manuali vengono conservate nell'archivio locale. La gestione delle Evidence non richiede di aggiungere scritture sui server HTTP o S3 di origine. Non si può dichiarare completato il CRUD lasciando queste unità in sola lettura senza un percorso di importazione utilizzabile.

Il descriptor evidence.source indica oggi l'origine acquisita dal preprocessing: non è già un importatore di documenti nel repository di authoring. Inoltre il runtime normalizza HTTP/S3 come documenti generici, mentre il parser canonico delle unità tipizzate viene applicato ai file sotto curated/<kind>/. La provenienza canonica ammette solo un percorso locale sotto source/; URI e fingerprint remoti esistono invece nel corpus acquisito. L'importazione deve collegare questi due livelli senza fingere che il percorso tipizzato sia già uniforme fra i trasporti.

Modifiche e ritiri devono sopravvivere alla successiva preparazione, sincronizzazione e reindicizzazione. La rigenerazione da una fonte non deve ripristinare silenziosamente una unità cancellata o sovrascrivere la correzione del curatore. La semantica di conflitto fra nuova Source Evidence e cura manuale è approvata in Q13.

Il runtime attuale non garantisce questa protezione durevole: evidence prepare rifiuta modifiche non committate ai file curati e al manifest, ma una fonte cambiata può rigenerare anche unità corrette manualmente e già committate. Il ritiro esplicito rimuove l'unità e i riferimenti nel manifest, senza conservare una soppressione che impedisca a una successiva generazione di riproporla. Questi comportamenti sono verificati in harness/tht/evidence/authoring.py; la gestione amministrativa richiede di evolverli, non solo di esporli come comandi dell'editor.

Q13, approvata: se la fonte aggiornata contraddice una correzione manuale, conservare in uso l'Evidence salvata dall'amministratore e mostrare il confronto in Evidence management. Una sostituzione richiede una scelta esplicita, seguita dalla stessa operazione di attivazione. La conseguenza è che la regola manuale può restare attiva anche se la fonte più recente dice altro, finché il conflitto non viene risolto. Il proprietario accetta questa conseguenza. La decisione comprende la permanenza delle cancellazioni e la protezione da sovrascritture silenziose: una nuova preparazione non deve riproporre automaticamente conoscenze eliminate.

Validazione e pubblicazione sono passaggi interni dell'unica operazione di salvataggio; un errore non dichiara attivo il nuovo contenuto. Il sistema continua a rispettare provenienza e coerenza del contenuto; il salvataggio esplicito dell'amministratore costituisce l'approvazione della modifica manuale. La decisione sullo storico delle Memory non elimina questi requisiti del dominio Evidence.

Creazione manuale e aggiornamento delle fonti — Q14 e Q15 approvate

Q14, approvata: consentire di scrivere una Evidence senza dover fornire un documento esterno. In release 0 la si scrive in un nuovo file Markdown nell'archivio indicato, usando l'esempio documentato. Il sistema registra una dichiarazione manuale come fonte gestita e la distingue dall'informazione derivata da documenti. Lo stesso criterio vale per una correzione che cambia il significato del contenuto: la dichiarazione dell'amministratore sostiene il testo corrente, mentre il documento originario resta collegato come origine e per rilevarne gli aggiornamenti. Non deve essere mostrato come prova di una regola che non contiene. Il consolidamento acquisisce anche le nuove unità manuali.

Oggi la provenienza canonica richiede fonte locale, hash ed estratti: non esiste un'origine manuale esplicita. La validazione verifica integrità e presenza testuale degli estratti, ma non dimostra la verità o il supporto semantico della regola. Attuare Q14 richiede distinguere nel contratto la fonte del testo corrente dal documento originario; non richiede inventare estratti o una validazione semantica automatica presentata come garanzia di correttezza.

Q15, approvata: riacquisire le fonti esterne su richiesta esplicita dell'amministratore, senza controlli periodici o accessi alle fonti a ogni domanda o salvataggio di una card. Fra due aggiornamenti richiesti, il sistema usa quanto già acquisito. Il consolidamento continua ad attivare la modifica locale senza richiedere prima un aggiornamento della fonte remota; eventuali conflitti scoperti alla successiva acquisizione seguono Q13.

Il proprietario ha approvato entrambe le raccomandazioni il 2026-09-08. Il successivo riesame conserva questi comportamenti e rende esplicita l'autonomia dello specialista che produce le draft. I dettagli tecnici seguenti descrivono la proposta semplificata.

Piano esecutivo

E1 — Raffinamento e archivio canonico locale

Modifica del sottosistema Evidence core. Rendere editabile il Markdown cambia il contratto che il codice attuale legge e scrive. Questa attività precede la pagina amministrativa: non è una modifica limitata alla presentazione o all'editor. Il nuovo formato conserva contenuti tipizzati, ambito e provenienza richiesti dal core, ma usa il testo visibile come unica rappresentazione autorevole del contenuto umano. Va identificato come una nuova versione del contratto Curated unit, distinta dalla versione del descriptor del workspace.

L'intervento coordinato comprende:

• parser, renderer e validazione in harness/tht/evidence/canonical.py;
• preparazione, scritture e migrazione in harness/tht/evidence/authoring.py, con adeguamento delle istruzioni e degli esempi usati nel raffinamento;
• acquisizione e normalizzazione in harness/tht/evidence/corpus/normalize.py, consolidamento e preprocessing, affinché producano il contenuto tipizzato atteso dall'indicizzazione e dal recall;
• correzioni deliberate dal core, provenienza e citazioni, che devono consumare e aggiornare coerentemente la nuova rappresentazione;
• contratto documentato e test del percorso completo: modifica del testo visibile, consolidamento, contenuto indicizzato e successivo utilizzo da parte del core.

Le Evidence esistenti devono essere convertite esplicitamente al nuovo formato e reindicizzate, verificando il mantenimento del contenuto e degli identificatori. La fase di sviluppo permette un passaggio unico; non è richiesto mantenere due formati di authoring concorrenti. Una conversione non rappresentabile fedelmente va segnalata. Si preserva il modello tipizzato interno dove possibile, per contenere la modifica nei componenti che dipendono dal documento senza ridisegnare le fasi del workflow NL→SQL.

Estendere i contratti in harness/tht/evidence/ per distinguere fonte corrente, dichiarazione manuale e documento originario. La dichiarazione viene gestita dall'applicazione insieme all'unità locale; chi scrive il Markdown non deve creare un file sorgente separato o gestire hash ed estratti. I campi per kind mantengono la validazione deterministica, senza attribuirle una verifica della verità della regola. Aggiornare il glossario e il contratto canonico con il codice.

Riutilizzare raffinamento, parser, renderer e validazione esistenti, distinguendo la working tree locale persistente dagli snapshot acquisiti e adattando il formato al testo Markdown editabile come fonte autorevole, senza duplicazione nascosta del contenuto umano. Documentare posizione dei file, campi richiesti e un esempio per la creazione. L'applicazione acquisisce le draft e conserva il risultato in file locali persistenti. Le mutazioni aggiornano contenuto canonico, presentazione Markdown e manifest; le scritture sono serializzate per workspace e controllano la versione corrente del record; una modifica concorrente non viene risolta sovrascrivendo silenziosamente il contenuto altrui.

Il salvataggio non richiede commit, push o un database condiviso con lo specialista. L'archivio locale è distinto dalla materializzazione runtime ricostruita da Git e dal corpus derivato. Consolidamento e preprocessing acquisiscono i contenuti locali curati; il core consulta soltanto il corpus attivo validato. Clear preserva i file e la ricostruzione dell'indice riparte da essi, senza sovrascriverli con nuove copie delle draft originali.

La persistenza conserva la cura manuale e le esclusioni necessarie a impedire la ricomparsa delle unità eliminate. La rigenerazione confronta le proposte con tale stato: assegnare un nuovo ID a un contenuto derivato non deve essere un modo per riattivarlo automaticamente aggirando una cancellazione. Le nuove proposte e i conflitti restano distinti dal corpus già approvato e attivo.

Verificare con archivi locali temporanei draft esterne e raffinamento, creazione manuale, cambiamento di significato con provenienza corretta, round trip del formato canonico, aggiornamento del manifest, cancellazione, conflitto fra scritture e retry. La validazione di un estratto presente nella fonte non viene usata come prova automatica di supporto semantico.

E2 — Pagina amministrativa e consolidamento manuale

Esporre API amministrative per elenco completo, filtri, dettaglio, mutazioni ed esito delle operazioni. Il backend applica autorizzazioni e isolamento, poi chiama il servizio di authoring del harness. Realizzare la pagina autonoma nell'AppShell con provenienza leggibile, percorsi effettivi dei file sull'host e istruzioni per modificarli con editor esterni, consolidarli e completare commit/push manualmente. Il comando di consolidamento acquisisce aggiunte, modifiche e rimozioni locali tramite lo stesso servizio. Nessun editor, form di contenuto o trasferimento file web è richiesto in R0; non serve una sessione del core.

Evolvere lo stage interno runEvidenceStage e il percorso harness tht preprocess evidence per attivare il contenuto canonico locale autorizzato. Il salvataggio non avvia una riacquisizione HTTP/S3, una nuova estrazione dalle Source Evidence o una scansione DWH. Il nuovo comando manuale Evidence riusa questo stage interno senza richiedere un preprocessing completo per ogni modifica.

Preparare e verificare il candidato Evidence prima di attivarlo. L'indicizzazione e la rimozione devono essere circoscritte al workspace e alle generazioni Evidence interessate nella collezione Reference condivisa. Preservare Schema, relazioni, LSH e Memory: il salvataggio non usa Preprocessing Clear e non ricrea l'intera collezione. Se l'attivazione fallisce, mostrare l'esito parziale e rendere ripetibile il completamento della stessa modifica, senza chiedere una nuova approvazione.

Adeguare la ricerca perché consumi l'archivio locale aggiornato, senza richiedere commit della fonte o cambiare configurazioni estranee. Adeguare il calcolo della readiness: aggiornare Evidence non dichiara risolto un blocco di Schema o Catalog. Dopo un Clear, l'eventuale necessità di preprocessing completo rimane esplicita; il solo consolidamento non ricostruisce tutti i derivati mancanti.

Verificare che i percorsi mostrati portino ai file effettivi anche su installazioni Docker e che una modifica alla frase visibile sia acquisita senza editing di metadati tecnici. Verificare creazione/modifica/cancellazione con esito disponibile al core, errore di indicizzazione dopo persistenza, retry e isolamento delle altre componenti della collezione. Le successive elaborazioni devono usare il contenuto corrente senza recuperare unità cancellate. Verificare le correzioni deliberate dalla sessione stessa, senza aggiungere prove di CRUD amministrativo concorrente al core. Un problema preesistente di Catalog deve continuare a impedire una falsa readiness. Verificare che errori strutturali impediscano l'attivazione e producano indicazioni correggibili, che il comando sia rieseguibile e che non esegua operazioni Git. Verificare che file modificati senza consolidamento e tentativi falliti non cambino il contenuto usato dal core né combinino versioni differenti di testo e indice. Provare la sequenza documentata di commit/push con repository temporanei e remoto locale, verificando l'inclusione delle cancellazioni e dei metadati necessari.

E3 — Importazione, refresh esplicito e conflitti con le fonti

Fornire un percorso di importazione locale per le origini già supportate, conservando contenuto acquisito e provenienza remota. Uniformare il passaggio alle unità canoniche: i documenti HTTP/S3 oggi normalizzati genericamente devono diventare file locali editabili. Le unità importate restano gestibili senza credenziali di scrittura sui server fonte.

L'azione amministrativa di aggiornamento delle fonti riacquisisce il contenuto e confronta le impronte con quanto già acquisito. Per le unità curate interessate, prepara il confronto con le proposte risultanti senza sostituire la dichiarazione manuale attiva. Questa protezione non dipende dalla capacità del modello di riconoscere ogni contraddizione semantica. La scelta dell'amministratore usa poi lo stesso salvataggio con attivazione; fonti invariate non richiedono nuova cura.

Verificare con origini controllate che la riacquisizione avvenga soltanto su richiesta, che un errore di accesso non venga scambiato per una cancellazione e che consolidamento/recall non chiamino i connettori di acquisizione remota. Verificare aggiornamento di una fonte collegata a una correzione manuale, permanenza della versione curata, decisione di sostituzione e mancata ricomparsa automatica delle unità eliminate.

La lettura può essere consegnata come incremento intermedio di E2, ma il progetto è completo soltanto con CRUD, attivazione e gestione delle origini previste. X1 nel piano comune collega le proposte provenienti dai conflitti con Memory e verifica che raggiungano questi stessi servizi con autorizzazioni ed esiti coerenti.

Criteri di completamento

• Tutte le unità sono raggiungibili mediante elenco e filtri, senza una sessione.
• La pagina mostra cartella e percorso effettivo sull'host per ogni unità. Markdown, campi richiesti ed esempi permettono creazione e modifica con editor esterni; i dati invalidi non vengono attivati e gli errori indicano il file da correggere.
• Una draft prodotta fuori dall'installazione può essere acquisita, raffinata e conservata localmente senza accesso dello specialista a PostgreSQL.
• Creazione, modifica e ritiro aggiornano l'archivio locale e il corpus usato dal core; non richiedono commit/push nel repository delle fonti.
• Una Evidence può essere creata senza documento esterno; la dichiarazione manuale è riconoscibile e il documento originario di una correzione non è mostrato come supporto di un'affermazione che non contiene.
• Una modifica o cancellazione completata resta valida dopo una nuova preparazione e reindicizzazione; non rimangono frammenti ricercabili della versione rimossa.
• Una fonte aggiornata in conflitto con la cura manuale non sostituisce l'Evidence attiva: il confronto resta disponibile all'amministratore fino alla sua decisione.
• Il consolidamento manuale completa anche l'attivazione, senza un successivo Publish; l'esito distingue operazione in corso, completata ed eventuali errori con retry.
• Il core usa soltanto l'ultimo corpus consolidato valido. File in lavorazione o consolidamenti falliti non diventano disponibili attraverso letture dirette.
• Dopo una modifica completata, le successive elaborazioni recuperano il contenuto corrente. Dopo una cancellazione completata non recuperano l'unità rimossa. Nessuna delle due operazioni riscrive decisioni, artefatti o SQL già prodotti.
• Clear e ricostruzione degli indici preservano le Evidence canoniche locali, incluse le correzioni e le esclusioni dovute a cancellazioni.
• Le correzioni originate da conflitti con Memory raggiungono lo stesso percorso autorevole delle modifiche amministrative e mostrano il proprio stato di pubblicazione.
• Le origini senza scrittura dispongono di un percorso utilizzabile verso l'authoring.
• Le fonti esterne vengono riacquisite solo su richiesta dell'amministratore; il consolidamento e il recall usano il contenuto locale già acquisito.
• API e pagina applicano accesso amministrativo e isolamento dei workspace.
• Le istruzioni identificano working tree e file effettivi; il seguito manuale include verifica del diff, commit e push. Nessun watcher o comando Git automatico è introdotto. L'esito distingue disponibilità locale e trasferimento al remoto.
• Il salvataggio delle Evidence preserva Memory, Schema, relazioni, LSH e Catalog Metadata; non elimina blocchi di readiness estranei all'aggiornamento Evidence.