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