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