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