Metnos è un assistente personale self-hosted con un'idea
insolita al centro: invece di nascere con un catalogo fisso di strumenti,
sintetizza da sé i propri executor — piccoli programmi firmati,
generati al volo dentro un vocabolario chiuso — e li orchestra con un
pianificatore LLM locale. Il cloud non serve né per pensare
né per agire: i modelli frontier sono un consulto opzionale, non il motore.
Il nome viene da mētis (l'intelligenza astuta) +
noûs (la mente). Vive su una macchina sotto il tuo controllo
fisico e legale; gli parli dai canali che già usi — Telegram
oppure il browser (porta 8770) — e tocca file, mail, foto,
calendario, web e GitHub: solo ciò che attivi, una skill alla volta.
Figura 1 — Metnos in un colpo d'occhio. Il processo vive su una macchina tua: i canali ricevono, la mente pianifica con l'LLM locale, le guardie filtrano, gli executor agiscono sui backend che hai attivato. Il tier frontier è l'unica cosa fuori dal recinto — ed è opt-in.
La carta d'identità
Voce
Stato reale
Forma
Processo Python ≥ 3.11, microarchitettura a executor; runtime ReAct con pianificazione one-shot (motore Mētis, cap. 5).
Strumenti
79 executor firmati nel repo, più quelli sintetizzati al volo dall'istanza (cap. 7) e quelli importati dietro gate (cap. 7). Tutti vettoriali: lista dentro, lista fuori.
Cervello
LLM locale servito da llama-server; quattro tier astratti fast / middle / wise / frontier (cap. 8). Frontier = cloud opt-in.
Canali
Telegram (long-poll in uscita, niente porte aperte) + web su porta 8770 (chat e dashboard admin), cap. 11.
Sensi
Pipeline immagini in-process: semantica + volti + EXIF in un indice unificato (cap. 10).
Lingua
i18n per costruzione: ogni stringa e prompt è dato per-lingua. IT + EN validate; altre lingue = pacchetto di traduzione drop-in (non ancora testate).
Una vetrina onesta, non un prodotto rifinito. Metnos è un
sistema vero, usato ogni giorno — ma costruito da una persona, per una
persona, su una macchina. È condiviso perché chi si appassiona di
homelab e architetture AI possa leggerlo, eseguirlo, costruirci sopra. Molte
capacità esistono ma sono state esercitate poco fuori dall'istanza di
riferimento.
2. Le tre scommesse
Tutto il progetto sta in tre scommesse architetturali. Sono scelte di campo,
non ottimizzazioni: ciascuna rovescia un'abitudine diffusa dei framework
agentici.
Figura 2 — Le tre scommesse. Ognuna rovescia un'abitudine dei framework agentici: skill importate a fiducia, cloud-first, LLM come oracolo da rilanciare a ogni turno.
Il confronto, senza sconti
Framework agentico tipico
Metnos
Strumenti
Scritti a mano, importati o generati free-form, poi eseguiti così come sono, con i privilegi dell'assistente
Sintetizzati anch'essi a runtime — ma da un vocabolario chiuso e auditato: firmati, invecchiati, smoke-testati e vagliati prima di poter girare
Sicurezza
Ci si fida dell'autore del pacchetto
Non ci si fida del pacchetto: il pacchetto deve superare i controlli (gate a 7 livelli, cap. 7)
LLM
Spesso cloud-first
Locale prima; frontier opt-in
Routing
Il modello sceglie un tool a ogni turno — non riproducibile
Deterministico per costruzione: inferenza locale a seed fissato, pareggi rotti da affinity curata (cap. 8)
Output
Libero, diverso per ogni tool
Uniforme: lista dentro / lista fuori, componibile fra step (cap. 6)
Undo
Raro o best-effort
Di prima classe: catalogo chiuso di pattern inversi, move = COPY-poi-DELETE, ok_count onesto (cap. 12)
Lingua
Inglese, stringhe nel codice
i18n per costruzione: stringhe e prompt sono dati per-lingua
Perché il determinismo conviene. La maggior parte degli agenti
tratta l'LLM come un oracolo da rilanciare: chiedi due volte, ottieni due piani
diversi. Metnos fa la scommessa opposta: un pianificatore locale,
vincolato a un vocabolario chiuso, può essere reso riproducibile.
Così il routing si misura, si mette sotto test di regressione, si
audita — come software ordinario. E si accumula: una richiesta già
risolta una volta viene rieseguita da un percorso veloce senza alcuna
chiamata LLM (cap. 9).
3. I concetti chiave, in sette carte
Sette parole reggono tutto il documento. Definirle adesso vi risparmia
mezz'ora di confusione fra trenta righe; ognuna ha la sua pagina di
microprogettazione in architecture/.
executor — una capacità eseguibile: un piccolo programma che
fa una cosa sola e bene (leggere file, mandare una mail, spostare messaggi,
cercare foto). Accetta liste in ingresso e produce liste in
uscita, ha un manifest che lo descrive, una firma Ed25519 che lo autentica e
un profilo di sandbox che lo confina. È l'unica classe di cose
che agiscono nel sistema.
vocabolario chiuso — ogni executor si chiama
verbo_oggetto[_qualifier[_descriptor]], componendo 23 azioni e 22
oggetti canonici più qualificatori in quattro famiglie. Non è una
convenzione estetica: è il confine di ciò che il sistema può
nominare — e quindi sintetizzare. Nuovi termini solo con governance
esplicita (necessario · generale · comprensibile).
manifest — la carta d'identità TOML di un executor:
descrizione in capitoli prescrittivi (SCOPO / PATTERN / NON / OUT), schema
degli argomenti, parole di affinità, pattern di reversibilità, digest del
codice. Non è documentazione per umani: è il prompt del tool,
scritto perché un LLM medio lo usi bene (cap. 6).
synt — il processo che fa esistere ciò che il pool non sa
ancora fare: una cascata di strategie a costo crescente che prima compone
executor esistenti e solo come eccezione documentata genera codice nuovo, in
cinque stadi più una verifica semantica (cap. 7). Propone; l'umano approva.
vaglio — il filtro che sta sempre prima dell'esecuzione:
una guardia deterministica (percorsi vietati, comandi irrecuperabili) seguita
da un giudice che pesa le operazioni in zona grigia e, sopra soglia, chiede
conferma esplicita all'utente con bottoni sul canale (cap. 12).
mnest · mnestoma — il mnest è il filo che collega due
executor attivati insieme: nasce dal contesto, si rinforza con l'uso, decade
se non riusato. Il mnestoma è il grafo di tutti i mnest: la memoria
associativa del sistema, su SQLite, curata da un processo notturno
(l'ager). Dà al pianificatore l'intuizione di «quale executor di
solito segue quale» (cap. 9).
skill ↔ backend — due assi ortogonali: la skill decide
se un gruppo di capacità è attivo, fidato e configurato (dormiente
finché manca il prerequisito); il backend decide come un'azione
gira contro un servizio concreto (calendario = ICS locale oppure Google), scelto
dalla configurazione — mai dall'LLM. Il pianificatore non vede mai il
fornitore.
L'anatomia di un nome
Il vocabolario chiuso è l'idea più fertile del progetto: rende i nomi
componibili (il pianificatore può prevedere come si chiama una
capacità che non ha mai visto), filtrabili (il prefilter ragiona su
verbo e oggetto) e sintetizzabili (synt non può nominare nulla fuori
dalla grammatica).
Figura 3 — L'anatomia di un nome. Quattro livelli posizionali, di cui gli ultimi due opzionali; i cinque verbi-produttori si distinguono per l'input primario, così il pianificatore non deve mai scegliere fra sinonimi.
4. L'architettura a strati
Metnos è una cipolla: l'esterno parla col mondo, l'interno esegue. Ogni
strato si fida solo di quello più interno e i privilegi calano scendendo
verso il centro. Una richiesta — venga da un utente o da un task
schedulato — li attraversa tutti, nell'ordine.
Figura 4 — I sette strati reali, con i moduli che li implementano. Il motore cognitivo (strato 3) è il cuore del capitolo 5; le guardie (strato 4) stanno sempre fra il piano e l'effetto.
Canali — un canale è un adattatore: converte un'interfaccia esterna (Telegram, browser) in messaggi e risposte. Aggiungerne uno non tocca il nucleo (cap. 11).
Runtime del turno — il guscio che misura e orchestra: telemetria per sotto-fase (intent_ms, prefilter_ms, vaglio_ms, exec_ms), cap di sicurezza, log.
Motore Mētis — pianifica una volta, esegue deterministicamente, recupera con criterio, e quando non c'è via d'uscita lo dice (cap. 5).
Guardie — nessun subprocess a mano libera, mai: ogni effetto passa da policy, vaglio e sandbox (cap. 12).
Executor e backend — chi agisce e contro cosa: la separazione skill↔backend tiene il fornitore fuori dalla testa del pianificatore (cap. 3 e 6).
Tessuti — ciò che resta fra un turno e l'altro: memoria associativa, scorciatoie apprese, cronologia per l'undo, audit.
5. Anatomia di un turno multitool
Questo è il capitolo da leggere se ne leggete uno solo. Seguiamo una
richiesta vera — «cerca le mail spam e mettile nel
cestino» — dall'ingresso alla risposta: quattro strumenti
concatenati, una sola chiamata al modello, ogni passaggio misurato e
annotato.
5.1 La cascata, passo per passo
La regola di fondo: il modello è l'ultima risorsa, non la
prima. Prima si tenta la memoria (zero LLM, millisecondi); se la
richiesta è nuova, il modello viene interrogato una volta sola e
gli si chiede l'intero piano; l'esecuzione che segue è pura meccanica
deterministica.
Figura 5 — L'anatomia di un turno multitool. Le scorciatoie (0 LLM) si tentano prima; se la richiesta è nuova, il Proposer chiede al modello l'intero piano in una sola chiamata vincolata; l'esecuzione è deterministica, con il vaglio davanti all'unico passo che modifica stato. A destra, i due percorsi d'errore: recovery mirata e vicolo cieco onesto.
Scorciatoie letterali. Una tabella chiusa riconosce le frasi notissime («che ora è») in microsecondi. Qui: nessun match.
Intent. Una chiamata al tier fast (ragionamento spento, ~0,4 s) estrae verbo canonico, oggetto e parole chiave. Le richieste composte diventano una lista ordinata di clausole, ognuna col suo pool.
Memoria dei piani. Fastpath (scorciatoie che hai approvato col bottone ★) e Autopath (piani imparati da soli) rispondono senza modello se riconoscono la richiesta. Qui: miss, è la prima volta.
Prefilter. Il catalogo si riduce al pool pertinente per la clausola: match su verbo+oggetto, bonus per qualifier, e — per rompere i pareggi fra fratelli — il bonus di affinity curata (cap +3). Tutto deterministico: stessa query, stesso pool, stesso ordine.
Proposer Mētis. UNA chiamata al tier wise produce l'intero piano: steps, collegamenti, messaggio finale. Genera fino a N candidati (adattivo, con early-stop), ognuno fisicamente vincolato dalla grammatica GBNF del pool; un rango teleologico sceglie il migliore.
Validator. Typecheck del piano prima di eseguire: tool esistenti, args ben formati, riferimenti reali. Un errore banale costa una riproposta, non un'esecuzione sbagliata.
Esecuzione. Meccanica pura: per ogni step il runtime risolve i segnaposti, passa dal vaglio, invoca in sandbox, accumula l'osservazione. Cap: 12 step per turno, stesso executor max 3 volte di fila.
Chiusura. Il messaggio finale è un template riempito dai risultati veri. Se il turno riesce, Autopath lo registra: la prossima volta si salta direttamente al punto 3.
5.2 Il piano: cosa propone davvero il modello
Il Proposer non produce prosa: produce un oggetto strutturato — steps,
slot da riempire (fillers), messaggio finale. Questo è il piano
reale della nostra richiesta:
{
"steps": [
{"tool": "find_messages",
"args": {"folder": "INBOX", "query": "is:unread"}},
{"tool": "classify_entries",
"args": {"from_step": 1, "dimension": "spam"}},
{"tool": "filter_entries",
"args": {"from_step": 2, "where_field": "spam", "where_value": "spam"}},
{"tool": "move_messages",
"args": {"from_step": 3, "dst_folder": "${FILLER:cestino_folder}"}}
],
"fillers": {
"cestino_folder": {
"prompt": "Come si chiama la cartella cestino per questo account?",
"default": "Trash",
"tier": "fast"
}
},
"final_message": "Spostate ${step4.ok_count} mail nel cestino."
}
Da notare: il modello non conosce il nome della cartella cestino
dell'account — e non lo inventa. Dichiara uno slot
(${FILLER:cestino_folder}) che il runtime riempirà al momento
giusto con una micro-chiamata economica (con cache) o col default.
5.3 Il data piping: come i passi si parlano
Segnaposto
Cosa fa
from_step: N
Prendi le entries prodotte dallo step N (numerazione da 1) e passale intere a questo step. Le liste viaggiano solo così: mai re-incollate nel prompt.
${stepN.field}
Estrai un campo scalare dal risultato dello step N (percorsi annidati supportati). Usato soprattutto nel messaggio finale.
${FILLER:nome}
Slot riempito al volo da una micro-chiamata al tier fast (con cache) o dal default dichiarato.
${RUNTIME:chiave}
Contesto del turno, risolto dal runtime: actor (chi parla), lang, channel.
Figura 6 — Il piano della Figura 5 visto come flusso di dati. Le liste scorrono fra gli step via from_step; gli scalari, gli slot e il contesto passano per segnaposti tipizzati che l'esecutore risolve in modo deterministico.
Quando un cap si fa sentire, lo vedi. Se un limite tronca un
risultato (entries, byte, step), l'executor lo dichiara nei campi
(truncated: true, used, available_total) e il runtime
lo dice nella risposta — con l'offerta di allargare solo se
tecnicamente possibile, e mai allargando da solo. Un parziale presentato come
completo è considerato un bug, non un'ottimizzazione.
6. Executor: vettoriali per costruzione
Ogni executor accetta una lista e ritorna una
lista — anche quando la lista ha zero o un elemento. Non
esiste nessun *_batch: la versione batch è l'executor.
È la decisione che rende i piani corti e i risultati componibili.
Figura 7 — Il contratto vettoriale. Zero, uno o mille elementi attraversano lo stesso codice; i cap sono argomenti espliciti e il troncamento è dichiarato nei campi, mai nascosto.
Dal contratto discendono tre convenzioni che vedrete ovunque:
entries vs results — chi arricchisce o legge una lista ritorna entries (lo schema dei record si conserva, la pipeline può continuare); chi trasforma (move, write, delete) ritorna results (lo schema cambia: esiti, non record).
Robustezza al confine col linguaggio naturale — 0 come placeholder vale «nessun limite»; i confronti sono case-insensitive di default; sui domini testuali aperti i valori con */? sono glob, sui domini chiusi (id, slug, scope) il match è esatto e stretto. Così i bias dell'LLM non diventano fallimenti silenziosi.
Onestà dei conteggi — ok_count conta gli elementi realmente processati. Mai dichiarare un esito che non corrisponde alla realtà.
Il manifest: il prompt del tool
Ogni executor porta con sé un manifest TOML. Non è documentazione di
cortesia: è ciò che il pianificatore legge quando decide se
e come usare lo strumento — scritto su misura per un LLM medio locale,
non per un modello frontier. Frasi corte, esempi letterali, default in
chiaro; la descrizione segue quattro capitoli prescrittivi:
[description]
it = "SCOPO: cerca file per pattern in directory.
PATTERN: find_files(base_path=\"/\", patterns=[\"*.jpg\"]).
NON: list_dirs+filter_entries; get_files (lookup ID).
OUT: entries=[{path,name,type,mime,kind,size,mtime}]."
Figura 8 — Un solo manifest, quattro consumatori: prefilter, pool del pianificatore, grammatica e undo leggono campi diversi dello stesso TOML. Il digest lega il manifest al codice firmato.
7. Synt: la fabbrica degli strumenti
Quando il pool non sa fare una cosa, il pianificatore non improvvisa codice
nel mezzo del turno: passa la mano a synt, il processo che fa
esistere ciò che manca. Prima prova a comporre executor esistenti;
solo come eccezione documentata genera un executor nuovo — in
cinque stadi, ognuno col suo contratto.
Figura 9 — La pipeline di sintesi: quattro stadi procedurali sul tier medio, il codice sul tier alto, poi verifica semantica indipendente, firma e test di nascita. Il multistadio convalida dove il prompt singolo falliva.
Due inneschi, una cascata
Modo
Innesco
Tempo
Reattivo
Durante un turno: il pianificatore non trova nessun executor che soddisfi la richiesta.
Sincrono — l'utente sta aspettando; prima si tenta la composizione di executor esistenti.
Introvertivo
Di notte: l'ager scorre il mnestoma e trova ricorrenze, tracce sovrapposte, famiglie con la stessa forma.
Asincrono, in omeostasi: propone fusioni, generalizzazioni, specializzazioni.
In entrambi i casi vale la stessa regola: synt propone, l'umano
approva. Nessuna auto-modifica senza filtro; ogni proposta arriva con
motivazione, ed è reversibile.
Il gate a 7 livelli
Lo stesso imbuto vale per il codice sintetizzato e per le skill
importate da fuori: nessun pacchetto si esegue sulla fiducia.
Figura 10 — Il gate a 7 livelli, identico per executor sintetizzati e importati: firma, vocabolario, quarantena d'uso, sandbox, smoke test, verifica semantica, audit. Solo in fondo all'imbuto un pacchetto diventa un executor fidato.
8. Quattro tier, un routing deterministico
I tier sono ruoli astratti, non modelli inchiodati:
fast / middle / wise sono incarichi che leghi a qualunque endpoint
tu abbia, frontier è l'unico opt-in cloud. Nell'istanza di
riferimento i tre tier locali puntano tutti alla stessa istanza di
llama-server: a cambiare sono solo i parametri per chiamata.
Tier
Ruolo
Nell'istanza di riferimento
fast
Estrazioni brevi e strutturate: intent, filler, classificazioni. Ragionamento spento.
Lavoro procedurale: stadi 1-4 della sintesi, descrizioni, giudizi.
Stessa istanza, parametri di default.
wise
Il pianificatore: propone il piano intero; scrive il codice dello stadio 5.
Stessa istanza. Obbligatorio: non degrada mai a fast.
frontier
Un consulto esterno quando richiesto esplicitamente (es. analisi di un issue).
API cloud, opt-in, con fallback gestito se la chiave non c'è.
Tier ≠ modello. Nessuna GPU o NPU è richiesta per
costruzione: un endpoint su CPU, un modello che già servi, o il fallback
frontier sono percorsi di prima classe. Un modello locale più debole
significa pianificazione più debole, non un'installazione rotta.
Le tre serrature del determinismo
Un LLM a temperatura zero non basta a rendere il routing
riproducibile: il server locale resta non-deterministico per via della
decodifica speculativa col seed casuale. Metnos chiude la porta con tre
serrature, una per ogni fonte di rumore:
Figura 11 — A sinistra i tier come ruoli legati a un'unica istanza locale (frontier a parte); a destra le tre serrature che rendono il routing riproducibile: seed fissato, affinity curata per i pareggi, grammatica GBNF sul decode.
Niente parser fragili. Il tool-use è nativo: il modello
emette tool_calls strutturati, e la grammatica garantisce la forma a
monte. Non c'è nessun parsing di JSON pescato dentro prosa — il punto
debole classico degli agenti fai-da-te.
9. La memoria che accelera
Metnos non addestra modelli: niente fine-tuning, niente RLHF. Tutto
ciò che impara è dato ispezionabile — piani, tracce,
scorciatoie — e ogni cosa imparata si può leggere, correggere,
cancellare. L'effetto pratico: più lo usi, meno chiama il modello.
Figura 12 — Il circolo dell'apprendimento senza addestramento: i piani riusciti diventano scorciatoie (Autopath, Fastpath ★), le co-attivazioni diventano mnest, le ricorrenze notturne diventano proposte di sintesi. Tutto è dato leggibile e reversibile.
10. I sensi: la pipeline immagini
Per cercare nelle foto, Metnos non spedisce nulla a nessuno: tre estrattori
in-process trasformano ogni immagine in tre segnali —
cosa si vede, chi c'è, dove e quando — fusi in un indice unificato
interrogabile dal vocabolario normale.
Figura 13 — La pipeline immagini: SigLIP per la scena, RetinaFace+ArcFace per le identità, EXIF per luogo e tempo. I tre segnali confluiscono in un indice unificato che si interroga con un executor normale del vocabolario.
La ricerca arriva dal canale come qualunque altra richiesta: il
pianificatore compone find_images_indices con i criteri estratti
dalla frase, e il canale mostra le anteprime inline. La costruzione
dell'indice è un lavoro di fondo, incrementale e riavviabile, che si
lancia con una frase («indicizza le foto in…»).
11. I canali: Telegram e web
Un canale è un adattatore: converte un'interfaccia esterna in messaggi e
risposte, più una capacità opzionale — rendere bottoni per
conferme e scelte. Due canali nascono con l'installazione; aggiungerne
altri non tocca il nucleo.
Figura 14 — I due canali. Il browser parla direttamente col server sulla 8770 (chat con streaming + dashboard); Telegram funziona per long-poll in uscita, quindi nessuna porta aperta né IP pubblico. In basso, il pairing che decide chi può parlare.
Canale
Cosa offre
Web :8770
Chat nel browser con risposta in streaming (SSE), anteprime immagini, badge di feedback; dashboard admin per proposte, executor, run, safety e turni. La stessa API risponde JSON o HTML a seconda dell'Accept. Chiave admin auto-creata al primo avvio, file con permessi 0600.
Telegram
Il tuo bot personale: messaggi, foto, bottoni inline per le conferme del vaglio e per le scelte a opzioni. Accoppiamento col comando /pair e un codice firmato con scadenza.
12. Sicurezza e reversibilità
La sicurezza non è un modulo: è una catena di guardie indipendenti, e
un'azione deve passarle tutte. E siccome anche la guardia migliore
sbaglia, l'ultima difesa è poter tornare indietro: undo onesto, per
costruzione.
Figura 15 — Cinque guardie in serie (pairing, policy, vaglio, sandbox, firma+audit) e, sotto, la rete di protezione: un undo con catalogo chiuso di pattern inversi, copie verificate prima di ogni cancellazione e conteggi onesti.
Il potere c'è, ed è per questo che è imbrigliato. Metnos
può davvero amministrare la macchina (shell, sudo, pacchetti,
mount) — è ciò che lo rende un assistente di sistema e non un
chatbot. Ma ogni azione privilegiata passa dal vaglio con conferma
esplicita, gira in sandbox, finisce nell'audit; e l'intera skill di sistema
si può disattivare, chiudendo Metnos fuori dal sistema operativo.
13. I principi, in otto carte
Se di questo documento doveste ricordare solo otto frasi, sono queste.
Tutto il resto — codice, prompt, convenzioni — discende da qui.
1Vettoriale per costruzione. Ogni executor accetta una lista e ritorna una lista, anche degenere. La versione batch è l'executor: *_batch non esiste.
2Vocabolario chiuso, governato. Tutto ciò che agisce ha un nome componibile dentro una grammatica chiusa. Un termine nuovo entra solo se necessario, generale e comprensibile.
3Nessun fallimento silenzioso. I conteggi riflettono ciò che è successo davvero; il troncamento si dichiara, non si nasconde; un parziale presentato come completo è un bug.
4Deterministico > LLM. Dove un automa o una tabella bastano, il modello non si usa. L'LLM entra dove un parser equipotente sarebbe davvero troppo complesso — e ci entra vincolato.
5Mai una cancellazione implicita. Ogni spostamento è copia → verifica → cancellazione; mai DELETE senza COPY confermata.
6Reversibilità con motivazione. Ogni atto evolutivo (sintesi, fusione, archiviazione) è reversibile e motivato. Dire sì costa meno quando si può tornare indietro.
7i18n per costruzione. Ogni stringa e prompt rivolto all'utente è dato per-lingua: una lingua nuova è un pacchetto di traduzione, non un fork del codice.
8Comprensibilità come dovere. Se l'utente non capisce il sistema, il sistema non serve. La semplicità non è estetica: è il criterio che ha selezionato tutto il resto.
14. Cosa NON è Metnos
Metà del design sta nei no. Ogni tentazione di aggiungere un elemento di
questa lista va respinta.
Non è un framework generalista. È un agente per una persona e una casa. Se serve un altro agente con regole diverse, se ne fa un'altra istanza: non si astrae.
Non esegue skill di terzi così come sono. I formati drop-in sono esecuzione di codice altrui con i tuoi privilegi. Qui ogni pacchetto passa il gate a 7 livelli, o non gira (cap. 7).
Non addestra modelli. Niente fine-tuning, niente RLHF. La crescita è memoria ispezionabile + sintesi col filtro umano (cap. 7 e 9).
Non è un cloud agent. Gira a casa; il frontier è un consulto esplicito, mai la sede. Nessuna apertura non scelta.
Non è un IDE né un dev assistant. Non scrive codice in altri progetti per conto tuo; al massimo analizza con executor read-only.
Non sostituisce la domotica. A un sistema domotico può chiedere; non lo duplica.
Non è multi-canale a tutti i costi. Due canali fatti bene; gli altri quando servono davvero.
15. Dove andare dopo
Questo era il Livello 1: il sistema dall'alto. Il Livello 2 — la
microprogettazione — ha una pagina per componente, con il dettaglio
sufficiente a scriverne il codice senza inventare nulla.
Metnos — Architettura: Introduzione (v2). mētis + noûs: l'intelligenza astuta al servizio della mente — su hardware tuo.
Documentazione bilingue IT+EN su metnos.com; codice su
github.com/brunialti/metnos.