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