1# Changelog
2
3Registro cronológico de cambios sustantivos en el monorepo Brahman. Cada
4entrada lista las acciones concretas tras un commit; para detalles de
5ratio/diff ver `git show <sha>`.
6
7## 2026-05-10
8
9### feat(brahman-demo): bootstrap script reproducible — broker + producer + consumer + 4 explorers
10Iter 22. Cierra el set de iteraciones de hoy: cualquier persona (o
11future-me retomando el repo) puede levantar el escenario completo
12con un comando.
13
14Crate nuevo `crates/apps/brahman-demo/` con 3 binarios:
15- **`brahman-demo-broker`**: standalone `Server::bind` con un Broker
16  configurado, escucha en el socket default. Reemplaza a
17  `ente-zero` para fines de demo (ente-zero pesa kernel surface +
18  child subreaper + bus + brain + audit; el demo no lo necesita).
19- **`brahman-demo-producer`**: registra una Card con `flow.output[demo-stream:json]`
20  y queda pingueando.
21- **`brahman-demo-consumer`**: registra una Card con `flow.input[demo-feed:json]`
22  (mismo type → matchea con el producer) y queda escuchando
23  `MatchEvent`s.
24
25Variables de entorno respetadas en los 3: `BRAHMAN_INIT_SOCKET`,
26`BRAHMAN_BROKER_CONTEXT` (sólo broker), `BRAHMAN_DEMO_LABEL/FLOW/TYPE`,
27`RUST_LOG`.
28
29Script nuevo `scripts/bootstrap-demo.sh`:
30- Modos: `all` (default — broker + producer + consumer + 4 explorers),
31  `broker` (sin GUIs, sólo backend), `only` (sólo broker, sin
32  producer/consumer ni GUIs).
33- Cleanup-safe: trap `EXIT INT TERM` mata todos los procesos
34  spawneados (con SIGTERM grace + SIGKILL fallback) y borra el socket.
35- Espera activa hasta 5s a que el socket aparezca antes de spawnear
36  los siguientes (evita ENOENT en el handshake).
37- Logs separados por proceso bajo `$BRAHMAN_DEMO_LOG_DIR` (default
38  `/tmp/brahman-demo`). Re-invocaciones limpian los logs viejos.
39- Re-build automático opcional (comentado por default — asume
40  `cargo build --workspace` ya hecho).
41
42Smoke verificado end-to-end (sin DISPLAY, sólo backend):
43- Broker arranca, bind del socket OK.
44- Consumer conecta, asigna session.
45- Producer conecta, asigna session.
46- Consumer recibe `MatchEvent { Available, demo-feed ← demo-stream,
47  via: Exact, pinned: false }` automáticamente — el broker computó
48  el match y lo pusheó por el push channel.
49
50Stack tests: brahman-demo (0 unit), workspace verde.
51
52### feat(brahman-handshake): ListMatches endpoint + timeline en broker-explorer
53Iter 21. Cierra el loop de observabilidad iniciado en iter 20: ahora
54se ven no sólo las sesiones registradas sino también qué matches
55consumer↔producer está computando el broker en cada momento, y la
56historia de cómo cambian.
57
58`brahman-handshake/messages.rs`:
59- **`Frame::ListMatches(ListMatches{session})`**: pedido (mismo
60  patrón de validación session-id).
61- **`Frame::MatchList(MatchList{matches: Vec<brahman_broker::Match>})`**:
62  respuesta. Cada `Match` ya es serializable y lleva `consumer`,
63  `consumer_label`, `producer`, `producer_label`, `ty`, `via`, `pinned`.
64
65`brahman-handshake/server.rs`:
66- `run_post_handshake` ahora pasa también `broker_for_match: Option<&SharedBroker>`
67  al `handle_inbound_frame`.
68- Si el server tiene broker configurado, `ListMatches` responde con
69  `broker.all_matches()`. Si no (server sin broker), responde
70  `MatchList { matches: vec![] }` — refleja "no hay matching activo",
71  no es un error.
72
73`brahman-handshake/client.rs`: `Client::list_matches()` análogo a
74`list_sessions()`, drena `MatchEvent`s intermedios al buffer.
75
76`brahman-sidecar/discovery.rs`: `list_matches` y `list_matches_blocking`
77con la misma forma de Card observer minimalista.
78
79`brahman-broker-explorer`:
80- Cada poll-tick ahora pide TANTO `list_sessions` COMO `list_matches`.
81- `Explorer.last_match_keys: HashSet<MatchKey>` mantiene el estado
82  del último snapshot. La key es `(consumer.session, consumer.flow,
83  producer.session, producer.flow)`.
84- `Explorer.timeline: VecDeque<TimelineEntry>` con cap `TIMELINE_CAP=50`.
85- Función pura `diff_matches(last_keys, list) -> (entries, new_keys)`:
86  emite `Available` para keys nuevas y `Lost` para keys desaparecidas.
87  Primer tick (last_keys vacío) marca todo como Available — cubre
88  el boot sin que la UI quede vacía.
89- Render: `stat_card` "Timeline de matches" con count + 20 entries
90  formateadas como `HH:MM:SS {+/-} consumer.flow ← producer.flow [via]`.
91  Más reciente arriba.
92
93Tests broker-explorer: 5 totales.
94- `diff_matches_first_snapshot_marks_everything_available`
95- `diff_matches_emits_lost_when_match_disappears`
96- `diff_matches_no_change_emits_nothing`
97- `pending_is_default_state_at_boot` (existente)
98- `poll_and_probe_constants_are_sane` (existente)
99
100Decisión: timeline polled (cada `POLL_INTERVAL=5s`), no push.
101Razón: los `MatchEvent` push del broker son consumer-céntricos
102(cada session sólo ve sus propios matches). Para "system-wide
103timeline" haría falta una API broker-level "subscribe a todos" —
104mucho más scope. Polling cada 5s es suficiente para observabilidad.
105
106### feat(brahman-handshake): ListSessions endpoint + cliente + UI broker-explorer
107Iter 20. Nuevo flujo end-to-end para observabilidad: cualquier
108módulo conectado puede preguntar al broker la lista de sesiones
109activas y mostrar labels + flows in/out por cada una.
110
111`brahman-handshake/messages.rs`:
112- **`Frame::ListSessions(ListSessions { session })`**: request del
113  cliente (server valida que `session` coincida con la sesión vigente,
114  mismo patrón que Ping/Farewell).
115- **`Frame::SessionList(SessionList { entries })`**: respuesta.
116  Cada `SessionEntry` lleva: `session`, `label`, `schema_version`,
117  `outputs` (nombres de flow.output), `inputs` (nombres de
118  flow.input), `conscious` (`true` si la Card vino con WIT).
119
120`brahman-handshake/server.rs`:
121- `run_post_handshake` ahora pasa `SessionRegistry` a
122  `handle_inbound_frame` (necesario para consultar el snapshot de
123  sesiones en respuesta a `ListSessions`).
124- Helper `build_session_list(sessions)` que toma el snapshot bajo
125  el lock, lo proyecta a `SessionList`, y suelta el lock antes de
126  escribir el frame al wire.
127- Validación `session_id` mismatched → `HandshakeError::Unauthorized`.
128
129`brahman-handshake/client.rs`:
130- `Client::list_sessions()` async: envía el request, drena
131  `MatchEvent`s intermedios al `pending_events` buffer (mismo patrón
132  que `ping`), retorna el `SessionList`.
133
134`brahman-sidecar/discovery.rs`:
135- `pub async fn list_sessions(observer_label)` y
136  `pub fn list_sessions_blocking(observer_label)`: arman una Card
137  observer mínima (sin flow.input/output), conectan, piden la lista,
138  Farewell. Para CLIs y módulos std-thread.
139
140`brahman-broker-explorer`:
141- Cada poll-tick (cuando el broker está UP*) ahora también pide
142  `list_sessions_blocking` y guarda el snapshot en `Explorer.sessions`.
143- Render extiende el body con un `stat_card` "Sesiones activas" que
144  muestra el count + lista ordenada por `session` (Ulid temporal),
145  cada item: `label · in:[flows] out:[flows]  (wit?)`.
146
147Tests:
148- `list_sessions_returns_currently_registered`: levanta server con
149  broker, conecta 3 clientes (alpha, beta, observer), observer pide
150  `list_sessions`, verifica los 3 labels presentes y que la entry
151  del observer reporte `conscious=false` y el `schema_version`
152  esperado.
153- Stack: handshake suite (24 tests), sidecar (3+8 unit + integ),
154  broker-explorer (4 tests). Todo verde.
155
156### feat(yahweh-launcher): F3 — extracción del shell standard de explorers
157Iter 19. Patrón con 4 consumers idénticos (nakui-explorer,
158nouser-explorer, minga-explorer, brahman-broker-explorer) declaraban
159~20 líneas de boot:
160`Application::new + Theme::install_default + cx.open_window
161+ WindowOptions{ window_bounds, titlebar } + cx.activate(true)`.
162Todo idéntico salvo título, tamaño, y root entity factory.
163
164Crate nuevo `crates/modules/ui_engine/libs/launcher/`
165(`yahweh-launcher`):
166- **Deps**: `gpui`, `yahweh-theme`. Sin más.
167- **`pub fn launch_app(title, size, root_factory)`**: 1-line boot.
168- **`pub fn launch_app_with(config, root_factory)`**: variante con
169  `AppLaunchConfig` armado afuera, para casos donde título/tamaño se
170  computan condicionalmente (env var, etc).
171- **`AppLaunchConfig::new(title, size)`**: builder normalizador.
172- 2 tests `#[test]` cubren la normalización de config (no se testea
173  `launch_app` per se porque bloquea el thread main hasta que la
174  ventana se cierra).
175
176Migración 4 consumers:
177- `main()` pasa de 20 líneas a 1: `launch_app("Title", (W, H), Explorer::new)`.
178- Imports de gpui se podan: ya no necesitan `App, Application,
179  Bounds, WindowBounds, WindowOptions` ni `SharedString` ni `prelude::*`.
180- Cada consumer agrega dep `yahweh-launcher` (path local).
181
182Naming: el slot natural era `yahweh-shell`, pero ya existe un crate
183`yahweh-shell` en `crates/apps/` (bootstrap heavyweight con file
184explorer + DB explorer + viewers). El helper es liviano y específico
185al patrón de launch, así que `yahweh-launcher` evita confusión.
186
187Total ahorro: ~75 líneas hardcoded de boilerplate UI a 4 líneas en
188total. Cambios de boot (window opts, theme, etc) ahora viven en un
189solo lugar.
190
191Tests stack: 2 nuevos en launcher; suites de los 4 consumers
192intactas. Todo verde.
193
194### chore(.gitignore): excluir .claude/ (state local de Claude Code)
195Iter 18. Side cleanup tras debugging: `.claude/` aparecía en
196`git status` cada sesión (contenía `scheduled_tasks.lock` y
197`settings.local.json`, ambos local-only). Excluido para que no se
198commitee accidentalmente y para que `git status` quede limpio.
199
200Investigación previa que motivó el cleanup: persiguiendo un supuesto
201deadlock en `drift_check_surfaces_expected_per_record_diffs` con
202eprintlns/macro de log a archivo en `drift.rs` y `run.rs`. Conclusión:
203no hay deadlock — pasa cleanly aislado, en suite nakui-core, y en
204`cargo test --workspace`. El "hang" original venía de procesos cargo
205y test-binaries huérfanos de sesiones anteriores compitiendo por el
206build lock. Source restaurado, ningún cambio funcional. Memoria
207`project_drift_hang.md` reescrita con el playbook correcto.
208
209### fix(nakui-core): schema_bundle_hash debe reflejar el contenido real del schema
210Iter 17. Regresión surfaceada por el workspace test
211`verify_log_rejects_seed_after_schema_kcl_changes` (rebautizado a
212`verify_log_rejects_seed_after_schema_changes`).
213
214**Bug**: `compute_schema_bundle_hash` operaba sobre los bytes del
215bundle compilado, que `build_schema_bundle` arma como
216`(import "/abs/path/schema.ncl") & ...`. Los bytes del bundle nunca
217cambian cuando se edita el archivo apuntado — sólo cambian si se
218agregan/quitan schemas o se mueve el módulo de path. Resultado: el
219hash quedaba pegado y los seeds firmados bajo schema vN se aceptaban
220silenciosamente como válidos bajo schema vN+1, aunque las invariantes
221hubieran cambiado.
222
223**Fix**: nueva fn `read_schema_files_concat(module_dir, schemas)`
224que lee los bytes de cada schema declarado y los concatena con
225framing `\0NCL:<name>\0` (separador no ambiguo + nombre relativo, no
226absoluto, para que el hash sea estable entre máquinas). Esos bytes
227alimentan `compute_schema_bundle_hash` y `compute_morphism_schema_hash`
228en lugar de los bytes del bundle. El bundle compilado sigue siendo
229imports-style (necesario para que Nickel resuelva paths relativos);
230sólo la fuente del hash cambió.
231
232**Impacto en logs existentes**: como cualquier cambio al insumo del
233hash, los seeds y morphisms versados bajo el bundle hash anterior
234fallarán `SchemaMismatch` al verificarse contra un binario nuevo. No
235hay migración — esto es exactamente el comportamiento que el hash
236busca: re-seed.
237
238Tests: 10/10 en `schema_versioning` (era 9/10 con 1 FAILED).
239
240### feat(yahweh-widget-app-header): promover el header standard de explorers
241Iter 16. Patrón con 4 consumers idénticos: `nakui-explorer`,
242`nouser-explorer`, `minga-explorer`, `brahman-broker-explorer`
243todos declaraban un header `flex_row + flex_grow(label) +
244theme_switcher + bg(panel) + border-bottom + text_size(14) +
245padding(16/12)`. Ahora es 1 línea.
246
247Crate nuevo `crates/modules/ui_engine/widgets/app-header/`
248(`yahweh-widget-app-header`):
249- **Deps**: `gpui`, `yahweh-theme`, `yahweh-widget-theme-switcher`.
250  El switcher se incluye automáticamente.
251- **`pub fn app_header(cx: &mut App, label: impl Into<SharedString>)
252  -> impl IntoElement`**: caso simple con texto plano.
253- **`pub fn app_header_with(cx, label_child: impl IntoElement)`**:
254  variante para cuando el lado izquierdo no es texto plano (icon
255  + text, múltiples spans, etc.).
256- 3 tests `#[gpui::test]`: smoke con string label, con custom
257  child IntoElement, type-check de label con literal/owned/format!.
258
259Migración de los 4 consumers:
260- Cada uno reemplaza un bloque `let header = div().flex().flex_row()...
261  .child(theme_switcher(cx))` (~13 líneas) por
262  `let header = app_header(cx, header_text)` (~1 línea).
263- Cada uno borra dep `yahweh-widget-theme-switcher` (ya no la
264  necesita directo — el `app_header` la incluye internamente).
265- Cada uno reemplaza `use yahweh_widget_theme_switcher::theme_switcher`
266  por `use yahweh_widget_app_header::app_header`.
267
268Total ahorro: ~50 líneas de código UI hardcoded en consumers.
269Cambios visuales en el header (padding, border, text_size) ahora
270viven en un solo lugar.
271
272Tests stack: 3 nuevos en app-header; suites de los 4 consumers
273intactas. Todo verde.
274
275Decisión: el sidebar header del `MetaApp` (que también incluye
276theme_switcher) NO se migra — es un header de sidebar, no de app
277top, y tiene styling distinto (px(12/10/13), sin bg/border-bottom
278porque ya está dentro del panel). Diferente patrón → diferente
279widget si emerge segundo consumer.
280
281### feat(yahweh-widget-stat-card): promover el patrón stat card como widget
282Iter 15. El patrón "tarjeta de dashboard con border-l accent +
283label + valor grande + descripción + listing opcional" tenía 2
284consumers (`minga-explorer` y `brahman-broker-explorer`); ahora vale
285extraer al stack yahweh para reusabilidad y mantenimiento single-place.
286
287Crate nuevo `crates/modules/ui_engine/widgets/stat-card/`
288(`yahweh-widget-stat-card`):
289- **Deps**: `gpui` + `yahweh-widget-card` (compone `card_themed`).
290  Sin theme directo — el caller pasa `text` y `text_dim` ya
291  resueltos del theme.
292- **`pub fn stat_card(cx, label, value, description, accent,
293  text, text_dim, recent_items)`**:
294  - `cx: &App` (acepta `&Context<T>` por deref auto-coerce).
295  - `value: impl Into<SharedString>` — sirve para counts (`"3"`),
296    status text (`"UP"`), o cualquier label corto.
297  - `recent_items: &[String]` — si no vacío, agrega sub-header
298    `"recent (N):"` + una linea por item.
299- 3 tests `#[gpui::test]` con TestAppContext: smoke con/sin
300  recent_items, type-check de `value` con literal/format/owned.
301- Dev-deps: gpui con `test-support` + yahweh-theme para construir
302  el cx con un theme global.
303
304Cambios consumer:
305- **`minga-explorer`**: sustituye su `fn stat_card` local
306  (~60 líneas) por `use yahweh_widget_stat_card::stat_card`.
307  Borra dep `yahweh-widget-card` (ya no se usa directo). Adapta
308  los 3 callsites para pasar `value.to_string()` (el widget
309  acepta `Into<SharedString>`).
310- **`brahman-broker-explorer`**: refactoriza su `fn state_card`
311  para que sea un wrap de `stat_card` con la traducción
312  `ProbeState → (accent, value, description)`. La función queda
313  como helper local porque la mapping del enum es app-specific,
314  pero el rendering pasa por el widget compartido. Borra dep
315  `yahweh-widget-card`.
316
317Tests stack: nuevos 3 del widget. Suites de los 2 consumers
318intactas (4 minga-explorer, 2 broker-explorer). Stack total ~120
319verdes (varía por compilation cache).
320
321Beneficio operativo:
322- Cualquier app nueva que necesite cards de dashboard usa
323  `stat_card(...)` directo; no re-implementa el pattern.
324- Cambios visuales (text sizes, padding, sub-header format)
325  ahora viven en un solo lugar.
326- `value: impl Into<SharedString>` es más expressive que el
327  `usize` rígido del original local.
328
329Pequeña simplificación documentada: el sub-header del listing
330pasa de `"recent (N de TOTAL):"` a `"recent (N):"`. El "TOTAL"
331ya no se calcula porque el widget no lo conoce — el caller que
332quiera mostrarlo lo formatea en el label/value (ej. label `"Nodos
333AST (5 de 247)"`). Acceptable trade-off por la reusabilidad
334genérica.
335
336### feat(brahman-broker-explorer): nueva app probe del broker brahman
337Iter 14. Cierra otro frente: visibilidad del broker brahman (el
338broker handshake que matchea Cards consumer/producer). Hasta ahora
339no había forma de "ver" si el broker estaba up sin invocar otro
340binario CLI. Ahora hay una app GUI que probe cada 5s y reporta 3
341estados claros.
342
343Crate nuevo `crates/apps/brahman-broker-explorer/`:
344- **Deps**: `brahman-handshake`, `brahman-sidecar` + el stack
345  yahweh themed (theme + 3 widgets). Consume el mismo
346  `await_provider_blocking` que usa `nouser-explorer`.
347- **`ProbeState` enum** con 4 variants:
348  - `Pending` (estado inicial al boot, antes del primer probe).
349  - `Down { reason }` — connect failed, broker no escucha.
350  - `UpNoProvider { flow }` — broker reachable + sin productor
351    para el flow probado dentro del timeout.
352  - `UpWithProvider { flow, producer_socket }` — broker reachable
353    + matcheó algo, devuelve el socket del provider.
354- **Polling loop** en `cx.spawn` cada 5s; el probe (que es
355  bloqueante porque internamente usa tokio runtime) se ejecuta en
356  `cx.background_executor().spawn(...)` para no congelar el main
357  thread del UI.
358- **Configuración via env**:
359  - `BRAHMAN_INIT_SOCKET` — path del broker (default resuelto por
360    `brahman_handshake::transport`).
361  - `BRAHMAN_BROKER_PROBE_FLOW` — flow del Card observer
362    (default `broker-health`).
363  - `BRAHMAN_BROKER_PROBE_TYPE` — type name (default `ping`).
364- **UI**: header con probe info + theme switcher; banner permanente
365  (Error/Warning/Success/none según estado) debajo del header;
366  stat card con accent color por estado y descripción.
367- 2 tests sanity (default state es Pending; constants coherentes:
368  PROBE_TIMEOUT < POLL_INTERVAL >= 2s).
369
370Smoke run del binario verificado: bootstrap completo OK, panic
371esperado en open_window por falta de display.
372
373Beneficio operativo:
374- Si tenés un broker corriendo en `~/.local/share/brahman/init.sock`,
375  el explorer lo detecta + reporta estado verde con su socket.
376- Si no hay broker, banner rojo + msg claro indicando el path
377  probado.
378- Si hay broker pero ningún Card produce el flow probado, banner
379  amber — útil para distinguir "broker down" de "broker up,
380  no productor del tipo X".
381- Apuntando el flow/type via env, podés monitor productores
382  específicos: ej. `BRAHMAN_BROKER_PROBE_FLOW=monad-list
383  BRAHMAN_BROKER_PROBE_TYPE=json` para ver si nouser está sirviendo.
384
385Apps GUI integradas al stack themed: **5** (nakui-ui, nakui-explorer,
386nouser-explorer, minga-explorer, brahman-broker-explorer).
387
388Limitaciones documentadas:
389- El observer registra una Card temporal en cada probe (cada 5s).
390  Eso ensucia un poco las estadísticas del broker (Cards
391  registradas/desregistradas). No impacta funcionalidad pero
392  inflama el log si el broker tiene observability habilitada.
393- No muestra la **lista global** de Cards registradas en el broker
394  — el protocolo handshake actual no expone esa API. Para eso
395  habría que agregar un endpoint `ListSessions` al broker server.
396- No mantiene un buffer de MatchEvents. Cada probe es independiente.
397  Para timeline de matches, hace falta mantener el Client vivo
398  entre probes — scope futuro.
399
400### feat(yahweh-theme): persistencia de la preferencia de theme entre runs
401Iter 13. El theme switcher ya cambiaba el chrome en runtime, pero
402al cerrar y reabrir la app el theme volvía a Nebula default. Ahora
403el name del theme se persiste en `$XDG_CONFIG_HOME/yahweh/theme`
404(default `~/.config/yahweh/theme`) y se restaura al boot.
405
406Cambios en `yahweh-theme`:
407- **`pub fn config_path() -> Option<PathBuf>`**: resuelve el path
408  XDG. Devuelve `None` si ni `XDG_CONFIG_HOME` ni `HOME` están
409  set (sandbox/CI).
410- **`pub fn load_persisted() -> Option<Theme>`**: lee el archivo,
411  trim, busca el theme por name vía `Theme::by_name`. `None` si
412  el file no existe, lectura falla, o el name no matchea ningún
413  preset (e.g. preset renombrado entre versiones).
414- **`pub fn persist(theme: &Theme) -> io::Result<()>`**: escribe
415  el name al config file. Crea el dir parent si no existe.
416- **`pub fn load_from_path` y `pub fn persist_to_path`**: variantes
417  con path explícito — útiles para tests con tempfile y para apps
418  que quieren un path custom (multi-user, staging, etc.).
419- **`Theme::install_default(cx)` cambia**: antes hardcoded
420  `nebula()`. Ahora intenta `load_persisted()`, fallback a Nebula.
421- **`Theme::set(cx, theme)` cambia**: antes sólo `cx.set_global`.
422  Ahora también `persist(&theme)` antes (best-effort: ignora io
423  errors). El `theme_switcher` widget ya consume `Theme::set`, así
424  que sin cambios en su código el switching ahora persiste.
425
4265 tests nuevos (`persistence_tests`):
427- `persist_then_load_round_trip` — escribir + leer Aurora.
428- `load_from_missing_file_returns_none` — no rebota.
429- `load_from_unknown_name_returns_none` — name desconocido →
430  `None` (degrada a default cuando se usa).
431- `persist_creates_parent_dir_if_missing` — crea
432  `~/.config/yahweh/` si no existe.
433- `config_path_uses_xdg_config_home_when_set` — respeta el env.
434
435Tests stack: ~5 nuevos en yahweh-theme. Todos los downstream
436(nakui-ui, *-explorer) compilan sin tocar nada — la API pública
437de `Theme::install_default` y `Theme::set` no cambió shape.
438Smoke run del binario verificado: bootstrap OK, panic esperado
439sin display.
440
441Beneficio operativo:
442- Usuario abre `nakui-ui`, cicla a Aurora con el switcher, cierra
443  app. Próxima apertura: Aurora cargado del disco. Todas las
444  apps yahweh-themed (4 del repo) comparten la misma preferencia.
445- Failure mode benigno: sin home dir o sin permisos de write,
446  el theme cambia in-memory pero no se persiste — el switcher
447  sigue usable, sólo no sobrevive al close.
448- Path canónico documentado: usuarios que quieran preset el
449  theme antes de abrir la app pueden hacer
450  `echo Aurora > ~/.config/yahweh/theme`.
451
452### feat(minga-explorer): listings de items recientes en cada stat card
453Iter 12. Hasta ahora minga-explorer mostraba sólo counts (3
454números). Ahora cada stat card muestra también un sample de los
455items dentro: hashes truncados de los 5 primeros nodos AST
456(con su `kind`), atestaciones (`content_hash ← did_short`) y
457claves MST. Mucho más útil para debugging que el "tengo N items".
458
459Cambios en `minga-explorer`:
460- **`RepoSnapshot` extendido** con 3 nuevos `Vec<...>`:
461  - `recent_nodes: Vec<(String, String)>` — `(hash_short, kind)`.
462  - `recent_attestations: Vec<(String, String)>` —
463    `(content_hash_short, did_short)`.
464  - `recent_mst_keys: Vec<String>` — `hash_short`.
465  - Cap de 5 items por sección via `RECENT_LIMIT` const.
466- **`load_snapshot` itera los stores** y toma los primeros 5
467  items via `iter().filter_map(Result::ok).take(RECENT_LIMIT)`.
468  Errores per-item se silencian (`filter_map`) — el dashboard
469  muestra lo que pueda; un par de items corruptos no debería
470  tirar el panel.
471- **`short_hash(&str)` helper local**: trunca un hex a sus
472  primeros 12 chars (48 bits, distintivo dentro de un repo
473  single-machine).
474- **`stat_card` extendido**: nuevo arg `recent_items: &[String]`.
475  Si no está vacío, agrega un sub-header `"recent (N de TOTAL):"`
476  + una linea por item. Cada line es texto pequeño (`px(11)`)
477  con el color principal del theme — visualmente queda como
478  monospace listing aunque no use mono font (no hay todavía
479  en el theme).
480
481Tests: 2 → **4** (+2 sanity de los nuevos defaults + del
482`short_hash`).
483
484Beneficio operativo:
485- Después de `minga ingest archivo.rs`, el explorer muestra
486  inmediatamente los hashes de los nodos AST creados, qué `kind`
487  tienen, y las atestaciones firmadas — sin necesitar `minga
488  status` o queries SQL.
489- "5 de 247" da contexto del crecimiento sin overwhelm de
490  listing completo.
491
492Limitación documentada: los "recent" no son cronológicos — sled
493ordena lexicográfico por hash. Para timeline real, agregar
494timestamp al schema (cambio breaking del store, scope futuro).
495
496### feat(minga-explorer): nueva app dashboard del repo Minga sobre stack yahweh
497Iter 11. Cierra el último frente identificado: integración del
498módulo Minga (VCS semántico P2P) al ecosistema GUI. Antes Minga
499sólo tenía CLI (`minga init/status/ingest/listen/sync/watch`).
500Ahora hay un **dashboard GPUI** que muestra los counts del repo
501en vivo, sobre el mismo stack themed que las otras dos apps
502explorer.
503
504Crate nuevo `crates/apps/minga-explorer/`:
505- **Deps**: `minga-store` (para `PersistentRepo::open`) +
506  `yahweh-theme` + `yahweh-widget-{banner,card,theme-switcher}`.
507  Sin `minga-cli` (no necesita prompts de passphrase) ni
508  `minga-core` (counts no requieren parsear AST).
509- **Lectura sin passphrase**: el `PersistentRepo` se abre directo
510  desde `<repo>/repo` sled. Los counts (`nodes.len()`,
511  `attestations.len()`, `mst.len()`) son lectura pública. Para el
512  DID se sigue necesitando `minga status` (CLI con passphrase).
513- **Refresh por polling cada 2s**: mismo pattern que
514  `nakui-explorer`/`nouser-explorer`.
515- **3 stat cards** una por dimensión:
516  - Nodos AST (cyan) — fragments parseados del código.
517  - Atestaciones (verde) — firmas Ed25519 sobre los nodos.
518  - Claves MST (purple) — entradas del Merkle Search Tree.
519- **Helper `stat_card(cx, label, value, description, accent, ...)`**:
520  fabrica una card con border-l colored + label tenue + número
521  grande (`px(28)`) + descripción. Reutilizable.
522- **Header**: título dinámico (`Repo: <path> · reload <ms> ms`)
523  + theme switcher derecha.
524- **Error banner**: themed Banner::Error si el repo no abre.
525- 2 tests: `load_snapshot_errors_on_missing_dir` (msg claro
526  cuando el dir no existe) + sanity del `RepoSnapshot::default`.
527
528Workspace: nueva entry en `members[]`.
529
530Smoke run del binario verificado: bootstrap completo OK, panic
531esperado en open_window por falta de display.
532
533Beneficio operativo:
534- Un usuario corre `minga init` + `minga ingest archivo.rs` desde
535  CLI, después abre `minga-explorer` y ve los counts crecer en
536  vivo cuando ingiere más archivos.
537- Comparte theme switcher con `nakui-explorer` y
538  `nouser-explorer` — cualquier preset elegido se aplica
539  visualmente igual cross-app.
540- `minga` deja de ser sólo CLI; gana presencia GUI sin tocar
541  el resto del módulo.
542
543Apps GUI integradas al stack themed: **4** (nakui-ui, nakui-explorer,
544nouser-explorer, minga-explorer).
545
546### feat(nouser-explorer): integración al stack yahweh themed
547Iter 10. `nouser-explorer` (la app paralela a `nakui-explorer`
548para ver Mónadas via daemon nouser) tenía colors hardcoded
549idénticos al patrón previo. Aplico el mismo refactor que se hizo
550para `nakui-explorer` en iter 4: instala el theme global, migra
551chrome a slots, usa los widgets `banner_themed` / `card_themed` /
552`theme_switcher`.
553
554Cambios en `nouser-explorer`:
555- **Nuevas deps**: `yahweh-theme`, `yahweh-widget-banner`,
556  `yahweh-widget-card`, `yahweh-widget-theme-switcher`.
557- **`main()`**: `Theme::install_default(cx)` antes de
558  `cx.open_window`.
559- **`render`**: 4 vars `let X = rgb(...)` (chrome) → theme slots
560  (`bg_app`/`fg_text`/`fg_muted`/`bg_panel`/`border`).
561- **Header**: gana flex_row + theme switcher en la derecha (mismo
562  pattern que nakui-explorer).
563- **`error_banner`**: pasa de div hardcoded a `banner_themed(cx,
564  Banner::Error, ...)` con override de padding (16/8) por
565  convención del header.
566- **2 cards de Engine y Monad**: pasan de `div().flex().flex_col()
567  .p().mb().bg(card_bg).rounded().border_l_4().border_color()...`
568  a `card_themed(cx).border_l_4().border_color(accent)...`.
569- **Acentos semánticos**: `accent_engine` (cyan, las "máquinas")
570  y `accent_data` (purple, las Mónadas) quedan locales — son
571  señales del dominio nouser, no del chrome.
572
573Tests: workspace stack intacto. nouser-explorer no tiene tests
574propios (siempre fue una vista live del daemon, sin lógica
575testable separada).
576
577Beneficio operativo: las dos apps explorer del repo
578(`nakui-explorer` para event log + `nouser-explorer` para Mónadas)
579ahora comparten la misma paleta themed + el mismo control de
580switcher. Si un usuario las corre lado a lado, la consistencia
581visual emerge sola.
582
583### feat(yahweh): caret blinking + slots ornament en theme + MetaApp full themed
584Iters 8-9 combinadas. Tres mejoras pequeñas que cierran la
585integración del theme:
586
587**1. Caret blinking en text-input** (`yahweh-widget-text-input`):
588- Nuevo field `caret_visible: bool` que toggea cada 500ms.
589- Nuevo field `_blink_task: Task<()>` mantiene el loop de blink
590  vivo y lo cancela al drop del widget.
591- En `new()`, `cx.spawn(...)` arranca el loop: `timer.timer(500ms)`
592  + `this.update(...)` que toggea + `cx.notify()`. Si el update
593  falla (entity drop), break.
594- En `render()`, caret `|` se dibuja sólo si
595  `is_focused && self.caret_visible`. Familiar feel del SO.
596
597**2. Slots ornament en yahweh-theme** (5 nuevos):
598- `bg_input() -> Hsla` — bg sutil para fields editables.
599- `bg_button() -> Hsla` + `bg_button_hover() -> Hsla` — controls
600  clickable secundarios.
601- `accent_destructive() -> Hsla` — rojo para acciones peligrosas.
602- `bg_destructive_hover() -> Hsla` — bg de hover sobre destructive.
603- Implementados como **methods** del `Theme` (no fields del
604  struct), derivados via `ornament_slots(self.is_dark)`. Esto
605  evita modificar los 6 presets — el slot vive donde uno lo
606  invoca.
607
608**3. MetaApp ornament cleanup** (`yahweh-widget-meta-form`):
609- 11 colores hardcoded `gpui::rgb(0x...)` migrados a slots del
610  theme:
611  - Sidebar menu items (selected/hover) → `bg_row_active` /
612    `bg_row_hover`.
613  - List row separator + button bgs → `bg_row_active` /
614    `bg_button()` / `bg_button_hover()`.
615  - Icon ✕ delete + hover → `accent_destructive()` /
616    `bg_destructive_hover()`.
617  - EntityRef selector hover/selected → `bg_row_active` /
618    `bg_row_hover`.
619  - EntityRef selector border → `theme.border` (slot existente).
620  - Form fallback input bg + submit button → `bg_input()` /
621    `bg_button()` / `bg_button_hover()`.
622  - Confirm modal hint subtitle + hovers de Cancel/Confirm →
623    `theme.fg_muted` / `bg_button_hover()` / `bg_destructive_hover()`.
624- Pattern: `let X = theme.slot()` antes de las closures + `move |d|
625  d.bg(X)` en hover/when para que el cierre tome ownership.
626
627Antes de este commit MetaApp tenía la **paleta principal** themed
628(iter 5) pero el ornament secundario (hovers, separators, botones
629inline) seguía hardcoded. Ahora el theme switcher cambia
630**absolutamente todo** el chrome del MetaApp en runtime.
631
632Tests: 117 verdes (sin cambios numéricos, pero downstream sigue
633compilando). Smoke run de nakui-ui: bootstrap completo OK.
634
635Limitación restante: `nouser-explorer` todavía no migra al stack
636yahweh themed — patrón idéntico a `nakui-explorer` aplicado pero
637más nuevo. Próxima iter.
638
639### feat(yahweh-widget-text-input): focus-aware border + caret sólo on focus
640Iter 7 (mini-iter — el text-input ya estaba themed, faltaba sólo
641el polish de focus visibility). Antes el border era siempre
642`accent_strong` y el caret `|` siempre estaba presente — imposible
643distinguir cuál input está activo en un form con varios fields.
644
645Cambios en `yahweh-widget-text-input`:
646- **Border focus-aware**: cuando el input está focused, border =
647  `theme.accent_strong` (color vivo). Cuando no, border =
648  `theme.border` (color tenue del chrome). Se obtiene via
649  `self.focus_handle.is_focused(window)`.
650- **Caret `|` sólo on focus**: cuando el input no tiene focus, se
651  muestra el texto plano sin caret. Reduce el "ruido visual" en
652  forms con muchos fields.
653- `render` ahora usa el `Window` arg (antes `_w`) para chequear
654  focus.
655
656Sin cambios en API pública — todo es interno al `render`. El
657binario no requiere migración.
658
659Tests: sin cambios (los tests del crate son struct constructors,
660no rendering). Tests downstream del widget (`yahweh-widget-meta-form`,
661`nakui-ui`) siguen verdes — el cambio es backward compatible.
662
663Beneficio operativo:
664- Forms con 5+ fields ahora son navegables: el usuario ve cuál
665  input recibe sus teclas via el border highlighted.
666- Cambio de theme afecta también a inputs (ya estaban themed; ahora
667  además respetan el `accent_strong` específico del preset
668  cuando focused, vs el `border` cuando no).
669
670Limitación pendiente: el caret `|` literal no parpadea (no hay
671animation timer). Cuando emerja la necesidad, agregar via
672`cx.spawn` con un loop de toggle. Por ahora el caret estático on
673focus es suficiente signal.
674
675### feat(yahweh-widget-theme-switcher): control para ciclar themes en runtime
676Iter 6. Cierra el ciclo del theme: ya teníamos paleta themed +
677widgets que la consumen, faltaba el control UI para rotar entre
678presets en vivo. Ahora hay un botón yahweh que muestra el theme
679actual y al click avanza al siguiente. `nakui-ui` y `nakui-explorer`
680lo incrustan en sus headers — un click cambia toda la paleta.
681
682Crate nuevo: `crates/modules/ui_engine/widgets/theme-switcher/`
683(`yahweh-widget-theme-switcher`):
684- **Deps**: `gpui` + `yahweh-theme`. Sin nada más.
685- **`pub fn theme_switcher(cx: &mut App) -> impl IntoElement`**:
686  botón clickable con `id`, padding consistente (`px(8/4)`),
687  bg = `theme.bg_panel_alt`, hover = `bg_row_hover`. Muestra
688  `"Tema: <name> ▸"` y al click hace
689  `Theme::set(cx, Theme::next_after(current.name))`.
690- 2 tests `#[gpui::test]`:
691  - `switcher_constructs_with_theme_installed` — smoke: el
692    constructor lee el global y devuelve un IntoElement sin panic.
693  - `theme_set_changes_global` — verifica que `Theme::set` reemplaza
694    el global y que el siguiente `Theme::global` devuelve el nuevo.
695- Dev-dep `gpui` con `test-support` para habilitar TestAppContext.
696
697Migración de consumers:
698- **`nakui-explorer`**: nueva dep `yahweh-widget-theme-switcher`.
699  El header pasa de `div().px().py()...child(text)` a
700  `div().flex_row().child(div().flex_grow().child(text)).child(theme_switcher(cx))`.
701  El switcher queda alineado a la derecha vía `flex_grow` del label.
702- **`yahweh-widget-meta-form`**: nueva dep. El sidebar header
703  ("Nakui" + 12px padding) gana el switcher con el mismo patrón
704  flex_row + flex_grow.
705
706Tests stack: 115 → **117** (+2 del switcher). Cada crate compila
707individualmente.
708
709Beneficio operativo:
710- Click en el switcher cambia toda la paleta en vivo: bg del app,
711  panels, banners (los que usan `_themed`), confirm modal, todo.
712- 6 presets disponibles via `Theme::all()` (Nebula, Aurora,
713  Sunset, Flat Dark, Solarized Light, High Contrast). El switcher
714  cicla circularmente.
715- Apps adoptantes del `Theme` heredan el switch sin esfuerzo.
716
717Decisión técnica: el handler usa `Theme::set(cx, ...)` que
718invalida el global. GPUI marca todos los views como dirty y
719re-renderea — los widgets que leen `Theme::global` en su `render`
720ven el nuevo automáticamente. No requiere `cx.observe_global`
721explícito en cada widget consumidor.
722
723Limitación: TextInput entities ya creadas no se actualizan visualmente
724si el theme cambia los colors del input bg/border (esos colors
725están hardcoded en `yahweh-widget-text-input`). Migrar text_input
726al theme es una iter futura — bajo scope porque actualmente vive
727suficientemente bien con sus defaults dark.
728
729### feat(yahweh-widget-meta-form): paleta del chrome migrada a `Theme::global(cx)`
730Iter 5 de integración. El `MetaApp::render` tenía 7 vars locales
731con colors hardcoded (`bg/panel/border/text/text_dim/accent/
732accent_active`) que se pasaban a las funciones internas
733(`render_sidebar`/`render_main`/`render_list`/`render_form`/
734`render_entity_ref_selector`). Ahora salen del `Theme::global(cx)`
735que el binario shell instala al boot. El `confirm_delete_banner`
736también usa `themed_colors(Banner::Warning)` / `themed_colors(Banner::Error)`
737para sus colors base.
738
739Cambios en `MetaApp::render`:
740- 7 `let X = gpui::rgb(0x...)` → derive del theme:
741  - `bg` ← `theme.bg_app` (Background, soporta gradientes).
742  - `panel` ← `theme.bg_panel`.
743  - `border` ← `theme.border` (Hsla).
744  - `text` ← `theme.fg_text`.
745  - `text_dim` ← `theme.fg_muted`.
746  - `accent` ← `theme.accent`.
747  - `accent_active` ← `theme.accent_strong`.
748- `toast_div` y `error_banner`: `banner(...)` → `banner_themed(cx, ...)`.
749
750Cambios de firma (internas, no API público):
751- `render_sidebar` / `render_main` / `render_list` /
752  `render_entity_ref_selector` / `render_form` cambian Rgba →
753  Hsla en sus parámetros de color (Background donde aplica para
754  `panel`). Los métodos `bg/text_color/border_color` de gpui::Div
755  aceptan ambos via `Into`, así que el uso interno no cambia.
756
757Cambios en `render_confirm_delete_banner`:
758- 6 colors hardcoded amber/red/gray → `themed_colors(Warning)` para
759  banner base, `themed_colors(Error)` para botón Confirm,
760  `theme.bg_panel_alt + fg_text` para botón Cancel.
761- Cambiar de Theme ahora cambia toda la paleta del modal.
762
763Lo que **NO** migra esta iter (queda como ornament hardcoded; iter
764futura si emerge la necesidad):
765- Row hovers misceláneos en `render_list` (px 0x232a36 / 0x1f2630
766  para selected/hover de filas).
767- Borders sutiles entre filas (px 0x232a36).
768- Bg de inputs custom (px 0x171a20).
769- Bg de botones en `render_entity_ref_selector` (px 0x2c3540).
770- Color rojo del icon `✕` de delete (px 0xd07070) y su hover
771  (px 0x4a2020).
772
773Estos son detalles ornamentales que un theme switcher real
774querría integrar; los aislo para una pasada futura cuando esté
775claro qué slots semánticos del theme conviene agregar (ej.
776`bg_row_selected` distinto de `bg_row_hover`, `accent_destructive`,
777etc.).
778
779`nakui-ui` shell ya instalaba `Theme::install_default(cx)` desde la
780iter pasada — sigue siendo el contract entre el shell y el widget.
781Smoke test del binario verificado: bootstrap completo OK, panic
782esperado en open_window sin display.
783
784Tests stack: 115 verdes (sin cambio — los tests del widget no
785acceden al render).
786
787Beneficio operativo:
788- El theme switcher (cuando llegue) cambia toda la paleta principal
789  de `MetaApp` con 1 sola llamada `Theme::set(cx, ...)`.
790- `MetaApp` y `nakui-explorer` comparten el mismo theme global en
791  un mismo proceso (si llegan a vivir juntos).
792- Los `confirm_delete_banner` y los toasts del MetaApp respetan
793  is_dark: el contrast ajusta automatic.
794
795### feat(yahweh): theme integration en `banner` + `card` + `nakui-explorer` consume themed
796Iter 4 de la integración. Los widgets `banner` y `card` ahora
797ofrecen variants `_themed(cx, ...)` que leen `Theme::global(cx)`.
798Las versiones sin theme se preservan para apps sin theme global.
799`nakui-explorer` migra a versiones themed + `Theme::install_default`
800al boot — el chrome hardcoded del explorer (5 variables `let bg =
801rgb(...)`) sale del theme.
802
803Cambios en `yahweh-widget-card`:
804- **Nueva dep**: `yahweh-theme`.
805- **`pub fn card_themed(cx: &App) -> Div`**: devuelve [`card`]
806  pre-aplicado con `bg(theme.bg_panel)`. El caller sigue componiendo
807  con borders, accents, children.
808
809Cambios en `yahweh-widget-banner`:
810- **Nueva dep**: `yahweh-theme`.
811- **`pub fn banner_themed(cx: &App, kind, message) -> Div`**:
812  deriva `(bg, fg)` según `kind` + `theme.is_dark`:
813  - `Info`: `theme.bg_panel_alt` + `theme.accent`.
814  - `Success` / `Warning` / `Error`: hue fijo (verde/amber/rojo)
815    + lightness flippeada según `is_dark` (dark = bg low, fg high;
816    light = invertido).
817- **`pub fn themed_colors(kind, theme) -> (Background, Hsla)`**:
818  helper público para callers que quieren computar el par sin
819  construir el div.
820- 3 tests nuevos del derivation: dark/light lightness contrast,
821  kinds distinguidos por hue.
822
823Migración de `nakui-explorer`:
824- Nueva dep `yahweh-theme`.
825- `main()` llama `Theme::install_default(cx)` antes de open_window
826  (el theme default es Nebula).
827- `render`:
828  - 5 `let bg/text/text_dim/card_bg/border = rgb(...)` colors
829    locales → `theme.bg_app/fg_text/fg_muted/bg_panel/border`.
830  - `card().bg(card_bg)` → `card_themed(cx)` (borra los locales).
831  - `banner(Banner::Error, ...)` → `banner_themed(cx, Banner::Error, ...)`.
832  - Los accents `accent_seed` / `accent_morphism` se preservan
833    locales: son **señales semánticas del log** (azul=seed,
834    verde=morphism), no chrome del app.
835
836Distribución de tests: 112 → **115** (+3 del banner derivation).
837Workspace stack pasó por la migración sin errores.
838
839Beneficio operativo:
840- Cambiar de Theme (Nebula → Aurora → Solarized Light, etc.) ahora
841  refleja en `nakui-explorer` automáticamente. Antes había que
842  buscar y reemplazar los hex codes uno a uno.
843- Apps que adopten el patrón `_themed` heredan el switcher de
844  theme cuando emerja.
845
846Decisiones:
847- **Hue fijo por kind**: Success siempre verde, Error siempre rojo,
848  etc. La lightness se ajusta al theme; el hue se mantiene como
849  invariante semántico cross-theme.
850- **API dual**: `banner` (defaults) + `banner_themed` (theme).
851  Apps sin theme global pueden seguir con la versión simple.
852- **Acentos semánticos del explorer (seed/morphism) NO migran**:
853  pertenecen al dominio del log, no al chrome.
854
855Próximas integraciones pendientes:
856- `MetaApp` (en `yahweh-widget-meta-form`) tiene su propia paleta
857  hardcoded de 6 colors que podría migrarse al theme. Scope mayor
858  que esta iter; queda como candidato.
859- Theme switcher widget (botón/menú en chrome para ciclar themes).
860  Cuando emerja la necesidad real.
861
862### feat(yahweh-widget-card): container card-shape compartido para timeline entries
863Iteración 3 de la integración nakui ↔ yahweh. El "card visual"
864pattern (padding consistente + rounded + flex_col + gap) que vivía
865duplicado en cada timeline entry de `nakui-explorer` ahora es un
866widget yahweh reusable. Sin acoplamiento a colores: el caller
867decide bg/border/accent.
868
869Crate nuevo: `crates/modules/ui_engine/widgets/card/`
870(`yahweh-widget-card`):
871- **Dep**: solo `gpui`. App-agnostic.
872- **`pub fn card() -> Div`**: container con `flex_col` + `px(12)`
873  + `py(8)` + `mb(4)` + `rounded(4)` + `gap(2)`. Sin colores
874  aplicados.
875- El return es `Div` GPUI — el caller compone con `.bg(...)`,
876  `.border_l_4()`, `.border_color(...)`, `.child(...)`, hover,
877  on_click, etc., según necesite.
878- 1 test smoke (constructor no panicea).
879
880Migración de `nakui-explorer`:
881- Nueva dep `yahweh-widget-card`.
882- Los 2 patterns de timeline entry (Seed y Morphism) pasan de:
883  ```rust
884  div().flex().flex_col().px(12).py(8).mb(4).bg(card_bg)
885       .rounded(4).border_l_4().border_color(accent).gap(2)...
886  ```
887  a:
888  ```rust
889  card().bg(card_bg).border_l_4().border_color(accent)...
890  ```
891- Reducción ~7 calls → ~3 por entry; legibilidad mejor (la
892  intención "card with accent" emerge del nombre `card()`).
893
894Tests stack: 111 → **112 verdes** (+1 del crate card). Cada crate
895afectado compila y testea individualmente.
896
897Beneficio operativo:
898- Si `MetaApp` o cualquier futura app necesita un container
899  card-shape (ej. info card, expanded list row), `card()` está
900  ya disponible.
901- Cambiar el padding/rounded/gap canónico = un cambio en un solo
902  lugar.
903- El widget no impone colores → no fuerza una paleta y permite
904  themes diversos por app/contexto.
905
906### feat(yahweh-widget-banner): widget compartido para toasts/errores cross-app
907Patrón visual común a `yahweh-widget-meta-form` (toast success +
908error_banner) y `nakui-explorer` (error_banner): un `div` con bg
909+ text colored según severidad. Antes vivía duplicado con colores
910hardcoded en cada consumer; ahora hay un widget yahweh con presets
911consistentes.
912
913Crate nuevo: `crates/modules/ui_engine/widgets/banner/`
914(`yahweh-widget-banner`):
915- **Dep**: solo `gpui` (sin nakui, sin runtime). Reusable por
916  cualquier app GPUI que necesite tiras de status.
917- **`pub enum Banner`** con 4 variants:
918  - `Info` (azul tenue, mensajes neutros).
919  - `Success` (verde, confirmaciones).
920  - `Warning` (amber, llamadas de atención).
921  - `Error` (rojo, errores fatales).
922- **Métodos `Banner::bg()` y `Banner::fg()`**: paleta hardcoded por
923  variant (sin tema dinámico todavía — cuando emerja, se
924  inyecta vía `yahweh-theme`).
925- **`pub fn banner(kind, message) -> Div`**: constructor que
926  devuelve el div ya con padding/text_size defaults; el caller
927  puede agregar children, override pads/sizes, attach handlers.
928- 2 tests sanity: ningún kind comparte bg, ningún kind comparte fg.
929
930Migración de consumers:
931- **`yahweh-widget-meta-form`**: nueva dep `yahweh-widget-banner`.
932  El `toast_div` (Success) y `error_banner` (Error) en
933  `MetaApp::render` pasan de 2x6 líneas hardcoded a una llamada
934  a `banner(...)` cada uno (~12 líneas → 2).
935- **`nakui-explorer`**: nueva dep. El error banner local pasa a
936  `banner(Banner::Error, e).px(16).py(8).text_size(12)` —
937  preserva el padding/size custom del header del explorer via
938  override builder.
939
940Tests stack: 109 → **111 verdes** (+2 del crate banner).
941
942Beneficio operativo:
943- Si emerge un tercer consumer, importa la dep + 1 llamada.
944- Cambiar la paleta de un kind = un cambio en un solo lugar
945  (ej. ajustar tono del Error o el contraste del Warning).
946- Composición preservada: el `banner()` devuelve un `Div` directo,
947  el caller modifica con builder calls (`.child()`, `.px()`,
948  `.on_click()`, etc.) sin rewrap.
949
950Próximo candidato natural: el `confirm_delete_banner` de MetaApp
951es Banner::Warning + 2 botones embedded. Cuando emerja un segundo
952consumer de modal-style banners, extraer un widget compositivo
953arriba del `Banner` base.
954
955### feat(yahweh): `MockBackend` público + tests E2E del widget con `gpui::TestAppContext`
956Cierra el ciclo de testabilidad del widget metainterfaz. Hasta
957ahora los tests del trait `MetaBackend` vivían como impl privada
958en `backend.rs`; el widget no tenía forma de testear handlers
959reales sin levantar `NakuiBackend` (que depende de event log +
960Rhai + nakui-core). Ahora el mock es público y los tests del widget
961lo consumen con `TestAppContext`.
962
963Cambios en `yahweh-meta-runtime`:
964- **Nuevo módulo `pub mod testing`** con
965  `pub struct MockBackend`. Exporta:
966  - `MockBackend::new()` — vacío.
967  - `MockBackend::with_records(iter)` — pre-poblado con
968    `(entity, uuid, value)` tuples.
969  - `MockBackend::with_morphism(name, |inputs, params| -> Result<usize>)` —
970    builder para registrar handlers callable de morphism (sin
971    handler, `morphism()` rebota con error claro).
972  - Métodos de inspección `total_records()` / `records_for(entity)`
973    (último devuelve `Vec<(Uuid, &Value)>` sin clones).
974  - `impl MetaBackend` completo: seed/load/list/update/delete con
975    semantica documentada.
976- **Tests del trait en `backend.rs` simplificados**: el `MemBackend`
977  duplicado se borra; los tests pasan a usar `MockBackend::new()`
978  importado de `crate::testing`. 8 tests del backend.rs intactos +
979  9 tests propios del mock en `testing.rs`.
980- Bajo `pub mod testing` (no `#[cfg(test)]`) deliberadamente: los
981  crates downstream pueden importarlo en sus dev/integ tests
982  vía `yahweh_meta_runtime::testing::MockBackend`.
983
984Cambios en `yahweh-widget-meta-form`:
985- **Dev-dep nueva**: `gpui = { workspace = true, features = ["test-support"] }`.
986  Habilita `TestAppContext` para tests sin abrir window real.
987- **`MetaApp::apply_action` ahora `pub`** (era privado). Necesario
988  para que los tests E2E lo invoquen desde fuera. La function ya
989  era el entry point de los click handlers internos; exponerla no
990  cambia el contract.
991- **Nuevo archivo `tests/widget_with_mock_backend.rs`** con 4 tests
992  `#[gpui::test]`:
993  - `meta_app_constructs_with_mock_backend_and_initial_state`:
994    instancia `MetaApp<MockBackend>` con records pre-poblados +
995    toast inicial; valida que la window construye sin panic.
996  - `open_view_action_does_not_panic`: invoca
997    `apply_action(OpenView)` real a través de
998    `window.update(cx, |meta, _, cx| ...)` → state machine corre
999    sin crash.
1000  - `backend_state_visible_from_widget_perspective`: demuestra el
1001    patrón "backend pre-poblado para fixtures" (typical para
1002    screenshots / demos).
1003  - `morphism_handler_can_be_registered_and_called_via_widget`:
1004    `MockBackend::with_morphism` registra un counter callback;
1005    `apply_action(Morphism)` lo dispara via `commit_morphism`
1006    sin tocar nakui-core / Rhai.
1007
1008Helpers de tests:
1009- `customers_module()`: fixture local de un `Module` con entity
1010  Customer + view list + view form. Reusable cross-test.
1011
1012Distribución de tests:
1013- `yahweh-meta-runtime`: 47 → **56** (+9 del nuevo testing
1014  module).
1015- `yahweh-widget-meta-form`: 3 → **7** (+4 E2E reales).
1016- Total stack: **109 tests verdes** (56 runtime + 31 cards + 12
1017  nakui-ui + 3 explorer + 7 widget).
1018
1019Beneficio operativo:
1020- El widget tiene cobertura runtime real, no sólo type-check.
1021- Cualquier app que tome `B: MetaBackend` puede testarse con
1022  `MockBackend` en sus dev-deps sin re-implementar el mock.
1023- Fixtures pre-pobladas habilitan demos/screenshots/CI con state
1024  conocido.
1025
1026Limitaciones:
1027- `render()` no se invoca en los tests (requiere window context
1028  más rico). Los tests verifican state machine, no pixels. Pixel
1029  comparison (snapshot tests) es scope futuro si emerge la
1030  necesidad.
1031- `apply_action(Morphism)` con un module que no declara
1032  `nakui_module_dir` rebota antes de llamar al mock handler. El
1033  4to test acepta ambos outcomes (counter 0 o 1) — si en el futuro
1034  agregamos un módulo de fixture con nakui_module_dir poblado, el
1035  test puede aserta exactamente.
1036
1037### feat(yahweh-meta-runtime): promover `short_hash` y `preview_value` desde nakui-explorer
1038Continúa la integración de las apps nakui al stack yahweh. Los
1039helpers visuales que `nakui-explorer` tenía locales y son reusables
1040suben a `yahweh-meta-runtime/format` para que cualquier app pueda
1041consumirlos sin duplicar.
1042
1043Cambios en `yahweh-meta-runtime`:
1044- **`pub fn short_hash(h: &[u8; 32]) -> String`**: hex de los
1045  primeros 4 bytes (8 chars). Útil para mostrar bundle/schema
1046  hashes en UI sin quemar pantalla.
1047- **`pub fn preview_value(v: &Value, max: usize) -> String`**:
1048  JSON one-liner truncado con `...` al final si excede `max`
1049  chars. Edge case: `max < 3` devuelve los primeros `max` chars
1050  sin sufijo.
1051- Re-exports en lib.
1052- 5 tests nuevos: 4 tests + 1 sanity para el caso `max < ellipsis`.
1053
1054Migración de `nakui-explorer`:
1055- Nueva dep `yahweh-meta-runtime` en Cargo.toml.
1056- Borrado helpers locales `short_uuid`, `short_hash`,
1057  `preview_value` (~30 líneas).
1058- `use yahweh_meta_runtime::{preview_value, short_hash, short_uuid}`.
1059- Borrados 4 tests duplicados (los runtime los testea).
1060
1061Tests:
1062- `yahweh-meta-runtime`: 42 → **47** (+5 helpers nuevos).
1063- `nakui-explorer`: 7 → **3** (–4 duplicados; quedan los 3
1064  específicos: load_log, breakdown, missing_file).
1065- Resto del workspace intacto.
1066
1067Beneficio operativo: 3 helpers visuales centralizados. Cualquier
1068app nueva que muestre UUIDs/hashes/JSON-previews los importa sin
1069re-implementar la heurística de truncamiento.
1070
1071Pendiente arquitectural: el render del card timeline en
1072`nakui-explorer` (border-l-4 colored + flex_col + texto en niveles)
1073es un pattern reusable que también aparece en `yahweh-widget-meta-form`
1074(render_list filas). Cuando aparezca un tercer consumer de ese
1075pattern se extrae a un widget yahweh.
1076
1077### feat(brahman-cards): templates Nickel canónicos para cada body kind
1078Materializa el patrón "import + override" del brazo: hasta ahora
1079`BRAHMAN_CARDS_TEMPLATES_DIR` existía como mecanismo pero el repo
1080no shippeaba ningún template. Ahora hay 3 templates basic (uno
1081por body kind del CardBody) bajo
1082`crates/core/brahman-cards/templates/`:
1083
1084- **`ente_basic.ncl`** — Card runtime mínima: `payload="Virtual"`,
1085  `supervision="OneShot"`, `schema_version=1`. Override típico:
1086  `id` + `label`.
1087- **`monad_basic.ncl`** — agrupación semántica de archivos
1088  (Mónada Nouser): metadata vacía, `dominant_lens="grid"` (lowercase
1089  por convención serde rename_all). Override típico: `id`, `label`,
1090  `members`, `cardinality`.
1091- **`ui_module_basic.ncl`** — descriptor UI con `entities=[]`,
1092  `menu=[]`, `views={}`. Override típico: `id`, `label` y los
1093  3 payloads.
1094
1095Cada field override-able marcada `| default` (sin eso Nickel
1096rebota merge de strings/numbers no-iguales).
1097
1098API nueva en `lib.rs`:
1099- **`pub fn canonical_templates_dir() -> PathBuf`**: devuelve el
1100  directorio de templates del crate (resuelto via
1101  `CARGO_MANIFEST_DIR`). Útil para apuntar el env
1102  `BRAHMAN_CARDS_TEMPLATES_DIR` en runtime/tests sin hardcoding
1103  del path.
1104- Doc explica que para distribución del binary standalone (cuando
1105  emerja), incluir templates como recursos via `include_dir!` o
1106  instalar el directorio junto al ejecutable.
1107
11085 tests E2E (`tests/templates.rs`) que cubren:
1109- `ente_basic` import + override `id`+`label` → Card body Ente
1110  con `payload=Virtual` (default preserved).
1111- `monad_basic` import + override `id`+`label`+`cardinality` →
1112  Card body Monad con members=[] y summary="" (defaults).
1113- `ui_module_basic` import + override de `id`+`label`+menu+views
1114  → Card body UiModule con entities=[] (default).
1115- Sanity: import sin override → defaults `"TEMPLATE_ID"` /
1116  `"TEMPLATE_LABEL"` pasan al wrapper sin error.
1117- Sanity: el path de `canonical_templates_dir()` apunta a un
1118  directorio existente con los 3 archivos esperados.
1119
1120Helper de test `with_canonical_templates(F)` setea/restaura el
1121env localmente; cada test single-thread-safe.
1122
1123Tests suite brahman-cards: 26 → **31** verdes (+5). El resto del
1124workspace intacto.
1125
1126Beneficio operativo:
1127- Un usuario que quiera declarar un Card nuevo puede empezar con
1128  un override de 2 líneas (`id` + `label`) en lugar de copiar el
1129  shape full desde cero.
1130- Templates auto-documentan la convención `| default` para que
1131  copiar uno y agregar fields propios "just works" en merge.
1132- El brazo sigue siendo agnostic — los templates son sólo
1133  archivos `.ncl` resueltos via el import resolver Nickel; nada
1134  hardcoded en código Rust.
1135
1136Limitaciones:
1137- No hay templates "ricos" tipo `crud_basic.ncl` que parametricen
1138  por entity name. Nickel no expone funciones-templates de la
1139  forma típica de templating engines; lo más cercano sería un
1140  template con un field `entity_name | String` y references
1141  internas via `me.entity_name`. Cuando aparezca el caso de uso
1142  real (e.g., un módulo donde el patrón list+form es repetitivo),
1143  se diseña el template paramétrico.
1144- `canonical_templates_dir()` resuelve via `CARGO_MANIFEST_DIR` —
1145  funciona en `cargo` (test/run/build) pero no para un binary
1146  instalado fuera del workspace. Para release distribution la API
1147  necesitará un fallback (resources embedded o convención de
1148  install path).
1149
1150### refactor(nakui-core): KCL → Nickel — `kcl_wrapper` reemplazado por evaluación in-process
1151Cierra el ciclo: el motor de validación de entities deja de
1152shellear el binario externo `kcl` y pasa a evaluar **Nickel
1153contracts** in-process via la dep `nickel-lang` (la misma que ya
1154usa `brahman-cards` para sus templates). Los 3 schemas de los
1155módulos sales/inventory/treasury migran de `.k` a `.ncl`.
1156Además se borran los 2 archivos `.k` doc-only del repo
1157(`ente-card/schema/card.k`, `ente-brain/schema/rule.k` — ambos
1158estaban marcados "REFERENCE ONLY. NOT LOADED").
1159
1160Cambios en **nakui-core**:
1161- **Nueva dep**: `nickel-lang = "2.0.0"` (interfaz estable).
1162- **Borrado** `kcl_wrapper.rs` (43 líneas) — shellear el binario
1163  desaparece.
1164- **Nuevo** `nickel_validator.rs`:
1165  - `pub fn vet(schema_path, state, schema_name) -> Result<(), NickelError>`
1166    evalúa `let bundle = (import "<schema>") in
1167    (std.deserialize 'Json m%%"<json>"%%) | bundle.<entity>`.
1168  - El state JSON va dentro de un raw string Nickel
1169    (`m%%"..."%%`) y se deserialize via `std.deserialize 'Json`.
1170    No embebemos el state como record literal Nickel directo
1171    porque la sintaxis JSON usa `:` (Nickel records usan `=`).
1172  - 5 tests propios cubriendo happy path + 4 fallure modes
1173    (field missing, predicate fails, cross-field invariant
1174    fails, optional field present/absent).
1175- **`executor.rs`**:
1176  - `kcl_wrapper::vet` → `nickel_validator::vet`.
1177  - `KclError` → `NickelError`.
1178  - `ExecError::KclPre/KclPost/KclPostCreate` → `SchemaPre/Post/PostCreate`
1179    (más neutro, ya no menciona KCL).
1180  - `kcl_check` (privado) → `validate_entity`.
1181  - `build_schema_bundle` ahora emite un archivo Nickel con
1182    `(import "X") & (import "Y") & ...` en lugar de concatenar
1183    bytes (cada `.ncl` es una expresión record completa, no
1184    juntable como texto plano).
1185- **`manifest.rs`**:
1186  - `effective_schemas` default `"schema.k"` → `"schema.ncl"`.
1187  - `extract_schema_names` reescrito: ahora detecta keys
1188    CapitalCase con 2 spaces de indent (convención de los
1189    `schema.ncl`), no más patrón `schema X:` de KCL.
1190  - Tests del extractor actualizados (1 test reemplazado por 2:
1191    `_handles_nickel_record_top_level` + `_skips_let_bindings_and_lowercase`).
1192
1193Cambios en **schemas de módulos**:
1194- **`sales/schema.ncl`**: contracts Nickel para `Venta`. Usa
1195  `std.contract.Sequence [record_contract, from_predicate]`
1196  para combinar shape + invariante cross-field
1197  (`total == cantidad * precio_unitario`). El patrón directo
1198  `record | from_predicate` rebota con "missing definition" porque
1199  el predicate evalúa el contract antes de que el value lo
1200  populate; documentado en el comment.
1201- **`inventory/schema.ncl`**: `Stock`, `MovimientoStock`,
1202  `TransferenciaStock` (esta última con cross-field
1203  `source != dest` via Sequence).
1204- **`treasury/schema.ncl`**: `Caja`, `Movimiento`,
1205  `Transferencia` (con cross-field via Sequence).
1206- Helpers locales en cada archivo: `positive_int`,
1207  `non_negative_int`, `currency_iso`, etc. via
1208  `std.contract.from_predicate`.
1209- Los 3 `schema.k` viejos **borrados**.
1210- `sales/nsmc.json` actualizado: paths `schema.k` →
1211  `schema.ncl`.
1212
1213Cambios en **tests**:
1214- `sales.rs`, `inventory.rs`: `KclPost` → `SchemaPost`.
1215- `kernel_guards.rs`: `KclPostCreate` → `SchemaPostCreate`,
1216  path del schema directo `treasury/schema.k` →
1217  `treasury/schema.ncl`.
1218- `graph.rs`, `manifest_validation.rs`: tests que escriben
1219  `schema.k` inline cambian a `schema.ncl` con sintaxis Nickel.
1220- `schema_versioning.rs`: refs `schema.k` → `schema.ncl`.
1221
1222Cambios documentales:
1223- **Borrado** `crates/core/ente-card/schema/card.k` (1 archivo,
1224  REFERENCE ONLY documentado en su header).
1225- **Borrado** `crates/core/ente-brain/schema/rule.k` (REFERENCE
1226  ONLY documentado en su header).
1227
1228Tests:
1229- **nakui-core**: 84 tests verdes (41 unit + 43 integration en
1230  graph/event_log/manifest_validation/schema_versioning/
1231  inventory/sales/kernel_guards). Suite full pasa.
1232- **nakui-ui**, **brahman-cards**, **yahweh-***: sin cambios,
1233  todos verdes.
1234- Total cubriendo el área: 174 tests.
1235
1236Beneficios:
1237- **Sin dep externa**: el binario `kcl` ya no es requisito de
1238  runtime ni de tests. Build limpio en CI sin instalar KCL.
1239- **Errores en línea**: Nickel reporta contract violations con
1240  caret pointing al field exacto del schema y el value que
1241  falló. KCL daba mensajes textuales menos navegables.
1242- **Mismo motor que el brazo de cards**: una sola dependencia
1243  Nickel para todo el repo (validación + templates de cards).
1244- **Sin tempfile JSON intermedio**: el state se evalúa
1245  directamente en memoria; no hay `std::fs::write` por cada
1246  validate.
1247
1248Limitaciones / decisiones:
1249- El comentario "REFERENCE ONLY" de los `.k` borrados ya estaba
1250  marcado en sus headers; eran sólo notas de diseño para humanos.
1251  La autoridad real (Rust validate methods) sigue intacta.
1252- La sintaxis Nickel `record_contract | from_predicate` no
1253  funciona — hay que envolver en `std.contract.Sequence [record,
1254  from_predicate]`. Documentado en cada schema y en el doc del
1255  validator.
1256
1257**Pendientes restantes**: ninguno del refactor original. Los
1258yahweh + KCL + card.k cierran. Próximos pendientes salen de
1259nuevo trabajo (no del plan que arrastrábamos).
1260
1261### refactor(yahweh): Fase 2c — extracción del widget al crate `yahweh-widget-meta-form`
1262Cierra el refactor de UI: el widget render (forms, lists, modal de
1263delete, EntityRef selector, sidebar, key handlers) deja de vivir en
1264el binario nakui-ui y pasa a un crate yahweh nuevo, genérico sobre
1265`MetaBackend`. nakui-ui queda como un shell de bootstrap de 424
1266líneas.
1267
1268Crate nuevo: `crates/modules/ui_engine/widgets/meta-form/`
1269(`yahweh-widget-meta-form`):
1270- **Deps**: gpui, yahweh-meta-schema, yahweh-meta-runtime, yahweh-theme,
1271  yahweh-widget-text-input, serde_json, uuid. **Cero deps a nakui** o
1272  brahman-cards — reusable por cualquier app.
1273- **`MetaApp<B: MetaBackend>`** público: estructura genérica con
1274  `modules`, `backend: B`, `active`, `form_inputs`, `editing`,
1275  `pending_delete`, `toast`, `load_error`. El bound `B: MetaBackend`
1276  se propaga a todos los `impl MetaApp<B>` y al `impl Render for
1277  MetaApp<B>`.
1278- **`MetaApp::new(modules, backend, initial_toast, initial_error, cx)`**:
1279  constructor sin lógica de bootstrap. El caller pre-construye
1280  modules + backend + cualquier mensaje inicial. La active view
1281  default es la primera entry del menú del primer módulo.
1282- **Methods preservados** del original (rename simbólico): select_view,
1283  open_edit, commit_seed, commit_morphism, commit_delete, apply_action,
1284  list_rows, render_*, tick interno via WriteOutcome.post_status.
1285- **Helpers locales del widget**: `lookup_field` (path walker JSON
1286  por la lista renderer), `append_compact_msg` (concatenador del
1287  toast), `format_seed_toast` (decide "creado/actualizado/sin cambios"
1288  según `WriteOutcome`).
1289- **3 tests funcionales puros**: `lookup_field`, `append_compact_msg`,
1290  `format_seed_toast`. Tests con GPUI cx no son posibles sin un
1291  TestAppContext setup; quedan implícitos vía type-check del trait
1292  bound.
1293
1294Cambios en `nakui-ui` (shell):
1295- **main.rs**: 1959 → **424** líneas (78% reducción). Ahora sólo:
1296  1. Carga modules via `brahman_cards::load_cards_from_dir` +
1297     `load_ui_modules` (filtra UiModule body, valida, dedup).
1298  2. Carga executors para módulos con `nakui_module_dir`.
1299  3. `NakuiBackend::open(...)` para inicializar el backend.
1300  4. `cx.open_window(...)` con `MetaApp::<NakuiBackend>::new(...)`
1301     como root view.
1302- **`use yahweh_widget_meta_form::MetaApp`** + dep nueva en
1303  Cargo.toml. Los imports de yahweh-meta-runtime/schema desaparecen
1304  de main (los consume el widget internamente).
1305- **Tests del shell**: 4 tests E2E que tocan nakui-core directamente
1306  (event_log_replay, morphism_pipeline_real_sales_vender,
1307  load_ui_modules x3). Los tests del NakuiBackend impl quedan en
1308  `backend.rs` (8 tests). Los tests del widget viven en su propio
1309  crate.
1310- **`backend.rs`**: sin cambios (NakuiBackend ya estaba aislado en
1311  Fase 2b).
1312
1313Distribución final del refactor yahweh:
1314- `yahweh-meta-schema`: 8 tests (data puro).
1315- `yahweh-meta-runtime`: 42 tests (helpers + trait MetaBackend).
1316- `yahweh-widget-meta-form`: 3 tests (widget genérico).
1317- `brahman-cards`: 26 tests (loader unificado).
1318- `nakui-ui`: 12 tests (4 shell + 8 backend impl).
1319- **Total: 91 tests** cubriendo el área.
1320
1321Cada crate compila individualmente. El widget consume el trait sin
1322saber qué backend hay debajo; `nakui-ui` provee el trait wireado a
1323nakui-core; cualquier futuro shell (mock para tests, otro stack de
1324storage) puede reusar el widget sin cambio.
1325
1326Lo que NO hace Fase 2c:
1327- No mueve `format_seed_toast`/`append_compact_msg`/`lookup_field`
1328  a `yahweh-meta-runtime`. Son lo bastante widget-flavored
1329  (`SharedString` de gpui, decisiones de UX del toast, etc.) que
1330  preferí dejarlos al lado del render.
1331- No introduce un `MetaApp::with_status` builder pattern. La
1332  signature de `new` con 5 args es manejable; si crece, se refactor
1333  después.
1334- No expone configuración del widget (theme override, layout
1335  custom, etc.). Cuando emerja una segunda app que use el widget
1336  con preferencias distintas, se agregan opts.
1337
1338**Pendientes**:
13391. **KCL → Nickel**: kcl_wrapper en nakui-core reemplazado por
1340   evaluación de Nickel contracts. Migrar los 3 schemas .k de
1341   sales/inventory/treasury a .ncl.
13422. **`card.k` eliminado** (REFERENCE ONLY documentado en su header).
1343
1344### refactor(yahweh): Fase 2b — `MetaBackend` trait + `NakuiBackend` + MetaUi consume el backend
1345Materialización del trait que diseñamos en charla. Tres pasos
1346combinados en un solo commit:
1347
1348**Step A** — trait + WriteOutcome en `yahweh-meta-runtime`:
1349- Nuevo módulo `backend.rs` con:
1350  - `pub trait MetaBackend: 'static` con 6 métodos:
1351    `list_records`, `load_record`, `seed`, `update`, `delete`,
1352    `morphism`. Convención de ids como `Uuid` canónico (los
1353    backends que internamente usan otros tipos mapean), `set+clear`
1354    pre-computados por el caller (no double-roundtrip al store),
1355    threshold `'static` sin Send/Sync (suficiente para handlers
1356    GPUI single-threaded).
1357  - `pub struct WriteOutcome { id, changed, post_status }` con
1358    constructor `no_change(id)`. La UI usa `changed = 0` para
1359    "sin cambios", `post_status` para concatenar mensajes
1360    auto-emitidos por el backend (compact, etc.).
1361- 9 tests con un `MemBackend` mínimo (HashMap por
1362  `(entity, uuid)`): seed/load round-trip, list/filter/order,
1363  update set/clear/no-op, delete/missing, object-safety check.
1364
1365**Step B** — `NakuiBackend` en `nakui-ui/src/backend.rs`:
1366- Estructura que ownea `Arc<Mutex<MemoryStore>>`,
1367  `Option<Arc<Mutex<EventLog>>>`, `BTreeMap<id, Arc<Executor>>`,
1368  `snap_path`, `snapshot_threshold`, `writes_since_compact`.
1369- `NakuiBackend::open(log_path, threshold, executors) -> (Self, OpenStatus)`:
1370  abre log, carga snapshot, replay, auto-compact si threshold
1371  cruzado; devuelve `OpenStatus { init_toast, load_error }` para
1372  que el caller agregue al banner.
1373- `tick_compact()` privado que cada write public method invoca
1374  tras éxito; devuelve `Option<String>` que se mete en
1375  `WriteOutcome.post_status`.
1376- `impl MetaBackend for NakuiBackend`:
1377  - `seed`: WAL order (log first, store after), `tick_compact`,
1378    devuelve `WriteOutcome { id: Some(uuid), changed: 1, post_status }`.
1379  - `update`: si `set+clear` vacíos devuelve `WriteOutcome::no_change`;
1380    si no construye `FieldOp::Set`+`FieldOp::Clear`, log Morphism
1381    `ui.edit_record` con `params.fields/cleared`, store.apply, tick.
1382  - `delete`: `FieldOp::Delete`, log Morphism `ui.delete_record`,
1383    store.apply, tick.
1384  - `morphism`: locks log + store, `execute_and_log_with_recovery`,
1385    tick. `WriteOutcome { id: None, changed: ops.len(), post_status }`.
1386- Funciones `snapshot_path_for` y `maybe_compact_log` movidas acá
1387  desde main.rs (ahora son detalle del backend).
1388- 7 tests del impl: round-trip via trait, set+clear, no-op edit
1389  no escribe, delete/load, list_records, morphism sin executor da
1390  error claro, threshold dispara snapshot.
1391
1392**Step C** — `MetaUi` consume el backend:
1393- Reemplaza fields `store` / `event_log` / `executors` /
1394  `snap_path` / `snapshot_threshold` / `writes_since_compact`
1395  por un único `backend: NakuiBackend`.
1396- `MetaUi::new` colapsa el wiring de persistencia en
1397  `NakuiBackend::open(...)` — pasó de ~150 líneas a ~10 líneas.
1398- `commit_seed` ya no construye `LogEntry`/`FieldOp` directos:
1399  - SEED → `self.backend.seed(entity, obj)`.
1400  - EDIT → `self.backend.load_record + compute_field_delta +
1401    compute_clear_fields → self.backend.update(set, clear)`.
1402  - Devuelve `WriteOutcome` (reemplaza el viejo enum `CommitOutcome`).
1403- `commit_morphism` parsea inputs/params del form y delega a
1404  `self.backend.morphism(...)`.
1405- `commit_delete` es one-liner: `self.backend.delete(entity, id)`.
1406- `tick_runtime_compact` eliminado (ahora interno al backend; el
1407  msg viaja en `WriteOutcome.post_status`).
1408- `list_rows` queda como proxy `self.backend.list_records(entity)`.
1409- `validate_entity_refs` callsite usa cierre sobre
1410  `backend.load_record` (en vez de `&Store`).
1411- Nuevo helper `format_seed_toast(entity, was_editing, &outcome)`
1412  reemplaza el match sobre `CommitOutcome`.
1413- Imports limpiados: no más `nakui_core::delta::FieldOp`/`FieldPath`,
1414  no más `nakui_core::event_log::*` en main.rs (sólo en tests E2E).
1415  No más `Arc/Mutex` (vive en backend).
1416
1417Distribución de tests post-refactor:
1418- `yahweh-meta-runtime`: 33 → **42** (+9 trait tests con MemBackend).
1419- `nakui-ui`: 14 → **21** (+7 tests del NakuiBackend impl).
1420- `yahweh-meta-schema`: 8 (sin cambio).
1421- `brahman-cards`: 26 (sin cambio).
1422- Total: **97**.
1423
1424Build: cada crate compila individualmente.
1425
1426Nota sobre Fase 2b/c estado:
1427- ✅ Backend trait + impl + MetaUi usa backend.
1428- ⏭ Falta extraer los **widgets render** (form/list/modal/EntityRef
1429  selector) de nakui-ui a un crate yahweh nuevo
1430  (sugerencia: `yahweh-widget-meta-form`). Esa extracción ahora es
1431  trivial: el render code ya consume sólo `&self.modules` +
1432  `self.backend` (vía trait). Lo dejo para próximo commit.
1433
1434**Pendientes**:
14351. **Fase 2c**: extraer widget render al crate yahweh
1436   (`yahweh-widget-meta-form` o similar) — `MetaApp<B: MetaBackend>`
1437   genérico, `nakui-ui` queda como ~50 líneas de shell con
1438   `MetaApp::<NakuiBackend>::new(...)`.
14392. **KCL → Nickel**: kcl_wrapper reemplazado por evaluación de
1440   Nickel contracts.
14413. **`card.k` eliminado** (REFERENCE ONLY).
1442
1443### refactor(yahweh): Fase 2 — extraer helpers puros a `yahweh-meta-runtime`
1444Sigue de la Fase 1 (lift del schema a yahweh). Ahora extraemos los
1445**helpers puros** que cualquier widget renderer o backend ejecutor
1446necesita sobre el schema: parse, delta, validation, format. Sin
1447GPUI, sin acoplamiento a un backend específico.
1448
1449Crate nuevo: `crates/modules/ui_engine/libs/meta-runtime/`
1450(`yahweh-meta-runtime`):
1451- **Deps**: `serde_json`, `thiserror`, `uuid`, `yahweh-meta-schema`.
1452  NO GPUI, NO nakui.
1453- **Módulos**:
1454  - `parse.rs` — `parse_field_value(kind, raw)`,
1455    `infer_param_value(raw)`, `resolve_param_value(name, raw, spec)`.
1456  - `delta.rs` — `compute_field_delta(current, proposed)`,
1457    `compute_clear_fields(current, to_clear)`.
1458  - `refs.rs` — `validate_entity_refs(load: F, refs)` donde `F`
1459    es un cierre `Fn(&str, Uuid) -> Option<Value>`. Decoupling vía
1460    closure en lugar de trait — evita atar el crate a cualquier
1461    backend específico (no hay `Store` trait acá), y los callers
1462    pasan `|e, id| store.load(e, id)` trivialmente.
1463  - `format.rs` — `human_label_for_record(value, id)`,
1464    `render_value(opt_value)`, `value_to_input_text(value)`,
1465    `short_uuid(id)`.
1466- **33 tests propios** en el crate nuevo (cubren todos los helpers
1467  movidos + edge cases).
1468
1469Cambios en `nakui-ui`:
1470- **Nueva dep** `yahweh-meta-runtime` en `Cargo.toml`.
1471- **Imports**: agrega `use yahweh_meta_runtime::{...}` con todos los
1472  helpers extraídos. Borrado el código local equivalente
1473  (~200 líneas).
1474- **`validate_entity_refs` callsite**: pasa de
1475  `validate_entity_refs(&*store, &refs)` a
1476  `validate_entity_refs(|e, id| store.load(e, id), &refs)` — el
1477  closure es ergonómico sobre cualquier `Store`.
1478- **Tests duplicados borrados** (~34 tests que ahora viven en
1479  `yahweh-meta-runtime`):
1480  - `parse_field_*` (text/number/boolean variants)
1481  - `infer_param_value_*`
1482  - `delta_*` (5 tests)
1483  - `clear_fields_*` (3 tests)
1484  - `validate_entity_refs_*` (5 tests)
1485  - `resolve_param_*` (6 tests)
1486  - `parse_field_entity_ref_*` (4 tests)
1487  - `human_label_*` (3 tests), `render_value_*`,
1488    `value_to_input_text_inverse_of_parse`
1489- **Tests que se quedan en nakui-ui** (runtime-específicos):
1490  - `lookup_field_simple_and_nested` — helper local del list renderer.
1491  - `append_compact_msg_handles_both_branches`,
1492    `runtime_compact_cycle_resets_counter_after_threshold`,
1493    `snapshot_path_for_replaces_extension`,
1494    `maybe_compact_log_*` (3) — wiring de persistencia a EventLog.
1495  - `load_ui_modules_via_brahman_cards_*` (3) — integración con el
1496    brazo de cards.
1497  - `value_to_input_then_parse_round_trip` — round-trip del par
1498    `value_to_input_text + parse_field_value` (toca ambos lados).
1499  - `event_log_replay_restores_memory_store`,
1500    `morphism_pipeline_executes_real_sales_vender`,
1501    `event_log_replay_handles_full_crud_cycle` — E2E nakui-core.
1502
1503Distribución de tests:
1504- `nakui-ui`: 48 → 14 (los 34 movidos viven en runtime).
1505- `yahweh-meta-runtime`: 33 (nuevos).
1506- `yahweh-meta-schema`: 8 (sin cambio).
1507- `brahman-cards`: 26 (sin cambio).
1508- Total cubriendo el área: 81.
1509
1510Build: cada crate afectado compila y testea limpio individualmente.
1511Workspace build full no se completó esta corrida por OOM al
1512compilar `surrealdb-core` (problema ambiental no relacionado al
1513refactor).
1514
1515Lo que NO hace Fase 2:
1516- No mueve los widgets render (`render_form`/`render_list`/
1517  `render_entity_ref_selector`/`render_confirm_delete_banner`) a
1518  yahweh — eso es Fase 2b/3, requiere diseñar el `MetaBackend`
1519  trait porque las render functions tocan el state de `MetaUi`
1520  (form_inputs, pending_delete, executors).
1521
1522**Pendientes** (orden):
15231. **Fase 2b**: extraer widget render a un crate yahweh nuevo
1524   (sugerencia: `yahweh-widget-meta-form`). Requiere diseñar
1525   `MetaBackend` trait.
15262. **Fase 3**: thin shell — `nakui-ui` queda reducido a una impl
1527   de backend wireada a `nakui-core`.
15283. **KCL → Nickel** + **card.k eliminado**.
1529
1530### refactor(yahweh): Fase 1 — `nakui-ui-schema` → `yahweh-meta-schema`
1531Primer paso del refactor yahweh. El schema de UI declarativa
1532(entities, menús, listas, formularios, acciones) vivía bajo
1533`crates/modules/nakui/ui-schema/` y se llamaba `nakui-ui-schema` —
1534un nombre que sugería acoplamiento con Nakui que en realidad no
1535existe (el crate sólo depende de `serde`/`serde_json`/`thiserror`).
1536Lo movemos a yahweh para que sea consumible por cualquier app de UI
1537metadata-driven sin hacer pasar la dep "rara" por nakui.
1538
1539Cambios mecánicos:
1540- **`git mv`**: `crates/modules/nakui/ui-schema/` →
1541  `crates/modules/ui_engine/libs/meta-schema/`.
1542- **Cargo.toml del crate movido**:
1543  - `name = "nakui-ui-schema"` → `name = "yahweh-meta-schema"`.
1544  - Description actualizada: "Yahweh — meta-schema: descriptores
1545    declarativos de UI ... independiente del backend".
1546- **Workspace `Cargo.toml`**: la entry del members[] pasa de
1547  `crates/modules/nakui/ui-schema` a
1548  `crates/modules/ui_engine/libs/meta-schema` (en su sección
1549  yahweh, no en la sección nakui).
1550- **`brahman-cards`**:
1551  - Cargo.toml: dep path/name a `yahweh-meta-schema`.
1552  - lib.rs: `pub use nakui_ui_schema::Module` →
1553    `pub use yahweh_meta_schema::Module`.
1554  - readers.rs: comment + doc-link al nuevo nombre.
1555- **`nakui-ui`**:
1556  - Cargo.toml: dep path/name a `yahweh-meta-schema`.
1557  - main.rs: `use nakui_ui_schema::{...}` →
1558    `use yahweh_meta_schema::{...}`.
1559- **Self-test del crate movido**
1560  (`tests/example_modules.rs`): `nakui_ui_schema` → `yahweh_meta_schema`,
1561  y se rebasa el path del repo root (5 niveles arriba ahora, era 4).
1562
1563Cambios documentales:
1564- **Doc de crate** (`lib.rs`): "Schema declarativo de la metainterfaz
1565  Nakui" → "Schema declarativo de la metainterfaz (yahweh
1566  meta-schema)" + "backend-agnostic" en la filosofía. La sección
1567  Persistencia universal pasa de "el runtime conecta cada vista al
1568  `nakui_core::store::Store`" a un wording neutro: "el runtime que
1569  consume este schema conecta vistas a su backend".
1570- **Doc del field `Module.nakui_module_dir`**: ahora marcado como
1571  "path opaco al backend, lo interpreta el runtime concreto". Se
1572  describe la convención actual de Nakui (nsmc.json + KCL + Rhai)
1573  como ejemplo, no como contrato del schema. El nombre del campo
1574  se mantiene por compat con módulos ya escritos; agregado
1575  `#[serde(alias = "backend_module_dir")]` para que un futuro
1576  rename no rompa los actuales.
1577
1578Tests:
1579- yahweh-meta-schema (crate movido): 13 tests propios siguen
1580  verdes tras el path rebase.
1581- brahman-cards: 26/26 verdes (17 integration + 9 nickel).
1582- nakui-ui: 48/48 verdes.
1583- Workspace build verde.
1584
1585Lo que NO hace Fase 1:
1586- No mueve los widgets de UI (form/list/modal/EntityRef selector)
1587  a yahweh — eso es Fase 2.
1588- No introduce un trait `MetaBackend` para desacoplar la lógica
1589  de runtime de Nakui — eso es Fase 3.
1590- No renombra el field `nakui_module_dir`. Se hará cuando aparezca
1591  un segundo backend que también lo necesite.
1592
1593**Pendientes** (orden):
15941. **Fase 2**: extraer widgets render (form/list/modal/EntityRef
1595   selector + helpers parse_field_value/render_value/etc.) a un
1596   nuevo crate `yahweh-widget-meta-form` (o nombre similar).
15972. **Fase 3**: trait `MetaBackend` + thin shell — `nakui-ui` queda
1598   reducido a una impl de backend wireada a `nakui-core`.
15993. **KCL → Nickel**: kcl_wrapper reemplazado por evaluación de
1600   Nickel contracts.
16014. **card.k eliminado** (REFERENCE ONLY).
1602
1603### feat(nakui-ui): migrar consumer al brazo unificado `brahman_cards::load_cards_from_dir`
1604Primera consumer migration del brazo. `nakui-ui` ya no llama a
1605`nakui_ui_schema::load_modules_from_dir` directamente — pasa por
1606`brahman_cards::load_cards_from_dir` y extrae el variant `UiModule`
1607del `CardBody` de cada Card. Beneficios concretos:
1608
1609- **Soporta `.ncl` además de `.json`**: el usuario puede dropear un
1610  `card.ncl` (con templates Nickel + merge) en cualquier subdir y
1611  el runtime lo levanta automáticamente. El layout legacy
1612  `examples/nakui-modules/<id>/module.json` sigue funcionando vía
1613  los filenames default `[card.ncl, card.json, module.ncl, module.json]`.
1614- **Cards de otros body kinds (Ente/Monad) se skipean limpio**:
1615  si el dir contiene Cards no-UiModule, se reportan en un toast
1616  informativo en lugar de fallar la carga.
1617
1618Cambios en `brahman-cards`:
1619- **Nuevo `load_cards_from_dir(dir)`** + variante con readers/filenames
1620  custom. Walkea subdirs (orden lexicográfico), busca el primero de
1621  `DEFAULT_CARD_FILENAMES`, dispatcha al reader. Subdirs sin ningún
1622  filename matching se skipean silenciosamente (permite assets/fixtures
1623  sueltos al lado de los cards). Errores per-file se propagan loud
1624  (sin ocultar corrupción).
1625- **`pub const DEFAULT_CARD_FILENAMES`**: lista canónica probada en
1626  orden. `card.ncl` tiene prioridad sobre `card.json` y sobre los
1627  legacy `module.*`.
1628- **4 tests nuevos del helper**: walk + skip de subdirs sin
1629  card, prioridad ncl > json, propagación loud de errores per-file,
1630  custom filenames.
1631
1632Cambios en `nakui-ui`:
1633- **Nueva dep** `brahman-cards` en `Cargo.toml`.
1634- **Nuevo helper `load_ui_modules(dir) -> (Vec<Module>, Vec<String>)`**
1635  que envuelve `brahman_cards::load_cards_from_dir`, filtra a
1636  UiModule body, valida cada Module con su `validate()`, ordena
1637  por id, y detecta duplicados. El callsite en `MetaUi::new` pasa
1638  a usarlo y al ver Cards skipped emite un toast informativo.
1639- **3 tests nuevos**:
1640  - `load_ui_modules_via_brahman_cards_returns_ui_modules_and_skips_others`
1641    — verifica que un dir con UiModule + Ente carga el primero y
1642    reporta el segundo en `skipped`.
1643  - `load_ui_modules_via_brahman_cards_rejects_invalid_module` —
1644    `Module::validate()` se sigue aplicando (menu apuntando a view
1645    inexistente rebota).
1646  - `load_ui_modules_detects_duplicate_id` — dos UiModule con
1647    mismo id rebotan con mensaje claro.
1648
1649Tests totales:
1650- `brahman-cards`: 22 → 26 (+4 helper directorio).
1651- `nakui-ui`: 45 → 48 (+3 e2e migración).
1652- Workspace build verde.
1653
1654Lo que NO cambió:
1655- `nakui_ui_schema::load_modules_from_dir` se mantiene intacto (sus
1656  propios tests lo siguen usando, y otros consumers futuros podrían
1657  preferir su error-typing más específico). La migración es opt-in:
1658  `nakui-ui` usa el brazo, ui-schema sigue siendo una API válida.
1659- Layout actual de `examples/nakui-modules/<id>/module.json` no
1660  requiere cambio. Un usuario puede convertir cualquier módulo a
1661  `card.ncl` sin tocar el dir layout.
1662
1663**Pendientes para próximos commits** (orden):
16641. **Yahweh refactor**: lift del MetaUi runtime a
1665   `crates/modules/ui_engine/` para reuso. El brazo + canónico ya
1666   estables, ahora puede extraerse el meta-form widget genérico.
16672. **KCL → Nickel**: kcl_wrapper reemplazado por Nickel contracts;
1668   los 3 schemas .k de nakui modules pasan a .ncl.
16693. **card.k eliminado** (es REFERENCE ONLY documentado).
1670
1671### feat(brahman-cards): Nickel reader + templates con merge nativo (V2)
1672Sigue al V1 (readers JSON). Ahora el brazo acepta inputs `.ncl`:
1673los evalúa via `nickel-lang` 2.0, exporta a JSON, y dispatcha por
1674los mismos readers JSON estándar. Un `.ncl` puede producir
1675cualquier `CardBody` siempre que su shape sea reconocida. Los
1676templates funcionan con los `import` + `&` merge nativos de
1677Nickel — el brazo no inventa una mecánica paralela.
1678
1679Cambios:
1680- **Dep `nickel-lang = "2.0.0"`** (interfaz estable, no
1681  `nickel-lang-core` que es internal/inestable). Compila clean
1682  pero suma ~1 min al build cold del crate.
1683- **Nuevo módulo `nickel_eval.rs`** con `eval_nickel_file(path) ->
1684  Result<Value, NickelEvalError>`. Errores tipados:
1685  `Io`, `Eval`, `Export`, `JsonReparse` — el mensaje de Nickel se
1686  formatea como texto plano (sin ANSI) para que sea legible en
1687  logs y toasts.
1688- **`load_card_with` añade `"ncl"`**: lee archivo → eval Nickel →
1689  exporta a JSON → parsea de vuelta a Value → dispatch a los
1690  readers JSON. Pipeline simétrico a `"json"`.
1691- **`CardLoadError::Nickel(NickelEvalError)`**: el error de
1692  Nickel se propaga limpio al error público del brazo.
1693- **Resolución de imports**:
1694  - El parent dir del input se agrega como import path → `import
1695    "./template.ncl"` resuelve sin config.
1696  - El env `BRAHMAN_CARDS_TEMPLATES_DIR` (constante exportada
1697    `BRAHMAN_CARDS_TEMPLATES_ENV`) agrega un registry global →
1698    `import "ui_module_minimal.ncl"` desde cualquier ubicación.
1699  - No hay magic resolución por kind. El autor del Card decide
1700    qué template importa.
1701
1702**Convención obligatoria de templates** (documentada en
1703`nickel_eval.rs`): las fields que el usuario va a sobrescribir
1704deben marcarse `| default` (o `| optional`). Sin ese marker
1705Nickel rechaza el merge de strings/numbers no-iguales con la
1706misma prioridad. Patrón canónico:
1707
1708```nickel
1709# template ui_module_basic.ncl
1710{
1711  id | String | default = "TEMPLATE_ID",
1712  label | String | default = "TEMPLATE_LABEL",
1713  ...
1714}
1715
1716# uso concreto
1717let base = import "ui_module_basic.ncl" in
1718base & { id = "my_id", label = "Mi Label" }
1719```
1720
17219 tests nuevos en `tests/nickel.rs`:
1722- `eval_nickel_file_returns_value_for_valid_input` — happy path.
1723- `eval_nickel_file_surfaces_evaluation_error` — variant `Eval`
1724  con path + message.
1725- `load_card_dispatches_ncl_to_ui_module_variant` — pipeline
1726  e2e a UiModule.
1727- `load_card_dispatches_ncl_to_ente_variant` — pipeline e2e a
1728  Ente.
1729- `template_merge_overrides_id_and_label_only` — el caso del
1730  user: template + override de id+label, resto del template
1731  intacto.
1732- `template_resolves_via_env_registry` — uso del env como
1733  registry global.
1734- `load_card_wraps_nickel_error_in_card_load_error` — wrap
1735  limpio del error.
1736- `nickel_contract_violation_caught_at_eval_time` — value-add
1737  concreto: `id | String = 42` falla en eval, no en deserialize
1738  ni aguas abajo.
1739- `ncl_evaluating_to_unknown_shape_returns_no_matching_reader`
1740  — sanity de coherencia con dispatcher JSON.
1741
174222 tests en total en `brahman-cards` (13 JSON V1 + 9 Nickel V2).
1743Workspace build verde tras la dep nueva.
1744
1745**Lo que NO hace V2** (sigue pendiente):
1746- No migra consumers — `nakui-ui` sigue cargando con
1747  `nakui_ui_schema::load_modules_from_dir`. La migración a
1748  `brahman_cards::load_card` queda para después.
1749- No define un set canonical de templates en el repo (algo
1750  como `templates/ente_basic.ncl`, `templates/ui_module_minimal.ncl`).
1751  Eso emerge cuando aparezcan los primeros casos de uso reales
1752  donde dos cards comparten estructura.
1753- No hace cross-validation entre template + override (ej:
1754  detectar que un override saca un campo required del template).
1755  Nickel ya lo hace via contracts si el template tiene un schema.
1756- No expone una API streaming (load N cards en paralelo). El
1757  use case actual es one-shot al boot.
1758
1759**Pendientes para próximos commits** (orden):
17601. Migrar consumers (`nakui-ui` consume `brahman_cards::load_card`).
17612. Yahweh refactor: lift del MetaUi runtime a `crates/modules/ui_engine/`.
17623. KCL → Nickel: kcl_wrapper reemplazado por evaluación de Nickel
1763   contracts; los 3 schemas .k de nakui modules pasan a .ncl.
17644. card.k eliminado (es REFERENCE ONLY documentado).
1765
1766### feat(brahman-cards): brazo unificado V1 — readers JSON + estructura canónica
1767**Pivote arquitectónico** decidido en charla: Brahman maneja varios
1768formatos legítimos de "Card" (cada formato vive en su crate origen y
1769conserva su shape público), y un **único brazo** los lee, completa
1770desde templates si vienen simplificados, y los proyecta a UNA sola
1771estructura interna canónica que consumen UI runtime / storage / DHT /
1772wire. Agregar un formato nuevo = agregar un reader, sin tocar
1773consumers.
1774
1775**V1 en este commit**: estructura canónica + readers para los 3
1776formatos JSON existentes en el monorepo. Sin Nickel todavía (aislado
1777para próximo commit).
1778
1779Crate nuevo `crates/core/brahman-cards/`:
1780- **`Card { id, schema_version, lineage, label, extensions, body }`**:
1781  wrapper común con identidad legible + extensiones forward-compat.
1782  `id` como String (no `Ulid`) porque cada body variant usa un tipo
1783  de id distinto (Ulid para Ente/Monad, slug human-friendly para
1784  UiModule). PartialEq omitido del derive porque `MonadManifest` y
1785  `nakui_ui_schema::Module` no lo implementan en sus crates origen.
1786- **`CardBody`** enum etiquetado `kind`:
1787  - `Ente(brahman_card::Card)` — entidad runtime con
1788    payload/soma/supervision.
1789  - `Monad(nouser_card::MonadManifest)` — agrupación semántica de
1790    archivos.
1791  - `UiModule(nakui_ui_schema::Module)` — descriptor de UI con
1792    entities/views/menu.
1793  - Convención: agregar variant nuevo + reader; los consumers que
1794    sólo manejen algunos hacen `match { Ente(..) => ..., _ => skip }`.
1795- **`trait CardReader`**: `name()` + `can_read(&Value) -> bool` +
1796  `read(Value) -> Result<Card>`. El dispatcher prueba en orden y
1797  delega al primero que matchee.
1798- **3 readers concretos** (en `readers.rs`):
1799  - `EnteJsonReader` — heurística: `payload` Y `supervision`
1800    presentes simultáneamente.
1801  - `MonadJsonReader` — heurística: `members` Y `cardinality`.
1802  - `UiModuleJsonReader` — heurística: `entities` Y `views` Y
1803    `menu`. El más específico, va primero en `default_readers()`.
1804- **Entry points**:
1805  - `load_card(path)` — abre archivo, dispatcha por extensión, dentro
1806    de JSON prueba los readers default.
1807  - `load_card_with(path, readers)` — variante con set custom para
1808    apps que quieren restringir formatos.
1809- **Errores tipados** vía `CardLoadError`: `Io`, `JsonParse`,
1810  `NoMatchingReader`, `ReaderFailed { reader, message }`,
1811  `UnsupportedExtension { ext, supported }`.
1812
181313 tests integration:
1814- 3 detection tests (cada reader matchea sólo su shape, rechaza los
1815  otros 2 + non-object).
1816- 3 dispatch+projection tests (cada formato JSON cargado produce el
1817  variant esperado con campos del wrapper bien derivados).
1818- 2 negative cases (NoMatchingReader, non-object input).
1819- 1 sanity de orden (UiModule gana cuando el shape acepta múltiples
1820  readers — defiende el contrato de orden documentado).
1821- 1 e2e desde disco con `load_card_with`.
1822- 1 unsupported extension.
1823- 1 custom reader set (restringir a sólo Ente).
1824- 1 documented invariant (extensions vacío en V1; si cambia, este
1825  test se rompe como signal).
1826
182713/13 verdes. Workspace build verde tras agregar el crate al
1828`members[]` del workspace Cargo.toml.
1829
1830**Lo que NO hace V1** (explícito):
1831- No carga Nickel — próximo commit. La dep `nickel-lang-core` queda
1832  aislada para no inflar este commit.
1833- No define templates — los templates Nickel se diseñan junto al
1834  reader Nickel (necesitan `merge` nativo de Nickel para fusionar
1835  override + base).
1836- No migra consumers. `nakui-ui` sigue cargando `module.json` con
1837  `nakui_ui_schema::load_modules_from_dir` directo. La migración a
1838  `brahman_cards::load_card` viene cuando V1 + Nickel + templates
1839  estén estables.
1840- No mueve los `extensions` del input a `Card.extensions` — los crates
1841  origen ya tienen sus propios `extensions` internos (`#[serde(flatten)]`).
1842  Documentado como decisión consciente.
1843
1844**Pendientes para próximos commits** (orden):
18451. Reader Nickel + template merge.
18462. Migrar consumers (`nakui-ui` consume `brahman_cards::load_card`).
18473. Yahweh refactor: lift del MetaUi runtime a `crates/modules/ui_engine/`
1848   (esperando hasta que el brazo + canónico estén estables).
18494. KCL → Nickel: kcl_wrapper reemplazado por evaluación de Nickel
1850   contracts; los 3 schemas .k de nakui modules pasan a .ncl.
18515. card.k eliminado (es REFERENCE ONLY documentado).
1852
1853### feat(nakui-ui): validación cross-field del EntityRef (existence en store)
1854Cierra otro pendiente. Hasta ahora `parse_field_value(EntityRef, raw)`
1855sólo validaba **forma** (UUID parseable + trim de whitespace) — un
1856UUID válido pero inexistente en el store pasaba silenciosamente al
1857log/store, dejando dangling references. Ahora validamos también
1858**existencia** contra la entity declarada en `FieldSpec.ref_entity`.
1859
1860Cambios:
1861- **Nuevo helper `validate_entity_refs<S: Store>(store, refs)`**:
1862  - `refs: &[(label, target_entity, uuid)]`.
1863  - Loop fail-fast: primer record ausente → error con label
1864    legible + UUID corto + target entity en el msg
1865    `"campo 'Stock': record abc12345 de 'Stock' no existe en el store"`.
1866  - Pure (toma `&S: Store`), totalmente testable sin GPUI.
1867- **Wireup en `commit_seed`**:
1868  - Durante el parse loop, cuando un field es EntityRef + tiene
1869    `ref_entity` declarado + value parseado a UUID, lo encolamos
1870    en `entity_refs: Vec<(String, String, Uuid)>`.
1871  - Después del parse loop (antes del seed/edit branch), si
1872    `entity_refs` no está vacío, una sola toma del store lock
1873    para validar todos via el helper.
1874  - Falla early: ningún log entry, ningún apply.
1875- **Cobertura**:
1876  - SEED path: alta nueva con EntityRef → validamos antes de
1877    `Seed { data }`.
1878  - EDIT path: edit con EntityRef → validamos antes de calcular
1879    delta. Una optional empty (que iría a clear) no cuenta como
1880    EntityRef (raw vacío skipea el push).
1881  - Morphism inputs: NO se duplica acá. `Executor::compute` ya
1882    valida cada input via `store.load(...).ok_or(EntityMissing)`
1883    antes de correr el script Rhai. Documentado en el doc del
1884    helper.
1885
18865 tests nuevos:
1887- `validate_entity_refs_passes_when_all_records_exist` — happy path.
1888- `validate_entity_refs_fails_on_first_missing` — fail-fast con
1889  msg que incluye entity + UUID corto.
1890- `validate_entity_refs_uses_label_not_entity_in_msg` — el label
1891  legible (ej: "Stock origen") aparece en el error, no la entity
1892  desnuda.
1893- `validate_entity_refs_empty_list_is_ok` — lista vacía es Ok.
1894- `validate_entity_refs_distinguishes_target_from_other_entities` —
1895  un UUID que existe bajo Customer pero NO Stock falla la
1896  validación contra Stock.
1897
189845 tests verdes en nakui-ui (+5). Workspace build verde.
1899
1900Comportamiento esperado:
1901- **Selector clickable es happy path**: el dropdown sólo lista
1902  records existentes, así que clickearlo nunca debería disparar
1903  el error. Sólo dispara con paste manual de UUID que no existe
1904  o records borrados después de la selección (timing race).
1905- **Optional empty no se valida**: si el field es EntityRef
1906  optional y el form lo deja vacío, lo manejamos como "no value"
1907  (skipea el push a `entity_refs`); la lógica de Clear se
1908  encarga del resto.
1909- **Lock contention**: una sola toma del store lock por
1910  `commit_seed`, no una por field. La validación es O(refs) reads.
1911
1912Pendientes restantes:
1913- **Validación KCL del record post-edit** antes de emitir Set/Clear
1914  (hoy `ui.edit_record` no pasa por `Executor::compute`).
1915- **EntityRef cross-module** (referenciar records de OTRO módulo
1916  por nombre, no sólo por entity local).
1917
1918### feat(nakui-core,nakui-ui): FieldOp::Clear — borrar values vía form vacío
1919Cierra el último pendiente de UX del round. El edit no podía
1920"borrar" un value vaciando el input — empty optional fields
1921hacían `continue` en `commit_seed`, así que el current value
1922quedaba intacto. Para honrar el intent del usuario ("este field
1923ya no aplica") necesitábamos un FieldOp explícito que remueva
1924la key del map.
1925
1926Cambios en **nakui-core** (la variante es semántica del kernel,
1927no específica de la UI):
1928
1929- **`delta::FieldOp::Clear { path }`** — nueva variante.
1930  Distinta de `Set { value: Null }`: Clear borra la clave; Set
1931  Null deja la clave con valor literal `null`. Importa para
1932  downstream que diferencia "ausente" vs "presente como null"
1933  (ej: serde con `skip_serializing_if = "Option::is_none"`).
1934- **`capability_token`** — Clear devuelve `entity.field`,
1935  mismo shape que Set. Una capability `writes: ["Customer.notes"]`
1936  autoriza tanto Set como Clear sobre ese field.
1937- **`simulate_on`** — Clear remueve la key del Object si el
1938  state es Some(Object). Skip silente si el state es None
1939  (deleted) o no-objeto.
1940- **`MemoryStore::apply_dry_run`** — Set y Clear comparten
1941  pre-condición (record padre existe + es objeto). Pattern
1942  combinado con `|`.
1943- **`MemoryStore::apply`** — Clear hace `map.remove(field)`.
1944  Field ausente = no-op silencioso (post-state idéntico).
1945- **`SurrealStore::apply_dry_run`** — Set/Clear combinados.
1946- **`SurrealStore::apply`** — Clear emite
1947  `UPDATE type::thing UNSET <field>`. El field name viene de
1948  un FieldSpec validado upstream; SurrealQL no soporta binding
1949  de identifiers, así que va inline (con la advertencia
1950  documentada en el comment).
1951- **`Executor` capability check** — Set/Clear comparten match
1952  (mismo token shape, misma resolución a binding role).
1953- **Conservation rules** (en `check_conservation`) NO consideran
1954  Clear — sólo Set. Documentado: morphism authors que querían
1955  clear de un field con conservation tienen que ser cuidadosos;
1956  KCL post-checks pueden capturar violations.
1957
1958Cambios en **nakui-ui**:
1959
1960- **`commit_seed` loop** acumula `to_clear: Vec<String>` con
1961  los nombres de fields optional empty (en lugar de hacer
1962  `continue` silencioso).
1963- **EDIT branch**:
1964  - Computa `set_delta` (igual que antes) + `clear_fields` via
1965    nuevo helper `compute_clear_fields(current, to_clear)`.
1966  - Helper filtra a sólo los fields que actualmente tienen
1967    valor non-null — Clear de un field ausente o ya null no
1968    se emite (sería no-op semántico). Preserva el orden del
1969    input para estabilidad del log entry.
1970  - Construye `ops` combinando Set + Clear.
1971  - NoChange ahora requiere AMBOS vacíos (set_delta y
1972    clear_fields).
1973  - `params` del log entry incluye `cleared: ["field1", ...]`
1974    sólo si non-empty (preserva la shape `fields:` para
1975    edits sin clears).
1976  - `CommitOutcome::Updated.changed = sets + clears` para
1977    que el toast `"actualizado X (N campo(s))"` siga siendo
1978    preciso.
1979
1980Tests nuevos:
1981- **delta.rs**: `simulate_clear_removes_field`,
1982  `simulate_clear_then_set_same_field_keeps_set`,
1983  `clear_capability_token_matches_set_shape`.
1984- **store.rs**: `apply_clear_removes_field_key`,
1985  `apply_clear_on_absent_field_is_noop`,
1986  `dry_run_rejects_clear_on_missing_record`,
1987  `dry_run_rejects_clear_on_non_object`.
1988- **nakui-ui main.rs**: `clear_fields_skips_absent_and_null`,
1989  `clear_fields_preserves_input_order`,
1990  `clear_fields_empty_when_current_is_null`.
1991
199234 tests verdes en nakui-core (+7), 40 en nakui-ui (+3).
1993Workspace build verde. E2E del morphism real
1994`morphism_pipeline_executes_real_sales_vender` intacto — `vender`
1995no usa Clear.
1996
1997Implicaciones:
1998- **El log puede crecer con entries `ui.edit_record` que sólo
1999  tienen `cleared: [...]`** sin `fields`. Esperado y esperable.
2000- **Replay**: las entries con Clear se aplican en orden via
2001  `store.apply(&ops)`. La semantic es deterministic.
2002- **Si un módulo tiene KCL invariants sobre la presencia de un
2003  field**, el usuario podría romper el record vaciando ese
2004  field via UI. Hoy esto NO se chequea — `ui.edit_record` es
2005  un morphism manual que no pasa por `Executor::compute`. Si
2006  esto es un problema, el camino futuro es validar contra el
2007  KCL del entity al submit (otro pendiente).
2008
2009Pendientes restantes:
2010- **Validación cross-field** (ej: UUID del EntityRef existe en
2011  la entity referida).
2012- **Validación KCL del record post-edit** antes de emitir Set/Clear.
2013
2014### feat(nakui-ui): snapshot/compaction durante runtime cada N writes
2015Cierra el último pending del round de persistencia. Antes el compact
2016sólo corría al startup — para una sesión larga con muchas escrituras,
2017el log crecía sin tope hasta el próximo restart, y el siguiente boot
2018pagaba el costo lineal del replay.
2019
2020Cambios:
2021- **Nuevos fields en `MetaUi`**:
2022  - `snap_path: PathBuf` — cacheado del init para que el tick no
2023    tenga que recomputarlo.
2024  - `snapshot_threshold: usize` — leído del env en `new()` y
2025    cacheado. `0` desactiva runtime compact (mismo env y
2026    semantic que el threshold de startup).
2027  - `writes_since_compact: u64` — contador que incrementa por cada
2028    write efectivo y se resetea cuando el threshold dispara
2029    `maybe_compact_log`.
2030- **Nuevo método `tick_runtime_compact()`**:
2031  - Early return si `threshold == 0`.
2032  - Increment + check vs threshold.
2033  - Si cruza: lock log + store, llama `maybe_compact_log`.
2034  - **Si compactó OK**: counter = 0, devuelve msg.
2035  - **Si `maybe_compact_log` returned None** (counter dijo "go"
2036    pero entries < 2): counter = 0 (no re-entrar cada write).
2037  - **Si error**: counter NO se resetea (próximo write reintenta),
2038    devuelve el error.
2039- **Nuevo helper `append_compact_msg(base, opt)`**: concatena el
2040  msg del compact al toast del op original con `";"` separator.
2041- **Wireup en 3 callsites de write efectivo**:
2042  - `apply_action::SeedEntity`: tick si outcome != NoChange.
2043  - `apply_action::Morphism`: tick siempre que Ok.
2044  - Click handler `[Confirmar]` del delete modal: tick si commit_delete Ok.
2045- **NoChange no cuenta**: un edit que no cambia nada no escribe al
2046  log, así que tampoco debería avanzar el counter — preserva la
2047  semantic "1 write = 1 log entry = 1 tick".
2048
20492 tests nuevos:
2050- `append_compact_msg_handles_both_branches` — base solo vs base
2051  + compact, formato del separator.
2052- `runtime_compact_cycle_resets_counter_after_threshold` — E2E
2053  estilo simulación: 7 writes con threshold=3 → 2 compacts (en
2054  write 3 y 6), counter residual = 1, log final con 2 entries
2055  (1 anchor + 1 write residual). Reproduce el algoritmo del tick
2056  sin GPUI cx; si la lógica del método cambia, se rompe como signal.
2057
205837 tests verdes (+2). Workspace build verde.
2059
2060Trade-offs:
2061- **Counter en memoria, no persistido**: si la app crashea entre
2062  compacts, al próximo boot el counter parte de 0. El startup
2063  compact (basado en entry_count del log file) compensa esto:
2064  si quedó mucho post-último-compact, se compacta al boot.
2065- **Lock orden**: tick toma log lock primero, store lock después.
2066  Misma orden que `commit_seed` y `commit_morphism`, no debería
2067  haber deadlock.
2068- **Costo del tick**: 1 increment + 1 compare por write. Cuando
2069  cruza threshold, 1 read del log (entries) + 1 snapshot write +
2070  1 compact. Para threshold=50 es ~1 fsync cada 50 writes —
2071  amortiza bien.
2072
2073Pendientes restantes:
2074- **`FieldOp::Clear`** — para soportar borrar un value vía form vacío.
2075- **Validación cross-field** (UUID del EntityRef existe en la
2076  entity referida).
2077
2078### feat(nakui-ui): atajo Esc para cancelar el modal de delete
2079Cierra otro pendiente de UX. El banner de confirmación de delete
2080ya tenía botones [Cancelar] / [Confirmar], pero la acción más
2081natural para cancelar un dialog es Esc — y no la teníamos wireada.
2082
2083Cambios:
2084- **`capture_key_down` en el root div** del `MetaUi::render`. Capture
2085  phase (no bubble) para interceptar el Esc *antes* que cualquier
2086  TextInput descendiente lo consuma. Sin pending el handler es
2087  no-op y el evento sigue su flujo normal.
2088- **Match `event.keystroke.key == "escape"`** + `pending_delete.take()`
2089  → toast `"delete cancelado (Entity) [esc]"` (sufijo `[esc]` para
2090  diferenciar visualmente del botón). Si no hay pending, return
2091  temprano sin tocar nada.
2092- **Hint visual en el banner**: subtítulo en amber tenue debajo del
2093  título: `"Esc para cancelar · click [Confirmar] para borrar"`.
2094  Que el usuario descubra el atajo sin RTFM.
2095
209635 tests verdes — el handler de Esc es 8 líneas no-testeables sin
2097GPUI cx (la lógica de pending_delete + toast vive dentro del
2098listener); el wireup compila por type-check.
2099
2100Pendientes restantes:
2101- **`FieldOp::Clear`** — para soportar borrar un value vía form vacío.
2102- **Snapshot durante runtime** (cada N writes, no sólo al startup).
2103- **Validación cross-field** (UUID del EntityRef existe en la
2104  entity referida).
2105
2106### feat(nakui-ui): EntityRef validation en parse_field_value (UUID al submit)
2107Cierra otro pendiente: `parse_field_value(FieldKind::EntityRef, raw)`
2108devolvía `Ok(json!(raw))` blindly — el value entraba al log/store
2109incluso si era basura. La validación de UUID sólo ocurría cuando el
2110field se usaba como **input** del morphism (línea ~540 de
2111`commit_morphism`); como **seed field** o como **param**, garbage
2112pasaba silenciosamente.
2113
2114Cambios:
2115- **`parse_field_value(EntityRef, raw)`** ahora hace
2116  `Uuid::parse_str(raw.trim())` y devuelve error claro si falla:
2117  `"'<raw>' no es UUID válido (usá el selector de records)"`. En
2118  caso de éxito, devuelve el UUID **trimmed** como string —
2119  protege contra paste manual con whitespace.
2120- **Doble cobertura**: este path cubre seed fields (commit_seed via
2121  obj.insert) y morphism params (resolve_param_value lo invoca por
2122  cada FieldSpec con kind=EntityRef). El path de morphism inputs
2123  ya validaba antes con `Uuid::parse_str` directo — sigue intacto,
2124  no hay double-validation.
2125- **Selector clickable es happy path**: el dropdown setea valores
2126  bien-formados, así que el usuario nunca debería ver el error en
2127  uso normal. Sólo dispara con paste manual o si el usuario escribe
2128  garbage en el input — defensivo.
2129
21305 tests nuevos (reemplazan al obsoleto `parse_field_entity_ref_returns_string`):
2131- `parse_field_entity_ref_accepts_valid_uuid` — happy path.
2132- `parse_field_entity_ref_trims_whitespace` — `"  uuid\n"` → `"uuid"`.
2133- `parse_field_entity_ref_rejects_non_uuid` — `"abc-123"` → error
2134  con el value y la palabra "UUID" en el mensaje.
2135- `parse_field_entity_ref_rejects_empty_string` — `""` → rebota.
2136- `resolve_param_strict_entity_ref_propagates_error` — sanity de
2137  que el wireup en resolve_param_value hereda el strict checking,
2138  con label del FieldSpec en el mensaje.
2139
214035 tests verdes (+4 net). El E2E del morphism real
2141`morphism_pipeline_executes_real_sales_vender` sigue verde — sus
2142inputs van por el path dedicado, no por parse_field_value.
2143
2144Pendientes restantes:
2145- **Atajo Esc para Cancelar** del modal de delete.
2146- **`FieldOp::Clear`** — para soportar borrar un value vía form.
2147- **Snapshot durante runtime** (cada N writes, no sólo al startup).
2148- **Validación cross-field** (ej: el UUID del EntityRef existe en
2149  la entity referida) — hoy sólo validamos forma; un UUID válido
2150  pero inexistente sí pasa.
2151
2152### feat(nakui-ui): snapshot/compaction automático del event log al startup
2153Cierra el último gran pendiente del round: el replay full cada
2154startup escala lineal en el log. Con 60+ entries el costo de boot
2155se nota; con 10k entries es prohibitivo. Wireamos el snapshot
2156machinery que ya estaba en `nakui-core` (`Snapshot`,
2157`replay_with_snapshot_into`, `EventLog::compact_through`) al
2158runtime de la UI.
2159
2160Cambios:
2161- **Path del snapshot**: sibling del log, extensión `.snap.json`.
2162  `nakui-ui-state.jsonl` ↔ `nakui-ui-state.snap.json`.
2163- **Nuevo helper `snapshot_path_for(log_path)`** — derivación
2164  pura, testeable.
2165- **Nuevo helper `maybe_compact_log(log, snap_path, store, threshold)`**:
2166  - Si `entry_count >= threshold` y `>= 2`, captura
2167    `Snapshot::from_memory_store(store, next_seq - 1)`, lo escribe
2168    atómicamente, y compacta el log dejando la última entry como
2169    anchor.
2170  - Anchor invariant: `EventLog::open` deriva `next_seq` del primer
2171    entry del archivo. Si compactáramos *todo* el log file, al
2172    reabrir el cursor volvería a 0 y el próximo append crashearía
2173    con `NonMonotonic`. Por eso compactamos sólo hasta
2174    `next_seq - 2` — la entry del `snap.seq` queda como anchor del
2175    cursor; `replay_with_snapshot_into` la skipea porque snap ya
2176    cubre hasta ese seq inclusive.
2177  - Threshold via env `NAKUI_SNAPSHOT_THRESHOLD`, default 50.
2178    `0` desactiva por completo.
2179  - Devuelve `Result<Option<msg>, String>`: `Ok(Some)` si compactó,
2180    `Ok(None)` si no había payoff, `Err` si snap o compact fallaron.
2181- **`MetaUi::new` reescrito**:
2182  - Carga snapshot al inicio (Some/None según exista).
2183  - `replay_with_snapshot_into(&log, snapshot.as_ref(), &mut store)`
2184    en lugar de `replay_into`.
2185  - Después del replay corre `maybe_compact_log` con el threshold.
2186  - Toast inicial menciona snapshot loaded si aplica
2187    ("snapshot @ seq K") y la compactación si ocurrió.
2188  - Errores de snapshot load **no son fatales**: cae a full replay
2189    con un msg en el banner.
2190  - Errores de auto-compact **no son fatales**: el log + snap
2191    quedan como estaban, msg al banner.
2192
21935 tests nuevos:
2194- `snapshot_path_for_replaces_extension` — `.jsonl` → `.snap.json`,
2195  edge case sin extensión.
2196- `maybe_compact_log_below_threshold_noops` — 5 entries vs threshold
2197  50: no toca nada, no escribe snap.
2198- `maybe_compact_log_threshold_zero_noops` — threshold 0 = disabled.
2199- `maybe_compact_log_then_reopen_preserves_records` — E2E:
2200  - Escribe 60 seeds (log + store en sync).
2201  - Compacta (60 >= 50): snap escrito, log queda con 1 anchor entry,
2202    msg reporta "59 entries dropped (1 anchor kept)".
2203  - Reopen: `next_seq=60` se preserva via anchor, `entries.len()=1`.
2204  - Replay con snap loadado en store fresco: los 60 records están.
2205  - Segunda corrida del compact con threshold=1: no-op (idempotente).
2206
220731 tests verdes (+5). Workspace build verde tras la nueva firma.
2208
2209Trade-offs y notas:
2210- **Fail-soft**: cualquier error de snap/compact no rompe el boot;
2211  la UI sigue funcionando con full replay y el toast lo reporta.
2212  Sólo `EventLog::open` failing es no-recoverable (pierde
2213  persistencia).
2214- **Crash-safety**: WAL order preservado — escribimos snap (atómico
2215  via tempfile + fsync + rename) ANTES de compactar el log
2216  (atómico igual). Si crasheamos entre los dos, próximo boot ve
2217  snap@K + log con todas las entries 0..N — replay skippea las que
2218  snap cubre, outcome idéntico.
2219- **Sólo en startup**: no hay snapshot durante runtime. Para sesiones
2220  largas con muchas escrituras, el log puede crecer arbitrariamente
2221  hasta el próximo restart. Pendiente futuro: snapshot N writes
2222  desde el último compact.
2223- **Anchor entry sobrevive sin uso útil**: el costo es 1 línea JSON
2224  por compact. No es preocupación a menos que el threshold sea
2225  muy chico (cada compact deja 1 línea de basura).
2226
2227Pendientes restantes:
2228- **EntityRef validation post-submit** — validar UUID parseable al
2229  submit en lugar de al execute del morphism.
2230- **Atajo Esc para Cancelar** del modal de delete.
2231- **`FieldOp::Clear`** — para soportar borrar un value vía form vacío.
2232- **Snapshot durante runtime** (cada N writes, no sólo al startup).
2233
2234### feat(nakui-ui): edit delta-only — sólo campos modificados al log/store
2235Antes de este cambio, editar un record emitía un `FieldOp::Set` por
2236**cada field del form**, incluso los no tocados. Eso bloata el log
2237(replay tenía que aplicar N ops cuando 1 alcanzaba) y oscurece el
2238intent en una auditoría posterior. Con delta-only, el edit emite
2239sólo los Sets cuyo value nuevo difiere del actual; un edit que no
2240cambia nada deja el log intacto.
2241
2242Cambios:
2243- **Nuevo helper `compute_field_delta(current, proposed)`** — toma
2244  el record actual del store (un `Value`, posible `Null` si el
2245  record no existe) y el `Map` propuesto desde el form, y devuelve
2246  sólo las entries que difieren. Comparación: `PartialEq` estructural
2247  de `serde_json::Value` (un `Null` en current = todos los proposed
2248  son nuevos).
2249- **Nuevo enum `CommitOutcome`**:
2250  - `Created(Uuid)` — alta nueva.
2251  - `Updated { id, changed }` — edit con N campos modificados.
2252  - `NoChange(Uuid)` — edit sin diferencias (el toast lo refleja
2253    como "X sin cambios — no log entry").
2254- **`commit_seed` en path EDIT**:
2255  - Carga current via `store.load(entity, id)` con fallback a
2256    `Value::Null`.
2257  - Calcula delta. Si vacío → return early sin tocar log ni store.
2258  - Si no vacío → emite `Morphism { ui.edit_record, ops: [Set...] }`
2259    con `params.fields` reflejando el delta (no todo el form),
2260    haciendo la auditoría grep-able por field cambiado.
2261- **Toast del callsite**:
2262  - `creado X uuid` (Created)
2263  - `actualizado X uuid (N campo(s))` (Updated)
2264  - `X uuid sin cambios — no log entry` (NoChange)
2265- **`editing` se limpia incluso en NoChange** — el modo edit cierra,
2266  el form vuelve al state limpio.
2267
22685 tests nuevos del helper:
2269- delta vacío cuando todo coincide.
2270- delta sólo con el field cambiado.
2271- delta full cuando current = Null (record no existe).
2272- distingue int 100 de string "100".
2273- ignora fields del current que no están en proposed.
2274
227527 tests verdes (+5). El path SEED no cambió; el E2E del morphism
2276real sigue verde.
2277
2278Limitación conocida (consistente con pre-delta): el form no puede
2279**borrar** un value vaciando el input — empty optional fields hacen
2280`continue` antes de llegar al delta. Para clearear un value hay que
2281declarar el field como required, o esperar a un `FieldOp::Clear`
2282futuro (no necesario hoy: ningún demo lo requiere).
2283
2284Pendientes restantes:
2285- **Snapshot/compaction** del log (replay full cada startup escala
2286  mal con repos grandes).
2287- **EntityRef validation post-submit** — validar UUID parseable al
2288  submit en lugar de al execute del morphism.
2289- **Atajo Esc para Cancelar** del modal de delete.
2290- **`FieldOp::Clear`** — para soportar borrar un value vía form.
2291
2292### feat(nakui-ui): confirmación de delete vía banner modal antes de borrar
2293Cierra el primer pending del último round: borrar un record pedía un
2294solo click en `✕` y se ejecutaba inmediatamente (irreversible —
2295queda en el log como `Morphism { name: "ui.delete_record" }`). Ahora
2296hay un paso intermedio: el click marca el record como pendiente y el
2297banner amber al tope de la ventana ofrece [Cancelar] o [Confirmar].
2298
2299Cambios:
2300- **Nuevo state `MetaUi.pending_delete: Option<(String, Uuid)>`**.
2301  Set en el click del `✕`; limpiado por:
2302  - [Cancelar] → toast "delete cancelado (Entity)".
2303  - [Confirmar] → llama `commit_delete` (igual que antes) y emite
2304    el toast usual.
2305  - Navegación a otra view (`select_view`) — el record marcado
2306    podría no estar visible en la nueva pantalla.
2307- **Click handler de `✕` ya no llama `commit_delete`**: sólo setea
2308  `pending_delete` y limpia toast. La acción destructiva ahora vive
2309  exclusivamente en el botón [Confirmar] del banner.
2310- **Nuevo método `render_confirm_delete_banner`**: devuelve
2311  `Option<Div>` (None si no hay pending). Banner amber con el texto
2312  `¿Borrar {Entity} {short_uuid}?` + dos botones. Renderea como
2313  sibling del row sidebar+main en `flex_col` raíz — no es overlay
2314  flotante (GPUI no expone z-index trivialmente), pero la posición
2315  fija al tope + color amber lo hacen imposible de ignorar.
2316- **Limpieza pre-commit**: `pending_delete = None` se ejecuta antes
2317  de `commit_delete`, así un fallo del commit no deja el banner
2318  colgado además del toast de error.
2319
232022 tests verdes — la lógica del store/log no cambió, sólo el state
2321machine de UI. La confirmación es puramente UX/state, no testable
2322sin GPUI cx, pero la compilación garantiza wireup correcto de las
2323closures.
2324
2325Pendientes restantes:
2326- **Snapshot/compaction** del log para repos grandes (replay full
2327  cada startup escala mal).
2328- **Edit delta-only** — sólo campos modificados, no todos.
2329- **EntityRef validation post-submit** — validar UUID parseable
2330  al submit en lugar de al execute del morphism.
2331- **Atajo de teclado Esc para Cancelar** — requiere event
2332  dispatcher de GPUI, fuera de scope inmediato.
2333
2334### feat(nakui-ui): validación estricta de params del morphism vía FieldKind del FieldSpec
2335Cierra el último trade-off documentado: `infer_param_value` adivinaba
2336el tipo de cada param por la shape del string (i64 → f64 → bool →
2337string). Ahora cuando hay `FieldSpec` declarado, usamos
2338`parse_field_value(spec.kind, raw)` — un Boolean field con value
2339"abc" rebota con mensaje claro en la UI antes de llegar al morphism
2340Rhai (donde el error sería opaco como "Function not found: * ((), ())").
2341
2342Cambios:
2343- **Nuevo helper `resolve_param_value(field_name, raw, spec)`**:
2344  - Si hay `FieldSpec`: validación de `required` (rebota empty con
2345    "param 'X' es obligatorio y está vacío") + parseo estricto via
2346    `parse_field_value(spec.kind, raw)`. Errores incluyen el `label`
2347    del spec para que el toast sea interpretable.
2348  - Si NO hay spec (param declarado en `Action::Morphism.params`
2349    que no existe en `form.fields` — módulo mal-formado): fallback
2350    a `infer_param_value` como red de seguridad.
2351  - Empty + opcional → `Value::Null`.
2352- **`commit_morphism` simplificado**: el loop de params ahora es
2353  3 líneas (lookup spec + llamada a `resolve_param_value` +
2354  inserción al map). La lógica vive en el helper standalone,
2355  testable sin GPUI.
2356
2357Tests: 6 nuevos en `tests` mod, todos contra `resolve_param_value`:
2358- `resolve_param_strict_number_parses_i64` — happy path.
2359- `resolve_param_strict_boolean_rejects_non_boolean` — un Boolean
2360  con "abc" rebota con mensaje que incluye el label.
2361- `resolve_param_strict_number_rejects_garbage` — Number con "abc"
2362  rebota.
2363- `resolve_param_required_empty_rejected` — required vacío rebota
2364  con "obligatorio".
2365- `resolve_param_optional_empty_returns_null` — optional vacío
2366  → null.
2367- `resolve_param_no_spec_falls_back_to_infer` — el fallback
2368  preserva el comportamiento anterior para back-compat.
2369
237022 tests verdes en nakui-ui (+6). E2E del morphism real
2371(`morphism_pipeline_executes_real_sales_vender`) sigue verde — la
2372validación estricta no rompe el path correcto, sólo agrega rebotes
2373tempranos a values mal-tipados.
2374
2375Beneficio operativo:
2376- Mensaje de error en la UI ahora identifica el field problemático
2377  por su label legible ("param 'Cantidad': 'abc' no es número")
2378  en lugar del error opaco del morphism Rhai.
2379- Errores se ven antes de tocar el log o el store — ningún cambio
2380  parcial.
2381- El módulo Nakui ya no tiene que defender contra inputs garbage
2382  desde la UI: la metainterfaz se vuelve la primera línea de
2383  validación tipada.
2384
2385Pendientes futuros (orden de prioridad):
2386- **Confirmación de delete** — modal antes de borrar.
2387- **Snapshot/compaction** del log para repos grandes.
2388- **Edit delta-only** — sólo campos modificados, no todos.
2389- **EntityRef validation post-submit**: hoy `parse_field_value`
2390  para EntityRef devuelve string raw; el commit_morphism luego
2391  valida como Uuid sólo cuando es input del morphism. Para
2392  EntityRef como param, podríamos validar UUID al submit.
2393
2394### feat(nakui-ui): FieldKind::EntityRef — selector clickable de records existentes
2395Cierra el principal trade-off documentado del commit anterior:
2396"Inputs UUID a mano (no dropdown)". Los formularios pueden declarar
2397un campo `entity_ref` que apunta a una entity y el runtime renderea
2398una lista clickable de records existentes; click selecciona, el
2399UUID queda guardado para el submit.
2400
2401Schema `nakui-ui-schema`:
2402- **Nueva variante `FieldKind::EntityRef`** (serializa como
2403  `"entity_ref"` en JSON).
2404- **`FieldSpec.ref_entity: Option<String>`** nuevo. Indica qué
2405  entity ofrecer en el selector. `validate()` chequea que cualquier
2406  field con `kind=entity_ref` tenga `ref_entity` set.
2407- Nuevo error tipado `SchemaError::EntityRefMissingTarget`.
2408
2409Runtime `nakui-ui`:
2410- **`render_entity_ref_selector(field_name, target_entity, ...)`** —
2411  helper que arma la lista debajo del input. Cada item:
2412  - Etiqueta humana via `human_label_for_record` (heurística:
2413    `name` → `label` → `title` → `sku` → `sku_id` → fallback al
2414    UUID corto).
2415  - Click handler vía `cx.listener` que llama
2416    `input.set_text(uuid_completo)` — el TextInput interno queda
2417    como source-of-truth, así que `commit_seed` y `commit_morphism`
2418    leen el UUID seleccionado sin saber que vino de un selector.
2419  - Highlight en accent color cuando el item es el actualmente
2420    seleccionado (compara contra el contenido del TextInput).
2421- **`parse_field_value(EntityRef, raw)`** devuelve string del raw
2422  (la validación como Uuid ocurre downstream en `commit_morphism`).
2423- Mensaje "(sin {entity}: creá uno antes para referenciar)" cuando
2424  la lista está vacía — el user sabe qué hacer en lugar de quedarse
2425  trabado.
2426
2427Demo actualizado: `examples/nakui-modules/sales_engine/module.json`:
2428- `vender_form.fields.stock_id_input` y `caja_id_input` cambian de
2429  `kind: "text"` a `kind: "entity_ref"` con `ref_entity: "Stock"`
2430  y `"Caja"` respectivamente.
2431- Ahora el flujo "Vender" es: (1) click en una Stock listada bajo
2432  el input, (2) click en una Caja, (3) escribir venta_id/cantidad/
2433  precio_unitario/timestamp, (4) submit. Sin copiar UUIDs.
2434
2435Tests:
2436- 2 nuevos en schema: `validate_catches_entity_ref_without_target`
2437  y `entity_ref_with_target_validates_clean`. 8 totales.
2438- 4 nuevos en runtime: `parse_field_entity_ref_returns_string`,
2439  `human_label_for_record_prefers_name_over_id`,
2440  `human_label_falls_back_through_label_title_sku`,
2441  `human_label_falls_back_to_id_when_no_known_keys`. 16 totales.
2442- Integration de los 7 demos sigue verde — el demo `sales_engine`
2443  ahora valida con EntityRef + ref_entity correctamente set.
2444
244529 tests totales nakui-ui + schema, 100% verde. El demo
2446`sales_engine` carga limpio con la nueva forma del schema.
2447
2448Pendientes futuros:
2449- **Confirmación de delete** — modal antes de borrar.
2450- **Snapshot/compaction** del log para repos grandes.
2451- **Edit delta-only** (sólo campos modificados).
2452- **Validación de tipos en params del morphism**: `FieldKind`
2453  declarado en el FieldSpec se podría usar para forzar parseo
2454  estricto en `commit_morphism` en lugar de la heurística
2455  `infer_param_value`.
2456
2457### feat(nakui-ui): Action::Morphism wired al pipeline real (compute → log → apply)
2458Cierra el último gran TODO de la metainterfaz Nakui: las acciones
2459`Action::Morphism` ya no son un toast informativo; despachan al
2460`Executor` cargado del manifest nakui-core (`nsmc.json` + schemas
2461KCL + scripts Rhai), pasando por el pipeline completo de Nakui:
2462compute (con dry-run + KCL post-checks) → log append → store apply.
2463
2464Schema `nakui-ui-schema` extendido:
2465- **`Module.nakui_module_dir: Option<String>`** nuevo. Path
2466  (relativo al directorio del `module.json` o absoluto) a un módulo
2467  nakui-core. Sin esto, las Action::Morphism del módulo quedan
2468  no-op con toast informativo. Las Action::SeedEntity siguen
2469  funcionando sin manifest (alta administrativa).
2470- **`Action::Morphism`** ganó dos campos opcionales:
2471  - `inputs: BTreeMap<String, String>` — mapeo `role → field_name`.
2472    Por cada input declarado en el `MorphismSpec.inputs`, indica
2473    qué field del form contiene el UUID del record. El runtime
2474    parsea como `Uuid` y lo pasa al `execute_and_log`.
2475  - `params: Vec<String>` — lista de fields cuyos values van al
2476    `params` JSON. Si vacío, todos los fields no-input van a params.
2477
2478Runtime `nakui-ui`:
2479- **`MetaUi.executors: BTreeMap<String, Arc<Executor>>`** nuevo.
2480  Carga `Executor::load_module(nakui_module_dir)` en `MetaUi::new`
2481  por cada módulo UI que declare la entry. Errores de carga van al
2482  banner; el módulo sigue cargado para SeedEntity, sólo Morphism
2483  queda no-op.
2484- **`commit_morphism(mod_idx, name, inputs_map, params_fields)`** nuevo.
2485  Resuelve inputs (parsea cada field como Uuid), arma params (Value
2486  object con tipos inferidos via `infer_param_value` — int/float/
2487  bool/string), llama `execute_and_log_with_recovery`. Toast con
2488  cantidad de ops aplicadas o el error tipado.
2489- **`infer_param_value`** nuevo helper: heurística simple para
2490  pasar values del form al morphism con tipo inferido (i64 → f64 →
2491  bool → string).
2492
2493Tests: 2 nuevos:
2494- `infer_param_value_int_then_float_then_bool_then_string` —
2495  cobertura de la heurística.
2496- **E2E `morphism_pipeline_executes_real_sales_vender`** —
2497  carga el módulo real `crates/modules/nakui/modules/sales`,
2498  arma store + log, ejecuta el morphism `vender` con inputs
2499  Stock+Caja y params (cantidad=5, precio_unitario=200,
2500  venta_id, timestamp). Asserta:
2501  - el morphism produce ops (no vacío).
2502  - stock.cantidad bajó 100 → 95.
2503  - caja.saldo subió 1_000_000 → 1_001_000.
2504
250512 tests verdes en nakui-ui (+1 vs commit anterior). Schema
2506extension no rompió nada (6 unit + 5 integration siguen verdes).
2507
2508Demo nuevo: **`examples/nakui-modules/sales_engine/module.json`**
2509- Apunta a `crates/modules/nakui/modules/sales` vía `nakui_module_dir`.
2510- 6 vistas: list + form para cada Stock, Caja, Venta + form
2511  "Vender" con `Action::Morphism { name: "vender", inputs: {stock,
2512  caja}, params: [venta_id, cantidad, precio_unitario, timestamp] }`.
2513- El user crea Stocks + Cajas con seed_entity, copia los UUIDs
2514  cortos a los inputs de "Vender", y ejecuta el morphism real:
2515  stock baja, caja sube, Venta se persiste, todo loggeado.
2516- Validaciones KCL fallan limpio (toast con error) si el morphism
2517  rebota — p. ej. cantidad > stock disponible.
2518
2519Activación full:
2520```sh
2521NAKUI_EVENT_LOG=~/.nakui/state.jsonl \
2522NAKUI_MODULES_DIR=examples/nakui-modules \
2523cargo run -p nakui-ui
2524# Sidebar gana "Ventas (con morphism)" — los 6 menús aparecen y
2525# el form "Vender" dispara el pipeline nakui-core completo.
2526```
2527
2528Trade-offs documentados:
2529- **Inputs UUID a mano**: el form pide que el user copie el UUID de
2530  un Stock/Caja existente. Para UX seria habría que agregar
2531  `FieldKind::EntityRef { entity }` que renderiza un dropdown — no
2532  hecho por scope, queda como nice-to-have.
2533- **Inferencia de tipo en params**: `infer_param_value` adivina
2534  por shape del string. Para casos sutiles (ej. "true" como string
2535  literal vs bool), el módulo nakui-core puede explicitar tipos
2536  via `kind` en el FieldSpec — el form lo respeta para validación
2537  pre-submit; la inferencia final sigue siendo heurística.
2538
2539### feat(nakui-ui): edit + delete de records (ciclo CRUD completo)
2540Cierra "no hay UI para editar/borrar records existentes" del commit
2541anterior. Cada fila de la lista gana dos botones (✎ edit, ✕ delete);
2542el form view se reusa para alta y para edit; el delete es inline.
2543Las mutaciones pasan por `LogEntry::Morphism` con sus ops, así el
2544replay restaura el estado correcto.
2545
2546Cambios:
2547
2548- **`MetaUi.editing: Option<(String, Uuid)>`** nuevo. Set al click
2549  en ✎; cleared al cambiar de view o tras submit exitoso.
2550- **`open_edit(mod_idx, entity, id, cx)`**: setea `editing`, busca la
2551  primera Form view del módulo cuya `entity` matchee, navega ahí. Si
2552  el módulo no tiene Form para esa entity → toast con error
2553  ("no hay form view para entity X").
2554- **`select_view`** extendido: cuando carga un Form, si `editing`
2555  matchea esa entity y el record existe en el store, pre-llena cada
2556  input con el valor del record (vía nuevo helper
2557  `value_to_input_text` — inverso de `parse_field_value`).
2558- **`commit_seed`** ramifica:
2559  - **Edit path** (cuando `editing.is_some()` y entity matchea):
2560    emite `LogEntry::Morphism { name: "ui.edit_record", ops:
2561    [Set { path, value } for each field], params: { entity, id,
2562    fields } }`. Aplica al store via `apply(&ops)`.
2563  - **Seed path** (alta nueva): comportamiento previo.
2564- **`commit_delete(entity, id)`**: emite `LogEntry::Morphism {
2565  name: "ui.delete_record", ops: [Delete { entity, id }] }` + apply.
2566- **Render del form**: título cambia a "Editar customer abc12345"
2567  cuando `editing` matchea; submit label cambia a "Guardar cambios
2568  en customer".
2569- **Render de la lista**: dos columnas nuevas — "id" y "acciones".
2570  Cada fila tiene ✎ (accent color, click → open_edit) y ✕ (rojo,
2571  click → commit_delete). Hover states.
2572
2573Ramificación visible en el event log:
2574```
2575{"kind":"seed","seq":0,"entity":"customer","id":"abc...","data":{"name":"Acme"}}
2576{"kind":"morphism","seq":1,"morphism":"ui.edit_record","ops":[
2577  {"op":"set","path":{"entity":"customer","id":"abc...","field":"name"},
2578   "value":"Acme S.A."}
2579]}
2580{"kind":"morphism","seq":2,"morphism":"ui.delete_record","ops":[
2581  {"op":"delete","entity":"customer","id":"abc..."}
2582]}
2583```
2584Coherente con el modelo de Nakui — todo cambio post-seed pasa por
2585ops dentro de Morphism. `nakui-explorer` muestra estos morphisms
2586con sus ops claros en su timeline.
2587
2588Trade-offs documentados:
2589- **`schema_hash: None`** sigue para los morphism de la UI (legacy/
2590  pre-versioning path) hasta que `Action::Morphism` cargue Manifest
2591  schemas.
2592- **Delete sin confirmación**: 1 click, sin modal. Para MVP es OK
2593  (los records son recuperables vía replay parcial), pero un futuro
2594  iter agregaría confirmación.
2595- **Edit sobreescribe TODOS los campos del form**, no sólo los
2596  cambiados — emite N ops Set, una por field. Adecuado para forms
2597  chicos; para forms con muchos campos optimizar a delta-only.
2598
2599Tests: 3 nuevos (10 totales en nakui-ui):
2600- `value_to_input_text_inverse_of_parse` y
2601  `value_to_input_then_parse_round_trip` — la propiedad fundamental
2602  del pre-llenado: text → parse devuelve el Value original.
2603- `event_log_replay_handles_full_crud_cycle` — E2E del log: escribe
2604  Seed + Morphism(Set ops) + Morphism(Delete op), replay desde cero,
2605  verifica que el store termina vacío (delete fue el último). Verifica
2606  además que un replay parcial (sin el delete) deja los valores
2607  editados.
2608
2609Activación:
2610```sh
2611NAKUI_EVENT_LOG=~/.nakui/state.jsonl \
2612NAKUI_MODULES_DIR=examples/nakui-modules \
2613cargo run -p nakui-ui
2614# Crear un customer, click ✎ en su fila, modificar campos,
2615# "Guardar cambios". Click ✕ en otra fila para borrar.
2616# Cerrar y reabrir: el state persiste con todos los cambios.
2617```
2618
2619### feat(nakui-ui): persistencia con event log + replay al startup
2620Cierra "sin persistencia entre runs" del commit anterior. Cada
2621`SeedEntity` se appendea al `nakui_core::event_log::EventLog` con
2622WAL semantics (log antes que store) y al re-abrir el binario el
2623replay reconstruye el `MemoryStore` desde cero. Cerrar y volver a
2624abrir ya no borra el data.
2625
2626Cambios:
2627- **`MetaUi.event_log: Option<Arc<Mutex<EventLog>>>`** nuevo.
2628  Compartido bajo `Mutex` para que el commit_seed pueda mutar.
2629- **Apertura + replay al startup** (`MetaUi::new`): path por env
2630  `NAKUI_EVENT_LOG`, default `./nakui-ui-state.jsonl`.
2631  `EventLog::open` + `replay_into` reconstruyen el store.
2632  Toast informativo: "log nuevo" o "log X cargado: N evento(s)
2633  replayed".
2634- **WAL en `commit_seed`**: si `event_log.is_some()`, primero
2635  `log.append(LogEntry::Seed { ..., schema_hash: None })`, después
2636  `store.seed`. Si el append falla, cancela toda la operación
2637  (el user reintenta sin haber dejado state inconsistente).
2638- **`schema_hash: None`**: documentado como path "legacy /
2639  pre-versioning" para seeds que no pasan por un Manifest+Executor.
2640  Es el path correcto para alta administrativa vía la metainterfaz
2641  hasta que `Action::Morphism` wireé el Manifest loader.
2642- **Degradación grácil**: si abrir log falla (permisos, disco),
2643  toast con error pero el runtime sigue en modo in-memory.
2644
2645Tests: 1 nuevo E2E `event_log_replay_restores_memory_store` que
2646escribe 2 seeds via `EventLog::append`, re-abre y `replay_into` un
2647store fresh, verifica que ambos records están con sus values
2648correctos. Reproduce el flujo del startup de `MetaUi::new` sin
2649necesitar GPUI. 7 tests verdes en nakui-ui.
2650
2651Activación con persistencia explícita:
2652```sh
2653NAKUI_EVENT_LOG=~/.nakui/state.jsonl \\
2654NAKUI_MODULES_DIR=examples/nakui-modules \\
2655cargo run -p nakui-ui
2656# Crear varios records vía el form, cerrar el binario, abrir de
2657# nuevo: los records están.
2658```
2659
2660Limitaciones que **siguen** (próximos iters):
2661- **`Action::Morphism`** sigue como TODO: requiere cargar el
2662  `Manifest` de nakui-core junto al `Module` UI para conocer los
2663  inputs/params declarados y poder llamar `execute_and_log`.
2664- **No hay snapshot/compaction**: el log crece append-only para
2665  siempre. Para repos grandes habría que integrar `Snapshot` de
2666  nakui_core (existe, no se usa todavía).
2667- **No hay UI para borrar/editar** records existentes — sólo alta
2668  vía form. Edit + delete en futuras iteraciones.
2669- **Widget input simple** (sin selection/IME/clipboard) — heredado
2670  de la limitación documentada de `yahweh-widget-text-input`.
2671
2672### feat(nakui-ui): inputs reales con yahweh-widget-text-input + click handlers funcionales
2673Cierra dos limitaciones documentadas en el commit anterior de la
2674metainterfaz: los formularios ahora aceptan teclado real, y los
2675clicks en menús + botones mutan estado correctamente.
2676
2677Cambios:
2678- **Inputs vivos**: cada `FieldSpec` del Form view materializa un
2679  `Entity<TextInput>` (de `yahweh-widget-text-input`) al entrar a la
2680  vista. Los entities se reemplazan al cambiar de view (drop limpio).
2681  El widget soporta: escribir caracteres, Backspace, Enter (Confirmed
2682  event — no usado todavía; el submit va por botón), Escape
2683  (Cancelled). El cursor se renderea como `|` al final.
2684- **Click handlers wired vía `cx.listener`**: menús del sidebar
2685  invocan `select_view`; botones de acción (header de list, submit
2686  de form) invocan `apply_action`. Los handlers tienen acceso real
2687  al `Context<MetaUi>` y mutan el modelo + emiten `cx.notify()`.
2688- **Submit lee texto de los inputs**: `commit_seed` reemplaza el
2689  buffer ad-hoc anterior por `input.read(cx).text()` por cada
2690  field. El value parseado va al `MemoryStore` con su tipo correcto
2691  (text/number/boolean/date).
2692- **Reset de inputs tras submit**: si la acción no tiene `next_view`,
2693  los inputs se vacían (`set_text("")`) para alta consecutiva sin
2694  re-tipear.
2695- **Hover states**: items del sidebar y botones cambian de bg al
2696  pasar el mouse, feedback visual consistente con el resto del
2697  ecosistema yahweh.
2698- **Theme global**: `Theme::install_default(cx)` al inicio (lo
2699  requiere el text_input para sus colores).
2700
2701Wire en Cargo:
2702- Deps nuevas: `yahweh-widget-text-input`, `yahweh-theme` (paths
2703  relativos al monorepo).
2704
2705Limitaciones que **siguen abiertas** (próximos iters):
2706- **`Action::Morphism`** sigue como TODO: requiere cargar el
2707  `Manifest` de nakui-core junto al `Module` UI para conocer los
2708  inputs/params declarados.
2709- **Sin persistencia entre runs**: `MemoryStore` en RAM. Wire con
2710  `EventLog` o `SurrealStore` queda para cuando exista el daemon
2711  Nakui.
2712- **Inputs simples**: el widget no soporta cursor positioning,
2713  selection, copy/paste, IME, multilínea. Para edits serios habrá
2714  que portar `gpui::examples::input` o adoptar `gpui-input` cuando
2715  exista upstream.
2716- **Enter no envía**: el `TextInputEvent::Confirmed` que emite el
2717  widget no está suscrito todavía; el submit va por click. Trivial
2718  de wirear si lo necesitamos.
2719
2720Tests: los 6 unit del runtime siguen verdes (parse_field_value para
2721los 5 kinds, lookup_field nested, render_value). El comportamiento
2722visual requiere correr el binario con `cargo run -p nakui-ui` y
2723probar a mano — GPUI no provee harness de UI testing en CI hoy.
2724
2725Activación full:
2726```sh
2727NAKUI_MODULES_DIR=examples/nakui-modules cargo run -p nakui-ui
2728# Click en un menú → carga vista. Click en "Nuevo" → form.
2729# Tipear en cada campo → ver el `|` al final. Click "Crear customer"
2730# → record aparece en la lista.
2731```
2732
2733### feat(nakui): metainterfaz declarativa + 6 módulos ERP estándar
2734Salto cualitativo: Nakui pasa de "library + demos + read-only viewer
2735del event log" a **plataforma ERP con UI dirigida por datos**. Cada
2736módulo de negocio se declara como un `module.json` (sin código Rust
2737nuevo) y el runtime GPUI lo carga dinámicamente: sidebar de menús,
2738listas con columnas configurables, formularios de alta.
2739
2740Tres entregables:
2741
2742**1) Crate nuevo `nakui-ui-schema`** (datos puros, ~250 LOC + 200
2743LOC tests):
2744- `Module { id, label, entities, menu, views }`.
2745- `View::List { entity, columns, actions, search_in }` o
2746  `View::Form { entity, fields, on_submit }`.
2747- `FieldSpec { name, label, kind, default, required, help }` con
2748  `FieldKind = Text|Multiline|Number|Boolean|Date`.
2749- `Action::OpenView | SeedEntity | Morphism` — el runtime las
2750  dispara desde botones / submits.
2751- `Module::from_path` parsea un JSON; `Module::validate` chequea que
2752  cada `MenuItem.view` exista en `views`.
2753- `load_modules_from_dir(dir)` busca `dir/<modulo>/module.json`,
2754  parsea, valida, detecta IDs duplicados, devuelve ordenado.
2755- 6 tests unit + 4 integration (los 6 demos cargan limpio, todos
2756  tienen list+form, kinds reconocidos, validate pasa).
2757
2758**2) Crate nuevo `nakui-ui`** (binario GPUI, ~700 LOC + 100 LOC tests):
2759- Carga módulos desde `NAKUI_MODULES_DIR` (default `./nakui-modules`).
2760- Sidebar con módulos + sus menús; click en menu cambia la vista activa.
2761- **List view**: tabla de instancias del entity con columnas
2762  weighted (header de columnas + filas + id corto).
2763- **Form view**: campos labeled + botón submit que dispara la action
2764  declarada (`SeedEntity` mete el record al `MemoryStore`
2765  in-process; `Morphism` queda como TODO hasta integrar el manifest
2766  loader nakui-core).
2767- `MemoryStore` compartido entre todas las vistas (Arc<Mutex>); el
2768  cambio en un módulo se refleja en otro inmediato.
2769- Toast + error banner para feedback.
2770- 6 tests unit (parse_field_value para los 5 kinds, lookup_field
2771  nested, render_value).
2772
2773**3) 6 módulos demo** en `examples/nakui-modules/` que cubren un
2774ERP estándar:
2775- **customers**: nombre, email, teléfono, activo, límite de
2776  crédito, notas.
2777- **products**: SKU, nombre, categoría, precio, stock, activo.
2778- **suppliers**: razón social, ID fiscal, contacto, email,
2779  teléfono, términos de pago.
2780- **inventory_movements**: fecha, tipo (in/out/adjustment), SKU
2781  producto, cantidad, costo unitario, motivo, doc. referencia.
2782- **sales_orders**: número, cliente, emisión, vencimiento,
2783  estado, subtotal, impuestos, total, notas.
2784- **invoices**: número, cliente, emisión, vencimiento, subtotal,
2785  impuestos, total, pagado, estado, moneda, orden referenciada.
2786
2787Cada módulo tiene su `list` (catálogo) + `form` (alta), con search
2788field y columns weighted. Los 6 cubren un setup de ERP de ventas
2789chico funcional para demo.
2790
2791Filosofía documentada:
2792- **UI como datos**: agregar un módulo = escribir un JSON, no
2793  recompilar el binario.
2794- **Persistencia universal**: el runtime conecta cada vista al
2795  `nakui_core::store::Store`; cambiar de MemoryStore a SurrealStore
2796  no toca los module.json.
2797- **Schema primero, semántica después**: `nakui-ui-schema` sólo
2798  define la forma; validación de referencias rotas (entity inexistente,
2799  morphism faltante) vive en el runtime.
2800
2801Activación:
2802```sh
2803NAKUI_MODULES_DIR=examples/nakui-modules cargo run -p nakui-ui
2804```
2805
2806Limitaciones conocidas (próximas iteraciones):
2807- **Inputs sin teclado**: GPUI no incluye text input; los forms
2808  muestran los `default` del schema y el submit usa esos. Próximo
2809  iter: integración con `yahweh-widget-text-input`.
2810- **Click handlers no wired**: GPUI necesita pasar `Entity<MetaUi>`
2811  a los handlers para mutar estado; refactor con `cx.listener` +
2812  weak refs queda para el próximo iter. Hoy la navegación es
2813  visual; el código de mutación sí funciona via API programática
2814  (los tests lo cubren).
2815- **Acción `Morphism`**: pendiente de cargar el `Manifest` de
2816  nakui-core junto con el `Module` UI para wirear `execute_and_log`.
2817- **Sin persistencia entre runs**: el `MemoryStore` se pierde al
2818  cerrar. Wire con `EventLog` o `SurrealStore` queda para cuando
2819  el daemon Nakui exista.
2820
2821Tests: 16 totales nuevos (10 schema + 6 runtime). 100% verde.
2822
2823Lo que esto desbloquea: cualquiera puede escribir un `module.json`
2824para su dominio (pacientes médicos, alumnos de escuela,
2825reservaciones de hotel) y aparece en la UI sin tocar Rust ni
2826recompilar. La forma de extender Nakui dejó de ser "agregar código
2827al ERP" y pasó a ser "escribir el contrato del módulo".
2828
2829### feat(nakui-explorer): nuevo binario GPUI — Nakui visible en la interfaz
2830Cierra "nakui no tiene UI propia" del audit. Nuevo binario standalone
2831`nakui-explorer` (paralelo a `nouser-explorer`) que renderea el
2832event log de un repo Nakui: timeline scrollable de seeds + morphisms
2833con sus parámetros, breakdown por entity type, polling cada 2s para
2834detectar nuevos eventos appended sin restart del explorer.
2835
2836Diseño:
2837- Lee directamente el archivo `.jsonl` del `nakui_core::event_log::EventLog`.
2838  Path por env `NAKUI_EVENT_LOG`, default `nakui.jsonl` en pwd.
2839- Sin discovery vía broker brahman porque nakui hoy es CLI/library/
2840  demos, no daemon. Cuando se daemonice, sustituir el lector de
2841  archivo por un sidecar consumer (mismo patrón que nouser-explorer
2842  actualmente usa).
2843
2844UI:
2845- **Header**: path del log, count total + breakdown seeds/morphisms,
2846  tiempo del último reload en ms.
2847- **Breakdown line**: top 5 buckets por frecuencia (entities + nombres
2848  de morphisms con prefijo `→`).
2849- **Timeline**: tarjetas color-coded por kind (azul=seed,
2850  verde=morphism). Cada tarjeta muestra `#seq`, kind, entity/morphism
2851  name, id corto (8 hex), preview del data/params (80 chars), schema
2852  hash corto (8 hex) o `(legacy)` si pre-versioning. Mostradas
2853  más-recientes-primero, hasta 200 visibles (suficiente para
2854  navegación; sin scroll virtualizado por ahora).
2855- **Error banner**: si la lectura falla (archivo inexistente o
2856  corrupto), banner rojo con el motivo. El explorer NO crashea —
2857  sigue intentando cada 2s.
2858
2859Wire en workspace:
2860- Nuevo `crates/apps/nakui-explorer/` agregado a `[workspace] members`.
2861- Deps mínimas: `nakui-core` (para EventLog + LogEntry), `gpui`,
2862  `serde_json`, `uuid` (con feature serde para parsear los IDs).
2863- Sin deps de brahman por ahora (Nakui standalone).
2864
2865Tests: 7 unitarios en `tests` mod del bin:
2866- `load_log_returns_all_entries_in_order` — cargar un .jsonl
2867  generado a mano, asserta que devuelve 5 entries con seqs 0..4
2868  contiguous.
2869- `breakdown_counts_seeds_morphisms_and_buckets` — verifica el
2870  conteo (3 seeds + 2 morphisms) y los buckets esperados.
2871- `load_missing_file_yields_empty_not_error` — archivo inexistente
2872  devuelve `[]` sin error (delegado al contrato de `EventLog::open`).
2873- `preview_value_truncates_long_strings` y `_keeps_short_strings_intact`.
2874- `short_uuid_takes_first_8_chars` y `short_hash_takes_first_4_bytes_hex`.
2875
2876Activación:
2877```sh
2878NAKUI_EVENT_LOG=/tmp/nakui_inv_xxx.jsonl cargo run -p nakui-explorer
2879```
2880
2881Estado del CHANGELOG global tras este commit: cero pendientes
2882fundamentados activos. Lo único que queda es `minga-vfs` (FUSE,
2883explícitamente diferido por el usuario) y mejoras nice-to-have
2884(cobertura adicional per-lenguaje, daemon-ización de nakui para
2885sidecar discovery).
2886
2887### feat(minga-core): α-hashing per-language para Python, TypeScript, JavaScript, Go
2888Cierra el último pendiente fundamentado del CHANGELOG. Cada lenguaje
2889soportado por `minga` tiene ahora su propio profile α-equivalente —
2890dos versiones del mismo programa que difieren sólo en nombres de
2891variables ligadas producen el mismo hash, no importa el lenguaje.
2892Refactorings tipo "rename variable" no inflan el storage del repo
2893en ningún dialecto.
2894
2895Refactor de `alpha.rs` (639 LOC) a módulo `alpha/`:
2896- **`alpha/common.rs`**: primitives compartidos (TAG_*, write_kind_and_field,
2897  emit_leaf_marker, emit_binder_body, emit_identifier_ref, push_identifier_name).
2898  Garantiza que el formato wire del hash sea bit-equivalente entre
2899  todos los profiles.
2900- **`alpha/rust.rs`**: la lógica de Rust (movida desde alpha.rs sin
2901  cambios funcionales).
2902- **`alpha/python.rs`**: nuevo.
2903- **`alpha/ecmascript.rs`**: nuevo (cubre TypeScript + JavaScript;
2904  comparten la mayoría de los kinds).
2905- **`alpha/go.rs`**: nuevo.
2906- **`alpha/mod.rs`**: re-exporta `hash_node_alpha` (Rust legacy) +
2907  expone `hash_alpha_with(dialect, node)` que despacha al profile
2908  correspondiente.
2909
2910Cobertura per-language:
2911
2912**Python** (`def`, `lambda`, `for`, comprehensions, `with`):
2913- `function_definition` y `lambda`: parámetros (incluyendo
2914  typed_parameter, default_parameter, *args, **kwargs) introducen
2915  binders al body. El nombre de la función NO es α-anónimo.
2916- `for_statement`: el `left` (identifier o tuple) introduce
2917  binder(es) al body.
2918- `list_comprehension`, `set_comprehension`, `dictionary_comprehension`,
2919  `generator_expression`: cada `for_in_clause` añade binders que
2920  viven en el body + clauses siguientes (semántica de scope
2921  incremental de Python).
2922- `with_statement`: `as` introduce binder al body (recursando en
2923  `as_pattern_target` para llegar al identifier).
2924
2925**ECMAScript** (TS + JS):
2926- `function_declaration`, `function_expression`, `method_definition`,
2927  `generator_function_*`: parameters → body. Soporta TS
2928  `required_parameter` y `optional_parameter` (`x: number`,
2929  `x?: number`).
2930- `arrow_function`: tanto `(x, y) => body` como shorthand `x => body`.
2931- `statement_block`: `lexical_declaration` (let/const) y
2932  `variable_declaration` (var) introducen binders al resto del block.
2933- `for_in_statement` (cubre `for-of` y `for-in`): `left` → body.
2934- `for_statement` (C-style): initializer (lexical decl) introduce
2935  binders al condition + increment + body.
2936- `catch_clause`: parameter → body.
2937
2938**Go**:
2939- `function_declaration`, `method_declaration`, `func_literal` (closure):
2940  `parameter_list` → body. `parameter_declaration` con varios names
2941  agrupa varios binders bajo un mismo tipo (`a, b int`).
2942- `block`: `short_var_declaration` (`x := ...`) introduce binders
2943  al resto.
2944- `for_statement` con `range_clause` (`for k, v := range m`): los
2945  identifiers del `left` son binders al body.
2946- `for_statement` con `for_clause` (C-style): initializer → body.
2947- `if_statement` con `initializer` (`if x := init(); x > 0`):
2948  binders viven en condition + consequence + alternative.
2949
2950API:
2951- `hash_alpha_with(Dialect, &SemanticNode) -> ContentHash` —
2952  despacho per-dialect.
2953- `hash_node_alpha(&SemanticNode) -> ContentHash` — alias histórico
2954  asume Rust (back-compat).
2955
2956Tests: 26 nuevos en `tests/alpha_polyglot.rs`:
2957- Python (9): def rename, lambda rename, for-loop rename, list comp,
2958  nested comp, with rename, function name matters, iterable name
2959  matters, sanity negativo (operación distinta → hash distinto).
2960- JS/TS (9): function rename, function name matters, arrow rename,
2961  arrow shorthand rename, let/const rename, for-of rename, classic
2962  for rename, catch rename, TS typed param rename, TS type matters.
2963- Go (6): function rename, function name matters, short var decl
2964  rename, range_clause rename, if-init rename, func_literal closure
2965  rename.
2966- Cross-language (1): mismos shapes en lenguajes distintos
2967  producen hashes distintos (sanity para evitar colisiones).
2968
2969141 tests verdes en minga-core (115 antes; +26 polyglot). Refactor
2970sin regresión: 36 α-Rust tests siguen pasando.
2971
2972Pendientes que quedan en Minga (orden de prioridad):
2973- `minga-vfs` FUSE (proyecto independiente, scope grande).
2974- Cobertura adicional por-lenguaje: Python class, JS destructuring,
2975  Go type_switch, etc. — cada uno pequeño, no urgente.
2976
2977### feat(minga-core): cierre del α-hashing de Rust — if let, while let, let-else, or-pattern, let-chains
2978Cierra los 5 pendientes documentados en `alpha.rs`. El hash
2979α-equivalente ahora es estable bajo renombre de TODOS los binders
2980de Rust, no sólo los del MVP (parámetros, let, for, match arms).
2981
2982Pendientes cerrados:
2983- **`if let X = expr { ... }`**: `if_expression` detecta
2984  `let_condition` en su `condition`, recolecta los binders del
2985  pattern, los propaga al `consequence`. El `alternative` (else)
2986  NO los ve.
2987- **`while let X = expr { ... }`**: simétrico al if-let, propaga al
2988  `body`. El `condition` mismo se evalúa con scope previo (los
2989  binders todavía no existen).
2990- **`let-else`**: `let_declaration` con campo `alternative`. El
2991  alternative se procesa con el scope ANTES de los binders (ya
2992  funcionaba: `feed_let` llama `feed` para no-pattern children con
2993  el scope actual; `feed_block` extiende el scope DESPUÉS de
2994  `feed_let`).
2995- **`or_pattern`**: en `pat1 | pat2` (Rust enforcement: ambos lados
2996  introducen los mismos binders). Para emit, recorremos cada lado
2997  con `feed_pattern`. Para collect, sólo el primer lado — iterar
2998  todos duplicaría binders y rompería los índices de Bruijn.
2999- **let-chains** (`if let X = a && let Y = b { ... }`): el
3000  `collect_let_condition_binders` recursa en el árbol del condition,
3001  capturando todos los `let_condition` (vivan dentro de
3002  `binary_expression` u otros nodos). Ambos binders quedan en scope
3003  del consequence.
3004
3005Helper nuevo: `feed_let_condition` para que el `pattern` del
3006let_condition pase por `feed_pattern` (que distingue binders vs
3007constructors). Sin esto, los identifiers del pattern se hasheaban
3008como variables libres y `Some(x)` ≠ `Some(y)` aún teniendo el
3009mismo significado.
3010
3011Tests: 6 nuevos en `tests/alpha_invariants.rs`:
3012- `alpha_if_let_binder_rename_invariant`
3013- `alpha_if_let_else_does_not_see_binder` (sanity)
3014- `alpha_while_let_binder_rename_invariant`
3015- `alpha_let_else_binder_rename_invariant`
3016- `alpha_or_pattern_binder_rename_invariant`
3017- `alpha_let_chain_binders_propagate_to_consequence`
3018- `alpha_if_let_does_not_collide_with_unrelated_program` (negativo:
3019  programas distintos NO deben dar el mismo hash)
3020
302136 tests α verdes (eran 30). 115 tests totales en minga-core.
3022
3023Lo que esto significa: el hash α-equivalente de Rust en minga es
3024**completo** — cubre todos los constructos del lenguaje que
3025introducen bindings. Dos versiones del mismo programa que difieren
3026sólo en nombres de variables (incluyendo en `if let`, `while let`,
3027`or-pattern`, etc.) producen el mismo hash y por tanto la misma
3028identidad CAS. Refactorings del tipo "rename variable" no inflan
3029el storage del repo.
3030
3031Pendientes futuros:
3032- α-hashing per-language (Python: def/lambda/comprehensions; TS/JS:
3033  function/arrow/destructuring; Go: func/closure). Cada uno
3034  requiere conocimiento profundo de la gramática y tests
3035  exhaustivos. Plantilla genérica no aplica.
3036
3037### feat(minga): multi-lenguaje en parser — Python, TypeScript, JavaScript, Go
3038Minga deja de ser Rust-only. Cualquiera de los cinco dialectos
3039(Rust + 4 nuevos) se ingresa al CAS por su AST normalizado, hashea
3040estructuralmente, sincroniza por DHT como cualquier nodo. La
3041auto-detección por extensión hace que `minga ingest archivo.py` o
3042`.ts` o `.go` "simplemente funcione".
3043
3044API nueva en `minga_core::parse`:
3045- Funciones por dialecto (~6 LOC c/u sobre el `parse_with` común):
3046  `python`, `typescript`, `javascript`, `go`. Más la `rust` existente.
3047- Enum `Dialect` con `parse(source) -> Result<SemanticNode>` y
3048  `name() -> &'static str` para logging.
3049- `detect_by_extension(ext) -> Option<Dialect>`: mapea `rs`/`py`/
3050  `pyi`/`ts`/`js`/`mjs`/`cjs`/`go` (case-insensitive). `None` para
3051  extensiones desconocidas — el caller decide si es error o se
3052  ignora silente.
3053
3054Wire en `minga-cli`:
3055- `cmd_ingest` deja de hardcodear `parse::rust` — usa
3056  `detect_dialect(file)?.parse(...)`. Acepta `.py`, `.ts`, `.js`,
3057  `.go` además de `.rs`.
3058- `initial_scan` y `cmd_watch` cambian `is_rs_file` → `is_supported_source`
3059  para incluir todas las extensiones soportadas en el filtro.
3060- `CliError::UnsupportedLanguage { path, extension }` nuevo, con
3061  mensaje que lista las extensiones reconocidas.
3062
3063Notas sobre hashing:
3064- El AST normalizado (`SemanticNode`) descarta whitespace y
3065  comentarios — propiedad universal de tree-sitter (extras). Misma
3066  lógica para los 5 dialectos.
3067- Hashing **estructural** (`cas::hash_node`) funciona para todos:
3068  dos textos semánticamente equivalentes-por-estructura producen el
3069  mismo hash. NO α-equivalente (las variables ligadas distinguen).
3070- Hashing **α-equivalente** (`alpha::hash_node_alpha`) sigue siendo
3071  Rust-only: cada lenguaje tiene reglas distintas para qué es
3072  binder vs. constructor (def/lambda en Python, arrow functions en
3073  TS/JS, func + closures en Go). Implementación per-language queda
3074  como work futuro — requiere conocimiento profundo de cada
3075  gramática y no se plantilla genéricamente.
3076- Sanity test `structural_hash_distinguishes_languages` verifica
3077  que `x = 1` parseado como Python ≠ parseado como JavaScript: las
3078  gramáticas no comparten kinds y los hashes salen distintos.
3079  Importante para evitar colisiones cuando el mismo source se
3080  ingresa bajo dialectos distintos.
3081
3082Deps nuevas (workspace + minga-core):
3083- `tree-sitter-python = "0.23"`
3084- `tree-sitter-typescript = "0.23"` (sólo el modo `LANGUAGE_TYPESCRIPT`,
3085  no TSX — bumpear a TSX es agregar otro dialecto cuando se necesite).
3086- `tree-sitter-javascript = "0.23"`
3087- `tree-sitter-go = "0.23"`
3088
3089Tests:
3090- 9 nuevos en `parse::tests`: parse básico para los 5 dialectos
3091  (Python con type hints, TS con tipos, JS sin tipos, Go con
3092  package declaration), `detect_by_extension` canonical +
3093  case-insensitive, `dialect_name`, `structural_hash_distinguishes_languages`.
3094- 108 tests verdes en minga-core (39 → 48 unit + integration tests
3095  pre-existentes intactos).
3096- 10 tests verdes en minga-cli (sin regresión en el path Rust;
3097  el refactor a `detect_dialect`/`is_supported_source` no rompe
3098  nada).
3099
3100Pendientes futuros del changelog:
3101- α-hashing per-language (Python: def/lambda/comprehensions;
3102  TS/JS: function/arrow/destructuring; Go: func/closure). Trabajo
3103  profundo, scope independiente.
3104- α-Rust pendientes documentados en `alpha.rs`: `if let`,
3105  `while let`, `let-else`, let-chains, `or_pattern` con bindings.
3106
3107### feat(brahman-handshake): multi-key identity — rotación de session sin perder peer_id lógico
3108Cierra el último pendiente del plan de red P2P. Hasta ahora, rotar
3109la keypair libp2p de un nodo cambiaba su `peer_id`, lo que
3110invalidaba todas las allowlists/denylists remotas que lo
3111referenciaban. Imposible rotar sin coordinar con todos los pares.
3112
3113Solución: separar **identity master** (Ed25519 persistente forever,
3114identifica al nodo como entidad lógica) de **session libp2p**
3115(Ed25519 efímera, rotable). El master firma certs de session con
3116expiración. La política de admisión se evalúa contra el
3117`master_peer_id` del cert — el session peer_id puede cambiar
3118libremente sin tocar las allowlists.
3119
3120API nueva en `brahman_handshake::identity`:
3121- `Identity::from_keypair(master)` — wrapper sobre la master kp.
3122- `Identity::master_peer_id()` — el peer_id estable del nodo.
3123- `Identity::issue_session_cert(session_kp, ttl) -> SessionCert` —
3124  firma un cert que vincula session_pubkey + expires_at_ms.
3125- `SessionCert::verify()` — chequea versión, firma criptográfica,
3126  no expiración. Devuelve `(master_peer_id, session_peer_id)`.
3127- `SessionCert::verify_against_session(expected_session_pk)` — verify
3128  + exige que el cert vincule esa session pubkey (previene reuso de
3129  certs ajenos con keypairs distintas).
3130- `CertError` tipado: `UnknownVersion`, `DecodeMaster`,
3131  `DecodeSession`, `InvalidSignature`, `Expired`, `SessionMismatch`,
3132  `Sign`.
3133- `DEFAULT_SESSION_TTL = 24h`.
3134
3135Wire:
3136- `Hello.identity_cert: Option<SessionCert>` agregado (default None,
3137  back-compat).
3138- `Client::connect_with_stream_signed_with_cert(stream, card, wit,
3139  session_kp, cert)` — variante que adjunta el cert.
3140- `network::connect_libp2p_with_cert(net, peer, card, wit,
3141  session_kp, cert)` — paralelo a `connect_libp2p`.
3142
3143Server (`do_handshake`):
3144- Nuevo paso ANTES del policy gate: si `Hello.identity_cert.is_some()`,
3145  se verifica con `verify_against_session(&hello.signature.public_key)`.
3146  El `logical_peer` que se evalúa contra la policy es el
3147  `master_peer_id` derivado, NO el session peer_id.
3148- Sin cert (path Fase 3): `logical_peer = expected_peer` (compat).
3149- Si el cert es inválido (firma rota, expirado, session mismatch),
3150  rechazo con `Unauthorized` antes de evaluar policy.
3151- Migración gradual: clientes sin cert siguen funcionando contra
3152  servers con policy basada en session peer_ids.
3153
3154Canonicalización del payload firmado:
3155```
3156[u8 version][b"sess"][u32 LE session_pubkey_len][session_pubkey][u64 LE expires_at_ms]
3157```
3158`SESSION_CERT_VERSION = 1` documenta el esquema; cualquier cambio
3159fuerza bump (clientes viejos no validan certs nuevos).
3160
3161Sobre el swarm-level deny:
3162- El `block_list` del swarm sigue operando con session peer_ids
3163  (Noise sólo conoce eso). Si la operatoria lista master_peer_ids
3164  en deny, el handshake-level gate los para; el swarm-level no.
3165  El operador elige granularity: listar masters = robust a
3166  rotaciones; listar sessions = rechazo más temprano.
3167
3168Tests: 8 unit en `identity::tests`:
3169- `issue_and_verify_cert` — roundtrip básico, peer_ids derivados.
3170- `verify_against_session_admits_matching` y
3171  `_rejects_mismatch` — el cert vincula 1 sola session pubkey.
3172- `cert_with_zero_ttl_is_expired` — expiración chequeada con tiempo
3173  real.
3174- `tampered_signature_rejected` y `tampered_expires_at_rejected` —
3175  cualquier mutación del cert post-firma falla.
3176- `unknown_version_rejected` — schema versionado defensivamente.
3177- `rotated_session_with_same_master_yields_same_master_peer_id` —
3178  la propiedad fundamental: rotar session NO cambia master_peer_id.
3179
3180Plus 1 E2E definitivo en `network_libp2p.rs`:
3181`identity_cert_allows_session_rotation_without_policy_change`.
3182- A configura `policy = allowlist[B.master_peer_id]` (master, no
3183  session).
3184- B se conecta con session1 + cert(master, session1) → admitido.
3185  Sesión registrada, farewell limpio.
3186- B "rota": genera session2 ≠ session1, mismo master, emite cert2.
3187- B se conecta con session2 + cert2 → admitido también, **sin que
3188  A toque su allowlist**.
3189- Sanity: una session sin cert (cuyo session_peer NO está en allow)
3190  es rechazada.
3191
319240 tests verdes en brahman-handshake + brahman-net (24 unit
3193incluyendo identity + 7 handshake + 3 discovery + 6 libp2p
3194incluyendo rotation E2E). Ningún regreso.
3195
3196Wire en Arje queda como follow-up: ente-zero hoy es server-only y
3197no necesita identity (su keypair libp2p ya es estable vía
3198keypair_store). Cuando algún módulo de Arje haga conexiones
3199salientes con cert, se cargará la identity master separada de la
3200session vía nueva env `BRAHMAN_IDENTITY_PATH`. La API ya está
3201lista.
3202
3203### feat(brahman-net+handshake): swarm-level deny — la denylist se proyecta al block_list de libp2p
3204Optimización de seguridad: la denylist ya no espera al handshake
3205brahman para rechazar — ahora se proyecta al `block_list` behaviour
3206del swarm libp2p. Conexiones desde peers baneados son rechazadas
3207**antes del Noise handshake**, ahorrando el round-trip TCP+Noise
3208por cada intento denegado.
3209
3210Wire de bajo nivel (`brahman-net`):
3211- Nuevo behaviour `block_list: allow_block_list::Behaviour<BlockedPeers>`
3212  añadido al `BrahmanBehaviour` derivado. Vive junto a `stream`,
3213  `kad`, `identify`. Default vacío al construir.
3214- Nuevos comandos `BlockPeer(PeerId)` y `UnblockPeer(PeerId)` en el
3215  enum interno + handlers que llaman
3216  `swarm.behaviour_mut().block_list.{block_peer,unblock_peer}`.
3217- API pública: `BrahmanNet::block_peer(peer)` y
3218  `BrahmanNet::unblock_peer(peer)`. Idempotentes.
3219- Dep nueva: `libp2p-allow-block-list = "0.6"` (sub-crate, no es
3220  feature de `libp2p` en 0.56).
3221
3222Wire en la política (`brahman_handshake::peer_policy`):
3223- `PeerPolicy` gana campo opcional `net: Arc<RwLock<Option<Arc<BrahmanNet>>>>`.
3224  Default `None` para preservar callers existentes.
3225- Nuevo método `attach_to_net(net: Arc<BrahmanNet>)`:
3226  - Sincronización inicial: itera la deny actual y llama
3227    `net.block_peer(p)` por cada uno.
3228  - Guarda el net para diff-sync en cada `reload`.
3229- `reload()` extendido: snapshot de `prev_deny` ANTES de mutar el
3230  inner. Tras la mutación, llama `sync_deny_to_swarm(prev, new)`
3231  que aplica `block_peer` por cada added y `unblock_peer` por cada
3232  removed.
3233- Atomicidad preservada: si un archivo falla al parsear, el sync
3234  no ocurre y la versión anterior persiste tanto en la policy
3235  como en el block_list del swarm.
3236
3237Wire en Arje (`ente-zero`):
3238- Tras setup_brahman_net + setup_brahman_policy, si AMBOS están
3239  presentes se llama `policy.attach_to_net(net.clone())` con un log
3240  informativo. Sin policy o sin net, no hay attach (modo abierto
3241  o solo gate-level deny).
3242
3243Tests: 1 nuevo E2E en `network_libp2p.rs`:
3244`swarm_level_deny_blocks_before_noise`. A configura policy con
3245deny de un peer + attach_to_net. Cliente baneado intenta
3246`connect_libp2p`; en lugar del `HandshakeError::Unauthorized` que
3247recibíamos antes (que requería completar Noise primero), ahora
3248falla con error de transporte/stream (o timeout, según timing) —
3249el dial nunca completa porque el swarm rechaza la conexión.
3250
32515 tests verdes en `network_libp2p.rs` (roundtrip, mismatched signing,
3252allowlist, denylist handshake-level, denylist swarm-level). 31 tests
3253totales en brahman-handshake + brahman-net. Sin regresión en
3254ente-zero.
3255
3256Trade-offs:
3257- **Más eficiente** contra DoS: un atacante que prueba miles de
3258  peer_ids no consume CPU del Noise handshake.
3259- **Misma fuente de verdad**: la denylist sigue viviendo en
3260  `PeerPolicy` (un solo archivo, hot-reloadable). El swarm es un
3261  cache derivado que se actualiza vía diff. No hay drift posible —
3262  cada reload re-sincroniza atómicamente.
3263- **El handshake-level gate sigue activo** como segunda línea: si
3264  por alguna razón un peer baneado pasa el block_list (race entre
3265  reload y nueva conexión, o bug del crate), el handshake brahman
3266  igual lo rechaza con `Unauthorized`. Defensa en profundidad.
3267
3268Pendientes futuros del changelog:
3269- Rotación de keypair sin perder peer_id (multi-key identity).
3270
3271### feat(brahman-handshake+ente-zero): denylist + hot reload de la política de peers
3272Consolida `PeerAllowlist` + nueva `PeerDenylist` en un único
3273`PeerPolicy` con allow + deny + hot reload vía `notify`. Cubre los
3274dos pendientes documentados en el commit anterior y simplifica la
3275API hacia un sólo punto de entrada.
3276
3277API consolidada en `brahman_handshake::peer_policy`:
3278- `PeerPolicy::open()` — todo permitido (default).
3279- `PeerPolicy::from_sets(allow: Option<BTreeSet<PeerId>>, deny: BTreeSet<PeerId>)`
3280  — política inline para tests.
3281- `PeerPolicy::from_files(allow_path?, deny_path?)` — carga ambos
3282  archivos opcionales.
3283- `PeerPolicy::evaluate(peer) -> Decision` — `Admit |
3284  DeniedByDenylist | NotInAllowlist`. Decision lleva su `reason()`
3285  para logging consistente.
3286- `PeerPolicy::reload()` — recarga atómica desde los paths
3287  asociados. **Si un archivo falla, conserva la versión anterior**
3288  (un typo no debe tirar al Init en modo inseguro).
3289- `PeerPolicy::spawn_watcher() -> JoinHandle` — vigila los
3290  archivos vía `notify`, debounce 250ms (coalesce de los varios
3291  eventos típicos de un save), recarga atómica al detectar cambio.
3292
3293Orden de evaluación (deny-first):
32941. Si `peer ∈ denylist` → `DeniedByDenylist`.
32952. Si hay allowlist y `peer ∉ allowlist` → `NotInAllowlist`.
32963. Resto → `Admit`.
3297
3298Esto significa que **deny gana sobre allow**: un peer en ambas listas
3299es rechazado. Diseño explícito para que la denylist sea la primitiva
3300de "kill switch" — agregar un peer al deny lo banea inmediatamente
3301sin importar dónde más esté listado.
3302
3303Watcher: vigila el **directorio padre** del archivo, no el archivo
3304mismo. Razón: editores típicos hacen rename-and-replace (escriben
3305a tmp y rename al destino), lo que rompe el watch del archivo pero
3306no el del dir. Filtra eventos por path al procesar.
3307
3308Wire en server:
3309- `ServerConfig.allowlist` → `ServerConfig.policy: Option<PeerPolicy>`
3310  (breaking rename, scope local al monorepo). Gate en `do_handshake`
3311  llama `policy.evaluate(&peer)` y usa `decision.reason()` para el
3312  mensaje de error tipado.
3313
3314Wire en Arje (`ente-zero`):
3315- Nueva env `BRAHMAN_PEER_DENYLIST` complementa
3316  `BRAHMAN_PEER_ALLOWLIST`. Cualquiera (o ambas) activa la política.
3317- `setup_brahman_policy()` carga + arranca watcher. Devuelve
3318  `(policy, JoinHandle)`; el handle se guarda en main para que el
3319  thread no se aborte.
3320- Failure modes degradan a "modo abierto" (sin política) con log,
3321  preservando la doctrina PID 1.
3322
3323Activación end-to-end con todas las capas activas:
3324```sh
3325BRAHMAN_LISTEN_MULTIADDR=/ip4/0.0.0.0/tcp/4101 \
3326BRAHMAN_PEER_ALLOWLIST=/etc/brahman/allow.txt \
3327BRAHMAN_PEER_DENYLIST=/etc/brahman/deny.txt \
3328ente-zero
3329# El operador puede editar deny.txt en caliente y la nueva regla
3330# entra en efecto en ~250ms sin restart del Init.
3331```
3332
3333Tests: 10 unit en `peer_policy::tests`:
3334- `open_admits_anyone`, `allow_only_admits_listed`,
3335  `deny_overrides_open`, `deny_overrides_allow` (deny-first
3336  semantics).
3337- `from_files_with_both_lists`, `from_files_only_deny`,
3338  `invalid_file_rejected_at_load`.
3339- `reload_picks_up_changes` — manualmente recarga y verifica.
3340- `reload_failure_preserves_previous_state` — invariante de
3341  seguridad: archivo roto NO baja la política activa.
3342- `watcher_reloads_on_file_change` — E2E del watcher con notify
3343  real: muta archivo, espera < debounce + margen, verifica que
3344  la política refleja el cambio sin haber llamado reload manualmente.
3345
3346Plus 1 E2E nuevo en `network_libp2p.rs`:
3347`libp2p_handshake_denylist_blocks_listed_peer` — A configura
3348`policy = PeerPolicy::from_sets(None, [banned_peer])`. Cliente
3349con keypair baneada es rechazado; cliente con keypair distinta
3350pasa el handshake.
3351
335230 tests verdes en brahman-handshake (16 unit + 7 handshake + 3
3353discovery + 4 libp2p incluyendo allowlist + denylist E2E). Sin
3354regresión en ente-zero.
3355
3356Lo que cierra esta entrega:
3357- Política completa de admisión: open / allow-only / deny-only /
3358  allow+deny.
3359- Hot reload sin restart del Init — el operador puede banear/admitir
3360  peers en caliente editando archivos.
3361- Atomicidad: la recarga es del paquete `(allow, deny)` completo, no
3362  de cada lista por separado. No hay momento donde una lista esté
3363  vieja y la otra nueva.
3364- Resiliencia: errores de parseo NO bajan la política activa.
3365
3366Pendientes futuros del changelog:
3367- Aplicar la política a nivel de swarm vía `libp2p_allow_block_list::
3368  Behaviour` (rechazar ANTES del Noise handshake, ahorrar el
3369  round-trip TCP+Noise por intento denegado).
3370- Rotación de keypair sin perder peer_id (multi-key identity).
3371
3372### feat(brahman-handshake+ente-zero): allowlist explícita de peers libp2p
3373Capa de política sobre el trust criptográfico de Fase 3. Hasta ahora
3374cualquier peer con keypair Ed25519 válida pasaba el handshake remoto;
3375con allowlist activa, sólo los peers explícitamente listados. Aplica
3376únicamente al path libp2p — el path Unix sigue usando SO_PEERCRED
3377del kernel, que es autenticación de proceso local, no de red.
3378
3379API nueva en `brahman_handshake::peer_allowlist`:
3380- `PeerAllowlist::from_iter([peer_id, ...])` para tests/inline.
3381- `PeerAllowlist::from_file(path)` parsea texto plano: un PeerId
3382  base58 por línea, `#` para comentarios (línea entera o inline),
3383  líneas vacías ignoradas. Errores de parseo incluyen número de
3384  línea para debug rápido.
3385- `is_allowed(peer)`, `len()`, `is_empty()`, `iter()`.
3386- `AllowlistError { Io, InvalidPeerId }`.
3387
3388Wire en el server:
3389- `ServerConfig.allowlist: Option<PeerAllowlist>`. `None` = modo
3390  abierto (compat con todo lo anterior). `Some` = sólo los listados.
3391- Gate en `do_handshake` ANTES de la verificación de firma — la
3392  comparación O(log n) en BTreeSet es más barata que crypto, así
3393  que rechazamos peers inválidos antes de gastar ciclos. Se devuelve
3394  `HandshakeError::Unauthorized("peer X no está en la allowlist")`.
3395
3396Wire en Arje (`ente-zero`):
3397- Nueva env var `BRAHMAN_PEER_ALLOWLIST` apuntando a un archivo.
3398- `setup_brahman_allowlist()` carga al startup; degrada a `None`
3399  (modo abierto) si el archivo falla, consistente con la doctrina
3400  PID 1 de no romper por subsistemas opcionales.
3401
3402Ejemplo de archivo de allowlist:
3403```text
3404# Peers permitidos en la malla brahman de prod-eu-1
3405# Generados con: ente-zero (peer_id loggeado al arrancar)
340612D3KooWFooBarBazFooBarBazFooBarBazFooBarBazFooBarBaz
340712D3KooWQuxQuxQuxQuxQuxQuxQuxQuxQuxQuxQuxQuxQuxQuxQux  # operador 2
3408```
3409
3410Activación end-to-end:
3411```sh
3412BRAHMAN_LISTEN_MULTIADDR=/ip4/0.0.0.0/tcp/4101 \\
3413BRAHMAN_PEER_ALLOWLIST=/etc/brahman/allowlist.txt \\
3414ente-zero
3415```
3416
3417Tests:
3418- 6 unit en `peer_allowlist::tests`: from_iter, parse limpio, parse
3419  con comentarios inline, parse rechaza PeerId inválido (y reporta
3420  número de línea), I/O error en archivo faltante, empty list
3421  rechaza todo.
3422- 1 E2E en `network_libp2p.rs`:
3423  `libp2p_handshake_allowlist_admits_listed_rejects_others`. A
3424  configura `allowlist = [allowed_peer]`. Cliente con keypair
3425  permitida pasa el handshake (sesión registrada, farewell limpio).
3426  Segundo cliente con keypair distinta es rechazado con error
3427  ANTES de que se le verifique la firma. Sanidad: el conteo de
3428  sesiones del server queda en 0 tras el rechazo.
3429
343025 tests verdes en brahman-handshake (12 unit + 7 handshake legacy
3431+ 3 discovery + 3 libp2p). Ningún regreso en ente-zero (4/4
3432keypair_store).
3433
3434Pendiente futuro:
3435- Denylist explícita (negada — banear peers específicos sin tener
3436  que listar a todos los demás).
3437- Hot reload de la allowlist sin restart del Init (signal SIGHUP o
3438  watch del archivo).
3439- Aplicar la política a nivel de swarm vía
3440  `libp2p_allow_block_list::Behaviour` para rechazar conexiones
3441  ANTES del Noise handshake (hoy se rechaza después, gastando un
3442  round-trip TCP+Noise por cada intento denegado).
3443
3444### feat(brahman-net+handshake): stop_providing automático en cleanup de sesión
3445Cierra el pendiente conocido del DHT: hasta ahora cuando una sesión
3446con outputs cerraba (Farewell, EOF, error), el record que la
3447anunciaba en el DHT seguía vivo hasta su TTL natural (~24h en kad
3448default). Consumers remotos podían descubrir un peer "vivo" que ya
3449no servía nada.
3450
3451Cambios:
3452- **`BrahmanNet::stop_providing(key)`** (nuevo): contraparte simétrica
3453  de `start_providing`. Manda `Command::StopProviding` al swarm que
3454  llama `kad.stop_providing(&key)`. Borra el record del provider
3455  store local al instante; replicas en peers remotos siguen
3456  expirando por TTL (kad no expone retracción cross-peer, simétrico
3457  al hecho de que `start_providing` también propaga eventualmente).
3458- **`brahman_handshake::network::withdraw_outputs(net, card)`**
3459  (nuevo): contraparte de `announce_outputs`. Itera `card.flow.output`
3460  y llama `net.stop_providing(flow_dht_key(...))` por cada uno.
3461- **`server::cleanup`**: extrae la `ResolvedCard` removida del registro
3462  de sesiones (en lugar de descartarla con `remove`) y, si
3463  `config.net` está set, llama `withdraw_outputs(net, &card)` antes
3464  de `broadcast_match_diffs`.
3465
3466Tests: nuevo E2E `dht_discovery_withdraws_on_session_cleanup`:
34671. A registra Card con `flow.output = monad-list:json`.
34682. B descubre a A vía `find_remote_providers` — confirma
3469   `before.contains(&a_peer)`.
34703. Cliente local de A hace `farewell` → cleanup → withdraw_outputs.
34714. Espera a que la sesión salga del registro (señal de cleanup
3472   completado) + 100ms para que el swarm procese el Command.
34735. Nueva query desde B: `after` NO debe contener `a_peer`.
3474
34753 tests verdes en `network_discovery.rs` (positivo, negativo,
3476withdraw). 18 tests totales en handshake + net.
3477
3478Pendiente futuro: retracción cross-peer en kad (requeriría extensión
3479del protocolo libp2p, no soportada hoy). Aceptable: simétrico al
3480modelo de propagación eventual del DHT.
3481
3482### feat(ente-zero): wire de Arje con brahman-net (red P2P opcional + identidad persistente)
3483Cierra el último pendiente del plan de red: Arje ahora puede arrancar
3484opcionalmente con `BrahmanNet` configurado, persistir su identidad
3485libp2p entre reboots, y participar en la malla brahman como nodo
3486público. Sin breaking changes: usuarios actuales (sin env vars) siguen
3487viendo el comportamiento Unix-only de antes.
3488
3489Activación por env vars:
3490- **`BRAHMAN_LISTEN_MULTIADDR`** — si set, activa la red P2P. Ej:
3491  `/ip4/0.0.0.0/tcp/4101` (público), `/ip4/127.0.0.1/tcp/0` (loopback,
3492  port aleatorio). Sin la var, `brahman_net = None` y todo sigue
3493  como antes.
3494- **`BRAHMAN_KEYPAIR_PATH`** — override del path donde se persiste
3495  la keypair Ed25519 de identidad libp2p del nodo. Defaults sensatos:
3496  - PID 1 (root): `/var/lib/brahman/init-keypair.bin`.
3497  - Dev mode: `$XDG_DATA_HOME/brahman/init-keypair.bin` →
3498    `$HOME/.local/share/brahman/init-keypair.bin` →
3499    `/tmp/brahman-init-keypair.bin` (último recurso).
3500- **`BRAHMAN_BOOTSTRAP_PEERS`** — lista coma-separada de multiaddrs
3501  para dial-ear al arranque y entrar al DHT. Sin esto, el nodo
3502  arranca aislado hasta que alguien se conecte a él.
3503
3504Comportamiento al activarse:
35051. `keypair_store::load_or_generate(path)` carga la keypair de disco
3506   o genera+persiste una nueva (32 bytes raw, permisos 0o600,
3507   atomic rename). Reboots conservan el `peer_id`.
35082. `BrahmanNet::with_keypair(kp)` arma el swarm con esa identidad.
35093. `net.listen(multiaddr)` espera dirección resuelta y la loggea.
35104. `BRAHMAN_BOOTSTRAP_PEERS` (si set) → dial a cada multiaddr.
35115. El handshake server se levanta con `ServerConfig.net = Some(net)`,
3512   que activa `announce_outputs` automático en el DHT por cada Card
3513   con outputs.
35146. Además del Unix accept loop (existing), se monta un libp2p accept
3515   loop sobre el mismo `Server` compartido. Sesiones locales y
3516   remotas conviven en las mismas tablas (sessions, push_table,
3517   broker, last_matches).
3518
3519Refactor del Unix accept loop: antes consumía el server vía
3520`server.run().await`; ahora usa `Arc<Server>::accept_one().await` en
3521loop para coexistir con el libp2p accept loop sin moverse el server.
3522
3523Degradación grácil en cada paso: si la keypair no carga, si el
3524multiaddr es inválido, si el listen falla, si el bootstrap dial
3525revienta — loggeamos y seguimos en modo Unix-only. La doctrina de
3526PID 1 ("ningún subsistema opcional rompe el bucle primordial") se
3527mantiene.
3528
3529Tests: 4 unit en `keypair_store`:
3530- `generate_persist_and_reload_yields_same_peer_id` — peer_id estable
3531  across reloads (la propiedad fundamental).
3532- `rejects_corrupted_file` — archivo de tamaño incorrecto rechazado.
3533- `persisted_file_is_owner_only` — permisos 0o600 verificados.
3534- `default_path_honors_env` — `BRAHMAN_KEYPAIR_PATH` override
3535  respeta tanto dev como root mode.
3536
3537Ente-zero compila clean. Ningún test del workspace regresa.
3538
3539Lo que esto desbloquea hoy:
3540- Para activar Arje como nodo público, basta:
3541  ```sh
3542  BRAHMAN_LISTEN_MULTIADDR=/ip4/0.0.0.0/tcp/4101 ente-zero
3543  ```
3544- Cualquier consumer (en otra máquina) puede luego dial-ar a ese
3545  multiaddr + descubrir Cards anunciadas via DHT + abrir handshake
3546  remoto firmado.
3547- La identidad del nodo (su `peer_id`) sobrevive reboots, así que
3548  los nodos remotos pueden cachear "este peer_id es Arje en
3549  máquina X" sin invalidarse cada vez.
3550
3551Pendientes futuros:
3552- `stop_providing` al cleanup de sesión (records DHT con TTL ~24h).
3553- Allowlist/Denylist de peers (PKI explícito).
3554- Rotación de keypair sin perder peer_id (multi-key identity).
3555
3556### feat(brahman-handshake): Fase 3 — trust remoto vía firma Ed25519 anclada al peer libp2p
3557Cuarto y último paso del plan "el encuentro entre Entes no se
3558restringe a local". Cierra la falla de seguridad que dejaba la red
3559P2P abierta: hasta ahora, un atacante que pudiera dial-ar al
3560multiaddr del Init podía registrar cualquier Card con cualquier
3561label/flow. Fase 3 cierra esto exigiendo que el Hello vía libp2p
3562venga firmado con la **misma keypair Ed25519 que produce el
3563`peer_id` autenticado por Noise**.
3564
3565Modelo:
3566- **Local Unix**: SO_PEERCRED del kernel autentica al cliente. Firma
3567  opcional. Si está presente, igual se verifica (defensa en
3568  profundidad).
3569- **Remoto libp2p**: firma obligatoria. La public key del Hello debe
3570  derivar al `peer_id` que Noise ya autenticó. Si falta o no coincide
3571  → `HandshakeError::Unauthorized`.
3572
3573Wire (`brahman_handshake::messages`):
3574- `Hello.signature: Option<HelloSignature>` (nuevo, default None).
3575- `HelloSignature { public_key: Vec<u8>, signature: Vec<u8> }` —
3576  public_key en formato canónico libp2p (`encode_protobuf`), firma
3577  Ed25519 sobre `(SIGNATURE_VERSION, WireCard, Option<WitInterface>)`
3578  serializado postcard.
3579- `SIGNATURE_VERSION = 1` documenta el esquema del payload firmado;
3580  bump al cambiar.
3581
3582Nuevo módulo `brahman_handshake::signature`:
3583- `sign_hello(keypair, card, wit) -> HelloSignature`.
3584- `verify_hello(sig, card, wit, expected_peer) -> Result<(), SignatureError>`.
3585- `SignatureError` tipado (`DecodeKey`, `EncodePayload`, `Invalid`,
3586  `PeerMismatch`, `Missing`, `Unexpected`).
3587
3588Server:
3589- `Session<S>` gana `expected_peer: Option<PeerId>`.
3590- `Server::session_from_libp2p_stream(stream, peer)` (nuevo)
3591  construye Session con `expected_peer = Some(peer)`.
3592  `session_from_stream` (Unix/in-memory) sigue con `None`.
3593- `do_handshake` exige firma + verifica peer match cuando
3594  `expected_peer.is_some()`. Si no, verifica firma presente por
3595  consistencia interna pero no exige que esté.
3596- `network::run_libp2p_accept_loop` ahora usa
3597  `session_from_libp2p_stream(stream.compat(), peer)` para propagar
3598  la identidad libp2p al gate de trust.
3599
3600Client:
3601- `Client::connect_with_stream_signed(stream, card, wit, &Keypair)`
3602  (nuevo) firma el Hello antes de mandarlo.
3603- `Client::connect_with_stream` sigue existiendo sin firma (path
3604  Unix / tests).
3605- `Client::connect`/`connect_with` (Unix) no cambian — siguen sin
3606  firma porque SO_PEERCRED autentica.
3607- `network::connect_libp2p(net, peer, card, wit, keypair)`
3608  **breaking change**: gana parámetro `keypair: &Keypair`.
3609
3610BrahmanNet:
3611- Almacena la `Keypair` en `Arc<Keypair>` (libp2p Keypair no es
3612  Clone; el truco es duplicar el `ed25519::Keypair` interno que sí
3613  es Clone, una copia para Noise/swarm y otra para signing).
3614- `BrahmanNet::keypair() -> Arc<Keypair>` accessor para que callers
3615  puedan firmar con la misma identidad libp2p del nodo sin tener
3616  que mantener la keypair por separado.
3617- `with_keypair` rechaza keypairs no-Ed25519 (RSA/ECDSA/Secp256k1
3618  vendrían a futuro si se necesitan).
3619
3620Tests:
3621- 4 unit en `signature::tests`: roundtrip propio, peer mismatch,
3622  card tampered, signature flipped.
3623- 1 E2E nuevo en `tests/network_libp2p.rs`:
3624  `libp2p_handshake_rejects_mismatched_signing_key` — el cliente
3625  intenta firmar con keypair distinta a la del net; server rechaza.
3626- E2E positivo (`libp2p_handshake_roundtrip`) ahora pasa la keypair
3627  del client_net y debe verificar OK.
3628- Discovery + handshake legacy + signature: 90+ tests verdes en
3629  brahman-handshake/brahman-net/brahman-card/minga-p2p.
3630
3631Lo que esto cierra:
3632- Brahman-net es una malla públicamente dial-able **con
3633  autenticación criptográfica end-to-end**: Noise para el transport,
3634  Ed25519 para las Cards.
3635- La cadena completa de discovery + connect + trust funciona
3636  cross-machine sin paths hardcodeados ni confianza implícita.
3637- El plan original ("el encuentro entre Entes no se restringe a
3638  local, la ejecución remota está pensada desde el principio")
3639  está implementado y testeado.
3640
3641Pendientes (futuro, no de hoy):
3642- `stop_providing` al cleanup de sesión (records DHT viven hasta
3643  TTL ~24h).
3644- Wire de Arje (`ente-zero`) para arrancar opcionalmente con
3645  `BrahmanNet` configurado y `ServerConfig.net = Some(...)`.
3646- Allowlist/Denylist de peers (hoy cualquier peer Ed25519-válido
3647  pasa el trust gate; producción podría querer un PKI explícito).
3648- Persistencia de la keypair de identidad del nodo entre reboots.
3649
3650### feat(brahman-handshake): Fase 2 — discovery remoto vía DHT por flow type
3651Tercer paso del plan "el encuentro entre Entes no se restringe a
3652local". Cuando un Init local acepta una sesión cuya Card declara
3653outputs, anuncia al DHT (Kademlia, vía `brahman-net`) que él provee
3654esos flow types. Cualquier nodo conectado al mismo DHT puede
3655consultar y obtener la lista de `PeerId`s que sirven el flow.
3656
3657API nueva en `brahman_handshake::network`:
3658- `flow_dht_key(flow_name, type_ref) -> [u8; 32]`: blake3 hash de
3659  `"brahman-flow|v1|{flow}|{type_canon}"`. Determinístico cross-host.
3660  Cambiar la canonicalización rompe compatibilidad — el prefijo `v1`
3661  documenta la versión del esquema y obliga a bump al modificar.
3662- `announce_outputs(net, card)`: llama `start_providing` en el DHT
3663  por cada `Flow` en `card.flow.output`. Idempotente, fire-and-forget.
3664- `find_remote_providers(net, flow_name, type_ref) -> Vec<PeerId>`:
3665  query DHT por la key derivada. Lista vacía si nadie anuncia o si
3666  la query no resuelve dentro del timeout interno de Kad.
3667
3668Wire en el server:
3669- `ServerConfig` gana `pub net: Option<Arc<BrahmanNet>>`. Si está set,
3670  cada Card registrada con outputs se anuncia automáticamente al DHT
3671  desde `register_session`. `None` = server "ciego al DHT" (correcto
3672  cuando no hay conectividad o el operador no quiere exponer).
3673- `ServerConfig` ahora tiene `Debug` manual (BrahmanNet no implementa
3674  Debug; loggeamos sólo presencia/ausencia).
3675
3676Canonicalización del TypeRef:
3677- `Primitive { name }` → `prim:{name}`
3678- `Wit { package, interface, name }` → `wit:{package}#{interface_or_empty}#{name}`
3679
3680Tests: 2 nuevos en `tests/network_discovery.rs`:
3681- `dht_discovery_finds_remote_provider`: dos nodos, A registra Card
3682  con `flow.output = monad-list:json`, B dial-ea a A y descubre el
3683  `peer_id` de A vía `find_remote_providers`. Asserts contains.
3684- `dht_discovery_negative_unknown_flow`: B busca un flow que nadie
3685  anunció, devuelve lista vacía sin colgarse.
3686
3687Lo que esto desbloquea:
3688- Un `nouser daemon` corriendo en máquina A puede ser descubierto por
3689  un `nouser-explorer` en máquina B sin conocimiento previo del peer
3690  — sólo necesitan compartir DHT (vía bootstrap inicial).
3691- La cadena completa "explorer → daemon → llm-provider" puede cruzar
3692  máquinas, no sólo procesos.
3693
3694Lo que queda para Fase 3 (trust):
3695- Cards remotas se aceptan hoy sin verificación. Para producción se
3696  necesita firma Ed25519 sobre la Card y verificación antes de
3697  aceptar el Hello remoto. Local sigue confiando en SO_PEERCRED.
3698- Stop-providing al cleanup de sesión (hoy records DHT viven hasta
3699  TTL ~24h aunque la sesión cierre).
3700
3701### feat(brahman-handshake): Fase 1 — handshake brahman sobre stream libp2p
3702Segundo paso del plan "el encuentro entre Entes no se restringe a
3703local". El protocolo brahman (Hello / HelloAck / Ping / Pong /
3704MatchEvent / Farewell, frames postcard length-prefixed) ahora también
3705viaja sobre streams libp2p de la malla `brahman-net` — el mismo Init
3706acepta sesiones por Unix socket Y por libp2p indistintamente, y un
3707consumer remoto puede dial-ar al multiaddr y completar handshake.
3708
3709Cambios:
3710- **`Session<S>` y `Client<S>` genéricos**: ambos dejan de estar atados
3711  a `UnixStream` y pasan a ser genéricos sobre `S: AsyncRead +
3712  AsyncWrite + Unpin + Send + 'static`. El path Unix queda como
3713  `Client = Client<UnixStream>` (default genérico). Constructores
3714  nuevos: `Server::session_from_stream(stream)`,
3715  `Client::connect_with_stream(stream, card, wit)`.
3716- **Refactor del post-handshake con split**: `tokio::select!` sobre
3717  `&mut self.stream` requería `S: Sync` indirectamente, y
3718  `libp2p::Stream` no es Sync. Reemplazado por
3719  `tokio::io::split(stream)` → reader loop principal + writer task
3720  separada que drena el push channel. Writer compartido bajo
3721  `Arc<Mutex<WriteHalf<S>>>` para serializar Pong/Error inline con
3722  los MatchEvents pusheados. Cleanup garantizado en todas las ramas.
3723  La lógica del post-handshake migra a funciones libres
3724  (`run_post_handshake`, `handle_inbound_frame`, `cleanup`,
3725  `broadcast_match_diffs`, `do_handshake`, `register_session`,
3726  `validate_hello`).
3727- **Nuevo módulo `brahman-handshake::network`**:
3728  - `BRAHMAN_HANDSHAKE_PROTOCOL = "/brahman/handshake/1.0.0"`.
3729  - `LibP2pHandshakeStream = Compat<libp2p::Stream>` (alias del
3730    stream una vez convertido al mundo `tokio::io`).
3731  - `run_libp2p_accept_loop(server, net)`: bucle accept sobre el
3732    protocolo que delega cada stream entrante a una `Session`
3733    construida vía `server.session_from_stream(stream.compat())`.
3734    Sesiones libp2p y Unix conviven en el mismo `Server` —
3735    comparten broker, push table, last_matches.
3736  - `connect_libp2p(net, peer, card, wit)`: abre stream libp2p al
3737    `peer` y arranca handshake.
3738  - `NetworkError` tipado (`OpenStream`, `Handshake`, `AcceptStream`).
3739
3740Deps: `brahman-handshake` gana `brahman-net`, `futures`, `tokio-util`.
3741`brahman-net` re-exporta `Multiaddr`, `PeerId`, `Stream`,
3742`StreamProtocol`, `Protocol`, `OpenStreamError` para que callers no
3743necesiten dep directa a libp2p.
3744
3745Tests:
3746- 9 tests unit + integration verdes (sin regresión en el path Unix).
3747- Nuevo `tests/network_libp2p.rs`: test E2E que arma server con
3748  Unix socket + BrahmanNet, hace listen TCP, monta el accept loop;
3749  cliente con su propio BrahmanNet dial-ea al peer_id, completa
3750  handshake remoto, pinguea, farewell. Verifica que la sesión se
3751  registró durante la conversación y se removió tras farewell.
3752
3753Próximo: Fase 2 (discovery remoto vía DHT — anunciar Cards bajo
3754flow type, broker query local + remoto).
3755
3756### feat(brahman-net): capa P2P compartida — Fase 0 (extracción del swarm libp2p)
3757Primer paso del plan "el encuentro entre Entes no se restringe a local".
3758El swarm libp2p que vivía dentro de `minga-p2p::network` (282 LOC) sale
3759a una crate compartida `brahman-net` para que cualquier protocolo de la
3760familia (handshake brahman remoto en Fase 1, sync minga, futuros) reuse
3761una sola malla TCP+Noise+Yamux+Kad+Identify+Stream.
3762
3763Diseño:
3764- `BrahmanNet::{new, with_keypair}` arma el swarm con DHT en modo
3765  Server, Identify auto-poblando el routing table de Kad, y un
3766  `stream::Control` accesible para que cada protocolo registre su
3767  `StreamProtocol` y abra/acepte streams sin acoplarse al swarm.
3768- API de comandos uniforme: `dial`, `listen`, `add_dht_peer`,
3769  `find_closest_peers`, `start_providing`, `find_providers`.
3770- Pública: `peer_id` (libp2p) + `control` (stream::Control).
3771- Re-exporta `Stream` y `StreamProtocol` para que callers no necesiten
3772  importar libp2p directo.
3773
3774Migración:
3775- `minga-p2p::network` reduce de 282 LOC a 22: ahora sólo re-exporta
3776  `BrahmanNet` bajo el alias histórico `LibP2pNode` (zero churn en
3777  `MingaPeer`) y declara la const `SYNC_PROTOCOL = "/minga/sync/1.0.0"`
3778  específica del sub-protocolo Minga.
3779- Cualquier consumer que necesite armar un nodo P2P puede importar
3780  `brahman_net::BrahmanNet` directo sin pasar por minga.
3781- Deps de `minga-p2p` ganan `brahman-net`; el resto del grafo
3782  (libp2p, libp2p-stream, futures, tokio-util) sigue igual porque
3783  `MingaPeer` aún los usa para la lógica específica de sync.
3784
3785Aclaración semántica anclada por el usuario: **Arje** es el init
3786(PID 1, runtime, ente-zero/kernel/soma); **Brahman** es el encuentro
3787entre Entes (handshake/broker/card/sidecar/ahora también net). El
3788nombre de la crate refleja que la malla pertenece al encuentro, no
3789al runtime — Arje puede usar la malla, Minga usa la malla, cualquier
3790futuro módulo (Nakui remoto, p.ej.) la usa, sin acoplarse a Minga.
3791
3792Tests: minga-p2p completo verde (58 tests, sin regresión). Behavior
3793verificado idéntico — sólo se movió código, ningún cambio funcional.
3794Próximo: Fase 1 (handshake brahman sobre libp2p stream).
3795
3796### refactor(explorer+card): independencia jerárquica enforced — cliente con los wire types + fallback al default path
3797Cierra el único debt estructural detectado en el audit de
3798independencia: `nouser-explorer` ya no arrastra `nouser-core`
3799(que aportaba `notify`/`walkdir`/`sled`/`blake3` al grafo de
3800compilación de una UI que sólo habla JSON contra un socket).
3801
3802Cambios:
3803- **Cliente movido**: `engine_socket::client::list_monads` (~60 LOC,
3804  std + serde_json puros) emigra de `nouser_core::engine_socket` a
3805  `nouser_card::query::client`. Vive donde viven los wire types,
3806  consistente con el principio "un consumer importa el contrato,
3807  no el runtime del productor".
3808- **Drop dep**: `nouser-explorer` deja de dependener de
3809  `nouser-core`. Verificado con `cargo tree`: `notify`, `sled`,
3810  `blake3` desaparecen del grafo del binario. (`walkdir` sigue
3811  pero llega vía `gpui_util` → `rust-embed`, fuera de nuestro
3812  control y pre-existente.)
3813- **Fallback "falla hacia la simplicidad"**: nueva función
3814  `resolve_socket()` en el explorer intenta primero broker
3815  discovery; si el broker no responde / no hay init vivo,
3816  fallback directo a `nouser_card::query::transport::default_socket_path()`.
3817  El explorer queda funcional contra un daemon "huérfano"
3818  (corriendo standalone sin init) — completa la cadena
3819  "consciente cuando hay ecosistema, soberano cuando está solo".
3820- `socket_source` en el header gana un tercer estado
3821  `"default-path"` para que el usuario vea por dónde se conectó.
3822
3823Audit estructural confirmó que el resto del ecosistema ya
3824respeta el principio: todos los `yahweh-*` viewers, `minga-cli`,
3825`minga-core`, `nouser-card`, `nouser-nous`, los providers
3826`nouser-nous-{mock,real}` y `nakui-core` corren standalone con
3827soft-fail hacia infra brahman cuando está ausente. Brahman es
3828"pegamento opcional, no chasis obligatorio" — y ahora el grafo
3829de Cargo lo enforcea, no sólo la convención.
3830
3831Tests: 4 (sidecar) + 10 (nouser-card) + 27 (nouser-core) verdes.
3832El cliente movido se ejercita end-to-end por los 3 tests integración
3833de `engine_socket` (importa ahora `nouser_card::query::client`).
3834
3835### feat(explorer+daemon): discovery dinámico vía broker + query socket
3836La UI deja de hardcodear el socket admin: ahora descubre al daemon
3837nouser vía `MatchEvent::Available` del broker brahman y le consulta
3838sus Mónadas directo, sin pasar por brahman-admin. Cierra el "explorer
3839encuentra al daemon de forma totalmente dinámica" del meta-plan.
3840
3841Pipeline end-to-end:
3842- Daemon publica engine Card con `service_socket = $XDG_RUNTIME_DIR/nouser-engine.sock`
3843  y `flow.output = monad-list:json`.
3844- Daemon binda un Unix socket en ese path y monta un listener
3845  blocking que sirve `nouser_card::query::QueryRequest::ListMonads`,
3846  responde `ListMonadsResponse { engine, monads: Vec<MonadView> }`.
3847- Explorer construye un consumer Card con `flow.input = monad-list:json`
3848  vía `brahman_sidecar::build_consumer_card`, llama
3849  `await_provider_blocking(card, 3s)` y recibe el socket descubierto.
3850- Cachea ese socket; cada poll (2s) llama
3851  `nouser_core::engine_socket::client::list_monads(socket, 2s)`.
3852  Fallo de query → invalida cache → próximo tick re-descubre.
3853
3854Wire types nuevos en `nouser_card::query`:
3855- `QueryRequest::ListMonads` (single variant por ahora).
3856- `ListMonadsResponse { engine: EngineInfo, monads: Vec<MonadView> }`.
3857- `MonadView`: proyección slim de `MonadManifest` SIN `centroid` ni
3858  `members` — la UI no los necesita y eran KB por Mónada que no
3859  tenían por qué viajar cada poll.
3860- `transport::default_socket_path()` con env override
3861  `NOUSER_ENGINE_SOCKET`.
3862- Const `FLOW_MONAD_LIST = "monad-list"`, `FLOW_TYPE_NAME = "json"`.
3863
3864Listener en `nouser_core::engine_socket`:
3865- `spawn_listener(config, db)` arma std::os::unix::net::UnixListener
3866  en thread blocking dedicado. Frecuencia esperada (UI cada 2s) no
3867  amerita tokio.
3868- `client::list_monads(socket, timeout)` — cliente blocking con
3869  `QueryError` tipado (Connect / Io / Serde / Daemon / Timeout / Empty).
3870- 3 tests integración: roundtrip vacío, Mónadas reales, request
3871  inválido devuelve ErrorResponse.
3872
3873Refactor explorer:
3874- Drop dep `brahman-admin`, add deps `brahman-sidecar`, `nouser-card`,
3875  `nouser-core`.
3876- State: `socket: Option<PathBuf>` cache + `snapshot: Option<ListMonadsResponse>`
3877  + `socket_source: "discovery"|"cache"` (sólo informativo).
3878- Tick: `tick(prior_socket)` separado del UI, devuelve un enum
3879  `TickOutcome::{Ok, DiscoveryFailed, QueryFailed}`. Cualquier
3880  fallo invalida la cache → re-discovery automática.
3881- Header reformulado: `Engine 'nouser_engine'  ·  N mónada(s)  ·
3882  socket: /...  (cache|discovery)  ·  watching: /tmp/x`.
3883- Render pintado de un engine card + Mónadas, sin ya iterar
3884  `BrokeredCard` del admin.
3885
3886Trade-offs aceptados:
3887- Polling 2s (no streaming). El broker no empuja cambios de Data
3888  cards hoy; agregar streaming requiere extender el protocolo
3889  handshake. Para snapshot UI, polling 2s es suficiente.
3890- Re-descubrimiento full en cada error de query (en lugar de retry
3891  con backoff). Discovery es barato (~ms vs broker), no vale la
3892  pena la complejidad.
3893
3894Tests: 10 (nouser-card, +3 query) + 27 (nouser-core, +3 engine_socket)
3895+ 4 (sidecar) verdes. Explorer compila clean.
3896
3897### feat(nous-real): cache de embeddings + write-through al CAS de arje
3898Cierra el ciclo de la crítica del usuario: "Si un archivo no ha
3899cambiado su hash en el CAS, Nouser ni siquiera debería pedirle al
3900LLM que re-genere el embedding". El modelo real
3901(`fastembed-allMiniLML6V2-384d`, ~1-50ms por archivo) era invocado
3902ciegamente en cada re-cluster del watcher. Ahora se cachea por
3903`sha256(bytes-vistos) + model_id`.
3904
3905Pipeline en `handle_file`:
39061. Lee primeros 8 KiB (igual que antes).
39072. `file_sha = ente_cas::sha256_of(buf)` — hash de los bytes que el
3908   modelo *realmente* verá (no del archivo completo). Garantiza
3909   que un archivo creciendo más allá de la ventana sin tocar la
3910   cabeza siga sirviendo cache hits.
39113. Cache lookup: HIT → respuesta en ~µs.
39124. MISS → `ente_cas::store(&buf)` (write-through al CAS de arje,
3913   no-fatal si falla) → `backend.embed_one(text)` → `cache.put(...)`.
3914
3915Backend de cache: sled local en
3916`$XDG_CACHE_HOME/brahman/nouser-nous-real-embed-cache.sled`. Tree
3917versionado `embed_cache_v1`; el `MODEL_ID` viaja en la key, así que
3918cambiar de modelo invalida el cache implícitamente. Override por env
3919`NOUSER_NOUS_REAL_CACHE`.
3920
3921Encoding compacto: cada `Vec<f32>` se serializa como bytes
3922little-endian (4B por f32, sin overhead). Para el modelo default
3923(384-d) son 1.5 KiB por entry. Decode tolera bytes corruptos
3924(longitud no-múltiplo de 4 → `None`, no panic).
3925
3926Por qué sled y no `ente-cas` directo: el CAS de arje es flat
3927sha256-keyed; la cache necesita un mapeo `(file_sha, model_id) →
3928embedding`, no expresable como entry CAS. El write-through a CAS
3929queda como registro consultable + futura GC.
3930
3931API:
3932- `EmbedCache::open()` → abre sled, idempotente.
3933- `EmbedCache::open_at(dir)` para tests.
3934- `EmbedCache::get(sha, model)` → `Option<Vec<f32>>`.
3935- `EmbedCache::put(sha, model, &[f32])` → no-fatal en error.
3936- `EmbedCache::len()` → contador para logs (best-effort).
3937
3938Mock NO se modifica — su embedding pseudo-32d es metadata-hashing
3939puro, sin costo. Cachearlo sería overhead.
3940
3941Tests: 5 unitarios (`roundtrip_returns_same_vector`, `miss_returns_none`,
3942`different_models_do_not_collide`, `different_content_different_keys`,
3943`corrupted_value_returns_none`). Verdes con `--features embeddings`;
3944stub mode (sin feature) sigue compilando sin tocar cache.
3945
3946### chore(nakui): alinear `nakui-core` con `[workspace.package]` y deps compartidas
3947Cleanup de drift de convenciones: `nakui-core` era el único crate del
3948monorepo que mantenía `version = "0.1.0"` / `edition = "2021"` /
3949`thiserror = "1"` hardcoded, mientras el resto heredaba del workspace
3950y usaba `thiserror = "2"`. Eso significaba que un bump global de versión
3951o de edition se olvidaba sistemáticamente de nakui.
3952
3953Cambios:
3954- `[package]`: `version`, `edition`, `rust-version`, `license`, `authors`,
3955  `publish` → todos `*.workspace = true`. Agregado `description` (cumple
3956  convención del resto de crates).
3957- Deps compartidas migradas a `{ workspace = true }`: serde, serde_json,
3958  thiserror (v1→v2), tokio, ulid, sha2.
3959- `uuid` migrado a `{ workspace = true, features = ["serde"] }` — la
3960  feature `serde` no está en el workspace dep porque nakui es el único
3961  user; queda local opt-in en lugar de inflar el dep común.
3962- Deps específicas de nakui (sin compartición posible): rhai, petgraph,
3963  surrealdb permanecen inline con versión local.
3964
3965Verificación: `cargo build -p nakui-core` verde tras el bump de
3966`thiserror` v1→v2 — el `#[derive(Error)]` de los 14+ enums de error
3967en nakui no requirió ajustes (la API de derive es backwards-compatible
3968para los patrones simples). `cargo test -p nakui-core --lib`: 27/27
3969verdes, sin regresión.
3970
3971### feat(card): `Card::new(label)` — alternativa segura a `Default::default()`
3972Cierra la trap documentada de `Card::default()` que devuelve `id =
3973Ulid::nil()`. Usar `Card::default()` "viva" colisionaba con cualquier
3974otra Card default-construida bajo el mismo id `00000000…`. La fix no
3975es romper `Default` (sigue siendo determinista, requerido por callers
3976que lo usan como template para deserialización), sino agregar un
3977constructor explícito:
3978
3979  let card = Card {
3980      kind: CardKind::Data,
3981      payload: Payload::Embedded(json),
3982      ..Card::new("mi-modulo.algo")
3983  };
3984
3985`Card::new(label)` asigna `id = Ulid::new()` (único) + `label`
3986provisto, dejando el resto en defaults seguros (Virtual / OneShot /
3987Ente). Pensado para usarse en struct-literals con override parcial,
3988igual sintaxis que el patrón viejo pero sin la trap.
3989
3990Refactor de call sites:
3991- `brahman_sidecar::discovery::build_consumer_card` → `..Card::new(label)`
3992- `nouser daemon::build_engine_card` → `..Card::new("brahman.nouser_engine")`
3993
3994`Default` se mantiene tal cual con docstring expandida que advierte
3995explícitamente sobre el uso "vivo" y apunta a `Card::new`. Tests
3996existentes y el patrón `nouser_card::MonadManifest::to_brahman_card`
3997(que asigna el id estable de la Mónada, no uno fresco) NO se
3998modifican — `Default` sigue siendo correcto cuando el caller
3999sobreescribe `id` explícitamente.
4000
4001Tests: 3 unitarios nuevos en brahman-card (`new_assigns_real_ulid_and_label`,
4002`new_yields_distinct_ids_per_call`, `default_keeps_nil_id_for_struct_update_pattern`).
400315 tests verdes (era 12).
4004
4005### feat(sidecar): API reusable de discovery vía broker
4006Promueve el patrón ad-hoc `discover_producer_socket` (que vivía
4007inline en `nouser attract --remote`) a un módulo público
4008`brahman_sidecar::discovery`. Cualquier consumer puede ahora
4009preguntar al broker "¿quién provee este TypeRef?" con dos llamadas:
4010
4011  // Construir un consumer Card mínimo (Ente, Oneshot, Virtual)
4012  let card = brahman_sidecar::build_consumer_card(
4013      "mi-cli",
4014      "embed-result",   // flow.input.name
4015      "json",            // TypeRef::Primitive { name }
4016  );
4017
4018  // Bloqueante (CLIs, std-thread loops):
4019  let socket: PathBuf = brahman_sidecar::await_provider_blocking(
4020      card, Duration::from_secs(3),
4021  )?;
4022  // O async (módulos con runtime tokio propio):
4023  let socket = brahman_sidecar::await_provider(card, timeout).await?;
4024
4025API:
4026- `build_consumer_card(label, flow_name, type_name) -> Card`
4027  abstrae la verbosidad del struct-literal repetido en cada caller.
4028  Genera un `id: Ulid::new()` real (no nil → seguro contra
4029  colisiones en el broker).
4030- `await_provider(card, timeout) -> Result<PathBuf, ConsumerError>`
4031  conecta al init, espera `MatchEvent::Available`, devuelve
4032  `producer_service_socket`, manda Farewell. Ignora eventos
4033  `Lost` durante el await (no aplican al arranque).
4034- `await_provider_blocking(card, timeout)` arma su propio
4035  runtime `current_thread` para mundos no-async.
4036- `ConsumerError` con variantes tipadas: `Connect { socket, source }`,
4037  `NoProvider { flow, type_ref, timeout }`, `Client(ClientError)`,
4038  `Runtime(String)`. Adiós al `Box<dyn Error>` de antes.
4039
4040Refactor en `nouser daemon`:
4041- `discover_producer_socket` (60 LOC inline en `bin/nouser.rs`) → 5
4042  líneas que delegan en el helper.
4043- `remote_embed` ya no construye su propio runtime tokio.
4044
4045Próximo consumer natural: `nouser-explorer`. Hoy renderea
4046`StatusSnapshot` vía socket admin (introspección pura). El día que
4047quiera **interactuar** con un Ente — p. ej., disparar un re-embed
4048desde la UI — usa este helper para resolver el socket del provider
4049sin hardcodear paths.
4050
4051Nota sobre identidad: este commit fuerza `Ulid::new()` para los
4052consumer Cards generados, evitando la trampa documentada del
4053`Card::default()` que devuelve `Ulid::nil()`. La fijación global de
4054`Default` queda como cleanup separado (requiere auditar que ningún
4055caller dependa del determinismo de `nil`).
4056
4057Tests: 4 unitarios nuevos en `discovery::tests` (id no-nil, id
4058único por llamada, formateo de TypeRef::Wit, fallback sin input).
4059Workspace verde.
4060
4061### feat(nouser+sidecar): watcher con debounce + re-publish al broker
4062Cierra las dos limitaciones del watcher previo: ya no spamea N veces por
4063una sola edición, y el broker ve los cambios estructurales en lugar de
4064quedarse con manifests congelados al arranque.
4065
4066  $ nouser daemon /tmp/x &
4067  $ touch /tmp/x/src/a.rs /tmp/x/src/b.rs /tmp/x/src/c.rs
4068  # daemon log (un solo batch, no 9 reacciones):
4069  [watcher] ⚙ batch: 6 path(s) coalescidos → re-scan
4070  [watcher] ✦ x/src nace (3 miembros, lens=Code)
4071  [watcher] ⌃ delta: 1 nuevas, 0 refrescadas, 0 cerradas — 3 sesiones vivas
4072
4073Mecánica del debounce (150ms):
4074- `spawn_fs_watcher` arma dos threads: **dispatcher** filtra eventos
4075  notify Create/Modify/Remove a un canal de paths; **coordinator**
4076  mantiene `HashMap<PathBuf, Instant>` y dispara batch sólo cuando
4077  todos los paths llevan ≥150ms quietos.
4078- Un `:w` típico de vim (~5 eventos por archivo) colapsa a 1 batch.
4079
4080Mecánica del re-publish:
4081- `SidecarPool` ahora trackea `HashMap<Ulid, AbortHandle>` indexado
4082  por `Card.id`. Llamar `pool.spawn(card)` con un id ya presente
4083  aborta la sesión previa y abre una nueva — `spawn` se vuelve
4084  idempotente: re-publicar una Mónada cuya composición cambió
4085  refresca su sesión en el broker sin dejar zombies.
4086- Nueva API `pool.drop_session(id)` para cerrar una sesión
4087  explícitamente cuando una Mónada desaparece (directorio quedó
4088  bajo `min_files` o se borró).
4089- `pool.live_sessions()` para introspección/logs.
4090- `process_change_batch` re-scanea + re-clusteriza con hidratación,
4091  diffea contra prior_monads, y para cada Mónada decide:
4092  - removida → `drop_session`
4093  - nueva → `spawn` con ✦
4094  - composición cambió (members o centroid distintos) → `spawn` con ↻
4095  - idéntica → no-op
4096
4097Trade-off aceptado: re-scan global por batch (no incremental). Es
4098O(N archivos) por evento y para árboles típicos (<10k) cae en
4099<100ms. Optimizar a re-cluster parcial cuando duela.
4100
4101Tests: workspace completo verde.
4102
4103### feat(nouser): notify watcher — el sistema reacciona en tiempo real
4104El daemon ahora monta un `notify::recommended_watcher` recursivo
4105sobre el directorio. Cada `Create`/`Modify` de archivo regular
4106dispara: embedding del archivo, filtro por `centroid_model`, ranking
4107contra centroides existentes, log con marker 🧲 / · según supere
4108el umbral de atracción.
4109
4110  $ nouser daemon /tmp/x &
4111  # en otra terminal:
4112  $ vim /tmp/x/src/nuevo.rs
4113  # daemon log:
4114  [watcher] 🧲 /tmp/x/src/nuevo.rs  →  x/src  (0.7470)
4115
4116  $ echo "edit" >> /tmp/x/docs/n1.md
4117  [watcher] 🧲 /tmp/x/docs/n1.md  →  x/docs  (0.8169)
4118
4119Mecánica:
4120- DB pasa a `Arc<Mutex<MonadDb>>` para sharing con el thread del
4121  watcher.
4122- Watcher en thread dedicado (`nouser-watcher`); reacciona sólo a
4123  Create/Modify, ignora Access/Metadata-only.
4124- `react_to_change(path, metadata, db)` computa embedding,
4125  filtra por `centroid_model`, busca best attraction.
4126- No re-publica al broker ni muta DB — sólo observa y narra. La
4127  invalidación selectiva (re-cluster + replace_monads + diff
4128  publish) queda como work futuro.
4129
4130Limitación conocida: `notify` emite múltiples eventos por una sola
4131edición (Create + Modify, etc.). Sin debounce, el watcher reporta
4132varias veces. Aceptable para demo; production conviene debounce
4133~100ms por path.
4134
4135Tests: 7 (card) + 24 (core) verdes, 0 errores, 0 warnings.
4136
4137### feat(nouser): hidratación del daemon vía sled + path_hint
4138El daemon ya no recomputa ciegamente al arrancar. Si la DB tiene
4139Mónadas previas con `centroid_model` válido, las publica instantáneo
4140y el re-scan reusa sus IDs vía `path_hint`.
4141
4142Schema:
4143- `MonadManifest.path_hint: Option<String>` — identidad estable
4144  derivada del origen (para `by_directory`, el parent dir
4145  canónico). Permite reusar ULID across re-scans.
4146
4147Algoritmo (cluster):
4148- Nueva fn `cluster::by_directory_hydrated(files, min_files,
4149  prior: Option<&MonadDb>)`. Cuando hay `prior`, busca Mónada con
4150  mismo `path_hint` Y mismo `centroid_model`; si la encuentra,
4151  reusa `id`, `lineage` y `created_at_ms`.
4152- `by_directory` queda como wrapper sin hidratación (back-compat).
4153
4154Daemon (cmd_daemon):
41551. Open sled si NOUSER_DB_PATH existe.
41562. Publica las Mónadas previas con `centroid_model` válido (las
4157  inválidas se descartan con log explícito).
41583. Re-scan + `by_directory_hydrated(prior=&db)`.
41594. Sólo spawnea sidecars para Mónadas con id que NO estaba en la
4160  hidratación inicial. Los path_hints existentes preservan identidad,
4161  evitando duplicados en el broker.
41625. Persiste el set actualizado.
4163
4164Validación end-to-end:
4165
4166  $ NOUSER_DB_PATH=/tmp/h.sled nouser daemon crates/core
4167  # arranque 1: DB vacía
4168    re-scan 102 archivos → 5 mónadas
4169    1 ente + 5 mónadas vivas (5 nuevas vs hidratación)
4170
4171  $ NOUSER_DB_PATH=/tmp/h.sled nouser daemon crates/core
4172  # arranque 2: DB poblada
4173    hidratadas 5 mónadas previas en O(1)
4174    re-scan 102 archivos → 5 mónadas
4175    1 ente + 5 mónadas vivas (0 nuevas vs hidratación)
4176
4177Costo del arranque 2: ~0.06s user CPU. Antes (sin hidratación) era
4178re-scan + cluster + spawn x N — segundos enteros para árboles grandes.
4179
4180Tests: 7 (card) + 24 (core) verdes.
4181
4182### feat(nouser): centroid_model — versionado de embeddings
4183Protege contra el bug silencioso de mezclar centroides de modelos
4184distintos (mock 32-d vs real 384-d), que daba scores sin sentido.
4185
4186- `MonadManifest.centroid_model: Option<String>` taggea qué modelo
4187  produjo el `centroid`. `None` = legacy pre-versioning.
4188- `nouser_core::embed::MODEL_ID = "nouser-pseudo-32d"`. El cluster lo
4189  setea en cada Mónada que genera.
4190- `nouser-nous-mock` reusa la misma constante (`use
4191  nouser_core::embed::MODEL_ID`); produce vectores idénticos al
4192  cluster local, así que reportar el mismo ID es honesto.
4193- `nouser-nous-real` reporta `"real-fastembed-allMiniLML6V2-384d"`
4194  (dim distinta, semántica distinta).
4195- `cmd_attract` ahora:
4196  - Captura el `model_id` del embedding del target (local o remote).
4197  - Filtra Mónadas cuyo `centroid_model` no matchee.
4198  - Reporta `embed: <source> (<model>)` y `skipped: N mónadas con
4199    centroid_model distinto` cuando descarta.
4200
4201Resultado operativo: cambiar de mock a real (vía
4202`BRAHMAN_BROKER_CONTEXT=prod`) hace que `attract` filtre las Mónadas
4203viejas con cero score en lugar de fingir que las puede comparar.
4204
4205## 2026-05-08
4206
4207### chore: profile.dev slim — target/ ~50% más liviano
4208Cambios en `[profile.dev]` raíz para que builds futuras no desborden
4209disco. Decisiones:
4210- `debug = "line-tables-only"`: stack traces correctos, drop del resto
4211  de symbols. Sin pérdida real para nuestro flujo.
4212- `split-debuginfo = "unpacked"`: relink más rápido, debuginfo en
4213  archivos aparte.
4214- `codegen-units = 256`: paralelismo + builds incrementales chicas.
4215- Override `[profile.dev.package.X]` para los pesados (gpui, ort,
4216  fastembed, tokenizers, image): `opt-level = 1`, `debug = false`.
4217  No los debuggeamos línea por línea, no necesitan info pesada.
4218
4219Resultado: binarios ~3× más livianos. ente-zero 125→47 MB; mock-nous
4220~50→22 MB.
4221
4222### feat(nouser): dynamic binding — consumer descubre el provider vía broker
4223Cierra el bucle prometido por `priority_contexts`: el cliente ya no
4224hardcodea el socket del provider de embeddings. En su lugar:
4225
42261. Si `NOUSER_NOUS_SOCKET` está set, lo usa directo (atajo explícito).
42272. Si no, abre `brahman_handshake::client::Client` al `brahman-init`,
4228   anuncia un consumer Card mínimo con `flow.input = embed-result:json`,
4229   espera 3s por el primer `MatchEvent::Available`, y usa el
4230   `producer_service_socket` que viaja en el evento.
4231
4232Esto activa el swap automático mock↔real:
4233- `BRAHMAN_BROKER_CONTEXT=test`: el bias `+1 en test` del mock lo hace
4234  ganar; consumer recibe el socket del mock.
4235- `BRAHMAN_BROKER_CONTEXT=prod`: el bias del real lo hace ganar.
4236- Sin contexto: empate alfabético entre los presentes.
4237
4238Validación end-to-end:
4239
4240  $ ente-zero & nouser-nous-mock &
4241  $ # Sin NOUSER_NOUS_SOCKET:
4242  $ nouser attract --remote crates/core archivo.rs
4243    embed: remote
4244    🧲  0.9058  ente-brain/src  ...
4245  (mock log confirma "embed_file path=...")
4246
4247Cambios:
4248- `nouser-core` Cargo.toml: deps directas brahman-handshake + tokio.
4249- `cmd_attract` resuelve el socket por discovery antes de llamar a
4250  `embed_via(&path, file)` (mini-runtime tokio current_thread inline).
4251
4252Bug que se descubrió en el camino: la "flakiness" reportada de
4253`cargo test --workspace` era disco lleno (24 GB en `target/`), no
4254condición de carrera. Con `cargo clean` + profile slim, todos los
4255tests pasan deterministas.
4256
4257### feat(nouser): yahweh widget — `nouser-explorer` panel GPUI
4258Bin GPUI standalone que consulta `brahman-admin` cada 2s y renderea
4259todas las sesiones del Init como cards. Cierra el círculo visual del
4260ecosistema brahman.
4261
4262- Crate nuevo `crates/apps/nouser-explorer` (deps: brahman-admin,
4263  brahman-card, gpui).
4264- Ventana 900×640 con header del estado del Init, banner de error
4265  cuando no conecta, y lista de cards (una por sesión).
4266- Cada card muestra: kind + label + lifecycle, ULID corto, summary
4267  (si data), keywords, lens hint, service_socket si está, y refs
4268  (RelationshipKind → target_label). El borde izquierdo coloreado
4269  diferencia ente (azul) de data (lavanda).
4270- `cx.spawn(async move |this, cx| { … })` corre el loop de refresh
4271  en el GPUI executor; `query_blocking` se usa porque GPUI no provee
4272  un runtime tokio.
4273- Nuevo helper en brahman-admin: `client::query_blocking(path)` —
4274  versión sync de `query()`, para callers con su propio executor.
4275
4276Uso:
4277
4278  $ ente-zero & nouser daemon crates/core &
4279  $ cargo run -p nouser-explorer
4280  # ventana muestra ~6 cards en vivo, refrescando cada 2s.
4281
4282cargo check --workspace: 0 errores, 0 warnings.
4283
4284### feat(nouser): persistencia sled write-through del MonadDb
4285`MonadDb` ahora soporta backend dual:
4286
4287- `MonadDb::new()` → memoria pura (default, back-compat).
4288- `MonadDb::open(path)` → sled-backed con cache en memoria. Carga
4289  contenido existente al abrir; cada `insert_*` hace write-through
4290  (cache + sled).
4291
4292Diseño:
4293- 2 trees sled: `files` y `monads`.
4294- Wire format: serde_json (ergonomía + inspectability con sled-cli;
4295  los manifests son chicos, JSON gana sobre postcard aquí).
4296- Reads SIEMPRE desde la cache — sled se consulta sólo al abrir.
4297- `replace_monads()` purga el tree de sled antes de escribir.
4298
4299Bin nouser: nueva env var `NOUSER_DB_PATH`. Si está set, persiste
4300en esa ruta; si no, in-memory:
4301
4302  $ NOUSER_DB_PATH=/tmp/monads.sled nouser scan crates/core
4303  scan: 102 archivos en crates/core, 5 mónadas
4304  $ ls /tmp/monads.sled
4305  blobs  conf
4306  $ NOUSER_DB_PATH=/tmp/monads.sled nouser scan crates/core
4307  # segunda corrida re-escribe la DB con el nuevo scan
4308
4309Tests nuevos en db.rs:
4310- `persistence_roundtrip` — escribe, cierra, reabre, datos están.
4311- `replace_monads_purges_persistent_tree` — replace limpia el tree.
4312
431324 tests en nouser-core (era 22, +2).
4314
4315### feat(sidecar): Phase B-3 — SidecarPool consolida en un runtime
4316Antes: cada `spawn(card)` creaba un thread + tokio runtime propio.
4317Para módulos que publican muchas sesiones (nouser daemon con 50+
4318Mónadas) eso es 50 threads + 50 runtimes. Ahora: **un thread + un
4319runtime tokio current_thread** que hostea N tasks de sidecar.
4320
4321API nueva (aditiva, no rompe `spawn`/`spawn_with_handle`):
4322
4323  let pool = SidecarPool::new()?;
4324  pool.spawn(card1);
4325  pool.spawn(card2);
4326  pool.spawn_conscious(card_wit, wit);
4327  pool.spawn_with_config(SidecarConfig::new(c).with_wit(w));
4328  // pool drop = todas las sesiones cierran.
4329
4330`run_client` se hace pública para que el pool pueda enqueuar tasks
4331externos al runtime con `handle.spawn(run_client(config))`.
4332
4333`nouser daemon` migrado al pool. Verificación con `ps -L`:
4334
4335  $ ps -L -p $(pidof nouser)
4336    LWP   CMD
4337    28817 nouser              # main thread
4338    28819 brahman-sidecar     # pool thread (todas las sesiones)
4339
4340Antes serían 6+ LWP (1 main + N sesiones); ahora 2 fijos sin importar
4341cuántas Mónadas se publiquen.
4342
4343### feat: Crossreferencia — Card.references como grafo del fractal
4344Las Cards ahora declaran sus relaciones con otras Cards. El Engine
4345posee Mónadas; las Mónadas declaran que son poseídas por el Engine.
4346La UI puede cruzar el grafo sin discovery especial.
4347
4348- `brahman-card`:
4349  - `RelationshipKind { Owns, OwnedBy, Processes, ProcessedBy, Sibling }`.
4350  - `CardReference { kind, target_id, target_label }` — `target_label`
4351    es cache del label en el momento de declarar (la UI puede pintar
4352    sin resolver).
4353  - `Card.references: Vec<CardReference>` y espejo en `WireCard`.
4354    Conversiones `From` propagan.
4355- `brahman-broker::BrokeredCard` propaga `references`.
4356- `brahman-status` imprime cada referencia: `ref OwnedBy → label (id)`.
4357- **nouser daemon**: cada Mónada que publica añade
4358  `RelationshipKind::OwnedBy` apuntando al engine. La declaración es
4359  unilateral; el engine no necesita conocer las IDs de antemano.
4360
4361Validación end-to-end:
4362
4363  $ ente-zero & nouser daemon crates/core
4364  $ brahman-status
4365  Sessions (6):
4366    [ente]  ... brahman.nouser_engine
4367    [data]  ... brahman-handshake/src
4368        ref OwnedBy  →  brahman.nouser_engine  (01K...)
4369        summary: 6 archivos...
4370    [data]  ... ente-brain/src
4371        ref OwnedBy  →  brahman.nouser_engine  (01K...)
4372    ...
4373
4374### feat: Phase D-3 + D-4 — service_socket en Card, providers coexisten
4375Cierra el ciclo del swap automático de Nous (mock↔real):
4376
4377- **Schema** (`brahman-card`): `Card.service_socket: Option<PathBuf>` y
4378  espejo en `WireCard`. Conversiones `From` propagan. Es el path del
4379  **data plane** (distinto del socket del Init); cualquier consumer
4380  que matchee con esta Card puede conectar directo sin discovery
4381  adicional.
4382- **Broker** (`brahman-broker`): `BrokeredCard` propaga
4383  `service_socket` desde la Card. Sin participación en el matching —
4384  sólo metadata para los observadores.
4385- **MatchEvent** (`brahman-handshake`): nuevo campo
4386  `producer_service_socket: Option<PathBuf>`. Cuando el server emite
4387  `Available`, busca la `BrokeredCard` del productor en el broker y
4388  copia su `service_socket`. El consumer recibe la ruta completa para
4389  conectar.
4390- **Transport** (`nouser-nous`): `provider_socket_path(provider: &str)`
4391  devuelve `nouser-nous-{provider}.sock` por default — mock y real
4392  coexisten en sockets distintos (Phase D-4). `default_socket_path()`
4393  conserva el comportamiento single-provider.
4394- **Providers**: mock declara `service_socket =
4395  /run/user/X/nouser-nous-mock.sock`; real declara
4396  `nouser-nous-real.sock`. La Card se construye DESPUÉS del bind para
4397  que el path declarado sea el real.
4398- **Status**: `brahman-status` imprime `socket:` por sesión cuando
4399  está presente.
4400
4401Validación end-to-end:
4402
4403  $ ente-zero & nouser-nous-mock & nouser-nous-real &
4404  $ ls /run/user/1001/nouser-nous-*.sock
4405    nouser-nous-mock.sock
4406    nouser-nous-real.sock
4407
4408  $ brahman-status
4409  Sessions (2):
4410    [ente]  ... nouser.nous_real
4411        socket:     /run/user/1001/nouser-nous-real.sock
4412        in  embed-request: Primitive { name: "json" }
4413        out embed-result: Primitive { name: "json" }
4414    [ente]  ... nouser.nous_mock
4415        socket:     /run/user/1001/nouser-nous-mock.sock
4416        in  embed-request, out embed-result
4417
4418Pendientes para futuro (no críticos):
4419- nouser-core attract --remote todavía usa NOUSER_NOUS_SOCKET hardcoded
4420  o `default_socket_path()`. El siguiente paso es subscribirse al
4421  MatchEvent del broker y usar `producer_service_socket` directo —
4422  con eso `BRAHMAN_BROKER_CONTEXT=test/prod` swapea provider sin
4423  tocar al consumer.
4424
4425### refactor(nouser): labels de Mónada con 2 componentes del path
4426Resuelve la fricción visual de monorepos donde múltiples Mónadas se
4427llamaban "src". Nueva función `label_from_path` toma los últimos hasta
44282 componentes normales del path y los une con `/`.
4429
4430  $ nouser scan crates/core
4431    [01K..] brahman-admin/src       card=5
4432    [01K..] brahman-handshake/src   card=6
4433    [01K..] ente-brain/src          card=11
4434    [01K..] ente-kernel/src         card=4
4435    ...
4436
4437Tests añadidos: `label_from_root_only_one_component`,
4438`label_from_deep_path_takes_last_two`. Tests existentes actualizados
4439con los nuevos labels.
4440
4441### feat(nouser): Phase D-2 — proveedor Nous real (LLM) detrás de feature flag
4442Cierra el ciclo del módulo Nous: existe un proveedor que produce
4443embeddings reales con un modelo LLM, mientras que `cargo build` sin
4444features sigue siendo liviano (no descarga ni compila ML deps).
4445
4446Crate nuevo:
4447
4448- `crates/modules/nouser/nous-real`: bin con dos modos según feature.
4449  - **Sin feature (default)**: stub. Bin compila en ~10s, arranca,
4450    sidecarea a brahman-init declarando la Card de real-nous, escucha
4451    en el socket Nous, y rechaza toda request con `ErrorResponse {
4452    error: "compilado sin la feature embeddings. Rebuild con
4453    cargo build -p nouser-nous-real --features embeddings" }`.
4454    `cargo build --workspace` sigue siendo limpio.
4455  - **Con `--features embeddings`**: pulls `fastembed = "4"`. Ese crate
4456    arrastra `ort 2.0.0-rc.9` (ONNX Runtime con binarios descargados
4457    por Cargo) + `tokenizers 0.21` + ~30 deps más. Compila en ~50s.
4458    Modelo default: `all-MiniLM-L6-v2` (384-d, descargado a
4459    `~/.cache/fastembed` la primera vez).
4460  - `EmbedText`: pasa el texto al modelo, devuelve vector 384-d.
4461  - `EmbedFile`: lee primeros 8KiB con UTF-8 lossy, embed como texto.
4462    Para binarios el resultado no es semánticamente útil — caller
4463    decide.
4464  - `Ping`: devuelve `model_id` y `embed_dim` reales.
4465
4466- Card de real-nous:
4467  - label `nouser.nous_real` (distinto del mock para coexistir).
4468  - `priority_contexts.prod = { priority_offset: +1 }`. En contexto
4469    prod gana sobre el mock; en `test` el mock gana por su propio
4470    `+1`. Sin contexto activo, empate alfabético entre ambos.
4471
4472Validación end-to-end con modelo real:
4473
4474  $ cargo build -p nouser-nous-real --features embeddings   # ~50s
4475  $ ente-zero & nouser-nous-real &
4476  $ # probe vía python al socket Unix:
4477  $ echo '{"kind":"embed_text","payload":{"text":"hello brahman"}}' \
4478    | python3 -c "..." | head
4479    model: real-fastembed-allMiniLML6V2-384d
4480    elapsed_ms: 8
4481    embed_dim: 384
4482    first 5 values: [0.0034, -0.0036, 0.0078, -0.0218, -0.0162]
4483
4484Tradeoff conocido: las dimensiones del mock (32-d) y real (384-d) son
4485incompatibles. Cambiar de proveedor invalida los centroides cacheados
4486de Mónadas. Documentar como "limpiar DB al cambiar proveedor".
4487
4488Workspace state:
4489- cargo build --workspace sigue limpio sin features (no ML).
4490- cargo build -p nouser-nous-real --features embeddings funciona.
4491- 0 errores, 0 warnings en ambos modos.
4492
4493Pendientes para D-3 / futuro:
4494- Discovery de socket: hoy el consumer hardcodea NOUSER_NOUS_SOCKET.
4495  Para que el broker brahman elija real vs mock per-contexto, falta
4496  inyectar el socket del provider electo en el MatchEvent o exponer
4497  un broker query "dame el socket de la sesión X".
4498- Coexistencia: hoy los dos providers compiten por el mismo socket
4499  path por default. Habría que parametrizarlos a sockets distintos
4500  cuando coexistan.
4501
4502### feat(nouser): Phase D — proveedor Nous mock + cliente remoto
4503Cierra el patrón "Nous como módulo aparte intercambiable": el contrato
4504del proveedor de embeddings vive en su crate, el mock determinístico
4505implementa ese contrato sirviéndolo por Unix socket, y `nouser-core`
4506sabe consumirlo remotamente. El switch entre mock y real (futuro) se
4507hará vía priority_contexts en el broker.
4508
4509Crates nuevos:
4510
4511- `crates/modules/nouser/nous`: contrato compartido. Tipos
4512  `EmbedRequest`, `RequestKind { EmbedFile, EmbedText, Ping }`,
4513  `EmbedFilePayload`, `EmbedTextPayload`, `EmbedResponse`,
4514  `PingResponse`, `ErrorResponse`. Wire format: line-delimited JSON
4515  por Unix socket, single-shot per conexión. Constants para los nombres
4516  de flow (`embed-request`/`embed-result`) y el tipo (`json`). Helper
4517  `transport::default_socket_path()` con env var
4518  `NOUSER_NOUS_SOCKET`.
4519- `crates/modules/nouser/nous-mock`: bin `nouser-nous-mock`. Sidecarea
4520  a brahman-init con Card kind=Ente declarando los flows
4521  `embed-request:json`/`embed-result:json` y un
4522  `priority_contexts.test = { priority_offset: +1 }` (gana sobre
4523  cualquier real-nous en contexto test). Bind del socket Nous, accept
4524  loop, despacha por `RequestKind`. EmbedFile usa
4525  `nouser_core::embed::embed` (los pseudo-embeddings de Phase C).
4526  Modelo: `mock-pseudo-32d`.
4527
4528Cambios:
4529
4530- `nouser-core`: dep nueva `nouser-nous`. Subcomando `attract` ahora
4531  acepta `--remote` que abre un socket UnixStream blocking, envía un
4532  `EmbedRequest` y lee la response. Imprime `embed: local|remote`
4533  para que se vea cuál ruta corrió.
4534
4535Validación end-to-end (un solo terminal, varios procesos):
4536
4537  $ ente-zero &
4538  $ nouser-nous-mock &
4539  $ NOUSER_MIN_FILES=5 nouser daemon crates/core &
4540  $ brahman-status
4541
4542  Sessions (7):
4543    [ente] nouser.nous_mock      flows: embed-request, embed-result
4544    [ente] brahman.nouser_engine
4545    [data] src   summary: 6 archivos en crates/core/brahman-handshake/src
4546    [data] graph summary: 7 archivos en crates/core/ente-zero/src/graph
4547    ...
4548
4549  $ nouser attract --remote crates/core <archivo.rs>
4550    embed: remote
4551    🧲  0.9058  src  ...
4552
4553  Mock log: "embed_file path=crates/modules/nouser/core/src/embed.rs"
4554
4555Bug encontrado y corregido en el camino:
4556- `ContextBias` tenía `#[serde(skip_serializing_if = ...)]` en sus
4557  campos. Postcard NO soporta skip-condicional (formato no
4558  self-describing): el serializer omitía bytes que el deserializer
4559  esperaba, rompiendo la wire de cualquier Card con
4560  `priority_contexts` poblada.
4561- Fix: removidos los `skip_serializing_if` de `ContextBias`. JSON
4562  pretty ahora emite `{"pin_to": null, "priority_offset": 0}` en lugar
4563  de objeto vacío. Trade-off aceptado por compatibilidad de wire.
4564- Test nuevo en brahman-card: `wirecard_postcard_with_priority_contexts`
4565  que ejercita el roundtrip completo postcard.
4566
4567Tests acumulados: 75 (card 12 +1 nuevo, broker 15, handshake 9,
4568card-wit 4, admin 0, nouser-card 7, nouser-core 20, nouser-nous 2).
4569cargo check --workspace: 0 errores, 0 warnings.
4570
4571Próximo natural: Phase D-2 — `real-nous` con un modelo ONNX/Llama de
4572text-embedding. La infraestructura ya está lista: declara la misma
4573Card con `priority_contexts.prod = { priority_offset: +1 }` y el
4574swap es transparente para el consumer.
4575
4576### feat(nouser): Phase C — pseudo-embeddings + atracción por centroide
4577El "imán semántico" matemático del diseño Kairos, sin LLM. Cada
4578archivo se proyecta a un vector 32-d derivado de sus metadatos; cada
4579Mónada calcula su centroide; archivos nuevos se asignan por cosine
4580similarity contra los centroides existentes.
4581
4582Cambios:
4583
4584- nouser-core dep nueva: `blake3` (hash determinista de strings).
4585- `crates/modules/nouser/core/src/embed.rs`:
4586  - `EMBED_DIM = 32`. Estructura del vector:
4587    - dims  0..8:  blake3(extension)     → identidad de tipo
4588    - dims  8..16: blake3(parent_dir)    → identidad de contenedor
4589    - dims 16..24: blake3(file_stem)     → identidad léxica
4590    - dims 24..28: tamaño (log + flags)
4591    - dims 28..32: mtime (escala día + cíclicas)
4592  - **Tip clave**: bytes del hash se centran a `[-1, 1]` (no `[0, 1]`).
4593    Sin centrar, dos vectores hash random tendrían cosine ~0.75
4594    espuria; centrados, expectativa ≈ 0 entre no-relacionados.
4595  - APIs: `embed`, `cosine_similarity`, `centroid`, `cohesion`,
4596    `attraction_score`, `best_attraction`. `DEFAULT_ATTRACTION_THRESHOLD = 0.7`.
4597- `cluster::by_directory` ahora computa el centroide de cada Mónada
4598  (promedio de embeddings de los miembros, L2-normalizado) y lo guarda
4599  en `MonadManifest.centroid`. El centroide viaja al brahman-status vía
4600  `DataFacet.centroid` → ahora se ven los Vec<f32> reales por cada Mónada.
4601- bin nouser nuevo subcomando: `attract <dir> <file>`.
4602  - Escanea el dir, embeda el archivo objetivo, ranking de afinidad
4603    contra todas las Mónadas con centroide.
4604  - Marca 🧲 si la mejor supera el umbral, `·` si es la mejor pero
4605    debajo, espacio en blanco para el resto.
4606
4607Validación end-to-end:
4608
4609  $ nouser attract crates/core crates/modules/nouser/core/src/embed.rs
4610  ranking de atracción (cosine similarity):
4611    🧲  0.9058  [01K..] src  (11 archivos en crates/core/ente-brain/src)
4612        0.8984  [01K..] src  (6 archivos en crates/core/brahman-handshake/src)
4613        0.8918  [01K..] src  (5 archivos en crates/core/ente-zero/src)
4614        ...
4615
4616  $ nouser attract crates/core crates/modules/nouser/core/Cargo.toml
4617  ranking:
4618        0.3427  [01K..] graph  (7 archivos en crates/core/ente-zero/src/graph)
4619        ...
4620    (mejor score 0.3427 < umbral 0.7000 — el archivo no se 'pega')
4621
4622Tests: 20 en nouser-core (era 13, +7 de embed). Total acumulado: 73
4623(card 11, broker 15, handshake codec+tr 2 + integ 7, card-wit 4,
4624admin 0, nouser-card 7, nouser-core 20, ente-card 0).
4625cargo check --workspace: 0 errores, 0 warnings.
4626
4627Próximo: **Phase D** — `nouser-nous`, módulo aparte para LLM real.
4628Mock-nous determinista (basado en estos pseudo-embeddings) en
4629`BRAHMAN_BROKER_CONTEXT=test`; real-nous en `prod`. El switch lo hace
4630el broker via priority_contexts sin tocar nada más.
4631
4632### feat(nouser): Phase B-2 — daemon que publica Mónadas al Init
4633Cierra la unificación: el `nouser daemon` se sidecarea como Ente y
4634publica cada Mónada como su propia sesión Data. Un solo
4635`brahman-status` muestra procesos y datos en la misma lista, exactamente
4636como buscaba el diseño.
4637
4638Cambios:
4639
4640- `crates/modules/nouser/core/Cargo.toml`: deps nuevas `brahman-card`
4641  y `brahman-sidecar`.
4642- `crates/modules/nouser/core/src/bin/nouser.rs`: subcomando
4643  `daemon <dir>`.
4644  - Spawna un sidecar para el "engine" (`brahman.nouser_engine`,
4645    kind=Ente) — el ser que produce y administra Mónadas.
4646  - Scan + cluster del dir.
4647  - Para cada Mónada, llama `monad.to_brahman_card()` y spawnea un
4648    sidecar (kind=Data). Cada Mónada es una sesión brahman propia
4649    con su ULID estable.
4650  - Park del thread principal: los sidecars siguen pingueando.
4651
4652Validación end-to-end:
4653
4654  $ ente-zero &
4655  $ NOUSER_MIN_FILES=5 nouser daemon crates/core &
4656  $ brahman-status
4657
4658  Sessions (6):
4659    [ente]  ... brahman.nouser_engine  lifecycle=Daemon
4660    [data]  ... src    summary: 5 archivos en crates/core/brahman-admin/src
4661                       members: 5 (dispersion=0.00)
4662                       lens hint: code
4663    [data]  ... src    summary: 11 archivos en crates/core/ente-brain/src
4664                       ...
4665    [data]  ... graph  summary: 7 archivos en crates/core/ente-zero/src/graph
4666
4667El protocolo de presentación es uno solo: la Card. La función — anunciar
4668identidad, exponer metadata, ser descubierto — es idéntica para procesos
4669vivos y agrupaciones de datos. La UI lo ve como una lista uniforme.
4670
4671Costo conocido: cada Mónada consume un thread + tokio runtime
4672current_thread (legacy del sidecar API). Para muchas Mónadas (>50)
4673conviene consolidar en un único runtime con N tasks. Defer a Phase B-3.
4674
4675Pendientes propuestos:
4676- **B-3**: consolidar todos los sidecars en un único runtime tokio
4677  para no spawnear N threads.
4678- **C**: pseudo-embeddings + atracción por centroide.
4679- **D**: módulo `nouser-nous` para LLM, swappable por priority_contexts.
4680- **Polish**: labels con 2-3 componentes del path.
4681- **Crossreferencia**: que un Ente pueda anunciar "estoy procesando la
4682  Mónada X" y la Mónada anuncie "Ente Y me está procesando".
4683
4684cargo check --workspace: 0 errores, 0 warnings.
4685
4686### feat: Phase B-1 — unificación ontológica de Cards (Ente ↔ Data)
4687La Card es **el** protocolo de presentación del ecosistema, no sólo de
4688los procesos. Una Mónada Nouser y un Ente Brahman son ambos "entidades
4689que se presentan"; el consumidor (UI, broker, admin) discrimina por
4690`kind` cuando importa, pero todos hablan el mismo idioma.
4691
4692Cambios:
4693
4694- `brahman-card`:
4695  - `CardKind { Ente (default), Data }`. Conserva back-compat:
4696    Cards existentes son `Ente` por default.
4697  - `DataFacet { summary, keywords, centroid, member_count, dispersion,
4698    presentation_hint }`. Liviano para el wire — listas grandes
4699    (members, embeddings completos) se consultan al daemon dueño bajo
4700    demanda.
4701  - `Card.kind` y `Card.data: Option<DataFacet>` agregados. WireCard
4702    espeja, conversiones `From` propagan.
4703  - Default impl actualizado.
4704
4705- `brahman-broker::BrokeredCard`: propaga `kind` y `data` desde la Card
4706  registrada. No afecta el matching (sigue siendo por TypeRef +
4707  priority + pin_to); permite a observadores discriminar sin re-query.
4708
4709- `nouser-card`: depende ahora de `brahman-card`. Nuevo método
4710  `MonadManifest::to_brahman_card()` que proyecta:
4711  - id, label, lineage → directos.
4712  - payload Virtual, supervision Delegate, lifecycle Daemon (placeholder
4713    semántico — la Mónada no se ejecuta).
4714  - kind = Data.
4715  - data = Some(DataFacet) con summary, keywords, centroide,
4716    member_count, entropy → dispersion, y un `presentation_hint` derivado
4717    del `Lens` (`Code` → `"code"`, `Gallery` → `"gallery"`, etc.).
4718  - Test nuevo: `projects_to_brahman_card`.
4719
4720- `brahman-status`: cada sesión muestra ahora `[ente]` o `[data]` como
4721  prefijo. Para sesiones `data`, render adicional con summary, members
4722  + dispersion, keywords y lens hint.
4723
4724Resultado: la UI (yahweh, brahman-status, futuro explorer) ve una sola
4725lista uniforme. No tiene que saber si está mirando un proceso o un
4726cúmulo de datos — sólo lee el Card y se adapta por `kind`.
4727
4728Tests acumulados: 59 (card 11, broker 15, handshake codec+transport 2 +
4729integ 7, card-wit 4, admin 0, nouser-card 7, nouser-core 13).
4730cargo check --workspace: 0 errores, 0 warnings.
4731
4732Próximo: **Phase B-2** — bin `nouser daemon <dir>` que sidecarea cada
4733Mónada como una sesión brahman, publicándola al broker. Brahman-status
4734las verá junto a los entes.
4735
4736### feat(nouser): Phase A — mecanismo determinista de Mónadas
4737Primer trozo del módulo Nouser (Kairos): explorador de Mónadas como
4738"imanes semánticos" sobre el filesystem. Phase A cubre el 90% de los
4739casos sin tocar IA — sólo metadatos y heurísticas.
4740
4741Crates nuevos:
4742
4743- `crates/modules/nouser/card`: `MonadManifest` (la Tarjeta de
4744  Presentación de una Mónada — espejo conceptual de `brahman::Card`
4745  pero para datos, no para procesos runtime). Campos: id (Ulid),
4746  label, summary, centroid (vacío en Phase A), keywords, cardinality,
4747  entropy [0,1], dominant_lens, pins, members, timestamps,
4748  extensions (forward-compat). 6 tests de validación + JSON roundtrip.
4749- `crates/modules/nouser/core`: pipeline determinista.
4750  - `scanner`: walkdir → `Vec<FileEntry>` con metadatos (path, size,
4751    mtime, extension). Skipea hidden por default. Configurable max
4752    depth y follow_links.
4753  - `cluster::by_directory`: agrupa por parent dir, mínimo 3 archivos
4754    para promover a Mónada (configurable). Calcula keywords (top-N
4755    extensiones por frecuencia + alfabético), elige `Lens` dominante
4756    (Code/Gallery/Markdown/Database/Grid) según extensión más
4757    frecuente, computa entropía de Shannon normalizada [0,1].
4758  - `db`: `MonadDb` en memoria con índices BTreeMap files/monads y
4759    `resolve_members(monad_id)` que filtra IDs huérfanos. Phase B
4760    traerá persistencia.
4761  - bin `nouser`: subcomandos `scan <dir>`, `show <dir> <prefix>`,
4762    `json <dir>`. Env var `NOUSER_MIN_FILES` para tunear el threshold.
4763  - 13 tests (4 scanner + 6 cluster + 3 db).
4764
4765Demo end-to-end:
4766
4767  $ nouser scan crates
4768  scan: 255 archivos en crates, 19 mónadas (min_files=3)
4769    [01KR4C13]  src                             card=12  ent=0.00  lens=Code
4770             keywords: rs
4771    [01KR4C13]  tests                           card=14  ent=0.00  lens=Code
4772             keywords: rs
4773    [01KR4C13]  fixtures                        card=5   ent=0.00  lens=Grid
4774             keywords: rhai
4775    ...
4776
4777  $ nouser show crates 01KR4C
4778  Monad 01KR4C1370DVF6NMTW6SECNXAF
4779    label:       src
4780    summary:     4 archivos en crates/modules/nouser/core/src (ext: rs)
4781    cardinality: 4
4782    entropy:     0.0000
4783    lens:        Code
4784    members (4):
4785            4132 bytes  crates/modules/nouser/core/src/db.rs
4786            ...
4787
4788Pendientes para próximas fases (anotados, no urgentes):
4789- **Phase B**: bin `nouser daemon` que sidecarea a brahman-init
4790  declarando flows (`scan-request:json` → `monad-update:json`).
4791- **Phase C**: pseudo-embeddings deterministas (hash de path/ext/size
4792  a 32-d) + atracción por centroide via cosine similarity. Implementa
4793  el "imán" sin LLM.
4794- **Phase D**: módulo `nouser-nous` aparte para el LLM real
4795  (Llama/ONNX). En `priority_contexts.test` el Init pinea a
4796  `mock-nous` (embeddings determinísticos); en `prod` a `real-nous`.
4797- **Polish**: labels de Mónada incluir 2-3 componentes del path para
4798  desambiguar `src/` repetidos en monorepo.
4799
4800Workspace: 0 errores, 0 warnings. Tests acumulados: 58
4801(card 11, broker 15, handshake codec+transport 2 + integ 7,
4802card-wit 4, admin 0, nouser-card 6, nouser-core 13).
4803
4804### feat(broker): priority contexts — biases per-contexto operativo
4805- `brahman-card::ContextBias { pin_to: Option<String>, priority_offset: i8 }`
4806  declara un override per-contexto.
4807- `Card.priority_contexts: BTreeMap<String, ContextBias>` y mismo en
4808  `WireCard` (cruza el wire). Las conversiones `From` lo propagan.
4809- `BrokerConfig.current_context: Option<String>`. Cuando el broker corre
4810  bajo un contexto y una Card declara biases para ese nombre, se aplican:
4811  - Como **consumidor**: `pin_to` sobreescribe el `Flow.pin_to` estático.
4812  - Como **productor**: `priority_offset` se suma a la priority base
4813    (clamp en `[Low=0, Critical=3]`) para el ranking.
4814- `BrokeredCard` propaga `priority_contexts`. `find_producer_for` usa
4815  `effective_priority(card)` y `effective_pin(card, input)` antes de
4816  los tiebreaks.
4817- `brahman-admin::AdminConfig.current_context` + `StatusSnapshot.current_context`
4818  espejan el contexto activo. `brahman-status` lo imprime como
4819  `Context: <nombre>` justo debajo de `Init: ...`.
4820- `ente-zero` lee `BRAHMAN_BROKER_CONTEXT` env var y la propaga al
4821  broker y al admin. Sin var, biases per-contexto inactivos.
4822- 4 tests nuevos en brahman-broker:
4823  `context_priority_offset_lifts_producer_above_alphabetic_winner`,
4824  `context_pin_to_overrides_static_pin`, `unknown_context_no_op`,
4825  `priority_offset_clamps_to_critical`.
4826- Validación end-to-end: `BRAHMAN_BROKER_CONTEXT=test ente-zero` →
4827  `brahman-status` muestra `Context: test`.
4828
4829### feat(card): WireCard + extensions — forward-compat sin romper postcard
4830- `Card.extensions: BTreeMap<String, serde_json::Value>` restaurado con
4831  `#[serde(flatten, default, skip_serializing_if = is_empty)]`. Los
4832  campos JSON/TOML desconocidos sobreviven el roundtrip de archivos.
4833- Nuevo `WireCard`: proyección postcard-friendly (sin `extensions`,
4834  `genesis: Vec<WireCard>` recursivo). Conversiones `From<Card>` y
4835  `From<WireCard>` con descarte/recreación de extensions.
4836- `brahman-handshake::Hello.card` pasa de `Card` a `WireCard`. Client
4837  hace `card.into()` antes de enviar; Server hace `hello.card.into()`
4838  para volver a Card antes de validar/registrar.
4839- 3 tests nuevos en brahman-card:
4840  `extensions_preserved_in_json_roundtrip`,
4841  `wire_card_roundtrip_strips_extensions`,
4842  `wire_card_postcard_friendly` (postcard encode/decode efectivo).
4843- brahman-card gana `postcard` como dev-dep para el último test.
4844- Contrato documentado: extensions = anotaciones locales que NO cruzan
4845  al Init; sólo viven en archivos.
4846
4847### `9420eae` chore: limpia warnings dead-code en arje (commit del usuario)
4848- `ente-zero/src/events.rs`: `#![allow(dead_code)]` a nivel módulo —
4849  es vocabulario de eventos con variantes/campos reservados para flujos
4850  no cableados aún (CapabilityRequested, ShutdownReason::Signal,
4851  CapabilityGrant::{Granted, Denied, QuotaExceeded}, ExitStatus
4852  fields).
4853- `ente-zero/src/graph/mod.rs`: comentado el re-export ahora innecesario
4854  de `SHUTDOWN_GRACE`. `DEFAULT_GRANT_TTL` con `#[allow(dead_code)]`
4855  + nota "reservado para capability granting".
4856- `ente-zero/src/graph/capabilities.rs`: `renew_grant` con
4857  `#[allow(dead_code)]` (capability renewal pendiente).
4858- `ente-kernel/src/surface.rs`: drop de `use anyhow::Context` (no se
4859  usaba).
4860- `ente-hostnamed-compat/src/main.rs`: drop de `Connection` (no se
4861  usaba).
4862- `ente-polkit-compat/src/main.rs`: `PolicyDecision.source` con
4863  `#[allow(dead_code)]` (sólo aparece en `Debug` para logging).
4864- `cargo check --workspace`: 17 warnings → 0.
4865
4866### feat(sidecar): WIT al sidecar — módulos conscientes vivos
4867- `brahman-card::WitInterface` deriva `Serialize`, `Deserialize`,
4868  `PartialEq`, `Eq` para cruzar el wire postcard.
4869- `brahman-handshake::Hello` lleva `wit: Option<WitInterface>`. Server
4870  usa `ResolvedCard::from_conscious` cuando viene presente, `from_agnostic`
4871  cuando no.
4872- `brahman-handshake::Client::connect` queda como wrapper agnóstico de
4873  `connect_with(path, card, wit: Option<WitInterface>)`.
4874- `brahman-broker::Broker::register` ahora toma `Option<WitInterface>`
4875  como tercer arg. `BrokeredCard` guarda el wit. 25 sitios de tests
4876  actualizados con `, None`.
4877- `brahman-sidecar::SidecarConfig` con campo `wit`. Helpers nuevos:
4878  `SidecarConfig::new(card).with_wit(wit)` y `spawn_conscious(card, wit)`.
4879  El log `attached` reporta `conscious=true|false`.
4880- `brahman-status` muestra marker 🧠 + sección `wit:` (package/world,
4881  imports, exports) por sesión consciente.
4882- Example nuevo `crates/shared/brahman-sidecar/examples/presence-conscious.rs`:
4883  toma label + path .wit (default `shared_wit/protocol.wit`), parsea
4884  con brahman-card-wit, spawna sidecar consciente.
4885- Validado end-to-end:
4886  ```
4887  $ presence-conscious demo.conscious shared_wit/protocol.wit &
4888  $ brahman-status
4889  Sessions (1):
4890    01K... demo.conscious 🧠  lifecycle=Daemon
4891        wit: brahman:protocol@0.1.0 / module
4892             imports: types, handshake, lifecycle
4893             exports: run
4894  ```
4895
4896### feat(core): brahman-card-wit — extractor opcional de contratos WIT
4897- Crate nuevo `crates/core/brahman-card-wit` con `wit-parser = "0.230"`.
4898- API: `parse_wit(source)` y `parse_wit_file(path)` devuelven
4899  `Vec<WitInterface>` (uno por `world` declarado).
4900- Interfaces importadas/exportadas (no sólo funciones) se resuelven
4901  por nombre via `resolve.interfaces[id].name`.
4902- Example `crates/core/brahman-card-wit/examples/brahman-wit-info.rs`
4903  CLI: `brahman-wit-info shared_wit/protocol.wit` → lista paquete,
4904  worlds, imports y exports.
4905- 4 tests: inline, archivo real (`shared_wit/protocol.wit`), parse
4906  error, world vacío.
4907- Validado contra `protocol.wit`: detecta worlds `module` y
4908  `admin-host` con sus imports/exports correctos.
4909
4910### `7b589b8` chore: agrega CHANGELOG.md retroactivo
4911- `CHANGELOG.md` en la raíz con los 11 commits previos documentados
4912  acción por acción. A partir de este punto, cada cambio sustantivo
4913  actualiza también este archivo en el mismo commit.
4914
4915### `8a83a26` feat(handshake): notificación push de matches
4916- Frame `MatchEvent { kind: Available | Lost, ... }` añadido al protocolo.
4917- `Session::run_post_handshake` usa `tokio::select!` para multiplexar
4918  reads del cliente y un canal `mpsc` push del server.
4919- Server: `SessionTxTable` (Arc<Mutex<HashMap<SessionId, Sender<Frame>>>>)
4920  y `LastMatches` para diff por sesión. `broadcast_match_diffs` corre
4921  tras cada `register` y `unregister`, emite sólo los cambios.
4922- Capacity del canal push: 32 (ephemeral, `try_send` non-blocking).
4923- Client: `VecDeque<MatchEvent>` interno, `take_event()` (non-blocking)
4924  y `await_event(timeout)`. `ping()` ahora drena MatchEvents intermedios
4925  hasta encontrar el Pong.
4926- Example `crates/core/brahman-handshake/examples/subscriber.rs`.
4927- Test `match_event_pushed_on_producer_arrival` (handshake integ 6→7).
4928
4929### `70a7a0d` feat: segundo módulo (nakui) + admin API + brahman-status
4930- Crate nuevo `crates/shared/brahman-sidecar` (DRY del thread + tokio +
4931  ping loop). API: `spawn(card)` / `spawn_with_handle(config)`.
4932- `nakui` cmd_run llama `brahman_sidecar::spawn` antes de `run_server`.
4933  Card: lifecycle Daemon, supervision Restart, flow `command` (json) /
4934  `report` (json).
4935- Crate nuevo `crates/core/brahman-admin` con `StatusSnapshot` JSON
4936  line-delim, `AdminServer` y `client::query`.
4937- ente-zero levanta también el AdminServer en `primordial_loop`.
4938- Example `crates/shared/brahman-sidecar/examples/presence.rs`
4939  (módulo dummy long-lived parametrizable por label).
4940- Example `crates/core/brahman-admin/examples/brahman-status.rs`
4941  (CLI que pretty-printa el snapshot).
4942- `brahman-broker`: `BrokeredCard` ahora incluye `lifecycle`. `Endpoint`
4943  y `Match` derivan `Serialize`/`Deserialize`. Nuevo `Broker::cards()`
4944  iterador.
4945- `brahman-card`: `pub use ::ulid` para que módulos no dependan de ulid.
4946- yahweh-shell migrado al sidecar compartido (96→53 LOC).
4947
4948### `595f68e` feat(yahweh-shell): primer módulo brahman vivo
4949- yahweh-shell spawnea sidecar antes de `Application::new()`.
4950- Card declarada: label `brahman.ui_engine`, lifecycle Widget,
4951  supervision Delegate, payload Virtual, flow input `render-data`
4952  (json) / output `user-intent` (json).
4953- Sidecar en thread aparte con tokio current_thread runtime,
4954  desacoplado del runtime GPUI.
4955
4956### `df9d10c` feat(ente-zero): enchufa el handshake server al Init real
4957- ente-zero levanta `brahman_handshake::server::Server::bind` en
4958  `primordial_loop` después del ente-bus, con degradación grácil
4959  si bind falla (mismo patrón que uevents).
4960- Nuevo módulo `brahman-handshake/src/transport.rs`: helper
4961  `default_socket_path()` con resolución `BRAHMAN_INIT_SOCKET` →
4962  `XDG_RUNTIME_DIR` → `TMPDIR`.
4963- Example `crates/core/brahman-handshake/examples/probe.rs`.
4964- Validación end-to-end manual: probe contra ente-zero vivo
4965  imprime `HelloAck: session=... init_attached=true`.
4966
4967### `07d77a3` feat(handshake): integra el broker con el ciclo de sesiones
4968- `ServerConfig` acepta `Option<Arc<Mutex<Broker>>>`.
4969- `register_session` indexa la Card en el broker y la `SessionRegistry`
4970  antes de emitir HelloAck.
4971- `Session::handle` refactor a `do_handshake → run_post_handshake →
4972  cleanup` con cleanup unificado (broker + sessions).
4973- Tests integ nuevos: `broker_registers_and_unregisters_with_session`
4974  y `broker_matches_two_live_modules`.
4975- Fix colateral: `brahman-card::TypeRef` pasa de internally-tagged
4976  (`#[serde(tag = "kind")]`) a externally-tagged. Postcard no soporta
4977  internally-tagged en formatos no self-describing. JSON cambia de
4978  `{"kind":"primitive","name":"x"}` a `{"primitive":{"name":"x"}}`.
4979
4980### `5091106` feat(core): brahman-broker — matching híbrido
4981- Crate nuevo `crates/core/brahman-broker`.
4982- 3 estrategias de matching: `Exact`, `Structural`, `ExactThenStructural`
4983  (default). Devuelven `Match::via` con la estrategia que ganó.
4984- Override `pin_to`: el consumer pide un productor por label; si la
4985  pista no resuelve, cae en type-search.
4986- Tiebreak por `Card.priority` desc, luego `label` asc (estable y
4987  determinista).
4988- API: `register`, `unregister`, `find_producer_for`, `all_matches`,
4989  `cards`, `sessions`, `len`, `is_empty`.
4990- 11 tests (matching, pin_to, priority, no-self-loops, all-matches).
4991
4992### `814390f` feat(core): brahman-handshake — protocolo runtime
4993- Crate nuevo `crates/core/brahman-handshake` con server y client
4994  Rust↔Rust sobre Unix socket.
4995- Frames length-prefixed (4 bytes LE) + cuerpo postcard.
4996- Mensajes: `Hello`, `HelloAck`, `Ping`, `Pong`, `Farewell`, `Error`.
4997- `MAX_FRAME_BYTES = 4 MiB` para evitar reservas absurdas.
4998- Tradeoff: drop `extensions`/`extra` de Card por incompat
4999  postcard ↔ `serde_json::Value`. Forward-compat queda en
5000  `schema_version` + `protocol_version` negotiation.
5001- 4 tests integ + 1 unit en codec.
5002
5003### `ed0e973` refactor(arje): migra ente-card a re-export de brahman-card
5004- `ente-card/src/lib.rs` reescrito como crate-shim de re-export
5005  (327 LOC → 25 LOC).
5006- `EntityCard` ≡ `brahman_card::Card` por type alias.
5007- `ente-card/Cargo.toml`: deps reducidas a `brahman-card`.
5008- `Card` impl `Default` (Ulid::nil(), label vacío) para que
5009  `..Default::default()` funcione en struct-literals.
5010- 4 sitios en `ente-zero/src/seed.rs` actualizados con
5011  `..Default::default()` para los campos aditivos.
5012- Los 21 consumidores arje compilan sin tocar fuente.
5013
5014### `0feba74` feat(core): brahman-card — Tarjeta canónica híbrida
5015- Crate nuevo `crates/core/brahman-card`.
5016- Hereda de arje: `id: Ulid`, `lineage`, `Capability` tipado,
5017  `Payload::{Wasm, Native, Virtual, Legacy}`, `SomaSpec`
5018  (namespaces, cgroups, rlimits, cpu_affinity), `Supervision`
5019  (Restart con backoff, OneShot, Delegate), `genesis` recursivo.
5020- Aditivo brahman: `Permissions` enumerados (`NetworkingPolicy`,
5021  `FsPolicy`, `IpcPolicy`), `Lifecycle` ortogonal a Supervision,
5022  `Priority` de scheduling, `Flows` con `TypeRef` discriminado
5023  (Primitive | Wit), `pin_to` opcional.
5024- `TrustLevel` derivado de `Permissions` (no declarado).
5025- `ResolvedCard { card, wit: Option<WitInterface>, trust }`.
5026- Soporta JSON (canónico) + TOML (auto-detectado por extensión).
5027- 8 tests incluido `arje_seed_format_compatible` que valida que
5028  el JSON de arje sigue parseando con defaults para los aditivos.
5029
5030### `4d50bfc` chore: absorbe nakui (ERP matemático) en modules/nakui
5031- `~/nakui` → `crates/modules/nakui/{core,modules}`.
5032- `core/`: el crate `nakui-core` con 4 bins (nakui, demo,
5033  inventory_demo, sales_demo) y tests.
5034- `modules/{inventory,sales,treasury}/`: data declarativa
5035  (`nsmc.json`, `schema.k`, `morphisms/`) que el crate consume.
5036  No son crates Cargo.
5037- Deps directas (no `workspace = true`): thiserror v1, surrealdb,
5038  rhai, petgraph. No conflicto con el resto del workspace.
5039
5040### `53dbdf0` chore: monorepo inicial con arje + minga + yahweh absorbidos
5041- 45 crates absorbidos en 4 ejes:
5042  - `crates/core/`: 24 crates de arje (Init systemd-compatible:
5043    `ente-card`, `ente-zero`, `ente-kernel`, `ente-bus`, `ente-cas`,
5044    `ente-soma`, `ente-wasm`, `ente-snapshot`, `ente-brain`,
5045    `ente-echo`, `ente-policy-provider`, + 12 `*-compat`).
5046  - `crates/modules/semantic_dht/`: 5 crates de minga (`minga-core`
5047    con AST/CAS/MST, `minga-p2p` con libp2p Kad, `minga-store`,
5048    `minga-vfs`, `minga-cli`).
5049  - `crates/modules/ui_engine/`: 11 crates de yahweh (libs/{core,
5050    theme, bus, providers}, widgets/{tree, splitter, tabs, tiled,
5051    container_core, text_input}).
5052  - `crates/apps/`: 5 crates de yahweh (file_explorer,
5053    database_explorer, text_viewer, image_viewer, yahweh-shell).
5054- `shared_wit/protocol.wit` con handshake/lifecycle inicial.
5055- `Cargo.toml` unificado: thiserror bumped a 2 (transparente para
5056  arje), tokio "full", paths intra-workspace de yahweh redirigidos.
5057- `cargo check --workspace`: 0 errores (sólo dead-code warnings
5058  preexistentes en ente-zero).