← Indice documentazione Guida all'architettura › modifiche

Metnos

Ciclo di vita delle modifiche

Un oggetto comune per proporre, decidere, applicare e osservare un cambiamento.

Le sorgenti che suggeriscono un miglioramento non modificano direttamente Metnos. Traducono il suggerimento in un change_intent, cioè un record tipizzato con origine, obiettivo, motivazione, punteggio e stato. La pagina /admin/changes presenta questi record e mantiene visibile il loro percorso.

Indice

L'oggetto comune
Stati e transizioni
Sorgenti attive
Materializzazione, applicazione e osservazione
Cosa viene applicato
Esempio in linguaggio naturale
Garanzie e limiti

1. L'oggetto comune

I record sono conservati in ~/.local/state/metnos/change_intents.sqlite. I campi principali sono:

Gruppo	Contenuto
Identità	`id` e impronta deterministica per deduplicare proposte equivalenti.
Provenienza	Famiglia, modulo sorgente, identificatore originario e data di scoperta.
Intento	Tipo chiuso, obiettivo, sintesi, motivazione e payload specifico.
Priorità	Punteggio, confidenza e numero di sorgenti convergenti.
Decisione	Persona, azione, motivazione e istante della decisione.
Esito	Effetto applicato, metriche osservate, errore o dati di ripristino.

L'impronta non contiene la famiglia d'origine. Se due sorgenti descrivono la stessa modifica, l'upsert può riunirle in un record e aumentare la convergenza senza duplicare l'azione. Il punteggio resta un criterio di ordinamento, non un'autorizzazione.

2. Stati e transizioni

proposed  --accetta--> accepted --applica--> applied
    |                         |                    |
    |                         +--errore--> failed  +--misura--> observed
    +--rimanda--> staged                              |
    +--rifiuta--> rejected                            +--ok--> finalized
                                                     +--problema--> rolled_back

Una proposta rimandata può tornare in valutazione. Un errore può essere riprovato oppure rifiutato. Il ripristino è terminale nel registro e viene eseguito fisicamente quando il tipo di modifica lo consente. La macchina a stati impedisce passaggi arbitrari: una proposta non può diventare applied senza essere prima accepted.

3. Sorgenti attive

Il materializzatore interroga quattro adapter senza effetti collaterali:

Sorgente	Che cosa può produrre
Telos	Creazione o estensione di executor e prova controllata di una sequenza, a partire dalle teste di gruppi azionabili.
Introvertiva	Deduplica di executor; conserva inoltre gli stati già registrati che devono restare consultabili.
Synt	Richieste di creazione di executor e relativi stati terminali o ancora in corso.
Riscontri dell'utente	Proposta di rifiutare uno schema ricorrente dopo almeno due riscontri negativi coerenti.

Gli adapter traducono strutture diverse nello stesso schema. Non applicano la modifica e non trasformano una deduzione automatica in consenso umano.

4. Materializzazione, applicazione e osservazione

Attività	Frequenza predefinita	Responsabilità
`change_intent_materialize`	Ogni giorno alle 01:00	Legge gli adattatori, elimina i duplicati in base all'impronta e aggiorna l'archivio.
`change_applier`	Ogni 10 minuti	Elabora fino a 20 record accettati e registra l'effetto o l'errore.
`change_observer`	Ogni giorno alle 03:15	Misura fino a 200 modifiche applicate o in osservazione e decide se finalizzarle o ripristinarle.

Il periodo di osservazione predefinito è di sette giorni ed è configurabile con METNOS_CHANGE_GRACE_DAYS. I criteri dipendono dal tipo: salute dell'executor, integrità di un alias, risultato del turno usato per provare una sequenza o un nuovo riscontro sullo schema rifiutato.

5. Cosa viene applicato

Tipo	Effetto corrente	Ripristino
`create_executor`	Avvia la sintesi dell'executor; se esiste già, non lo duplica.	Archivia l'executor sintetizzato.
`extend_executor`	Estende il manifest, conserva una copia e firma di nuovo l'executor.	Ripristina il manifest conservato e lo firma di nuovo.
`dedupe_executors`	Crea un alias e ritira il duplicato solo se la provenienza consente l'operazione.	Rimuove l'alias e riattiva il duplicato.
`materialize_pipeline`	Esegue una volta la richiesta proposta come turno reale, con policy e controlli normali.	Registra il ripristino; il turno non installa un artefatto persistente da rimuovere.
`reject_pattern`	Aggiunge lo schema approvato al registro dei percorsi da evitare.	Rimuove la registrazione corrispondente.
`cache_pattern`	Resta supportato per record compatibili già presenti nell'archivio.	Retrocede la registrazione associata.

6. Esempio in linguaggio naturale

Chiedi a Metnos con una richiesta come quella di questo esempio: «Mostrami le modifiche al sistema che aspettano una mia decisione e spiegami la prima in parole semplici».

Le decisioni si prendono nella chat web. Se stai parlando con Metnos da Telegram, apri la chat web, entra nell'area di amministrazione e scegli Modifiche; il percorso tecnico è /admin/changes. La pagina permette di filtrare per stato, sorgente e tipo e offre soltanto le transizioni ammesse per ciascun record.

7. Garanzie e limiti

L'accettazione è una decisione esplicita attribuita all'utente amministratore; un punteggio alto non la sostituisce.
L'applicatore è idempotente per tipo e conserva una traccia locale; un errore porta a failed, non a un successo apparente.
Il ripristino dipende dal tipo. Per una sequenza eseguita come turno reale non è possibile annullare effetti esterni già avvenuti; restano validi i normali gate di consenso prima dell'esecuzione.
I testi provenienti da generatori automatici aiutano il triage, ma devono essere letti insieme a origine, payload ed effetti registrati.

Riferimenti nel codice: runtime/change_intents.py, runtime/change_intent_adapters/, runtime/jobs/change_intent_materialize.py, runtime/change_applier.py, runtime/change_observer.py, runtime/change_rollback.py e runtime/http_routes_admin.py.