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