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