← Indice documentazione Guida all'architettura › Synt

Metnos

Synt: colmare una lacuna senza attivare codice alla cieca

Prima riusa ciò che esiste; se non basta, costruisce e mette alla prova un candidato isolato.

Synt è la parte di Metnos che affronta una capacità mancante. Può trovare una combinazione di executor già ammessi oppure generare un nuovo candidato. In nessuno dei due casi una risposta del modello diventa subito un potere attivo: composizione e generazione seguono percorsi distinti, con controlli e responsabilità diverse.

1. Due percorsi diversi

Percorso	Quando serve	Che cosa produce
Composizione	La capacità esiste già, ma è distribuita tra più executor.	Una breve catena di executor attivi e firmati. Non nasce nuovo codice.
Generazione	Manca davvero una capacità rappresentabile dallo standard.	Un executor candidato con manifest, codice e prove, ancora escluso dal catalogo operativo.

Synt non aumenta i permessi dell'utente e non aggira il catalogo. Un nuovo executor deve usare i verbi e gli oggetti canonici, dichiarare argomenti, capacità ed eventuale annullamento, superare le prove e rispettare il profilo di esecuzione. La firma protegge l'integrità dell'artefatto; non ne autorizza da sola l'uso.

2. Prima di generare

Il percorso multistadio inizia dalla richiesta interna request_new_executor, che contiene un nome atteso e l'intento da coprire. Prima di interrogare i modelli, il runtime verifica se la lacuna esiste davvero:

se il nome esiste già nel catalogo, restituisce l'executor corrente;
se esiste un produttore canonico equivalente, reindirizza a quello;
se una skill importata copre già verbo e oggetto, reindirizza a quella capacità;
se la richiesta riguarda un'associazione nativa, come file remoti, SSH o un sito autenticato, indica l'executor integrato appropriato;
se esiste già un candidato proposed o synthesized, non ne crea un duplicato.

Questi controlli usano catalogo, vocabolario e registro delle integrazioni. Non dipendono da frasi speciali inserite per un singolo caso. Se trovano una capacità esistente, Synt restituisce il nome da usare e non genera nulla.

3. Comporre executor esistenti

Quando il runtime osserva una relazione ancora incompleta tra attività già note, può cercare nel mnestoma una catena di massimo cinque passaggi. La ricerca considera soltanto executor attivi; se trova un percorso, propone al motore il primo executor da eseguire e lascia che il turno prosegua con i controlli ordinari.

Questa composizione reattiva non è un finto primo stadio di request_new_executor. È un percorso separato, basato su una relazione già registrata nel mnestoma. La generazione multistadio parte invece dopo i controlli di ammissione descritti sopra.

4. Generare un candidato

La generazione separa le decisioni sul contratto dalla scrittura del codice. I primi cinque stadi producono l'artefatto; un sesto lo confronta con la descrizione:

Passaggio	Carico logico	Risultato vincolante
1. Nome e classe	`middle`	`azione_oggetto[_qualifier]`, criticità, annullabilità e tipo di bersaglio.
2. Firma operativa	`middle`	Schema degli argomenti, capacità dichiarate e schema inverso quando richiesto.
3. Prove iniziali	`middle`	Almeno tre casi con dati in ingresso ed esito osservabile atteso.
4. Descrizione	`creative`	Testa del manifest, termini di affinità e confini d'uso.
5. Codice	`wise`	`invoke`, `main` e l'eventuale operazione inversa, costruiti sul contratto precedente.
6. Coerenza	`wise`	Confronto tra comportamento descritto e codice generato.

I nomi indicano carichi logici, non modelli fissati nel codice. Provider, modello e criteri di generazione sono scelti dalla configurazione centrale dei tier. Ogni passaggio riceve la richiesta e soltanto gli esiti già convalidati: il codice non può ridefinire in silenzio nome, argomenti o annullabilità.

5. Controlli e prove reali

Validazione per stadio. Forma del nome, vocabolario, tipi, reversibilità, prove e descrizione vengono controllati prima di proseguire.
Controllo strutturale. Tra codice e verifica semantica, un controllo deterministico impedisce al manifest di citare argomenti inesistenti, campi risolti dal runtime o un risultato incompatibile.
Verifica semantica. Un giudice separato confronta descrizione e codice. Il verdetto è probabilistico; la decisione di rifiutare una discordanza esplicita è applicata dal codice.
Contratto generato. Formato del manifest, standard, ciclo di vita e regole di esecuzione devono coincidere con il modello posseduto dal runtime.
Compilazione e prove reali. Prima dell'installazione il codice deve essere Python valido. Subito dopo, il test runner esegue i casi dichiarati; se uno fallisce, la copia in quarantena viene rimossa.

Se il giudice semantico segnala una discordanza, restituisce un payload non tipizzato o non è disponibile, il candidato viene rifiutato. Linter e giudice non sono disattivabili tramite variabili d'ambiente. Un errore infrastrutturale viene registrato come indisponibilità, non trasformato in una certificazione di coerenza.

6. Quarantena e promozione

Quando i passaggi e le prove terminano con successo, il runtime salva il candidato nell'archivio degli executor dell'utente, imposta il ciclo di vita a synthesized e firma il manifest. Il caricatore può ispezionarlo, ma pianificatore e compositore non possono ancora sceglierlo.

Ogni giorno il promotore esamina fino a cinque candidati, partendo dai più vecchi. Il valutatore è deterministico: controlla nome, sovrapposizione con capacità esistenti, prove, coerenza dell'annullamento, classi di errore, stabilità del risultato, frequenza d'uso e vantaggio stimato.

Verdetto	Effetto
`accept`	Promozione automatica dopo una nuova verifica di ammissione, con archivio di ripristino e, di norma, 72 ore di grazia.
`gray`	Stato `review_needed`; nessuna attivazione automatica.
`reject`	Archiviazione con la motivazione; il candidato non entra nel catalogo attivo.

Prima della promozione viene creato un archivio di ripristino. Se le notifiche Telegram dell'amministratore sono configurate, durante la grazia un riepilogo permette di confermare o annullare; scaduto il termine, la promozione viene finalizzata. Il controllo automatico degli errori osserva sempre i segnali, ma esegue davvero il ripristino soltanto se è stata abilitata l'opzione METNOS_PROMOTER_KILLSWITCH_ENFORCE=1.

Questo ciclo appartiene al promotore, non alla pagina unificata degli intenti di modifica. Un candidato synthesized non viene duplicato come falsa proposta da approvare in un secondo archivio.

7. Lingua e registri

I prompt vengono caricati nella lingua del turno. La descrizione del candidato e quella dei suoi argomenti nascono in quella lingua; il normale processo di allineamento dei manifest può aggiungere le altre versioni. Nome canonico, campi dello schema e identificatori restano invece stabili.

Il campo affinity è ancora una lista piatta di parole chiave, spesso mescolata tra italiano e inglese. Non è quindi pienamente conforme all'architettura i18n. La riprogettazione generale è registrata come attività di massima priorità e richiede analisi, confronto tra alternative, specifica e solo dopo sviluppo.

Proposte, risultati dei passaggi, motivi di rifiuto, valutazioni, promozioni e ripristini restano negli archivi locali. I prompt non ricevono credenziali in chiaro. Il codice generato è soggetto ai moduli Python consentiti, alla sandbox e ai limiti dell'Executor Standard.

8. Garanzie e limiti attuali

Nome, descrizione, prove e codice sono generati probabilisticamente. I controlli riducono il rischio, ma non sono una dimostrazione formale.
Le prove coprono soltanto i casi dichiarati. Periodo di grazia, telemetria e ripristino servono proprio per gli errori che emergono nell'uso reale.
Un verdetto accept produce oggi una promozione automatica. Il punteggio è una politica operativa configurata, non la prova che la nuova capacità sia utile in assoluto.
Il percorso gray viene registrato come richiesta di revisione, ma non dispone ancora di una superficie web dedicata e completa.
Il ripristino automatico basato sugli errori è disattivato per impostazione predefinita; senza l'opzione di enforcement, il controllo si limita a segnalare che avrebbe ritirato il candidato.
Synt non deve duplicare ciò che una sequenza appresa, una skill o un'integrazione sanno già fare.

Riferimenti nel codice:

runtime/synth_request.py: ammissione iniziale e persistenza del candidato;
runtime/synt_multistage.py: generazione a stadi, controllo strutturale e verifica semantica;
runtime/generated_executor_contract.py: contratto dei manifest generati;
runtime/proposal_evaluator.py: valutazione deterministica;
runtime/jobs/promoter*.py: promozione, riepilogo, grazia e ripristino;
runtime/loader.py: visibilità dei cicli di vita.