Un telos è una direzione generale scelta dall'utente: liberare tempo, proteggere la privacy, non perdere una scadenza. Aiuta Metnos a preferire una soluzione rispetto a un'altra e a proporre miglioramenti sensati. Non è un comando, un permesso o un obiettivo da inseguire a ogni costo.

1. Che cos'è un telos

Metnos usa i telos come preferenze morbide. Se due strategie portano a un risultato paragonabile, può scegliere quella più coerente con i fini dichiarati. Per esempio, davanti a due modi ugualmente affidabili di riassumere la posta, può preferire quello più rapido se l'utente ha dato molto peso al proprio tempo.

Il confine importante è semplice: un telos non autorizza un executor, non scavalca il Vaglio e non trasforma una proposta in un'azione. Inoltre non deve essere usato per rifiutare arbitrariamente una richiesta esplicita. Permessi, politiche e conferme continuano ad avere la precedenza.

2. Il file TELOS.md

I telos sono scritti in workspace/TELOS.md. La convenzione ne raccomanda da tre a sette, abbastanza pochi da esprimere priorità reali. Questo intervallo è una regola editoriale, non un blocco del parser. Ogni sezione ha questa forma:

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

Metnos rilegge il file quando cambia. Il parser è deterministico: nessun modello linguistico inventa o modifica i fini. Se il file manca o non contiene sezioni valide, il sistema continua a funzionare senza questo segnale.

3. Come orienta una richiesta

Il runtime inserisce i telos correnti nel contesto del pianificatore, ordinandoli per peso. Le istruzioni che li accompagnano ne ribadiscono il ruolo: servono a scegliere tra alternative con esito simile, non a cambiare il significato della richiesta.

Questo uso è immediato ma limitato. Il pianificatore vede la frase originale e il peso; non deduce nuovi fini dal comportamento dell'utente e non può trasformare il suo silenzio in un consenso.

4. Il laboratorio notturno

Metnos comprende anche un'attività sperimentale che cerca possibili miglioramenti. È disattivata per impostazione predefinita e parte soltanto se l'operatore abilita METNOS_TELOS_NIGHTLY=1. Quando è attiva, telos_introspect_nightly applica ai telos dieci modi diversi di esaminare lo stesso problema, chiamati lenti:

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

La generazione usa il carico logico creative; il modello reale, il provider e l'endpoint dipendono dalla configurazione centrale dei tier. Il codice, non il modello, sceglie le lenti, limita i risultati, controlla i nomi, scarta le formulazioni paternalistiche e rimuove i duplicati della stessa coppia obiettivo–lente.

Un secondo carico logico, middle, stima quanto ogni proposta favorisca o ostacoli ciascun telos. Il codice applica poi pesi e soglie: mette in risalto il contributo principale, considera i contributi secondari e penalizza gli effetti contrari. Il punteggio serve a ordinare il lavoro umano, non dimostra che un'idea sia buona.

Le proposte grezze restano nell'archivio locale ~/.local/share/metnos/telos_proposals.jsonl. Quelle rivolte allo stesso obiettivo vengono raggruppate, così la convergenza tra lenti diverse è visibile senza fingere che una ripetizione sia una nuova prova.

5. Dal suggerimento alla decisione

Solo il rappresentante di un gruppo con un risultato realmente applicabile diventa un change_intent. A seconda del caso può proporre di creare un executor, estenderne uno o provare una sequenza esistente. Il suo stato iniziale è sempre proposed: fino a quel momento non è cambiato niente.

L'amministratore trova le proposte nella sezione Modifiche della chat web, all'indirizzo /admin/changes. Può accettarle, rifiutarle o rimandarle. Solo una proposta accettata raggiunge il componente che la applica; poi viene osservata e, quando il tipo di modifica lo permette, può essere consolidata o annullata. La pagina sul ciclo di vita delle modifiche descrive tutti gli stati.

Approvare una proposta autorizza quella modifica precisa. Non autorizza tutte le azioni future che sembrano coerenti con lo stesso telos.

In ogni passaggio restano attivi questi controlli:

6. Limiti attuali

• La formula prevede un costo per il disturbo arrecato all'utente, ma il flusso corrente gli passa ancora il valore 0: non esiste quindi un vero budget operativo delle interruzioni.
• Testo e punteggi prodotti dai modelli sono valutazioni probabilistiche. I dati locali, la proposta originale e la decisione devono restare consultabili.
• Il laboratorio notturno è facoltativo e rimane spento finché un operatore non lo abilita esplicitamente.

Per verificare l'implementazione:

• 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.