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