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