Un telos è un fine generale dichiarato dall'utente nel file workspace/TELOS.md. Metnos lo tratta come un segnale graduato: può preferire una strategia o ordinare una proposta, ma non può ricavarne nuovi permessi, superare le regole di autorizzazione o bloccare arbitrariamente una richiesta esplicita.

1. Che cosa contiene TELOS.md

Il loader riconosce da tre a sette sezioni nel formato seguente:

## t.tempo — Liberare il mio tempo dalle incombenze ripetitive
peso: 0.25
soglia_attivazione: 0.30
note: considera soprattutto attività ripetitive e verificabili.

Il file viene riletto quando cambia. Se manca o non contiene sezioni valide, il runtime prosegue senza il segnale teleologico. Il parser è deterministico; non usa un modello linguistico per inventare o modificare i fini.

2. Dove interviene il telos

Il telos ha due impieghi distinti:

1. Contesto di pianificazione. Il runtime può rendere i fini correnti nel contesto del pianificatore. Le istruzioni precisano che sono segnali orientativi: servono a scegliere fra alternative con esito comparabile e non sostituiscono regole, capacità o richiesta dell'utente.
2. Generazione facoltativa di proposte. Un'attività offline può esaminare catalogo, schemi d'uso e fini dichiarati per formulare possibili miglioramenti. Il risultato è una proposta; non è un'azione già autorizzata.

Le due strade non attribuiscono autorità al testo di TELOS.md. Una richiesta diretta resta soggetta alle normali regole di esecuzione; una proposta spontanea deve attraversare il proprio ciclo di revisione.

3. Come nasce una proposta

Il processo telos_introspect_nightly è disattivato per impostazione predefinita. Viene eseguito soltanto quando l'operatore abilita METNOS_TELOS_NIGHTLY=1. In quella modalità applica dieci lenti registrate ai telos correnti:

• scamper, oulipo, inverse_rl;
• endgame_book, analogy_transfer, boden_transformational;
• pattern_language, generative_design;
• counterfactual e constitutional.

Le lenti usano il tier logico wise per la parte generativa. Il provider, il modello, l'endpoint e la politica di generazione sono quelli configurati per quel tier; il job non li sostituisce con un profilo locale. Attorno a questa parte probabilistica, il runtime applica regole deterministiche: selezione delle lenti, controlli anti-paternalismo, convalida dei nomi, limite delle proposte, eliminazione dei duplicati per coppia obiettivo–lente e persistenza locale.

Le proposte grezze sono registrate in ~/.local/share/metnos/telos_proposals.jsonl. L'archivio raggruppa quelle che puntano allo stesso obiettivo e misura la convergenza fra lenti diverse. Solo le teste dei gruppi con un esito nominale azionabile vengono trasformate in change_intent.

4. Valutazione e controlli

Per ogni proposta, il giudice teleologico stima un valore di aderenza per ciascun telos. La stima è prodotta da un modello linguistico; pesi, soglie, composizione e ordinamento sono invece applicati dal codice. Il punteggio aiuta l'esame preliminare, ma non costituisce una prova oggettiva della qualità della proposta.

5. Decisione e ciclo di vita

L'adattatore telos traduce la testa di un gruppo in uno dei tipi supportati, per esempio creazione di un executor, estensione parametrica o esecuzione controllata di una sequenza. Il materializzatore la inserisce nell'archivio unificato come proposed.

L'utente la esamina nella pagina /admin/changes e può accettarla, rifiutarla o rimandarla. Soltanto una proposta accettata passa all'applicatore; dopo l'applicazione viene osservata e può essere finalizzata oppure annullata secondo il tipo di modifica. Il flusso completo è descritto nella pagina sul ciclo di vita delle modifiche.

6. Esempio pratico

Chiedi a Metnos con una richiesta come quella di questo esempio: «Quali modifiche al sistema sono in attesa della mia decisione?»

Metnos può spiegare che le proposte si amministrano nella chat web. Se la domanda parte da Telegram, apri quindi la chat web, vai all'area di amministrazione e scegli Modifiche; il percorso tecnico corrispondente è /admin/changes. Una proposta telos resta distinta dalle preferenze scritte in TELOS.md: approvarla autorizza quella modifica, non tutte le azioni future che sembrano coerenti con lo stesso fine.

7. Limiti attuali e riferimenti

• Il costo di disturbo previsto dalla formula di allineamento viene passato come 0 nel flusso introspettivo corrente: non esiste ancora un limite operativo delle interruzioni.
• Il sistema non deduce nuovi telos o permessi dal silenzio dell'utente.
• La prosa e i punteggi generati dal modello non sono prove deterministiche; la decisione deve poter risalire ai dati locali e alla proposta originale.
• Il processo notturno resta facoltativo e disattivato per impostazione predefinita.

Riferimenti nel codice:

• runtime/telos_loader.py: parsing, normalizzazione e ricarica di TELOS.md.
• runtime/telos_lenses/ e runtime/telos_introspect.py: generazione e controlli.
• runtime/alignment_engine.py: stima e composizione dell'allineamento.
• runtime/telos_proposals_store.py: persistenza, raggruppamento e convergenza.
• runtime/change_intent_adapters/telos.py e runtime/change_intents.py: ingresso nel ciclo di vita.