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