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