Synt costruisce un candidato executor quando il catalogo non offre una capacità adatta. Non trasforma una frase del modello in codice subito eseguibile: prima esclude duplicati, separa contratto e implementazione, esegue controlli e prove iniziali, firma l'artefatto in stato di quarantena e lo consegna al processo di promozione, che lo valuta e ne governa osservazione e ripristino.
Synt riceve un intento non coperto e produce una proposta conforme al contratto degli executor. Il risultato può includere nome canonico, schema degli argomenti, capacità, reversibilità, prove, descrizione, affinità e codice Python.
Synt non amplia i permessi dell'utente, non crea verbi o oggetti fuori dal vocabolario, non sovrascrive executor artigianali e non rende un candidato visibile al pianificatore soltanto perché il codice compila. Regole, standard, firma, sandbox e consenso restano controlli separati.
La richiesta interna request_new_executor deve indicare un nome atteso
e l'intento da coprire. Prima di spendere chiamate di generazione, il runtime esegue
controlli di ammissione:
proposed o synthesized, non
ne crea un duplicato.Questi controlli sono guidati dal catalogo, dal vocabolario e dal registro delle integrazioni, non da eccezioni scritte per una singola frase.
La soluzione meno invasiva è la composizione di capacità già firmate. Il compositore può cercare nel mnestoma una catena breve che soddisfi l'intento e restituire al motore il primo passo suggerito. In questo caso non nasce un nuovo executor.
Se manca davvero una capacità atomica o una sequenza promuovibile, parte la sintesi multistadio. I due risultati restano distinti:
| Esito | Artefatto | Visibilità |
|---|---|---|
| Composizione | Catena di executor esistenti | Usabile nel turno dopo i controlli ordinari |
| Sintesi | Nuovo candidato con manifest, codice e prove | Quarantena fino alla promozione |
| Stadio | Risultato vincolante |
|---|---|
| 1. Nome e classe | azione_oggetto[_qualifier], criticità, reversibilità e tipo di bersaglio. |
| 2. Firma operativa | Schema degli argomenti, capacità dichiarate e schema inverso quando richiesto. |
| 3. Prove iniziali | Almeno tre casi con dati in ingresso ed esito osservabile atteso. |
| 4. Descrizione | Intestazione del manifest conforme, affinità e confini d'uso. |
| 5. Codice | Implementazione di invoke e dell'eventuale operazione inversa, costruita sul contratto precedente. |
Gli stadi 1–4 usano il ruolo LLM middle; il codice usa
wise. Sono ruoli configurabili e possono puntare allo stesso fornitore
locale. Ogni stadio riceve soltanto la richiesta e i risultati convalidati degli stadi
precedenti: il codice non può ridefinire silenziosamente il contratto.
Un errore infrastrutturale del giudice semantico viene registrato ma non è da solo un rifiuto: i controlli deterministici, le prove e il valutatore a valle restano obbligatori. Questa è una degradazione esplicita, non una prova di allineamento.
Quando tutti gli stadi e le prove iniziali terminano con successo, il runtime scrive
il candidato nell'archivio degli executor dell'utente con ciclo di vita
synthesized e firma il manifest. La firma attesta integrità
dell'artefatto; non equivale all'attivazione. Il caricatore può ispezionarlo, mentre il
catalogo del compositore lo esclude.
Il processo di promozione valuta poi il documento della proposta con segnali deterministici: conformità del nome, sovrapposizione con capacità esistenti, prove, parità della reversibilità, classi di errore, stabilità dello schema, frequenza d'uso, vantaggio stimato e rischio di interferenza con l'instradamento.
| Verdetto | Effetto |
|---|---|
accept | Nuova verifica di ammissione, firma attiva, archivio di ripristino e periodo di grazia. |
gray | Revisione amministrativa necessaria; nessuna attivazione implicita. |
reject | Archiviazione con motivazione; il candidato non entra nel catalogo attivo. |
Chiedi a Metnos con una richiesta come quella di questo esempio: «Nei file CSV della cartella Sensori individua le sequenze di almeno cinque misure che aumentano senza interruzioni e crea un riepilogo per sensore.»
Metnos tenta prima una sequenza con le capacità esistenti: ricerca dei file, lettura CSV, estrazione e raggruppamento. Solo se il catalogo non rappresenta l'operazione necessaria può proporre una nuova capacità. La risposta deve distinguere chiaramente tre casi: operazione completata con strumenti esistenti, candidato creato ma non ancora attivo, oppure sintesi rifiutata con motivo.
Da Telegram si usa la stessa frase. Se serve una decisione amministrativa, Metnos deve indicare che la gestione avviene nella chat web e fornire il percorso corrente, per esempio Settings › Ciclo di vita › Modifiche, invece di mostrare soltanto un identificatore di proposta.
Una proposta accettata entra normalmente in un periodo di grazia configurabile. Il processo di promozione crea prima un archivio di ripristino. Durante la grazia, gli errori gravi osservati nei turni possono attivare l'interruttore di arresto; l'amministratore può inoltre confermare o ritirare la promozione dal riepilogo ricevuto. Alla scadenza senza segnali negativi, la promozione viene finalizzata.
Il ciclo di promozione dei candidati Synt e il ciclo unificato degli
intenti di modifica hanno responsabilità distinte. Un candidato
synthesized non viene duplicato come falsa proposta da approvare in un
secondo archivio.
I prompt degli stadi vengono caricati nella lingua del turno. Descrizione e affinità possono essere localizzate; nomi canonici, campi di schema e identificatori restano stabili. Eventuali chiavi i18n introdotte dal codice vengono registrate per il normale processo di traduzione, non inventate in una singola pagina dell'interfaccia.
Proposte, risultati degli stadi, motivi di rifiuto, valutazioni, promozioni e operazioni di ripristino sono conservati negli archivi locali e nei registri JSONL. I prompt non ricevono credenziali in chiaro. Il codice generato resta soggetto ai moduli Python consentiti, al profilo di sandbox e ai limiti dell'executor standard.
Riferimenti nel codice:
runtime/synth_request.py: ammissione iniziale e persistenza del candidato;runtime/synt_multistage.py: cinque 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.