Il runtime accompagna una richiesta dall'ingresso alla risposta. Mantiene il contesto dell'utente, sceglie le capacità ammesse, costruisce o riusa un piano, applica i controlli e coordina gli executor. È il direttore d'orchestra di un turno, non un executor universale.
Un turno comincia quando Metnos riceve una richiesta e termina quando restituisce una risposta, chiede un'informazione indispensabile oppure affida un lavoro lungo a LRE. Il runtime associa subito la richiesta a:
Queste informazioni delimitano tutto ciò che segue. La cronologia di una conversazione non viene mescolata con quella di un altro utente; un dispositivo associato a un proprietario non diventa una risorsa comune; una credenziale viene cercata soltanto entro il mandato autorizzato per quel turno.
Consideriamo la richiesta: «Leggi i tre preventivi nella cartella Acquisti, confronta i prezzi e crea una tabella riepilogativa».
Il modello linguistico aiuta nei punti in cui serve capire o comporre linguaggio. I controlli di schema, identità, autorizzazione, collocazione e firma restano invece deterministici. Proporre un piano non equivale ad avere il potere di eseguirlo.
Il runtime prova i percorsi dal più semplice al più generale:
| Percorso | Quando serve | Che cosa viene ricontrollato |
|---|---|---|
| Regola deterministica | Per operazioni dal significato chiuso, come annullare l'ultimo turno o riprendere un dialogo noto. | Identità, stato corrente e contratto specifico. |
| Fast path | Per riusare un piano riuscito sulla stessa richiesta. | Firme del catalogo, argomenti variabili e condizioni operative. |
| Autopath | Per riusare un piano generalizzato e confermato su una richiesta affine. | Somiglianza, assenza di valori personali incorporati, catalogo e validazione completa. |
| Nuova proposta | Quando non esiste un percorso precedente affidabile. | Intero piano, passo per passo. |
Fast path e autopath sono cache di piani, non scorciatoie intorno ai controlli. Conservano le firme delle capacità rilevanti. Se il mondo operativo cambia, il riuso non è più valido e Metnos torna alla pianificazione ordinaria.
I modelli sono scelti per funzione attraverso livelli configurabili. Il runtime chiede, per esempio, un modello adatto alla pianificazione o alla sintesi; non dipende dal nome commerciale di un modello. La configurazione effettiva è visibile in Sistema › Modelli.
Un piano è una lista finita di passi tipizzati. Ogni passo nomina un executor presente nel catalogo, fornisce argomenti conformi al suo schema e può dipendere da risultati precedenti. Non contiene codice libero da eseguire.
{
"steps": [
{"tool": "find_files", "args": {"base_path": "~/Acquisti", "pattern": "*.pdf"}},
{"tool": "read_files", "args": {"from_step": 1}},
{"tool": "extract_entries", "args": {"from_step": 2, "fields": ["fornitore", "prezzo"]}},
{"tool": "create_files_spreadsheet", "args": {"from_step": 3, "path": "~/Acquisti/riepilogo.xlsx"}}
]
}L'esempio mostra la forma, non promette che ogni installazione possieda esattamente quegli executor. Il catalogo generato è la fonte per le capacità installate.
Il validatore rifiuta un executor sconosciuto, un argomento fuori schema, un riferimento a un passo futuro o una combinazione incoerente. Le guardie comuni possono anche inserire un produttore indispensabile, riallineare dipendenze note o chiedere una nuova proposta quando manca un'azione esplicitamente richiesta. Non aggiungono capacità estranee al catalogo.
I risultati non vengono copiati a mano nella richiesta del passo successivo. Il piano usa due riferimenti principali:
from_step: N passa la raccolta prodotta dal passo N;{{stepN.campo}} passa un singolo valore del risultato.Prima dell'invocazione, il runtime risolve questi riferimenti e ricontrolla lo schema finale. Se un produttore non restituisce dati, il consumer non riceve per errore il risultato di un vecchio passo. Se una raccolta è molto grande, può essere conservata nello scratchpad mentre il pianificatore ne vede soltanto una proiezione utile e dichiaratamente troncata.
I dati conservano anche la loro provenienza. Sapere che un valore arriva dal passo 2 non basta a trasformarlo in un percorso locale, in un destinatario o in un'autorizzazione: il consumer deve dichiarare che cosa accetta e il runtime deve poterlo verificare.
Ogni passo attraversa lo stesso punto di invocazione, indipendentemente dal fatto che il piano sia nuovo, riusato, programmato o destinato a un dispositivo remoto. Qui il runtime applica i controlli comuni e registra l'esito reale.
Se serve una conferma, l'esecuzione si ferma prima dell'effetto. La proposta deve rendere riconoscibili azione, scopo, destinazione e conseguenze rilevanti. La risposta viene legata all'utente e al turno che l'ha generata, così una conferma vecchia o appartenente a un'altra conversazione non può riprendere il piano.
Le credenziali seguono un percorso separato. Il pianificatore può indicare il tipo di accesso necessario, ma il runtime risolve il segreto da un archivio cifrato e da un mandato circoscritto soltanto al momento dell'esecuzione. Il valore non entra nel piano, nei messaggi del modello o nei registri ordinari.
Non tutte le richieste possono concludersi in un'unica risposta HTTP o Telegram.
Una ripresa non ricomincia alla cieca. Il runtime ricontrolla proprietario, scadenza, stato del dialogo, catalogo e condizioni operative prima di proseguire.
LRE distingue presenza del servizio e avanzamento del lavoro. Quando è disabilitato continua a segnalare la propria presenza senza eseguire attività; quando non ci sono unità eseguibili evita di aprire lavoratori concorrenti. La manutenzione periodica delle autorizzazioni resta attiva. Il numero di lavoratori segue la domanda e i limiti centrali, senza sostituire i controlli atomici di ammissione. La console separa risultati confermati, errori ed elementi saltati e indica quando i dati non sono aggiornati. Consumi non verificabili fermano il lavoro per sicurezza: non significano necessariamente spesa esaurita.
Il registro delle superfici e la guida del Tutor distinguono motore, lavoro accodato, unità in attesa e risultati confermati: l'attesa non implica approvazione e un risultato salvato non implica completamento dell'intero lavoro. La lettura di stati e contatori è una domanda informativa, non una richiesta di avviare operazioni.
Nella pagina Servizi, l'indicatore principale di LRE descrive la funzione, non il solo processo: grigio se disattivata con stato confermato, verde solo se abilitata e pronta, giallo se in transizione o non verificata, rosso per errore del servizio o configurazione non valida. I dettagli tecnici conservano lo stato del processo. Questa distinzione visiva non cambia i controlli di salute, le decisioni del supervisore o l'abilitazione persistente.
Un prerequisito conserva la collocazione prevista dai contratti verificati: se sia la ricerca sia la preparazione sono riservate al server, anche la preparazione LRE avviene sul server, indipendentemente dal dispositivo ricordato nella conversazione. Se uno dei componenti può lavorare su un dispositivo, la destinazione richiesta resta invariata e soggetta ai normali controlli. I dati restituiti da un executor non possono scegliere la destinazione.
La console LRE ricava l'avvio dai tentativi realmente eseguiti nella revisione corrente, non dalla creazione del lavoro. Una tabella compatta separa batch completati e previsti nella fase corrente dal totale noto di tutte le fasi, che può crescere. La percentuale principale riguarda la fase indicata come x/y, non il tempo; quella aggregata rimane nei dettagli tecnici. Un'unica lettura aggregata per pagina, circoscritta al proprietario, ricava una fine prevista indicativa della sola fase corrente già interamente materializzata, con almeno tre risultati della stessa fase sufficientemente recenti. Non somma fasi diverse: la previsione dell'intero lavoro resta separata e disponibile solo per piani a fase unica. Errori, pausa, motore non pronto o dati non aggiornati producono n.a. con un motivo; un lavoro da verificare ha precedenza sugli altri motivi.
L'analisi foto richiede una risposta del modello vincolata a uno schema e la convalida nuovamente prima di salvare. Una risposta troncata non diventa un risultato riuscito; il consumo effettivo resta registrato, senza aumentare automaticamente il limite. Il dominio distingue descrizione indisponibile, troncata, non valida o vuota e dichiara una causa recuperabile; uno schema di richiesta non valido richiede invece una verifica. Non ripete la chiamata al proprio interno: LRE applica i tentativi e gli effetti già ammessi. La diagnostica LRE conserva solo codici dichiarati nello schema di uscita approvato e cause enumerate del caricatore, mai testo arbitrario delle eccezioni.
Nel motore generale, l'esaurimento dei tentativi per un errore recuperabile porta a Richiede attenzione, conservando batch in attesa e risultati confermati. Una causa ignota richiede verifica senza retry automatici; errori permanenti espliciti e violazioni di contratto restano non recuperabili. La decisione di riprovare autorizza un solo tentativo, non un ciclo illimitato. Contabilità, autorizzazioni e sicurezza degli effetti restano obbligatorie. Lo storico può mostrare la causa approvata del tentativo senza confonderla con gli elementi che hanno prodotto un esito negativo di dominio.
Il controllo delle cartelle vuote lasciate da una pubblicazione interrotta usa una lettura condivisa: altri lettori non rendono il catalogo non valido, mentre lo scrittore resta escluso durante la verifica. Formato, proprietà, permessi e assenza di contenuti restano obbligatori; il controllo non ripara né elimina le cartelle. Uno stato LRE da verificare sospende nuovi blocchi, ma consente a quelli già avviati di salvare il proprio risultato.
La domanda di esecuzioni parallele rispetta la risorsa più limitata richiesta da ciascun blocco e i vincoli condivisi tra lavori: le capacità CPU, disco e VLM non si sommano quando servono contemporaneamente. L'ammissione effettiva resta del coordinatore centrale. L'analisi foto decodifica anche HEIC, senza modificare gli originali; un formato illeggibile resta un errore esplicito, mai una foto indicizzata. Ogni analisi completa salva un riferimento privato verificabile: un nuovo tentativo della stessa generazione riusa solo risultati con sorgente, modelli, istruzioni e contesto cartella corrispondenti. I riferimenti non pubblicano un indice parziale e non eliminano i controlli sui consumi.
L'elenco identifica attività e cartella, quando disponibili nel piano ammesso del proprietario; il dettaglio distingue fase osservata, blocchi in esecuzione e limite di concorrenza del lavoro. Questi conteggi non misurano thread o processi. Durante la scansione iniziale delle foto, un blocco rappresenta la scoperta, non l'intero archivio; il totale delle fasi successive non è ancora noto. Percentuale e previsione sono n.a., con motivo esplicito. Gli errori del lavoro restano evidenti anche quando il servizio è pronto.
Una contesa temporanea di scrittura SQLite sospende le nuove ammissioni con attesa crescente e limitata, senza fermare immediatamente le altre corsie. Più errori simultanei contano come un singolo ciclo fallito. Corruzione e guasti diversi non vengono classificati come contesa. Il caricatore delle capacità distingue gli aggiornamenti delle statistiche d'uso dalle effettive modifiche di disponibilità, che continuano a invalidare il catalogo verificato.
Un executor può riuscire, non produrre alcun elemento, produrre un risultato parziale oppure fallire. Questi casi non sono equivalenti. Il runtime conserva la distinzione e la usa per decidere se proseguire, tentare un recupero limitato o terminare.
Il recupero non ripete ciecamente un'azione che potrebbe avere già modificato lo stato. Prima classifica l'errore e considera gli effetti registrati. Se non esiste una ripresa sicura, la risposta dichiara il limite. Quando solo una parte del piano fallisce, ciò che è riuscito rimane visibile senza trasformare il risultato complessivo in un falso successo.
La traccia del turno comprende il percorso scelto, i passi, i controlli, i tempi, gli esiti e l'eventuale ricevuta di annullamento. Non deve contenere segreti. Amministratori e utenti vedono soltanto le informazioni compatibili con il proprio ruolo e la propria identità.
In una frase. Il runtime non stabilisce che cosa Metnos può fare: lo stabiliscono gli executor ammessi. Il runtime fa sì che quelle capacità vengano scelte, controllate, eseguite e raccontate nello stesso modo, qualunque sia il percorso che ha prodotto il piano.