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