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