1. L'oggetto unico: change_intent

Tutti i cambiamenti al sistema convergono in un singolo schema in ~/.local/state/metnos/change_intents.sqlite:

id UUID
fingerprint sha256[:32] # deterministico per dedup cross-source
state PROPOSED|ACCEPTED|APPLIED|OBSERVED|FINALIZED|
 STAGED|REJECTED|FAILED|ROLLED_BACK
origin_family telos|introvertiva|synt|multi_tool|canonical|user
origin_module scamper|dedupe|request_new_executor|L1|L2|feedback|...
intent_kind create_executor|extend_executor|dedupe_executors|
 materialize_pipeline|cache_pattern|reject_pattern
intent_target nome executor o pattern
intent_summary 1 frase user-facing
intent_body dict kind-specific (arg_name, tools_sequence,...)
score 0–1 normalizzato cross-source
confidence 0–1
convergence N. sorgenti che propongono cose equivalenti
decision_* registro accept/reject/stage utente
applied_effect diff applicato + rollback_blob path
observed_metrics metriche grace period

Il fingerprint NON include origin_family: cosi' due sorgenti diverse che propongono cose equivalenti (es. telos:scamper + introvertiva:specialize sullo stesso executor) coalescono in un solo record, con convergence bumpato.

2. Il ciclo di vita in 5 atti

 +-----------+
 | PROPOSED | ← qualche sorgente l'ha generata
 +-----------+
 / | \
 / | \
 (utente) | (utente decide piu' tardi)
 / | \
 v v v
+----------+ +--------+ +---------+
| ACCEPTED | | STAGED | |REJECTED |
+----------+ +--------+ +---------+
 | (daemon applier)
 v
+----------+ +----------+
| APPLIED | ----> | FAILED | (retry possibile)
+----------+ +----------+
 | (daemon observer, grace period default 7gg)
 v
+----------+ +-------------+
| OBSERVED | ----> | ROLLED_BACK | (fisico, per kind)
+----------+ +-------------+
 |
 v
+-----------+
| FINALIZED | ← consolidato, rimosso dalle viste default
+-----------+

Da QUALSIASI stato si puo' transizionare a ROLLED_BACK (escape hatch audit umano). Da REJECTED e' possibile re-proporre (transition a PROPOSED).

3. Le 6 sorgenti come adapter

Le sorgenti storiche non vengono cancellate: continuano ad esistere come «input feed» che alimenta il materializer. Per ognuna c'e' un adapter in runtime/change_intent_adapters/ che proietta i record legacy in ChangeIntent.

Score normalization per family:

• telos: expected_alignment gia' 0–1
• multi_tool / canonical: uses via log-saturante mid=20 (es. uses=20 → score 0.50, uses=100 → 0.83)
• introvertiva: n_seen*0.05 + last_uses*0.005 (formula storica)
• synt: installed=0.8, abandoned=0.3, rejected*=0.05
• user reject_pattern: min(0.9, 0.3 + 0.15*n_rejections)

4. I 3 daemon: materializer, applier, observer

Applier handler per kind:

• create_executor: invoca pipeline synth_request esistente (~150s wall). Idempotente: short-circuit se gia' nel catalog.
• extend_executor: change_applier_extend.py. Append della sezione [args.properties.<arg>] in fondo al manifest TOML, backup pre-modifica in ~/.local/share/metnos/rollback_blobs/<sha8>-<name>.toml, re-sign via sign.sign_executor.
• dedupe_executors: alias setup in executor_aliases.json + deprecate del duplicato in executor_stats.db.
• materialize_pipeline: UPDATE multi_tool_paths SET state='active'.
• cache_pattern: UPDATE canonical_query_log SET state='active'.
• reject_pattern: append in ~/.local/share/metnos/rejected_patterns.jsonl (agent_runtime lo legge come HARD CONSTRAINT del planner).

Observer verifica metrics post-applied_at e applica grace period (default 7 giorni, env METNOS_CHANGE_GRACE_DAYS). Trigger di rollback:

• create/extend_executor: last_call_ok=False con ≥3 chiamate; deprecato dall'executor_ager.
• materialize_pipeline / cache_pattern: state ha derivato a demoted.
• dedupe_executors: alias rimosso dal file.
• reject_pattern: nuovi feedback ✗ post-applied per la stessa (canonical_query, tools).

Rollback fisico delegato a change_rollback.py (per kind: archive synth dir, restore manifest da blob + re-sign, rimuovi alias, demote state, rimuovi linea jsonl).

5. Esempio end-to-end: find_recipes

Telos engine SCAMPER suggerisce: «Estendi find_files con kind=recipe per matchare file .md in ~/Documents/Recipes.»

Se invece dopo apply Roberto preme ✗ in chat su una risposta usando il nuovo arg, observer vede new_rejects≥2 per la query target e transiziona a ROLLED_BACK — physical restore del manifest dal blob.

6. Riferimenti operativi

• UI: /admin/changes con 9 tab per stato. Default tab=proposed, cap 30 rows (override ?limit=100|500).
• API JSON: stesso endpoint con header Accept: application/json (no text/html).
• Smoke test: python3 -m pytest runtime/tests/test_change_*.py -v (55 test).
• Materializer dry-run: python3 -m runtime.jobs.change_intent_materialize (idempotente).
• Inspezione DB: sqlite3 ~/.local/state/metnos/change_intents.sqlite.
• Audit JSONL: ~/.local/share/metnos/audit/change_{intent_materialize,applier,observer}.jsonl.

— allineato con il codice.