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