myclaw, come lo disegna l'architettura attuale, è un assistente reattivo: l'utente scrive, il gateway avvia un loop, il loop risponde. Questo documento introduce cinque famiglie di capacità che spostano il baricentro: da reattivo a ambientale. myclaw smette di rispondere soltanto e inizia a percepire, collaborare, osservare, proporre.
Il design di base resta valido: i quattro strati, le quattro Leggi, l'audit, la memoria a tre livelli, l'autonomia graduata. Ma un sistema ambientale introduce elementi che la versione reattiva non prevede:
FactProposal);Questo doc stabilisce ciascuno di questi elementi al livello di intento e tensione architetturale. La microprogettazione concreta arriverà dopo, in nuovi HTML di Livello 2 che questo doc elenca al §5.
L'architettura odierna è request-driven: tutto parte da un messaggio di un canale, passa per il loop, finisce con una risposta. Queste capacità sono task-driven nel tempo: un processo scansiona, aggiorna un indice, notifica quando succede qualcosa. È un modello diverso.
image_search(subject, date_range), file_dedup_report(path), voice_match(audio_clip). Sono tool normali, che leggono un indice, non lo costruiscono.SOURCES.md: dove l'Indexer può guardare, quali cartelle sono off-limits).ActionProposal (vedi §2D).Channel (oltre CLI, Telegram, voce, cron). Implementa il Protocol Channel esistente, ma il sender è un altro agente (es. agent:home-assistant), non un umano.{intent: "query.calendar", date: "2026-04-23"}), non in linguaggio naturale. Motivazione: determinismo, audit leggibile, niente ambiguità.Non è un tool. È un regime operativo: un modo in cui myc sta in una chat. Diverso da non presente (attuale), diverso da interattivo (attuale), simile a lurker consapevole nel vocabolario delle community online.
constitution.html dedicata allo shadow mode: default off, abilitabile chat per chat, richiede (a) whitelist scritta dall'utente, (b) notifica ai membri della chat in testa a ogni sessione (\"c'è un assistente che osserva—è mio\"), (c) non registrazione di contenuto che non riguarda l'utente proprietario.kind="shadow_catch", ogni cosa che ignora non è registrata (altrimenti l'audit stesso viola la privacy di terzi).Oggi memory §6 definisce la
reflection come produttrice di FactProposal: la proposta
di ricordare qualcosa. La proattività creativa è una generalizzazione:
la reflection produce anche ActionProposal, la
proposta di fare qualcosa di non banale (che coinvolga molti file,
molti record, azioni ripetitive).
@dataclass
class ActionProposal:
"""Una proposta di azione di grande scala emersa da reflection."""
kind: Literal["restructure", "homogenize", "cleanup",
"enrich", "classify", "consolidate"]
scope: str # "~/Documenti/lavoro/" etc
impact: ImpactReport # quanti record/file toccati
rationale: str # perché myc propone questo
plan: list[PlannedAction] # azioni concrete, step-by-step
reversibility: Literal["reversible", "reversible_with_cost", "irreversible"]
confidence: float # 0..1, quanta fiducia ha myc
created_at: datetime| Aspetto | ApprovalRequest (oggi) | ActionProposal (nuovo) |
|---|---|---|
| Origine | Il loop sta per fare qualcosa, chiede permesso. | myc ha osservato dati, propone qualcosa che nessuno ha chiesto. |
| Urgenza | Blocca il loop finché l'utente risponde. | Non blocca nulla. Rimane in un inbox proposte finché l'utente la guarda. |
| Azione implicita | Se timeout: l'azione non succede. | Se timeout: la proposta scade senza conseguenze. |
| UX | Bottoni Sì/No/Modifichiamo nel canale attivo. | Digest serale, inbox proposte, preview di esempio, accetta/rifiuta/ricevi meno di queste. |
È una superficie UX nuova. Va dettagliata in un proposal_ux.html
dedicato.
tool.html.Sono tool nel senso stretto del Protocol attuale. Implementano la
stessa interfaccia di fs_read o shell_exec. Passano
per Policy, approvazione, trace. Non introducono componenti architetturali
nuovi.
Le famiglie A, B e D generano intenzioni non richieste: l'indexer propone una tassonomia, un agente suggerisce una delega, la proattività propone un riassetto. Serve un criterio per dire quali di queste intenzioni hanno senso, senza chiedere all'utente di valutarle tutte. È la funzione di valutazione che l'agente proattivo, da solo, non ha.
Il design reattivo non si pone il problema: l'utente chiede, myc esegue, la valutazione è implicita nella richiesta. L'agente proattivo è libero di proporre qualunque cosa — e senza un criterio diventa un generatore entusiasta di rumore.
Un sesto file nel workspace, accanto a IDENTITY, USER, MEMORY, AGENTS, SOUL. Scritto dall'utente, 3-7 frasi brevi. Non si raggiungono, si approssimano: sono aristotelici. Esempi tipo:
Ogni telos ha un peso (priorità in conflitto) e una soglia di attivazione. Sono revisionabili in ogni momento con rito firmato, come la Costituzione.
Ogni proposta viene valutata con un singolo scalare:
expected_alignment = Σᵢ (weightᵢ · fitᵢ) · urgency · confidence − bother_cost
dove:
weightᵢ = peso del telos i (dichiarato in TELOS.md)
fitᵢ = quanto la proposta avvicina il telos i (0..1, stimato dall'LLM)
urgency = pressione temporale (scadenze, eventi)
confidence = fiducia di myc nella stima
bother_cost = costo del disturbare, cresce con la frequenza recenteSe expected_alignment < θ → la proposta non arriva all'utente.
Finisce in un journal interno che l'utente può ispezionare a volontà
("proposte scartate oggi: 47"). Il threshold θ è un parametro,
non una decisione morale.
Il TrustStore (già in rl_offline)
si estende con un asse per-telos: se le proposte legate a ordine
vengono accettate in 8/10 casi recenti, il peso effettivo di quel telos cresce.
Se quelle legate a parsimonia vengono ignorate per 48 ore, il peso
decresce. L'ignorare è un segnale — più debole di un "no",
più forte di "non ancora vista".
| Trappola | Perché è pericolosa | Contromisura |
|---|---|---|
| Goodhart | Se i telos sono misurabili con metriche troppo precise, myc ottimizza la metrica invece della sostanza. | I fitᵢ sono stimati dall'LLM con spiegazione testuale ("libera 2h/mese perché…"), non da contatori hardcoded. L'LLM giudica la sostanza. |
| Paternalismo | "Non spendere oltre X" come telos rischia di diventare giudizio morale sugli acquisti dell'utente. | I telos si applicano a ciò che myc fa per l'utente, non a ciò che l'utente fa. myc non giudica, si giudica. Questo va scritto esplicitamente in constitution.html. |
TELOS.md: sesto file del workspace. Manifest schema in workspace.html da estendere.telos.html (microprogettazione nuova): schema, funzione di allineamento, bother budget, apprendimento dai silenzi, rito di revisione.memory.html §6: la reflection produce ActionProposal già pesate contro i telos, non grezze.rl_offline.html: TrustStore si arricchisce con telos_fitness: dict[telos_id, EMA].constitution.html: distinzione Leggi vs Telos, clausola anti-paternalismo.fit
della funzione di allineamento non può essere affidata all'LLM che
ha generato la proposta: un LLM valuta i propri output in modo conforme
(self-enhancement bias, Zheng 2023). Da questa osservazione è
emerso un secondo componente, Vaglio,
che garantisce indipendenza di contesto tra proponente e valutatore. Il
Vaglio ha due fasi di natura diversa: Guardia costituzionale
(deterministica, binaria) e Giudice teleologico (LLM
indipendente, gradiente). Il principio che articola le due fasi è
cristallizzato nella frase: "La Costituzione non giudica, la teleologia
sì." — la Costituzione verifica e, se viola, blocca; altrimenti
tace. Solo il giudizio teleologico produce un punteggio. La ricostruzione
completa del ragionamento è nel Dialogo sui
fini e i limiti, Giornate III-IV.
Quattro delle cinque famiglie (A voice-id, B agent channel, C shadow mode, D proattività per-utente) condividono un bisogno che il design attuale copre male: sapere chi sta parlando.
Oggi il binding è: sender = "<canale>:<handle>"
(es. telegram:@roberto). La memoria episodic usa sender
come chiave (vedi il fix §3.5 di review
di coerenza). Questo è sufficiente per un utente singolo che usa sempre lo
stesso canale.
Appena entrano voice-id, agenti, casa condivisa, serve un livello in più:
Questo introduce:
IdentityResolver: componente nuovo che dato un sender ritorna un'Identity con confidence. Se confidence bassa, myc può chiedere: "scusa, sei Roberto o qualcun altro?".identity_id, non sender. Il fix è stato corretto nella direzione giusta ma andrà raffinato.IdentityResolver nasce già in fase 4 come
singleton identity (sempre Roberto). La struttura esiste, ma tratta
un solo utente. Questo permette di introdurre voice-id senza rifattorizzare
tutto dopo.
Queste capacità introducono attriti con le 4 Leggi che il design attuale non può risolvere in-situ. Elenco le più importanti con verdetto provvisorio.
| Tensione | Famiglia | Verdetto v1 | Motivazione |
|---|---|---|---|
| Ascoltare chat di terzi senza consenso esplicito | C. Shadow | blocca | Sotto-legge dedicata obbligatoria prima del rilascio. Default off, whitelist scritta, notifica in chat. |
| Volti umani riconosciuti → etichettati con nome | A. Percezione | gate | Clustering OK (cluster_id). Associazione cluster → nome solo con ActionProposal approvata. |
| Voice ID su chiunque passa in microfono | A. Percezione | gate | Riconoscere solo voci iscritte nel workspace (enrollment esplicito). Voci sconosciute → unknown_speaker. |
| Un sibling agent delega azioni senza conferma dell'utente | B. Multi-agente | blocca | Nessun agente esterno può firmare approvazioni per conto dell'utente. Richiesta inter-agente → loop approvazione standard. |
| Proposta di rinominare 300 file senza preview | D. Proattività | gate | ActionProposal deve includere sempre: preview, impact count, piano di rollback. Senza questi, rigetto automatico. |
| Web search su topic sensibili (finanza, salute, minori) | E. Esterno | gate | Lista di topic dove la ricerca passa a supervised anche in full autonomy. |
| Indexer scansiona directory con file personali di altri conviventi | A. Percezione | blocca | Sorgenti indicizzabili solo quelle dichiarate in SOURCES.md. Mai scoperta autonoma. |
Questa sezione elenca i nuovi doc di Livello 2 che le cinque famiglie richiederanno. Non sostituisce l'ordine canonico di Prospettive & Giudizio §8, che resta valido fino a compimento. Li aggiunge in coda.
| # | Nuovo doc | Cosa copre | Fase |
|---|---|---|---|
| 1 | telos.html | TELOS.md, funzione di allineamento, bother budget, apprendimento dai silenzi. Fondante per le famiglie A, B, D. | 4-5 |
| 2 | indexer.html | Processo long-running, scan, embedding, indici persistenti. Integra famiglia A. | 5 |
| 3 | identity.html | IdentityResolver, evidenze multi-canale, voice enrollment, confidence. Rende primario il concetto di identità umana. | 4 |
| 4 | agent_channel.html | Quinto canale, pairing simmetrico, vocabolario inter-agente, delega. Integra famiglia B. | 6 |
| 5 | shadow_mode.html | Regime di ascolto, sotto-legge costituzionale, filtri, audit intensificato. Integra famiglia C. | 7+ |
| 6 | proposal_ux.html | ActionProposal, inbox proposte, digest serale, preview. Integra famiglia D. | 5 |
| 7 | estensioni a tool.html | Tool web_search, calendar_read, calendar_write. Famiglia E — non serve un doc nuovo, basta un'appendice. | 3 |
| 8 | estensioni a constitution.html | Sezione "estensioni applicative" con le 7 sotto-leggi del §4 + clausola anti-paternalismo dei telos. | 2 |
| 9 | estensioni a workspace.html | Aggiunta del 6° file TELOS.md al manifest del workspace. | 4 |
| 10 | estensioni a memory.html e rl_offline.html | Reflection produce ActionProposal pesate contro telos. TrustStore aggiunge asse telos_fitness. | 5 |
Cinque doc nuovi (telos, indexer, identity,
agent_channel, shadow_mode, proposal_ux), quattro
estensioni. Nessuno di questi blocca i 19 doc di microprogettazione già
approvati. Nessuno di questi richiede di riscrivere un doc esistente.
telos.html e identity.html. Il primo perché è
fondante per tre famiglie (A, B, D): senza funzione di allineamento, la
proattività è inutilizzabile. Il secondo perché sblocca quattro famiglie e
richiede di raffinare il fix §3.5 della review di coerenza (episodic indicizzata
per identità, non per sender). Tutti gli altri possono seguire in base alla
fase.
Le fasi di rilascio di Neuroni & Memoria §11 restano valide. Qui mappo le cinque famiglie sulle fasi, con priorità interna.
| Fase | Focus esistente | Aggiunte da questo doc |
|---|---|---|
| 1 | scheletro + CLI + shell sandboxata | — |
| 2 | policy + workspace + audit | Estensione constitution.html con le 7 sotto-leggi |
| 3 | Telegram + pairing | Tool web_search, calendar_read (famiglia E) |
| 4 | memory + failover | identity.html (singleton-identity iniziale), telos.html (contratto), TELOS.md nel workspace |
| 5 | voce, tunnel, dashboard | indexer.html, proposal_ux.html, attivazione funzione di allineamento (famiglie A+D+F insieme) |
| 6 | neuroni, sintesi, sinapsi | agent_channel.html (famiglia B) |
| 7+ | maturazione | shadow_mode.html (famiglia C, dopo collaudo e sotto-legge) |
La fase 5 diventa così più densa: indexer e inbox proposte sono entrambi capacità d'uso quotidiano che cambiano la percezione del prodotto. È voluto: la fase 5 è il salto da "prompt → risposta" a "myclaw mi sorprende".
myclaw — Prospettive estese v1.0 — 22 aprile 2026
Apre un secondo tronco di design: da reattivo ad ambientale. Non sostituisce nessun doc.