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