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