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