← 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. Il runner isolato esegue i casi dichiarati prima dell'ammissione; un caso fallito o un ambiente indisponibile arrestano il percorso.

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. Proposte, revisione e consenso

Una sintesi rifiutata da Birth resta una proposta inattiva: codice, manifest, lingue e motivo sono conservati fuori dal catalogo. Il suo identificativo serve per ritrovarla e non costituisce un consenso. Nessuna firma dell'agente può sostituire l'ammissione attraverso Birth.

L'operatore prepara o conferma da tre a sei casi indipendenti, ciascuno con nome, ingresso e risultato atteso. I casi generati da Synt non vengono presentati come prove indipendenti.
L'autorità amministrativa esegue quei casi nell'ambiente isolato di Birth e registra una prova firmata solo se tutti riescono. La prova lega il candidato esatto, il contesto, i casi e i risultati osservati.
L'operatore vede scopo, effetti dichiarati e risultati e decide separatamente se approvare. Il consenso vale un'ora ed è monouso per quel candidato.
Il produttore riprende il candidato attraverso tutti i controlli Birth. Una modifica dei file o del contesto invalida la revisione; un giudizio semantico incerto continua a impedire l'ammissione.

Il comando synt review prepara il documento di prova; metnos-f5-authority proposal review esegue la verifica e proposal approve registra il consenso esatto. Le chiavi private restano nell'autorità amministrativa. La registrazione delle prove firmate passa dall'autorità di scrittura dell'installer, senza nuovi permessi al runtime. Il revisore usa la stessa configurazione del modello dei servizi installati, anche quando il modello è un servizio esterno. Le variabili del chiamante non possono scegliere un modello diverso per la revisione. Prima delle prove e del consenso, la preparazione comune calcola l’impronta dai sorgenti acquisiti, senza modificare il codice della funzione. Questa prima integrazione usa l'installazione Linux supportata e non dispone ancora di una pagina web dedicata.

Ammissione in pre-esercizio e attivazione sono passaggi distinti. Il promotore e la gestione del ciclo di vita restano soggetti a Birth, alle prove indipendenti e ai permessi correnti. Un punteggio favorevole non certifica F5 e non attiva da solo il candidato.

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.
Revisione indipendente e consenso sono distinti: il loro esito positivo non sostituisce i restanti controlli Birth e la certificazione F5/F6.
La prima integrazione amministrativa è in collaudo; F5/F6 non sono dichiarati certificati. I casi indipendenti richiedono conferma dell'operatore.
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.