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