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