Un mnest rappresenta una relazione diretta e pesata da un executor
sorgente a uno di destinazione. Il relativo archivio, le query e l'ager sono
implementati. Il runtime corrente, però, non chiama automaticamente
record_passing() alla fine dei turni: un record presente è quindi un
dato inserito da un chiamante esplicito, non la prova che ogni passaggio osservato
venga appreso dal prodotto.
Il tipo Mnest e le sue operazioni vivono in
runtime/mnestoma.py. Conservano e interrogano collegamenti fra nomi
e versioni di executor; non rappresentano una memoria personale e non implicano
apprendimento automatico.
| 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. |
Un mnest ha direzione src_executor → dst_executor, versioni,
numero di usi, peso, istanti di primo e ultimo aggiornamento e stato. La struttura
può rappresentare il fatto operativo «un chiamante 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
è composta da due archi; la navigazione di più archi avviene nella query
walk().
Il record non contiene l'output scambiato e non verifica da solo che il
trasferimento sia avvenuto. La provenienza dipende dal chiamante di
record_passing(). L'eventuale turn_id nell'evento permette
di risalire al turno d'origine, ma soltanto se quel riferimento è stato fornito e
il relativo log esiste ancora.
Per questo un mnest non deve essere presentato come prova autonoma, memoria biografica o preferenza dell'utente. È telemetria strutturata su una relazione fra capability.
| 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() apre una transazione. Se trova lo stesso arco
active, applica il decadimento maturato, aggiunge il rinforzo,
incrementa uses e registra un evento. Altrimenti crea un nuovo arco
con peso 0.30 e un primo evento.
Con dst_exists=False la stessa API crea o rinforza un proto-mnest.
La chiamata è atomica per la coppia cercata, ma l'oggetto
Mnestoma mantiene una connessione per processo e non dichiara la
propria istanza thread-safe.
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 ospita canonical_query_log, alimentato da alcuni
turni come telemetria di normalizzazione. Quella tabella non è un mnest e non
dimostra che il grafo degli archi sia stato aggiornato. Il modulo non implementa
snapshot mensili o compressione automatica.
Chiedi a Metnos con una richiesta come quella di questo esempio: «Spiegami se il mnestoma viene alimentato automaticamente dai miei turni e 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.