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