Il mnestoma è l'archivio locale dei mnest: i collegamenti fra executor che, insieme, formano un grafo operativo. Il codice sa salvare, percorrere, indebolire nel tempo e ispezionare questi collegamenti. Il runtime, però, non li registra ancora automaticamente alla fine di ogni turno; il mnestoma non va quindi scambiato per una memoria personale già appresa.

1. Scopo e stato

Mnestoma apre un database SQLite con scrittura WAL e vincoli di integrità fra le tabelle. La sua API permette di registrare collegamenti, cambiarne lo stato, percorrerli, cercare i proto-mnest ricorrenti e leggere statistiche ed eventi.

Nello stesso file esiste anche la tabella distinta canonical_query_log, con un collegamento di registrazione best effort dal runtime dei turni. Il riuso corrente dei piani non dipende da quella tabella e il runtime non chiama record_passing() per costruire gli archi. Le due strutture non vanno confuse.

2. Modello del grafo

Nel modello logico, ogni nodo identifica il nome e la versione di un executor; ogni mnest è un collegamento diretto e pesato fra due nodi. Un collegamento proto termina invece sul nome di un executor desiderato che non ha ancora una versione concreta. walk(start, max_depth) percorre il grafo a partire da un executor, esclude i proto per impostazione predefinita e ordina i percorsi dal peso medio più alto al più basso.

Questa struttura può essere usata dal composer di Synt per trovare una catena di executor già esistenti. Non genera L0 o L1, non modifica il ranking ordinario del pianificatore e non sostituisce il catalogo firmato.

3. Che cosa non contiene

4. Schema del database

All'apertura, migrazioni idempotenti aggiungono events.turn_id e canonical_query_log.args_observed ai database precedenti.

5. Scrittura e interrogazione

Le principali operazioni pubbliche sono:

• record_passing(): crea o rinforza un mnest o proto;
• transition_state() e promote_proto_to_active(): cambiano stato con evento;
• top_k_outgoing(), top_k_incoming(), walk() e by_tag(): interrogano il grafo;
• recurring_protos(), decaying() e top_active(): selezionano insiemi operativi;
• events_for(), audit_recent() e stats(): supportano ispezione e tracciabilità;
• record_canonical_query(): aggiorna la telemetria separata delle query normalizzate.

6. Ager notturno

Lo scheduler installa il processo nightly_aging alle 03:30. Il processo esegue in sequenza l'ager degli executor e Mnestoma.apply_ager(). Quest'ultimo:

1. decade gli archi active e proto in base al tempo;
2. sposta gli active sotto soglia a decaying;
3. conta i decaying candidati all'archiviazione;
4. elimina i proto sotto soglia;
5. conta i proto che hanno raggiunto le soglie di ricorrenza.

Se il processo viene richiamato due volte con lo stesso istante di riferimento, la seconda chiamata non applica altro decadimento. Una chiamata successiva con un orario più avanzato calcola invece il nuovo intervallo, aggiorna ts_last e registra gli eventi corrispondenti.

7. Archiviazione e conservazione

L'ager non archivia automaticamente gli archi decaying: restituisce un conteggio proposed_archive. Non esiste nel modulo una routine che crei snapshot mensili, comprima copie annuali o includa il database in un backup. Queste operazioni richiedono una politica esterna esplicita.

La sola cancellazione automatica del grafo eseguita dall'ager riguarda i proto-mnest con peso inferiore a 0.05. Anche in questo caso gli eventi associati vengono rimossi dalla foreign key con ON DELETE CASCADE.

8. Il nome nelle due lingue

Mnestoma è un nome tecnico di Metnos e resta invariato in italiano e in inglese, come mnest. Anche il modulo Python, la classe e la directory SQLite usano mnestoma. La pagina inglese conserva per compatibilità il vecchio indirizzo /en/architecture/mnestome.html, ma nel testo il nome del componente non viene tradotto.

9. Avvio e alimentazione

Alla prima apertura il database viene creato con schema vuoto. Non viene installato un seed nascosto di archi e non esiste uno stato seed ammesso dalla classe Mnest. Gli archi compaiono soltanto attraverso chiamate esplicite all'API o dati già presenti nel database configurato.

Un collegamento best effort può tentare di aggiungere ai turni una riga in canonical_query_log. Nessun sottosistema corrente fa affidamento su questa tabella per riusare i piani. In ogni caso, una sua riga non rappresenta la nascita di un mnest, di un cluster o di un percorso L0/L1.

10. Ispezione e osservabilità

Il comando python3 -m mnestoma offre sottocomandi per statistiche, ager, principali relazioni in ingresso e in uscita, proto-mnest, percorsi, riepiloghi ed eventi. Il renderer python3 -m observability render può includere conteggi, archi attivi, proto ed eventi recenti in una pagina HTML statica.

Questi strumenti leggono il contenuto dell'archivio; non dimostrano che il contenuto sia completo. Un mnestoma vuoto è un esito legittimo dell'integrazione corrente.

11. Confini operativi

• Il percorso predefinito è <workspace>/.mnestoma/mnest.sqlite: l'ambito è il workspace configurato, non un utente ricavato dal turno.
• Non inserire fatti personali, credenziali o contenuti dei documenti in tag e firme desiderate.
• Prima di usare il grafo per decisioni per utente servono ownership esplicita, autorizzazione e filtraggio; lo schema corrente non li rappresenta.
• Il composer può soltanto proporre catene presenti: catalogo, firme, policy, argomenti e guardie restano vincoli indipendenti.
• Il codice sorgente è la fonte del contratto operativo: runtime/mnestoma.py, runtime/synt.py, runtime/jobs/maintenance_tasks.py e runtime/observability.py.