Un mnest annota che l'output di un executor è stato passato a un altro executor. Per esempio, può collegare la ricerca di alcuni file alla lettura dei file trovati. Il collegamento ha una direzione, un peso e un numero di utilizzi. L'archivio e le operazioni per gestirlo esistono, ma il runtime non registra ancora automaticamente i passaggi di ogni turno.
Il tipo Mnest e le relative operazioni sono definiti in
runtime/mnestoma.py. Il modulo conserva e interroga collegamenti fra
nomi e versioni di executor. Questi collegamenti descrivono una struttura
operativa dell'installazione: non sono ricordi personali e, da soli, non
dimostrano che Metnos stia imparando dalle abitudini dell'utente.
| Parte | Stato |
|---|---|
| Schema SQLite e API CRUD/query | Implementati. |
| Rinforzo, decadimento e rilevazione dei proto ricorrenti | Implementati. |
| Ager nel ciclo notturno | Registrato nello scheduler. |
| Registrazione automatica degli archi da ogni turno | Non collegata al runtime ordinario. |
| Uso diretto da pianificatore o Vaglio | Non collegato. |
Ogni mnest va da un executor sorgente a uno di destinazione:
src_executor → dst_executor. Conserva le versioni coinvolte, il
numero di utilizzi, il peso della relazione, le date del primo e dell'ultimo
aggiornamento e lo stato. In termini rigorosi afferma soltanto questo: un
componente ha registrato il passaggio da A a B.
La direzione conta: A→B e B→A sono record diversi. Anche una nuova
versione della destinazione produce una relazione distinta. Una catena
A→B→C contiene due collegamenti; walk() permette di
percorrerne più di uno.
Il record non contiene l'output scambiato e non può verificare da solo che
il trasferimento sia davvero avvenuto. La sua attendibilità dipende quindi dal
componente che chiama record_passing(). L'evento può includere un
turn_id, utile per cercare il turno d'origine se il riferimento
è stato fornito e il relativo registro esiste ancora.
Un mnest non è quindi una prova autonoma, una memoria biografica o una preferenza dell'utente. È telemetria strutturata su una relazione fra executor.
| Campo | Contratto |
|---|---|
id | Prefisso mn_ seguito da un token casuale. |
src_executor, src_version | Sorgente e versione dichiarate dal chiamante. |
dst_executor, dst_version | Destinazione; la versione è nulla per un proto. |
weight | Numero reale vincolato fra 0 e 1. |
uses | Contatore intero, almeno 1. |
ts_first, ts_last | Timestamp UTC; l'ultimo non precede il primo. |
decay_lambda | Velocità di decadimento. |
state | active, proto,
decaying o superseded. |
tags | Etichette JSON facoltative; non modificano il peso. |
desired_sig | Firma desiderata facoltativa, usata dai proto-mnest. |
L'unicità SQLite comprende sorgente, versioni, destinazione e stato. Poiché
SQLite considera distinti più valori NULL, il codice esegue una query
esplicita per rinforzare un proto esistente.
record_passing() esegue l'aggiornamento in una transazione. Se
trova lo stesso collegamento nello stato active, calcola quanto il
peso è diminuito dall'ultimo utilizzo, aggiunge il nuovo rinforzo, incrementa
uses e registra l'evento. Se il collegamento non esiste, lo crea
con peso 0.30.
Con dst_exists=False la stessa API crea o rinforza un
proto-mnest. La chiamata è atomica per la coppia cercata. Ogni istanza di
Mnestoma apre però una propria connessione SQLite e non va
condivisa fra thread.
Prima di ogni rinforzo, il peso precedente viene moltiplicato per
exp(-lambda × giorni); quindi viene aggiunto
0.15 e il risultato viene limitato all'intervallo 0–1. Il lambda
predefinito è 0.018 al giorno.
apply_ager() applica il decadimento agli archi
active e proto. Un arco attivo sotto
0.20 passa a decaying; un proto sotto
0.05 viene eliminato. Un arco decaying sotto
0.05 e inattivo da almeno 90 giorni viene soltanto contato come
candidato all'archiviazione: l'ager non lo cancella.
| Stato | Uso nel codice corrente |
|---|---|
active | Arco reale consultabile e rinforzabile. |
proto | Destinazione desiderata senza versione concreta. |
decaying | Arco sceso sotto la soglia dell'ager. |
superseded | Arco marcato come sostituito da un chiamante esplicito. |
transition_state() accetta soltanto questi valori e registra un
evento. Un uso successivo di record_passing() cerca un arco
active; non riattiva automaticamente un record
decaying.
Un proto-mnest conserva una sorgente reale e il nome di una destinazione ancora
mancante. desired_sig può contenere sommario, input, output ed errori
attesi. recurring_protos() seleziona per default i record con almeno
tre usi e peso almeno 0.30.
promote_proto_to_active() imposta la versione di destinazione,
rimuove la firma desiderata e registra la transizione. Non crea, testa o attiva
l'executor: queste responsabilità appartengono a Synt e
al suo ciclo di promozione.
active; i comandi diagnostici possono elencare proto ricorrenti.nightly_aging richiama
apply_ager() insieme all'ager degli executor.Il pianificatore corrente non usa il peso dei mnest per ordinare il catalogo; il Vaglio non li legge. L0 e L1 hanno archivi e segnali distinti.
Il database predefinito è
<workspace>/.mnestoma/mnest.sqlite, modificabile con
METNOS_WORKSPACE o MNESTOMA_DB_PATH. Le tabelle
mnests ed events conservano stato ed eventi; la vista
v_mnestoma espone gli archi active e
proto.
Lo stesso database contiene anche canonical_query_log, una
tabella separata nata per la telemetria di normalizzazione delle richieste. Il
riuso corrente dei piani avviene negli archivi L0 e L1 descritti nella guida ai
fastpath e autopath: una riga in questa tabella non
è un mnest e non dimostra che il grafo dei collegamenti sia stato aggiornato.
Il modulo non crea snapshot mensili e non comprime automaticamente il database.
Puoi chiedere a Metnos: «Il mnestoma viene alimentato automaticamente dai miei turni? Quali componenti lo consultano oggi?»
La risposta corretta deve distinguere il codice disponibile dall'integrazione: l'archivio, il compositore, l'ager e gli strumenti di ispezione esistono; la registrazione automatica degli archi dai turni non è collegata. Non deve inventare un grafo personale già appreso.