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