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