Il design d'insieme di myclaw era abbastanza maturo per una revisione critica. L'ho sottoposto a quattro ottiche esperte (programmazione agentica, psicologia, UI, AI) e poi pesato ciascun punto emerso rispetto ai tre obiettivi dichiarati del prodotto. Questo documento consolida sia l'analisi sia il giudizio e chiude la fase 0 di progettazione.
Il metodo: generare critiche generose dalle quattro prospettive, poi applicare un filtro pragmatico "questa critica blocca utilità/intelligenza/autonomia? se sì la accetto, altrimenti la soppeso". Cinque verdetti possibili:
| Verdetto | Significato |
|---|---|
| bloccante | Senza questa modifica, almeno uno dei tre obiettivi non può essere raggiunto. Va fatta. |
| rinforzo | Non nuovo concept. Completa un pezzo del design esistente. Accettato. |
| rinvio | Utile, non bloccante. Si farà, con un gate esplicito per promuoverlo quando serve davvero. |
| tensione | Problema reale non risolvibile. Si gestisce, non si elimina. Accettazione esplicita del trade-off. |
| scartato | Valutato, costo supera il beneficio. Motivazione tracciata. |
Prima di giudicare serve definire. I tre termini non sono interscambiabili.
Risolve un problema reale di Roberto al primo tentativo, senza intervento tecnico.
Misurato in: task completati / approvazioni chieste.
Capisce il contesto, sceglie lo strumento giusto, gestisce l'inatteso senza cadere in loop o risposte generiche.
Misurato in: success rate su casi non visti + qualità del "non lo so".
Agisce da solo nei casi prevedibili, chiede permesso solo quando serve.
Misurato in: azioni riuscite / approvazioni chieste.
Architettura a 4 strati pulita, protocol-based, audit log come feature. Ma
manca: la scelta del loop (ReAct? function calling? planner+executor?),
l'ownership dello stato in caso di crash, l'idempotenza dei tool, una
ExecutionTrace come oggetto first-class, la modalità dry-run,
e qualsiasi test strategy. Senza ExecutionTrace non ricucirai mai audit + replay
+ fitness darwiniana + eval — perché sono la stessa cosa vista da angolature diverse.
La memoria a tre livelli allinea con working/episodic/semantic. La selezione darwiniana ha fondamento in RL/ACT-R. Le 4 Leggi sono etica deontologica trasparente. Ma: "neurone" evoca intenzionalità (effetto ELIZA amplificato), l'approval fatigue svuota il significato dei gate, l'automation bias cresce con la fitness. Capability creep nelle aspettative: gli utenti proietteranno "diventa sempre più intelligente" e saranno delusi.
Documenti visivamente coerenti, progressive disclosure buona. Ma la superficie UX più delicata — il "vuoi che proceda?" in Telegram, in CLI, alla voce — non ha design. Status visibility durante il thinking è invisibile. Audit JSONL va benissimo per forensica e malissimo per "cosa ha fatto oggi il mio maggiordomo". Una dashboard admin minimale (anche sobria) cambia la quotidianità più di dieci feature nuove.
Consapevolezza esplicita dei limiti del self-judge LLM e del prompt injection indiretto. Vocabolario CoALA adottato. Ma: nessun modo di misurare se v0.2 è meglio di v0.1 (serve una mini eval, 15-20 scenari). Nessun cost model (ordine di grandezza: 1-3 €/giorno con Claude Sonnet su uso domestico). Model tiering ignorato: 60-80% di costo risparmiabile mettendo i gate su modello locale e le azioni serie su frontier. Il synthesis prompt per i neuroni — il pezzo che determina l'80% del success rate — non è specificato.
La tavola completa. Ogni riga è una critica specifica con il verdetto e la destinazione nel piano di lavoro.
| # | Critica | Prospettiva | Verdetto | Dove / quando |
|---|---|---|---|---|
| 1 | Reasoning loop non specificato | agentica + AI | bloccante | agent_runtime.html |
| 2 | Tool-call validation con schema + reject loop | AI | bloccante | agent_runtime.html |
| 3 | ExecutionTrace come oggetto first-class | agentica + AI | bloccante | agent_runtime.html |
| 4 | Status visibility in ogni canale | UI | bloccante | channel.html (req.) |
| 5 | Approval UX disegnata (batching, pause, revoca) | psicologia + UI | bloccante | approval_ux.html |
| 6 | Eval minimo (15-20 scenari YAML + harness) | AI | bloccante | eval.html |
| 7 | Model tiering + 5ª Legge operativa | AI + agentica | bloccante | policy.html + cost_tiering |
| 8 | Framing linguistico anti-antropomorfizzazione | psicologia | rinforzo | constitution.html |
| 9 | Prompt structure esplicita + caching rules | AI | rinforzo | agent_runtime.html |
| 10 | Admin web UI minimale (5 viste htmx) | UI | rinvio | fase 3-bis; gate: se JSONL non è mai aperto → promuove a fase 1 |
| 11 | Retrieval strategy memoria lunga | AI | rinvio | gate: >4k token lunga → RAG |
| 12 | MCP adoption | AI | rinvio | gate: 3+ tool esterni MCP |
| 13 | State persistence post-crash | agentica | rinvio | fase 1 accetta "sessione persa"; gate: >1×/settimana |
| 14 | Neuron versioning formale (semver) | agentica | rinvio | gate: >20 neuroni in library |
| 15 | Antropomorfizzazione → ELIZA | psicologia | tensione | mitigata da #8 + tool "cosa sai di me" |
| 16 | Automation bias con fitness alta | psicologia | tensione | mitigata da tutor mode in approval_ux.html |
| 17 | Costo dell'autonomia | psicologia + AI | tensione | Roberto deve sapere "Full mode 24h = X €" |
| 18 | Pairing SLA formale come meta-doc | UI | scartato | dettaglio di pairing.html |
| 19 | Mobile-first esplicito | UI | scartato | è testing, non design |
| 20 | Docs search | UI | scartato | trigger: >15 doc (ora 5) |
| 21 | Deadlock sinapsi come design dedicato | agentica | scartato | timeout globale copre il 95% |
| 22 | Multimodal day-1 | AI | scartato | già rimandato nel Survival Kit |
| 23 | Multi-utente famiglia day-1 | UI | scartato | prima release mono-principale; fase 3 |
| 24 | Cost model fine (TCO analysis) | AI | scartato | ordine di grandezza basta |
Totale: 7 bloccanti · 2 rinforzi · 5 rinvii · 3 tensioni · 7 scartati.
Queste sono le uniche modifiche non negoziabili. Tutte le altre sono al contorno.
| # | Cosa | Scelta di default + motivazione |
|---|---|---|
| 1 | Reasoning loop | ReAct + function calling nativo del provider per fase 1. Semplice, testato, compatibile con caching. Rivedere a fase 5 valutando CodeAct. |
| 2 | Tool-call validation | Ogni tool ha uno JSON Schema strict. Il dispatcher valida prima di eseguire. Errore di validazione → risposta "tool X esiste ma l'argomento Y è di tipo Z" reiniettata al LLM, max 2 tentativi, poi abbandono con messaggio utente. |
| 3 | ExecutionTrace first-class | Oggetto Python con: id, session_id, channel, messages[], tool_calls[],
cost_tokens, cost_usd, wall_time_ms, outcome. È la stessa struttura
usata da audit log, dry-run/replay, fitness darwiniana, eval. Una
sola fonte di verità su "cosa è successo". |
| 4 | Status visibility | Ogni canale ha il dovere di mostrare "penso...", typing indicator, e aggiornare al cambio di tool in esecuzione. Telegram: messaggio editabile; CLI: spinner con tool-name; voce: prompt di cortesia a fine di ogni secondo. |
| 5 | Approval UX | Batching: "approva azioni simili per 10 minuti".
Pausa lettura: il pulsante "ok" si abilita dopo 3 secondi.
Revoca: un comando /undo che ferma l'esecuzione in corso.
Tutor mode: ogni N approvazioni consecutive, un prompt
obbligatorio "controlla tu questa" rompe il flusso. |
| 6 | Eval minimo | 15-20 scenari YAML con input + oracolo (risposta attesa o criterio).
Harness che li gira via replay del reasoning loop. Report: success rate,
p95 latency, cost. Rigira ad ogni commit che tocca
agent_runtime/ o policy/. |
| 7 | Model tiering + budget | Due tier: local-fast (llama.cpp locale, < 500ms, gratis) per gate di policy + classification; frontier (Claude/Opus via supra) per ragionamento, sintesi, risposta utente. Budget: 2 €/giorno soft cap, 5 € hard cap. Notifica quando hai consumato 80%. |
Se elimini la metafora "maggiordomo", perdi calore e familiarità; se la lasci libera, scivoli nell'effetto ELIZA (utenti che attribuiscono coscienza e responsabilità morale al sistema). Scelta: teniamo la metafora, accettiamo la mitigazione al 70% via framing linguistico + tool "cosa sai di me" + tutor mode. Preferiamo caldo-con-monitoraggio a freddo-senza-ambiguità.
Più la fitness di un neurone è alta, più l'utente smette di controllare l'output. È il paradosso della selezione per qualità: amplifica la fiducia anche dove non dovrebbe. Mitigazione: tutor mode (forza review periodica anche su neuroni "affidabili"), separazione visiva tra "ho fatto X" e "ho fatto X perché l'ho già fatto 40 volte". Non risolve, limita.
Più l'utente vuole autonomia, più il sistema esplora, più spende.
Gestione: dichiarazione esplicita del costo prima di ogni
upgrade di autonomy (es. myclaw session --level full --for 24h
mostra "stima: 3.50 €"). Budget diventa parte del consenso.
Dei tre aggettivi, utile e intelligente sono proprietà che l'agente può avere indipendentemente. Autonomo no: emerge solo se le prime due sono tarate bene e i gate di approvazione sono dimensionati correttamente. Né un punto in più di utilità né un punto in più di intelligenza producono autonomia. Solo la calibrazione del gap tra "fa da solo" e "chiede permesso" la produce.
Implicazione operativa:
agent_runtime.html, 10h
approval_ux.html, 10h eval.html. Tutto
il resto emerge da queste tre fondamenta.Prima di questo giudizio, la fase 1 prevedeva 4 doc di microprogettazione classici:
gateway · channel · tool · sandbox.
Dopo questo giudizio, vanno prodotti prima tre doc trasversali, e solo dopo i quattro classici:
| Ordine | Doc | Coprono (critiche bloccanti) |
|---|---|---|
| 1 | agent_runtime.html | #1 reasoning loop · #2 tool validation · #3 ExecutionTrace · #9 prompt structure |
| 2 | approval_ux.html | #5 approval UX · mitigazione tensioni 1 e 2 |
| 3 | eval.html | #6 eval harness |
| 4 | gateway.html | (fase 1 classici) #4 status visibility in parte |
| 5 | channel.html | #4 status visibility completo |
| 6 | tool.html | pre-requisito per #2 |
| 7 | sandbox.html | — |
| 8+ | policy.html + cost_tiering (sotto-sezione) | #7 tiering · #17 costo autonomia |
myclaw — Prospettive & Giudizio v1.0 — 2026-04-21
Chiude la fase 0 di progettazione. Apre la fase 1 con un ordine nuovo.