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](../contracts/archive-repair.md). Risultati e limiti in
[E1 — validazione](../reports/knowledge-archives-release.md) e
[E2 — validazione](../reports/knowledge-archives-release.md) e
[E3 — validazione](../reports/knowledge-archives-release.md).

La [revisione di semplicità](2026-09-08-memory-evidence-simplification-review.md)
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](2026-09-08-memory-evidence-administration.md)
ed è consegnabile separatamente da [Memory management](2026-09-08-memory-management.md).

## 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](../adr/0019-author-evidence-in-app-with-automatic-activation.md).

## Consolidamento manuale e seguito Git — release 0 {#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, è:

```text
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](../evidence.md) attribuisce l'authoring al repository
del workspace: ThothII non lo modifica, non crea commit e non esegue push.
Il [contratto Workspace Evidence v3](../contracts/workspace-evidence-v3.md) 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.