1# Changelog — nakui
2
3ERP categórico.
4
5### feat(nakui-ui): CRM como ERP — listas y formularios
6
7UiModule `examples/nakui-modules/crm/module.json`: hace que el módulo
8`crm` se vea como un ERP de verdad en `nakui-ui` (sidebar + listas +
9formularios), no como el timeline del event log de `nakui-explorer`.
10
11- 3 entities, 7 vistas: lista + formulario de Clientes, Oportunidades e
12  Interacciones, más los formularios de morfismo «Abrir», «Mover» y
13  «Registrar».
14- `nakui_module_dir` engancha el módulo-kernel `crm`: el form de cliente
15  siembra (`seed_entity`); «Abrir/Mover/Registrar» disparan los morfismos
16  reales con la validación del kernel (etapas, transiciones, canal).
17- 2 tests en `nakui-ui` verifican que el UiModule parsea, valida y carga
18  por el camino real (`brahman_cards::load_cards_from_dir`).
19
20Correr: `NAKUI_MODULES_DIR=examples/nakui-modules cargo run -p nakui-ui`.
21
22### feat(nakui): módulo `crm` — clientes, pipeline de ventas, interacciones
23
24Módulo CRM funcional, declarativo como inventory/sales/treasury
25(`crates/modules/nakui/modules/crm/`): `schema.ncl` + `nsmc.json` +
26morfismos Rhai. Tres entities — `Cliente`, `Oportunidad`, `Interaccion`
27— y tres morfismos:
28
29- `abrir_oportunidad(cliente)` — crea una `Oportunidad` en etapa
30  `prospecto`.
31- `mover_oportunidad(oportunidad)` — avanza el pipeline
32  (prospecto→calificado→propuesta→negociacion→ganada/perdida). Valida:
33  etapa destino conocida, no mover una oportunidad cerrada, no retroceder.
34- `registrar_interaccion(cliente)` — crea una `Interaccion`
35  (llamada/email/reunión).
36
37- `core/src/bin/crm_demo.rs` — demo realista (3 clientes, 18 eventos).
38  A diferencia de los otros demos **no borra el event log**: lo deja en
39  disco e imprime el comando para abrirlo con `nakui-explorer` — así el
40  explorador, que sólo mostraba un log vacío, muestra un CRM con cuerpo.
41- `core/tests/crm.rs` — 8 tests de integración (pipeline completo +
42  rechazos: retroceso, oportunidad cerrada, etapa/canal/monto inválidos).
43
44Nota: el engine Rhai de `nakui-core` es `Engine::new_raw()` con paquetes
45selectos — `Array::index_of` no resuelve; los morfismos usan sólo
46`if`/`==`/`throw`.
47Iter 17. Regresión surfaceada por el workspace test
48`verify_log_rejects_seed_after_schema_kcl_changes` (rebautizado a
49`verify_log_rejects_seed_after_schema_changes`).
50
51**Bug**: `compute_schema_bundle_hash` operaba sobre los bytes del
52bundle compilado, que `build_schema_bundle` arma como
53`(import "/abs/path/schema.ncl") & ...`. Los bytes del bundle nunca
54cambian cuando se edita el archivo apuntado — sólo cambian si se
55agregan/quitan schemas o se mueve el módulo de path. Resultado: el
56hash quedaba pegado y los seeds firmados bajo schema vN se aceptaban
57silenciosamente como válidos bajo schema vN+1, aunque las invariantes
58hubieran cambiado.
59
60**Fix**: nueva fn `read_schema_files_concat(module_dir, schemas)`
61que lee los bytes de cada schema declarado y los concatena con
62framing `\0NCL:<name>\0` (separador no ambiguo + nombre relativo, no
63absoluto, para que el hash sea estable entre máquinas). Esos bytes
64alimentan `compute_schema_bundle_hash` y `compute_morphism_schema_hash`
65en lugar de los bytes del bundle. El bundle compilado sigue siendo
66imports-style (necesario para que Nickel resuelva paths relativos);
67sólo la fuente del hash cambió.
68
69**Impacto en logs existentes**: como cualquier cambio al insumo del
70hash, los seeds y morphisms versados bajo el bundle hash anterior
71fallarán `SchemaMismatch` al verificarse contra un binario nuevo. No
72hay migración — esto es exactamente el comportamiento que el hash
73busca: re-seed.
74
75Tests: 10/10 en `schema_versioning` (era 9/10 con 1 FAILED).
76
77### refactor(nakui-core): KCL → Nickel — `kcl_wrapper` reemplazado por evaluación in-process
78Cierra el ciclo: el motor de validación de entities deja de
79shellear el binario externo `kcl` y pasa a evaluar **Nickel
80contracts** in-process via la dep `nickel-lang` (la misma que ya
81usa `brahman-cards` para sus templates). Los 3 schemas de los
82módulos sales/inventory/treasury migran de `.k` a `.ncl`.
83Además se borran los 2 archivos `.k` doc-only del repo
84(`ente-card/schema/card.k`, `ente-brain/schema/rule.k` — ambos
85estaban marcados "REFERENCE ONLY. NOT LOADED").
86
87Cambios en **nakui-core**:
88- **Nueva dep**: `nickel-lang = "2.0.0"` (interfaz estable).
89- **Borrado** `kcl_wrapper.rs` (43 líneas) — shellear el binario
90  desaparece.
91- **Nuevo** `nickel_validator.rs`:
92  - `pub fn vet(schema_path, state, schema_name) -> Result<(), NickelError>`
93    evalúa `let bundle = (import "<schema>") in
94    (std.deserialize 'Json m%%"<json>"%%) | bundle.<entity>`.
95  - El state JSON va dentro de un raw string Nickel
96    (`m%%"..."%%`) y se deserialize via `std.deserialize 'Json`.
97    No embebemos el state como record literal Nickel directo
98    porque la sintaxis JSON usa `:` (Nickel records usan `=`).
99  - 5 tests propios cubriendo happy path + 4 fallure modes
100    (field missing, predicate fails, cross-field invariant
101    fails, optional field present/absent).
102- **`executor.rs`**:
103  - `kcl_wrapper::vet` → `nickel_validator::vet`.
104  - `KclError` → `NickelError`.
105  - `ExecError::KclPre/KclPost/KclPostCreate` → `SchemaPre/Post/PostCreate`
106    (más neutro, ya no menciona KCL).
107  - `kcl_check` (privado) → `validate_entity`.
108  - `build_schema_bundle` ahora emite un archivo Nickel con
109    `(import "X") & (import "Y") & ...` en lugar de concatenar
110    bytes (cada `.ncl` es una expresión record completa, no
111    juntable como texto plano).
112- **`manifest.rs`**:
113  - `effective_schemas` default `"schema.k"` → `"schema.ncl"`.
114  - `extract_schema_names` reescrito: ahora detecta keys
115    CapitalCase con 2 spaces de indent (convención de los
116    `schema.ncl`), no más patrón `schema X:` de KCL.
117  - Tests del extractor actualizados (1 test reemplazado por 2:
118    `_handles_nickel_record_top_level` + `_skips_let_bindings_and_lowercase`).
119
120Cambios en **schemas de módulos**:
121- **`sales/schema.ncl`**: contracts Nickel para `Venta`. Usa
122  `std.contract.Sequence [record_contract, from_predicate]`
123  para combinar shape + invariante cross-field
124  (`total == cantidad * precio_unitario`). El patrón directo
125  `record | from_predicate` rebota con "missing definition" porque
126  el predicate evalúa el contract antes de que el value lo
127  populate; documentado en el comment.
128- **`inventory/schema.ncl`**: `Stock`, `MovimientoStock`,
129  `TransferenciaStock` (esta última con cross-field
130  `source != dest` via Sequence).
131- **`treasury/schema.ncl`**: `Caja`, `Movimiento`,
132  `Transferencia` (con cross-field via Sequence).
133- Helpers locales en cada archivo: `positive_int`,
134  `non_negative_int`, `currency_iso`, etc. via
135  `std.contract.from_predicate`.
136- Los 3 `schema.k` viejos **borrados**.
137- `sales/nsmc.json` actualizado: paths `schema.k` →
138  `schema.ncl`.
139
140Cambios en **tests**:
141- `sales.rs`, `inventory.rs`: `KclPost` → `SchemaPost`.
142- `kernel_guards.rs`: `KclPostCreate` → `SchemaPostCreate`,
143  path del schema directo `treasury/schema.k` →
144  `treasury/schema.ncl`.
145- `graph.rs`, `manifest_validation.rs`: tests que escriben
146  `schema.k` inline cambian a `schema.ncl` con sintaxis Nickel.
147- `schema_versioning.rs`: refs `schema.k` → `schema.ncl`.
148
149Cambios documentales:
150- **Borrado** `crates/core/ente-card/schema/card.k` (1 archivo,
151  REFERENCE ONLY documentado en su header).
152- **Borrado** `crates/core/ente-brain/schema/rule.k` (REFERENCE
153  ONLY documentado en su header).
154
155Tests:
156- **nakui-core**: 84 tests verdes (41 unit + 43 integration en
157  graph/event_log/manifest_validation/schema_versioning/
158  inventory/sales/kernel_guards). Suite full pasa.
159- **nakui-ui**, **brahman-cards**, **yahweh-***: sin cambios,
160  todos verdes.
161- Total cubriendo el área: 174 tests.
162
163Beneficios:
164- **Sin dep externa**: el binario `kcl` ya no es requisito de
165  runtime ni de tests. Build limpio en CI sin instalar KCL.
166- **Errores en línea**: Nickel reporta contract violations con
167  caret pointing al field exacto del schema y el value que
168  falló. KCL daba mensajes textuales menos navegables.
169- **Mismo motor que el brazo de cards**: una sola dependencia
170  Nickel para todo el repo (validación + templates de cards).
171- **Sin tempfile JSON intermedio**: el state se evalúa
172  directamente en memoria; no hay `std::fs::write` por cada
173  validate.
174
175Limitaciones / decisiones:
176- El comentario "REFERENCE ONLY" de los `.k` borrados ya estaba
177  marcado en sus headers; eran sólo notas de diseño para humanos.
178  La autoridad real (Rust validate methods) sigue intacta.
179- La sintaxis Nickel `record_contract | from_predicate` no
180  funciona — hay que envolver en `std.contract.Sequence [record,
181  from_predicate]`. Documentado en cada schema y en el doc del
182  validator.
183
184**Pendientes restantes**: ninguno del refactor original. Los
185yahweh + KCL + card.k cierran. Próximos pendientes salen de
186nuevo trabajo (no del plan que arrastrábamos).
187
188### feat(nakui-ui): migrar consumer al brazo unificado `brahman_cards::load_cards_from_dir`
189Primera consumer migration del brazo. `nakui-ui` ya no llama a
190`nakui_ui_schema::load_modules_from_dir` directamente — pasa por
191`brahman_cards::load_cards_from_dir` y extrae el variant `UiModule`
192del `CardBody` de cada Card. Beneficios concretos:
193
194- **Soporta `.ncl` además de `.json`**: el usuario puede dropear un
195  `card.ncl` (con templates Nickel + merge) en cualquier subdir y
196  el runtime lo levanta automáticamente. El layout legacy
197  `examples/nakui-modules/<id>/module.json` sigue funcionando vía
198  los filenames default `[card.ncl, card.json, module.ncl, module.json]`.
199- **Cards de otros body kinds (Ente/Monad) se skipean limpio**:
200  si el dir contiene Cards no-UiModule, se reportan en un toast
201  informativo en lugar de fallar la carga.
202
203Cambios en `brahman-cards`:
204- **Nuevo `load_cards_from_dir(dir)`** + variante con readers/filenames
205  custom. Walkea subdirs (orden lexicográfico), busca el primero de
206  `DEFAULT_CARD_FILENAMES`, dispatcha al reader. Subdirs sin ningún
207  filename matching se skipean silenciosamente (permite assets/fixtures
208  sueltos al lado de los cards). Errores per-file se propagan loud
209  (sin ocultar corrupción).
210- **`pub const DEFAULT_CARD_FILENAMES`**: lista canónica probada en
211  orden. `card.ncl` tiene prioridad sobre `card.json` y sobre los
212  legacy `module.*`.
213- **4 tests nuevos del helper**: walk + skip de subdirs sin
214  card, prioridad ncl > json, propagación loud de errores per-file,
215  custom filenames.
216
217Cambios en `nakui-ui`:
218- **Nueva dep** `brahman-cards` en `Cargo.toml`.
219- **Nuevo helper `load_ui_modules(dir) -> (Vec<Module>, Vec<String>)`**
220  que envuelve `brahman_cards::load_cards_from_dir`, filtra a
221  UiModule body, valida cada Module con su `validate()`, ordena
222  por id, y detecta duplicados. El callsite en `MetaUi::new` pasa
223  a usarlo y al ver Cards skipped emite un toast informativo.
224- **3 tests nuevos**:
225  - `load_ui_modules_via_brahman_cards_returns_ui_modules_and_skips_others`
226    — verifica que un dir con UiModule + Ente carga el primero y
227    reporta el segundo en `skipped`.
228  - `load_ui_modules_via_brahman_cards_rejects_invalid_module` —
229    `Module::validate()` se sigue aplicando (menu apuntando a view
230    inexistente rebota).
231  - `load_ui_modules_detects_duplicate_id` — dos UiModule con
232    mismo id rebotan con mensaje claro.
233
234Tests totales:
235- `brahman-cards`: 22 → 26 (+4 helper directorio).
236- `nakui-ui`: 45 → 48 (+3 e2e migración).
237- Workspace build verde.
238
239Lo que NO cambió:
240- `nakui_ui_schema::load_modules_from_dir` se mantiene intacto (sus
241  propios tests lo siguen usando, y otros consumers futuros podrían
242  preferir su error-typing más específico). La migración es opt-in:
243  `nakui-ui` usa el brazo, ui-schema sigue siendo una API válida.
244- Layout actual de `examples/nakui-modules/<id>/module.json` no
245  requiere cambio. Un usuario puede convertir cualquier módulo a
246  `card.ncl` sin tocar el dir layout.
247
248**Pendientes para próximos commits** (orden):
2491. **Yahweh refactor**: lift del MetaUi runtime a
250   `crates/modules/ui_engine/` para reuso. El brazo + canónico ya
251   estables, ahora puede extraerse el meta-form widget genérico.
2522. **KCL → Nickel**: kcl_wrapper reemplazado por Nickel contracts;
253   los 3 schemas .k de nakui modules pasan a .ncl.
2543. **card.k eliminado** (es REFERENCE ONLY documentado).
255
256### feat(nakui-ui): validación cross-field del EntityRef (existence en store)
257Cierra otro pendiente. Hasta ahora `parse_field_value(EntityRef, raw)`
258sólo validaba **forma** (UUID parseable + trim de whitespace) — un
259UUID válido pero inexistente en el store pasaba silenciosamente al
260log/store, dejando dangling references. Ahora validamos también
261**existencia** contra la entity declarada en `FieldSpec.ref_entity`.
262
263Cambios:
264- **Nuevo helper `validate_entity_refs<S: Store>(store, refs)`**:
265  - `refs: &[(label, target_entity, uuid)]`.
266  - Loop fail-fast: primer record ausente → error con label
267    legible + UUID corto + target entity en el msg
268    `"campo 'Stock': record abc12345 de 'Stock' no existe en el store"`.
269  - Pure (toma `&S: Store`), totalmente testable sin GPUI.
270- **Wireup en `commit_seed`**:
271  - Durante el parse loop, cuando un field es EntityRef + tiene
272    `ref_entity` declarado + value parseado a UUID, lo encolamos
273    en `entity_refs: Vec<(String, String, Uuid)>`.
274  - Después del parse loop (antes del seed/edit branch), si
275    `entity_refs` no está vacío, una sola toma del store lock
276    para validar todos via el helper.
277  - Falla early: ningún log entry, ningún apply.
278- **Cobertura**:
279  - SEED path: alta nueva con EntityRef → validamos antes de
280    `Seed { data }`.
281  - EDIT path: edit con EntityRef → validamos antes de calcular
282    delta. Una optional empty (que iría a clear) no cuenta como
283    EntityRef (raw vacío skipea el push).
284  - Morphism inputs: NO se duplica acá. `Executor::compute` ya
285    valida cada input via `store.load(...).ok_or(EntityMissing)`
286    antes de correr el script Rhai. Documentado en el doc del
287    helper.
288
2895 tests nuevos:
290- `validate_entity_refs_passes_when_all_records_exist` — happy path.
291- `validate_entity_refs_fails_on_first_missing` — fail-fast con
292  msg que incluye entity + UUID corto.
293- `validate_entity_refs_uses_label_not_entity_in_msg` — el label
294  legible (ej: "Stock origen") aparece en el error, no la entity
295  desnuda.
296- `validate_entity_refs_empty_list_is_ok` — lista vacía es Ok.
297- `validate_entity_refs_distinguishes_target_from_other_entities` —
298  un UUID que existe bajo Customer pero NO Stock falla la
299  validación contra Stock.
300
30145 tests verdes en nakui-ui (+5). Workspace build verde.
302
303Comportamiento esperado:
304- **Selector clickable es happy path**: el dropdown sólo lista
305  records existentes, así que clickearlo nunca debería disparar
306  el error. Sólo dispara con paste manual de UUID que no existe
307  o records borrados después de la selección (timing race).
308- **Optional empty no se valida**: si el field es EntityRef
309  optional y el form lo deja vacío, lo manejamos como "no value"
310  (skipea el push a `entity_refs`); la lógica de Clear se
311  encarga del resto.
312- **Lock contention**: una sola toma del store lock por
313  `commit_seed`, no una por field. La validación es O(refs) reads.
314
315Pendientes restantes:
316- **Validación KCL del record post-edit** antes de emitir Set/Clear
317  (hoy `ui.edit_record` no pasa por `Executor::compute`).
318- **EntityRef cross-module** (referenciar records de OTRO módulo
319  por nombre, no sólo por entity local).
320
321### feat(nakui-core,nakui-ui): FieldOp::Clear — borrar values vía form vacío
322Cierra el último pendiente de UX del round. El edit no podía
323"borrar" un value vaciando el input — empty optional fields
324hacían `continue` en `commit_seed`, así que el current value
325quedaba intacto. Para honrar el intent del usuario ("este field
326ya no aplica") necesitábamos un FieldOp explícito que remueva
327la key del map.
328
329Cambios en **nakui-core** (la variante es semántica del kernel,
330no específica de la UI):
331
332- **`delta::FieldOp::Clear { path }`** — nueva variante.
333  Distinta de `Set { value: Null }`: Clear borra la clave; Set
334  Null deja la clave con valor literal `null`. Importa para
335  downstream que diferencia "ausente" vs "presente como null"
336  (ej: serde con `skip_serializing_if = "Option::is_none"`).
337- **`capability_token`** — Clear devuelve `entity.field`,
338  mismo shape que Set. Una capability `writes: ["Customer.notes"]`
339  autoriza tanto Set como Clear sobre ese field.
340- **`simulate_on`** — Clear remueve la key del Object si el
341  state es Some(Object). Skip silente si el state es None
342  (deleted) o no-objeto.
343- **`MemoryStore::apply_dry_run`** — Set y Clear comparten
344  pre-condición (record padre existe + es objeto). Pattern
345  combinado con `|`.
346- **`MemoryStore::apply`** — Clear hace `map.remove(field)`.
347  Field ausente = no-op silencioso (post-state idéntico).
348- **`SurrealStore::apply_dry_run`** — Set/Clear combinados.
349- **`SurrealStore::apply`** — Clear emite
350  `UPDATE type::thing UNSET <field>`. El field name viene de
351  un FieldSpec validado upstream; SurrealQL no soporta binding
352  de identifiers, así que va inline (con la advertencia
353  documentada en el comment).
354- **`Executor` capability check** — Set/Clear comparten match
355  (mismo token shape, misma resolución a binding role).
356- **Conservation rules** (en `check_conservation`) NO consideran
357  Clear — sólo Set. Documentado: morphism authors que querían
358  clear de un field con conservation tienen que ser cuidadosos;
359  KCL post-checks pueden capturar violations.
360
361Cambios en **nakui-ui**:
362
363- **`commit_seed` loop** acumula `to_clear: Vec<String>` con
364  los nombres de fields optional empty (en lugar de hacer
365  `continue` silencioso).
366- **EDIT branch**:
367  - Computa `set_delta` (igual que antes) + `clear_fields` via
368    nuevo helper `compute_clear_fields(current, to_clear)`.
369  - Helper filtra a sólo los fields que actualmente tienen
370    valor non-null — Clear de un field ausente o ya null no
371    se emite (sería no-op semántico). Preserva el orden del
372    input para estabilidad del log entry.
373  - Construye `ops` combinando Set + Clear.
374  - NoChange ahora requiere AMBOS vacíos (set_delta y
375    clear_fields).
376  - `params` del log entry incluye `cleared: ["field1", ...]`
377    sólo si non-empty (preserva la shape `fields:` para
378    edits sin clears).
379  - `CommitOutcome::Updated.changed = sets + clears` para
380    que el toast `"actualizado X (N campo(s))"` siga siendo
381    preciso.
382
383Tests nuevos:
384- **delta.rs**: `simulate_clear_removes_field`,
385  `simulate_clear_then_set_same_field_keeps_set`,
386  `clear_capability_token_matches_set_shape`.
387- **store.rs**: `apply_clear_removes_field_key`,
388  `apply_clear_on_absent_field_is_noop`,
389  `dry_run_rejects_clear_on_missing_record`,
390  `dry_run_rejects_clear_on_non_object`.
391- **nakui-ui main.rs**: `clear_fields_skips_absent_and_null`,
392  `clear_fields_preserves_input_order`,
393  `clear_fields_empty_when_current_is_null`.
394
39534 tests verdes en nakui-core (+7), 40 en nakui-ui (+3).
396Workspace build verde. E2E del morphism real
397`morphism_pipeline_executes_real_sales_vender` intacto — `vender`
398no usa Clear.
399
400Implicaciones:
401- **El log puede crecer con entries `ui.edit_record` que sólo
402  tienen `cleared: [...]`** sin `fields`. Esperado y esperable.
403- **Replay**: las entries con Clear se aplican en orden via
404  `store.apply(&ops)`. La semantic es deterministic.
405- **Si un módulo tiene KCL invariants sobre la presencia de un
406  field**, el usuario podría romper el record vaciando ese
407  field via UI. Hoy esto NO se chequea — `ui.edit_record` es
408  un morphism manual que no pasa por `Executor::compute`. Si
409  esto es un problema, el camino futuro es validar contra el
410  KCL del entity al submit (otro pendiente).
411
412Pendientes restantes:
413- **Validación cross-field** (ej: UUID del EntityRef existe en
414  la entity referida).
415- **Validación KCL del record post-edit** antes de emitir Set/Clear.
416
417### feat(nakui-ui): snapshot/compaction durante runtime cada N writes
418Cierra el último pending del round de persistencia. Antes el compact
419sólo corría al startup — para una sesión larga con muchas escrituras,
420el log crecía sin tope hasta el próximo restart, y el siguiente boot
421pagaba el costo lineal del replay.
422
423Cambios:
424- **Nuevos fields en `MetaUi`**:
425  - `snap_path: PathBuf` — cacheado del init para que el tick no
426    tenga que recomputarlo.
427  - `snapshot_threshold: usize` — leído del env en `new()` y
428    cacheado. `0` desactiva runtime compact (mismo env y
429    semantic que el threshold de startup).
430  - `writes_since_compact: u64` — contador que incrementa por cada
431    write efectivo y se resetea cuando el threshold dispara
432    `maybe_compact_log`.
433- **Nuevo método `tick_runtime_compact()`**:
434  - Early return si `threshold == 0`.
435  - Increment + check vs threshold.
436  - Si cruza: lock log + store, llama `maybe_compact_log`.
437  - **Si compactó OK**: counter = 0, devuelve msg.
438  - **Si `maybe_compact_log` returned None** (counter dijo "go"
439    pero entries < 2): counter = 0 (no re-entrar cada write).
440  - **Si error**: counter NO se resetea (próximo write reintenta),
441    devuelve el error.
442- **Nuevo helper `append_compact_msg(base, opt)`**: concatena el
443  msg del compact al toast del op original con `";"` separator.
444- **Wireup en 3 callsites de write efectivo**:
445  - `apply_action::SeedEntity`: tick si outcome != NoChange.
446  - `apply_action::Morphism`: tick siempre que Ok.
447  - Click handler `[Confirmar]` del delete modal: tick si commit_delete Ok.
448- **NoChange no cuenta**: un edit que no cambia nada no escribe al
449  log, así que tampoco debería avanzar el counter — preserva la
450  semantic "1 write = 1 log entry = 1 tick".
451
4522 tests nuevos:
453- `append_compact_msg_handles_both_branches` — base solo vs base
454  + compact, formato del separator.
455- `runtime_compact_cycle_resets_counter_after_threshold` — E2E
456  estilo simulación: 7 writes con threshold=3 → 2 compacts (en
457  write 3 y 6), counter residual = 1, log final con 2 entries
458  (1 anchor + 1 write residual). Reproduce el algoritmo del tick
459  sin GPUI cx; si la lógica del método cambia, se rompe como signal.
460
46137 tests verdes (+2). Workspace build verde.
462
463Trade-offs:
464- **Counter en memoria, no persistido**: si la app crashea entre
465  compacts, al próximo boot el counter parte de 0. El startup
466  compact (basado en entry_count del log file) compensa esto:
467  si quedó mucho post-último-compact, se compacta al boot.
468- **Lock orden**: tick toma log lock primero, store lock después.
469  Misma orden que `commit_seed` y `commit_morphism`, no debería
470  haber deadlock.
471- **Costo del tick**: 1 increment + 1 compare por write. Cuando
472  cruza threshold, 1 read del log (entries) + 1 snapshot write +
473  1 compact. Para threshold=50 es ~1 fsync cada 50 writes —
474  amortiza bien.
475
476Pendientes restantes:
477- **`FieldOp::Clear`** — para soportar borrar un value vía form vacío.
478- **Validación cross-field** (UUID del EntityRef existe en la
479  entity referida).
480
481### feat(nakui-ui): atajo Esc para cancelar el modal de delete
482Cierra otro pendiente de UX. El banner de confirmación de delete
483ya tenía botones [Cancelar] / [Confirmar], pero la acción más
484natural para cancelar un dialog es Esc — y no la teníamos wireada.
485
486Cambios:
487- **`capture_key_down` en el root div** del `MetaUi::render`. Capture
488  phase (no bubble) para interceptar el Esc *antes* que cualquier
489  TextInput descendiente lo consuma. Sin pending el handler es
490  no-op y el evento sigue su flujo normal.
491- **Match `event.keystroke.key == "escape"`** + `pending_delete.take()`
492  → toast `"delete cancelado (Entity) [esc]"` (sufijo `[esc]` para
493  diferenciar visualmente del botón). Si no hay pending, return
494  temprano sin tocar nada.
495- **Hint visual en el banner**: subtítulo en amber tenue debajo del
496  título: `"Esc para cancelar · click [Confirmar] para borrar"`.
497  Que el usuario descubra el atajo sin RTFM.
498
49935 tests verdes — el handler de Esc es 8 líneas no-testeables sin
500GPUI cx (la lógica de pending_delete + toast vive dentro del
501listener); el wireup compila por type-check.
502
503Pendientes restantes:
504- **`FieldOp::Clear`** — para soportar borrar un value vía form vacío.
505- **Snapshot durante runtime** (cada N writes, no sólo al startup).
506- **Validación cross-field** (UUID del EntityRef existe en la
507  entity referida).
508
509### feat(nakui-ui): EntityRef validation en parse_field_value (UUID al submit)
510Cierra otro pendiente: `parse_field_value(FieldKind::EntityRef, raw)`
511devolvía `Ok(json!(raw))` blindly — el value entraba al log/store
512incluso si era basura. La validación de UUID sólo ocurría cuando el
513field se usaba como **input** del morphism (línea ~540 de
514`commit_morphism`); como **seed field** o como **param**, garbage
515pasaba silenciosamente.
516
517Cambios:
518- **`parse_field_value(EntityRef, raw)`** ahora hace
519  `Uuid::parse_str(raw.trim())` y devuelve error claro si falla:
520  `"'<raw>' no es UUID válido (usá el selector de records)"`. En
521  caso de éxito, devuelve el UUID **trimmed** como string —
522  protege contra paste manual con whitespace.
523- **Doble cobertura**: este path cubre seed fields (commit_seed via
524  obj.insert) y morphism params (resolve_param_value lo invoca por
525  cada FieldSpec con kind=EntityRef). El path de morphism inputs
526  ya validaba antes con `Uuid::parse_str` directo — sigue intacto,
527  no hay double-validation.
528- **Selector clickable es happy path**: el dropdown setea valores
529  bien-formados, así que el usuario nunca debería ver el error en
530  uso normal. Sólo dispara con paste manual o si el usuario escribe
531  garbage en el input — defensivo.
532
5335 tests nuevos (reemplazan al obsoleto `parse_field_entity_ref_returns_string`):
534- `parse_field_entity_ref_accepts_valid_uuid` — happy path.
535- `parse_field_entity_ref_trims_whitespace` — `"  uuid\n"` → `"uuid"`.
536- `parse_field_entity_ref_rejects_non_uuid` — `"abc-123"` → error
537  con el value y la palabra "UUID" en el mensaje.
538- `parse_field_entity_ref_rejects_empty_string` — `""` → rebota.
539- `resolve_param_strict_entity_ref_propagates_error` — sanity de
540  que el wireup en resolve_param_value hereda el strict checking,
541  con label del FieldSpec en el mensaje.
542
54335 tests verdes (+4 net). El E2E del morphism real
544`morphism_pipeline_executes_real_sales_vender` sigue verde — sus
545inputs van por el path dedicado, no por parse_field_value.
546
547Pendientes restantes:
548- **Atajo Esc para Cancelar** del modal de delete.
549- **`FieldOp::Clear`** — para soportar borrar un value vía form.
550- **Snapshot durante runtime** (cada N writes, no sólo al startup).
551- **Validación cross-field** (ej: el UUID del EntityRef existe en
552  la entity referida) — hoy sólo validamos forma; un UUID válido
553  pero inexistente sí pasa.
554
555### feat(nakui-ui): snapshot/compaction automático del event log al startup
556Cierra el último gran pendiente del round: el replay full cada
557startup escala lineal en el log. Con 60+ entries el costo de boot
558se nota; con 10k entries es prohibitivo. Wireamos el snapshot
559machinery que ya estaba en `nakui-core` (`Snapshot`,
560`replay_with_snapshot_into`, `EventLog::compact_through`) al
561runtime de la UI.
562
563Cambios:
564- **Path del snapshot**: sibling del log, extensión `.snap.json`.
565  `nakui-ui-state.jsonl` ↔ `nakui-ui-state.snap.json`.
566- **Nuevo helper `snapshot_path_for(log_path)`** — derivación
567  pura, testeable.
568- **Nuevo helper `maybe_compact_log(log, snap_path, store, threshold)`**:
569  - Si `entry_count >= threshold` y `>= 2`, captura
570    `Snapshot::from_memory_store(store, next_seq - 1)`, lo escribe
571    atómicamente, y compacta el log dejando la última entry como
572    anchor.
573  - Anchor invariant: `EventLog::open` deriva `next_seq` del primer
574    entry del archivo. Si compactáramos *todo* el log file, al
575    reabrir el cursor volvería a 0 y el próximo append crashearía
576    con `NonMonotonic`. Por eso compactamos sólo hasta
577    `next_seq - 2` — la entry del `snap.seq` queda como anchor del
578    cursor; `replay_with_snapshot_into` la skipea porque snap ya
579    cubre hasta ese seq inclusive.
580  - Threshold via env `NAKUI_SNAPSHOT_THRESHOLD`, default 50.
581    `0` desactiva por completo.
582  - Devuelve `Result<Option<msg>, String>`: `Ok(Some)` si compactó,
583    `Ok(None)` si no había payoff, `Err` si snap o compact fallaron.
584- **`MetaUi::new` reescrito**:
585  - Carga snapshot al inicio (Some/None según exista).
586  - `replay_with_snapshot_into(&log, snapshot.as_ref(), &mut store)`
587    en lugar de `replay_into`.
588  - Después del replay corre `maybe_compact_log` con el threshold.
589  - Toast inicial menciona snapshot loaded si aplica
590    ("snapshot @ seq K") y la compactación si ocurrió.
591  - Errores de snapshot load **no son fatales**: cae a full replay
592    con un msg en el banner.
593  - Errores de auto-compact **no son fatales**: el log + snap
594    quedan como estaban, msg al banner.
595
5965 tests nuevos:
597- `snapshot_path_for_replaces_extension` — `.jsonl` → `.snap.json`,
598  edge case sin extensión.
599- `maybe_compact_log_below_threshold_noops` — 5 entries vs threshold
600  50: no toca nada, no escribe snap.
601- `maybe_compact_log_threshold_zero_noops` — threshold 0 = disabled.
602- `maybe_compact_log_then_reopen_preserves_records` — E2E:
603  - Escribe 60 seeds (log + store en sync).
604  - Compacta (60 >= 50): snap escrito, log queda con 1 anchor entry,
605    msg reporta "59 entries dropped (1 anchor kept)".
606  - Reopen: `next_seq=60` se preserva via anchor, `entries.len()=1`.
607  - Replay con snap loadado en store fresco: los 60 records están.
608  - Segunda corrida del compact con threshold=1: no-op (idempotente).
609
61031 tests verdes (+5). Workspace build verde tras la nueva firma.
611
612Trade-offs y notas:
613- **Fail-soft**: cualquier error de snap/compact no rompe el boot;
614  la UI sigue funcionando con full replay y el toast lo reporta.
615  Sólo `EventLog::open` failing es no-recoverable (pierde
616  persistencia).
617- **Crash-safety**: WAL order preservado — escribimos snap (atómico
618  via tempfile + fsync + rename) ANTES de compactar el log
619  (atómico igual). Si crasheamos entre los dos, próximo boot ve
620  snap@K + log con todas las entries 0..N — replay skippea las que
621  snap cubre, outcome idéntico.
622- **Sólo en startup**: no hay snapshot durante runtime. Para sesiones
623  largas con muchas escrituras, el log puede crecer arbitrariamente
624  hasta el próximo restart. Pendiente futuro: snapshot N writes
625  desde el último compact.
626- **Anchor entry sobrevive sin uso útil**: el costo es 1 línea JSON
627  por compact. No es preocupación a menos que el threshold sea
628  muy chico (cada compact deja 1 línea de basura).
629
630Pendientes restantes:
631- **EntityRef validation post-submit** — validar UUID parseable al
632  submit en lugar de al execute del morphism.
633- **Atajo Esc para Cancelar** del modal de delete.
634- **`FieldOp::Clear`** — para soportar borrar un value vía form vacío.
635- **Snapshot durante runtime** (cada N writes, no sólo al startup).
636
637### feat(nakui-ui): edit delta-only — sólo campos modificados al log/store
638Antes de este cambio, editar un record emitía un `FieldOp::Set` por
639**cada field del form**, incluso los no tocados. Eso bloata el log
640(replay tenía que aplicar N ops cuando 1 alcanzaba) y oscurece el
641intent en una auditoría posterior. Con delta-only, el edit emite
642sólo los Sets cuyo value nuevo difiere del actual; un edit que no
643cambia nada deja el log intacto.
644
645Cambios:
646- **Nuevo helper `compute_field_delta(current, proposed)`** — toma
647  el record actual del store (un `Value`, posible `Null` si el
648  record no existe) y el `Map` propuesto desde el form, y devuelve
649  sólo las entries que difieren. Comparación: `PartialEq` estructural
650  de `serde_json::Value` (un `Null` en current = todos los proposed
651  son nuevos).
652- **Nuevo enum `CommitOutcome`**:
653  - `Created(Uuid)` — alta nueva.
654  - `Updated { id, changed }` — edit con N campos modificados.
655  - `NoChange(Uuid)` — edit sin diferencias (el toast lo refleja
656    como "X sin cambios — no log entry").
657- **`commit_seed` en path EDIT**:
658  - Carga current via `store.load(entity, id)` con fallback a
659    `Value::Null`.
660  - Calcula delta. Si vacío → return early sin tocar log ni store.
661  - Si no vacío → emite `Morphism { ui.edit_record, ops: [Set...] }`
662    con `params.fields` reflejando el delta (no todo el form),
663    haciendo la auditoría grep-able por field cambiado.
664- **Toast del callsite**:
665  - `creado X uuid` (Created)
666  - `actualizado X uuid (N campo(s))` (Updated)
667  - `X uuid sin cambios — no log entry` (NoChange)
668- **`editing` se limpia incluso en NoChange** — el modo edit cierra,
669  el form vuelve al state limpio.
670
6715 tests nuevos del helper:
672- delta vacío cuando todo coincide.
673- delta sólo con el field cambiado.
674- delta full cuando current = Null (record no existe).
675- distingue int 100 de string "100".
676- ignora fields del current que no están en proposed.
677
67827 tests verdes (+5). El path SEED no cambió; el E2E del morphism
679real sigue verde.
680
681Limitación conocida (consistente con pre-delta): el form no puede
682**borrar** un value vaciando el input — empty optional fields hacen
683`continue` antes de llegar al delta. Para clearear un value hay que
684declarar el field como required, o esperar a un `FieldOp::Clear`
685futuro (no necesario hoy: ningún demo lo requiere).
686
687Pendientes restantes:
688- **Snapshot/compaction** del log (replay full cada startup escala
689  mal con repos grandes).
690- **EntityRef validation post-submit** — validar UUID parseable al
691  submit en lugar de al execute del morphism.
692- **Atajo Esc para Cancelar** del modal de delete.
693- **`FieldOp::Clear`** — para soportar borrar un value vía form.
694
695### feat(nakui-ui): confirmación de delete vía banner modal antes de borrar
696Cierra el primer pending del último round: borrar un record pedía un
697solo click en `✕` y se ejecutaba inmediatamente (irreversible —
698queda en el log como `Morphism { name: "ui.delete_record" }`). Ahora
699hay un paso intermedio: el click marca el record como pendiente y el
700banner amber al tope de la ventana ofrece [Cancelar] o [Confirmar].
701
702Cambios:
703- **Nuevo state `MetaUi.pending_delete: Option<(String, Uuid)>`**.
704  Set en el click del `✕`; limpiado por:
705  - [Cancelar] → toast "delete cancelado (Entity)".
706  - [Confirmar] → llama `commit_delete` (igual que antes) y emite
707    el toast usual.
708  - Navegación a otra view (`select_view`) — el record marcado
709    podría no estar visible en la nueva pantalla.
710- **Click handler de `✕` ya no llama `commit_delete`**: sólo setea
711  `pending_delete` y limpia toast. La acción destructiva ahora vive
712  exclusivamente en el botón [Confirmar] del banner.
713- **Nuevo método `render_confirm_delete_banner`**: devuelve
714  `Option<Div>` (None si no hay pending). Banner amber con el texto
715  `¿Borrar {Entity} {short_uuid}?` + dos botones. Renderea como
716  sibling del row sidebar+main en `flex_col` raíz — no es overlay
717  flotante (GPUI no expone z-index trivialmente), pero la posición
718  fija al tope + color amber lo hacen imposible de ignorar.
719- **Limpieza pre-commit**: `pending_delete = None` se ejecuta antes
720  de `commit_delete`, así un fallo del commit no deja el banner
721  colgado además del toast de error.
722
72322 tests verdes — la lógica del store/log no cambió, sólo el state
724machine de UI. La confirmación es puramente UX/state, no testable
725sin GPUI cx, pero la compilación garantiza wireup correcto de las
726closures.
727
728Pendientes restantes:
729- **Snapshot/compaction** del log para repos grandes (replay full
730  cada startup escala mal).
731- **Edit delta-only** — sólo campos modificados, no todos.
732- **EntityRef validation post-submit** — validar UUID parseable
733  al submit en lugar de al execute del morphism.
734- **Atajo de teclado Esc para Cancelar** — requiere event
735  dispatcher de GPUI, fuera de scope inmediato.
736
737### feat(nakui-ui): validación estricta de params del morphism vía FieldKind del FieldSpec
738Cierra el último trade-off documentado: `infer_param_value` adivinaba
739el tipo de cada param por la shape del string (i64 → f64 → bool →
740string). Ahora cuando hay `FieldSpec` declarado, usamos
741`parse_field_value(spec.kind, raw)` — un Boolean field con value
742"abc" rebota con mensaje claro en la UI antes de llegar al morphism
743Rhai (donde el error sería opaco como "Function not found: * ((), ())").
744
745Cambios:
746- **Nuevo helper `resolve_param_value(field_name, raw, spec)`**:
747  - Si hay `FieldSpec`: validación de `required` (rebota empty con
748    "param 'X' es obligatorio y está vacío") + parseo estricto via
749    `parse_field_value(spec.kind, raw)`. Errores incluyen el `label`
750    del spec para que el toast sea interpretable.
751  - Si NO hay spec (param declarado en `Action::Morphism.params`
752    que no existe en `form.fields` — módulo mal-formado): fallback
753    a `infer_param_value` como red de seguridad.
754  - Empty + opcional → `Value::Null`.
755- **`commit_morphism` simplificado**: el loop de params ahora es
756  3 líneas (lookup spec + llamada a `resolve_param_value` +
757  inserción al map). La lógica vive en el helper standalone,
758  testable sin GPUI.
759
760Tests: 6 nuevos en `tests` mod, todos contra `resolve_param_value`:
761- `resolve_param_strict_number_parses_i64` — happy path.
762- `resolve_param_strict_boolean_rejects_non_boolean` — un Boolean
763  con "abc" rebota con mensaje que incluye el label.
764- `resolve_param_strict_number_rejects_garbage` — Number con "abc"
765  rebota.
766- `resolve_param_required_empty_rejected` — required vacío rebota
767  con "obligatorio".
768- `resolve_param_optional_empty_returns_null` — optional vacío
769  → null.
770- `resolve_param_no_spec_falls_back_to_infer` — el fallback
771  preserva el comportamiento anterior para back-compat.
772
77322 tests verdes en nakui-ui (+6). E2E del morphism real
774(`morphism_pipeline_executes_real_sales_vender`) sigue verde — la
775validación estricta no rompe el path correcto, sólo agrega rebotes
776tempranos a values mal-tipados.
777
778Beneficio operativo:
779- Mensaje de error en la UI ahora identifica el field problemático
780  por su label legible ("param 'Cantidad': 'abc' no es número")
781  en lugar del error opaco del morphism Rhai.
782- Errores se ven antes de tocar el log o el store — ningún cambio
783  parcial.
784- El módulo Nakui ya no tiene que defender contra inputs garbage
785  desde la UI: la metainterfaz se vuelve la primera línea de
786  validación tipada.
787
788Pendientes futuros (orden de prioridad):
789- **Confirmación de delete** — modal antes de borrar.
790- **Snapshot/compaction** del log para repos grandes.
791- **Edit delta-only** — sólo campos modificados, no todos.
792- **EntityRef validation post-submit**: hoy `parse_field_value`
793  para EntityRef devuelve string raw; el commit_morphism luego
794  valida como Uuid sólo cuando es input del morphism. Para
795  EntityRef como param, podríamos validar UUID al submit.
796
797### feat(nakui-ui): FieldKind::EntityRef — selector clickable de records existentes
798Cierra el principal trade-off documentado del commit anterior:
799"Inputs UUID a mano (no dropdown)". Los formularios pueden declarar
800un campo `entity_ref` que apunta a una entity y el runtime renderea
801una lista clickable de records existentes; click selecciona, el
802UUID queda guardado para el submit.
803
804Schema `nakui-ui-schema`:
805- **Nueva variante `FieldKind::EntityRef`** (serializa como
806  `"entity_ref"` en JSON).
807- **`FieldSpec.ref_entity: Option<String>`** nuevo. Indica qué
808  entity ofrecer en el selector. `validate()` chequea que cualquier
809  field con `kind=entity_ref` tenga `ref_entity` set.
810- Nuevo error tipado `SchemaError::EntityRefMissingTarget`.
811
812Runtime `nakui-ui`:
813- **`render_entity_ref_selector(field_name, target_entity, ...)`** —
814  helper que arma la lista debajo del input. Cada item:
815  - Etiqueta humana via `human_label_for_record` (heurística:
816    `name` → `label` → `title` → `sku` → `sku_id` → fallback al
817    UUID corto).
818  - Click handler vía `cx.listener` que llama
819    `input.set_text(uuid_completo)` — el TextInput interno queda
820    como source-of-truth, así que `commit_seed` y `commit_morphism`
821    leen el UUID seleccionado sin saber que vino de un selector.
822  - Highlight en accent color cuando el item es el actualmente
823    seleccionado (compara contra el contenido del TextInput).
824- **`parse_field_value(EntityRef, raw)`** devuelve string del raw
825  (la validación como Uuid ocurre downstream en `commit_morphism`).
826- Mensaje "(sin {entity}: creá uno antes para referenciar)" cuando
827  la lista está vacía — el user sabe qué hacer en lugar de quedarse
828  trabado.
829
830Demo actualizado: `examples/nakui-modules/sales_engine/module.json`:
831- `vender_form.fields.stock_id_input` y `caja_id_input` cambian de
832  `kind: "text"` a `kind: "entity_ref"` con `ref_entity: "Stock"`
833  y `"Caja"` respectivamente.
834- Ahora el flujo "Vender" es: (1) click en una Stock listada bajo
835  el input, (2) click en una Caja, (3) escribir venta_id/cantidad/
836  precio_unitario/timestamp, (4) submit. Sin copiar UUIDs.
837
838Tests:
839- 2 nuevos en schema: `validate_catches_entity_ref_without_target`
840  y `entity_ref_with_target_validates_clean`. 8 totales.
841- 4 nuevos en runtime: `parse_field_entity_ref_returns_string`,
842  `human_label_for_record_prefers_name_over_id`,
843  `human_label_falls_back_through_label_title_sku`,
844  `human_label_falls_back_to_id_when_no_known_keys`. 16 totales.
845- Integration de los 7 demos sigue verde — el demo `sales_engine`
846  ahora valida con EntityRef + ref_entity correctamente set.
847
84829 tests totales nakui-ui + schema, 100% verde. El demo
849`sales_engine` carga limpio con la nueva forma del schema.
850
851Pendientes futuros:
852- **Confirmación de delete** — modal antes de borrar.
853- **Snapshot/compaction** del log para repos grandes.
854- **Edit delta-only** (sólo campos modificados).
855- **Validación de tipos en params del morphism**: `FieldKind`
856  declarado en el FieldSpec se podría usar para forzar parseo
857  estricto en `commit_morphism` en lugar de la heurística
858  `infer_param_value`.
859
860### feat(nakui-ui): Action::Morphism wired al pipeline real (compute → log → apply)
861Cierra el último gran TODO de la metainterfaz Nakui: las acciones
862`Action::Morphism` ya no son un toast informativo; despachan al
863`Executor` cargado del manifest nakui-core (`nsmc.json` + schemas
864KCL + scripts Rhai), pasando por el pipeline completo de Nakui:
865compute (con dry-run + KCL post-checks) → log append → store apply.
866
867Schema `nakui-ui-schema` extendido:
868- **`Module.nakui_module_dir: Option<String>`** nuevo. Path
869  (relativo al directorio del `module.json` o absoluto) a un módulo
870  nakui-core. Sin esto, las Action::Morphism del módulo quedan
871  no-op con toast informativo. Las Action::SeedEntity siguen
872  funcionando sin manifest (alta administrativa).
873- **`Action::Morphism`** ganó dos campos opcionales:
874  - `inputs: BTreeMap<String, String>` — mapeo `role → field_name`.
875    Por cada input declarado en el `MorphismSpec.inputs`, indica
876    qué field del form contiene el UUID del record. El runtime
877    parsea como `Uuid` y lo pasa al `execute_and_log`.
878  - `params: Vec<String>` — lista de fields cuyos values van al
879    `params` JSON. Si vacío, todos los fields no-input van a params.
880
881Runtime `nakui-ui`:
882- **`MetaUi.executors: BTreeMap<String, Arc<Executor>>`** nuevo.
883  Carga `Executor::load_module(nakui_module_dir)` en `MetaUi::new`
884  por cada módulo UI que declare la entry. Errores de carga van al
885  banner; el módulo sigue cargado para SeedEntity, sólo Morphism
886  queda no-op.
887- **`commit_morphism(mod_idx, name, inputs_map, params_fields)`** nuevo.
888  Resuelve inputs (parsea cada field como Uuid), arma params (Value
889  object con tipos inferidos via `infer_param_value` — int/float/
890  bool/string), llama `execute_and_log_with_recovery`. Toast con
891  cantidad de ops aplicadas o el error tipado.
892- **`infer_param_value`** nuevo helper: heurística simple para
893  pasar values del form al morphism con tipo inferido (i64 → f64 →
894  bool → string).
895
896Tests: 2 nuevos:
897- `infer_param_value_int_then_float_then_bool_then_string` —
898  cobertura de la heurística.
899- **E2E `morphism_pipeline_executes_real_sales_vender`** —
900  carga el módulo real `crates/modules/nakui/modules/sales`,
901  arma store + log, ejecuta el morphism `vender` con inputs
902  Stock+Caja y params (cantidad=5, precio_unitario=200,
903  venta_id, timestamp). Asserta:
904  - el morphism produce ops (no vacío).
905  - stock.cantidad bajó 100 → 95.
906  - caja.saldo subió 1_000_000 → 1_001_000.
907
90812 tests verdes en nakui-ui (+1 vs commit anterior). Schema
909extension no rompió nada (6 unit + 5 integration siguen verdes).
910
911Demo nuevo: **`examples/nakui-modules/sales_engine/module.json`**
912- Apunta a `crates/modules/nakui/modules/sales` vía `nakui_module_dir`.
913- 6 vistas: list + form para cada Stock, Caja, Venta + form
914  "Vender" con `Action::Morphism { name: "vender", inputs: {stock,
915  caja}, params: [venta_id, cantidad, precio_unitario, timestamp] }`.
916- El user crea Stocks + Cajas con seed_entity, copia los UUIDs
917  cortos a los inputs de "Vender", y ejecuta el morphism real:
918  stock baja, caja sube, Venta se persiste, todo loggeado.
919- Validaciones KCL fallan limpio (toast con error) si el morphism
920  rebota — p. ej. cantidad > stock disponible.
921
922Activación full:
923```sh
924NAKUI_EVENT_LOG=~/.nakui/state.jsonl \
925NAKUI_MODULES_DIR=examples/nakui-modules \
926cargo run -p nakui-ui
927# Sidebar gana "Ventas (con morphism)" — los 6 menús aparecen y
928# el form "Vender" dispara el pipeline nakui-core completo.
929```
930
931Trade-offs documentados:
932- **Inputs UUID a mano**: el form pide que el user copie el UUID de
933  un Stock/Caja existente. Para UX seria habría que agregar
934  `FieldKind::EntityRef { entity }` que renderiza un dropdown — no
935  hecho por scope, queda como nice-to-have.
936- **Inferencia de tipo en params**: `infer_param_value` adivina
937  por shape del string. Para casos sutiles (ej. "true" como string
938  literal vs bool), el módulo nakui-core puede explicitar tipos
939  via `kind` en el FieldSpec — el form lo respeta para validación
940  pre-submit; la inferencia final sigue siendo heurística.
941
942### feat(nakui-ui): edit + delete de records (ciclo CRUD completo)
943Cierra "no hay UI para editar/borrar records existentes" del commit
944anterior. Cada fila de la lista gana dos botones (✎ edit, ✕ delete);
945el form view se reusa para alta y para edit; el delete es inline.
946Las mutaciones pasan por `LogEntry::Morphism` con sus ops, así el
947replay restaura el estado correcto.
948
949Cambios:
950
951- **`MetaUi.editing: Option<(String, Uuid)>`** nuevo. Set al click
952  en ✎; cleared al cambiar de view o tras submit exitoso.
953- **`open_edit(mod_idx, entity, id, cx)`**: setea `editing`, busca la
954  primera Form view del módulo cuya `entity` matchee, navega ahí. Si
955  el módulo no tiene Form para esa entity → toast con error
956  ("no hay form view para entity X").
957- **`select_view`** extendido: cuando carga un Form, si `editing`
958  matchea esa entity y el record existe en el store, pre-llena cada
959  input con el valor del record (vía nuevo helper
960  `value_to_input_text` — inverso de `parse_field_value`).
961- **`commit_seed`** ramifica:
962  - **Edit path** (cuando `editing.is_some()` y entity matchea):
963    emite `LogEntry::Morphism { name: "ui.edit_record", ops:
964    [Set { path, value } for each field], params: { entity, id,
965    fields } }`. Aplica al store via `apply(&ops)`.
966  - **Seed path** (alta nueva): comportamiento previo.
967- **`commit_delete(entity, id)`**: emite `LogEntry::Morphism {
968  name: "ui.delete_record", ops: [Delete { entity, id }] }` + apply.
969- **Render del form**: título cambia a "Editar customer abc12345"
970  cuando `editing` matchea; submit label cambia a "Guardar cambios
971  en customer".
972- **Render de la lista**: dos columnas nuevas — "id" y "acciones".
973  Cada fila tiene ✎ (accent color, click → open_edit) y ✕ (rojo,
974  click → commit_delete). Hover states.
975
976Ramificación visible en el event log:
977```
978{"kind":"seed","seq":0,"entity":"customer","id":"abc...","data":{"name":"Acme"}}
979{"kind":"morphism","seq":1,"morphism":"ui.edit_record","ops":[
980  {"op":"set","path":{"entity":"customer","id":"abc...","field":"name"},
981   "value":"Acme S.A."}
982]}
983{"kind":"morphism","seq":2,"morphism":"ui.delete_record","ops":[
984  {"op":"delete","entity":"customer","id":"abc..."}
985]}
986```
987Coherente con el modelo de Nakui — todo cambio post-seed pasa por
988ops dentro de Morphism. `nakui-explorer` muestra estos morphisms
989con sus ops claros en su timeline.
990
991Trade-offs documentados:
992- **`schema_hash: None`** sigue para los morphism de la UI (legacy/
993  pre-versioning path) hasta que `Action::Morphism` cargue Manifest
994  schemas.
995- **Delete sin confirmación**: 1 click, sin modal. Para MVP es OK
996  (los records son recuperables vía replay parcial), pero un futuro
997  iter agregaría confirmación.
998- **Edit sobreescribe TODOS los campos del form**, no sólo los
999  cambiados — emite N ops Set, una por field. Adecuado para forms
1000  chicos; para forms con muchos campos optimizar a delta-only.
1001
1002Tests: 3 nuevos (10 totales en nakui-ui):
1003- `value_to_input_text_inverse_of_parse` y
1004  `value_to_input_then_parse_round_trip` — la propiedad fundamental
1005  del pre-llenado: text → parse devuelve el Value original.
1006- `event_log_replay_handles_full_crud_cycle` — E2E del log: escribe
1007  Seed + Morphism(Set ops) + Morphism(Delete op), replay desde cero,
1008  verifica que el store termina vacío (delete fue el último). Verifica
1009  además que un replay parcial (sin el delete) deja los valores
1010  editados.
1011
1012Activación:
1013```sh
1014NAKUI_EVENT_LOG=~/.nakui/state.jsonl \
1015NAKUI_MODULES_DIR=examples/nakui-modules \
1016cargo run -p nakui-ui
1017# Crear un customer, click ✎ en su fila, modificar campos,
1018# "Guardar cambios". Click ✕ en otra fila para borrar.
1019# Cerrar y reabrir: el state persiste con todos los cambios.
1020```
1021
1022### feat(nakui-ui): persistencia con event log + replay al startup
1023Cierra "sin persistencia entre runs" del commit anterior. Cada
1024`SeedEntity` se appendea al `nakui_core::event_log::EventLog` con
1025WAL semantics (log antes que store) y al re-abrir el binario el
1026replay reconstruye el `MemoryStore` desde cero. Cerrar y volver a
1027abrir ya no borra el data.
1028
1029Cambios:
1030- **`MetaUi.event_log: Option<Arc<Mutex<EventLog>>>`** nuevo.
1031  Compartido bajo `Mutex` para que el commit_seed pueda mutar.
1032- **Apertura + replay al startup** (`MetaUi::new`): path por env
1033  `NAKUI_EVENT_LOG`, default `./nakui-ui-state.jsonl`.
1034  `EventLog::open` + `replay_into` reconstruyen el store.
1035  Toast informativo: "log nuevo" o "log X cargado: N evento(s)
1036  replayed".
1037- **WAL en `commit_seed`**: si `event_log.is_some()`, primero
1038  `log.append(LogEntry::Seed { ..., schema_hash: None })`, después
1039  `store.seed`. Si el append falla, cancela toda la operación
1040  (el user reintenta sin haber dejado state inconsistente).
1041- **`schema_hash: None`**: documentado como path "legacy /
1042  pre-versioning" para seeds que no pasan por un Manifest+Executor.
1043  Es el path correcto para alta administrativa vía la metainterfaz
1044  hasta que `Action::Morphism` wireé el Manifest loader.
1045- **Degradación grácil**: si abrir log falla (permisos, disco),
1046  toast con error pero el runtime sigue en modo in-memory.
1047
1048Tests: 1 nuevo E2E `event_log_replay_restores_memory_store` que
1049escribe 2 seeds via `EventLog::append`, re-abre y `replay_into` un
1050store fresh, verifica que ambos records están con sus values
1051correctos. Reproduce el flujo del startup de `MetaUi::new` sin
1052necesitar GPUI. 7 tests verdes en nakui-ui.
1053
1054Activación con persistencia explícita:
1055```sh
1056NAKUI_EVENT_LOG=~/.nakui/state.jsonl \\
1057NAKUI_MODULES_DIR=examples/nakui-modules \\
1058cargo run -p nakui-ui
1059# Crear varios records vía el form, cerrar el binario, abrir de
1060# nuevo: los records están.
1061```
1062
1063Limitaciones que **siguen** (próximos iters):
1064- **`Action::Morphism`** sigue como TODO: requiere cargar el
1065  `Manifest` de nakui-core junto al `Module` UI para conocer los
1066  inputs/params declarados y poder llamar `execute_and_log`.
1067- **No hay snapshot/compaction**: el log crece append-only para
1068  siempre. Para repos grandes habría que integrar `Snapshot` de
1069  nakui_core (existe, no se usa todavía).
1070- **No hay UI para borrar/editar** records existentes — sólo alta
1071  vía form. Edit + delete en futuras iteraciones.
1072- **Widget input simple** (sin selection/IME/clipboard) — heredado
1073  de la limitación documentada de `yahweh-widget-text-input`.
1074
1075### feat(nakui-ui): inputs reales con yahweh-widget-text-input + click handlers funcionales
1076Cierra dos limitaciones documentadas en el commit anterior de la
1077metainterfaz: los formularios ahora aceptan teclado real, y los
1078clicks en menús + botones mutan estado correctamente.
1079
1080Cambios:
1081- **Inputs vivos**: cada `FieldSpec` del Form view materializa un
1082  `Entity<TextInput>` (de `yahweh-widget-text-input`) al entrar a la
1083  vista. Los entities se reemplazan al cambiar de view (drop limpio).
1084  El widget soporta: escribir caracteres, Backspace, Enter (Confirmed
1085  event — no usado todavía; el submit va por botón), Escape
1086  (Cancelled). El cursor se renderea como `|` al final.
1087- **Click handlers wired vía `cx.listener`**: menús del sidebar
1088  invocan `select_view`; botones de acción (header de list, submit
1089  de form) invocan `apply_action`. Los handlers tienen acceso real
1090  al `Context<MetaUi>` y mutan el modelo + emiten `cx.notify()`.
1091- **Submit lee texto de los inputs**: `commit_seed` reemplaza el
1092  buffer ad-hoc anterior por `input.read(cx).text()` por cada
1093  field. El value parseado va al `MemoryStore` con su tipo correcto
1094  (text/number/boolean/date).
1095- **Reset de inputs tras submit**: si la acción no tiene `next_view`,
1096  los inputs se vacían (`set_text("")`) para alta consecutiva sin
1097  re-tipear.
1098- **Hover states**: items del sidebar y botones cambian de bg al
1099  pasar el mouse, feedback visual consistente con el resto del
1100  ecosistema yahweh.
1101- **Theme global**: `Theme::install_default(cx)` al inicio (lo
1102  requiere el text_input para sus colores).
1103
1104Wire en Cargo:
1105- Deps nuevas: `yahweh-widget-text-input`, `yahweh-theme` (paths
1106  relativos al monorepo).
1107
1108Limitaciones que **siguen abiertas** (próximos iters):
1109- **`Action::Morphism`** sigue como TODO: requiere cargar el
1110  `Manifest` de nakui-core junto al `Module` UI para conocer los
1111  inputs/params declarados.
1112- **Sin persistencia entre runs**: `MemoryStore` en RAM. Wire con
1113  `EventLog` o `SurrealStore` queda para cuando exista el daemon
1114  Nakui.
1115- **Inputs simples**: el widget no soporta cursor positioning,
1116  selection, copy/paste, IME, multilínea. Para edits serios habrá
1117  que portar `gpui::examples::input` o adoptar `gpui-input` cuando
1118  exista upstream.
1119- **Enter no envía**: el `TextInputEvent::Confirmed` que emite el
1120  widget no está suscrito todavía; el submit va por click. Trivial
1121  de wirear si lo necesitamos.
1122
1123Tests: los 6 unit del runtime siguen verdes (parse_field_value para
1124los 5 kinds, lookup_field nested, render_value). El comportamiento
1125visual requiere correr el binario con `cargo run -p nakui-ui` y
1126probar a mano — GPUI no provee harness de UI testing en CI hoy.
1127
1128Activación full:
1129```sh
1130NAKUI_MODULES_DIR=examples/nakui-modules cargo run -p nakui-ui
1131# Click en un menú → carga vista. Click en "Nuevo" → form.
1132# Tipear en cada campo → ver el `|` al final. Click "Crear customer"
1133# → record aparece en la lista.
1134```
1135
1136### feat(nakui): metainterfaz declarativa + 6 módulos ERP estándar
1137Salto cualitativo: Nakui pasa de "library + demos + read-only viewer
1138del event log" a **plataforma ERP con UI dirigida por datos**. Cada
1139módulo de negocio se declara como un `module.json` (sin código Rust
1140nuevo) y el runtime GPUI lo carga dinámicamente: sidebar de menús,
1141listas con columnas configurables, formularios de alta.
1142
1143Tres entregables:
1144
1145**1) Crate nuevo `nakui-ui-schema`** (datos puros, ~250 LOC + 200
1146LOC tests):
1147- `Module { id, label, entities, menu, views }`.
1148- `View::List { entity, columns, actions, search_in }` o
1149  `View::Form { entity, fields, on_submit }`.
1150- `FieldSpec { name, label, kind, default, required, help }` con
1151  `FieldKind = Text|Multiline|Number|Boolean|Date`.
1152- `Action::OpenView | SeedEntity | Morphism` — el runtime las
1153  dispara desde botones / submits.
1154- `Module::from_path` parsea un JSON; `Module::validate` chequea que
1155  cada `MenuItem.view` exista en `views`.
1156- `load_modules_from_dir(dir)` busca `dir/<modulo>/module.json`,
1157  parsea, valida, detecta IDs duplicados, devuelve ordenado.
1158- 6 tests unit + 4 integration (los 6 demos cargan limpio, todos
1159  tienen list+form, kinds reconocidos, validate pasa).
1160
1161**2) Crate nuevo `nakui-ui`** (binario GPUI, ~700 LOC + 100 LOC tests):
1162- Carga módulos desde `NAKUI_MODULES_DIR` (default `./nakui-modules`).
1163- Sidebar con módulos + sus menús; click en menu cambia la vista activa.
1164- **List view**: tabla de instancias del entity con columnas
1165  weighted (header de columnas + filas + id corto).
1166- **Form view**: campos labeled + botón submit que dispara la action
1167  declarada (`SeedEntity` mete el record al `MemoryStore`
1168  in-process; `Morphism` queda como TODO hasta integrar el manifest
1169  loader nakui-core).
1170- `MemoryStore` compartido entre todas las vistas (Arc<Mutex>); el
1171  cambio en un módulo se refleja en otro inmediato.
1172- Toast + error banner para feedback.
1173- 6 tests unit (parse_field_value para los 5 kinds, lookup_field
1174  nested, render_value).
1175
1176**3) 6 módulos demo** en `examples/nakui-modules/` que cubren un
1177ERP estándar:
1178- **customers**: nombre, email, teléfono, activo, límite de
1179  crédito, notas.
1180- **products**: SKU, nombre, categoría, precio, stock, activo.
1181- **suppliers**: razón social, ID fiscal, contacto, email,
1182  teléfono, términos de pago.
1183- **inventory_movements**: fecha, tipo (in/out/adjustment), SKU
1184  producto, cantidad, costo unitario, motivo, doc. referencia.
1185- **sales_orders**: número, cliente, emisión, vencimiento,
1186  estado, subtotal, impuestos, total, notas.
1187- **invoices**: número, cliente, emisión, vencimiento, subtotal,
1188  impuestos, total, pagado, estado, moneda, orden referenciada.
1189
1190Cada módulo tiene su `list` (catálogo) + `form` (alta), con search
1191field y columns weighted. Los 6 cubren un setup de ERP de ventas
1192chico funcional para demo.
1193
1194Filosofía documentada:
1195- **UI como datos**: agregar un módulo = escribir un JSON, no
1196  recompilar el binario.
1197- **Persistencia universal**: el runtime conecta cada vista al
1198  `nakui_core::store::Store`; cambiar de MemoryStore a SurrealStore
1199  no toca los module.json.
1200- **Schema primero, semántica después**: `nakui-ui-schema` sólo
1201  define la forma; validación de referencias rotas (entity inexistente,
1202  morphism faltante) vive en el runtime.
1203
1204Activación:
1205```sh
1206NAKUI_MODULES_DIR=examples/nakui-modules cargo run -p nakui-ui
1207```
1208
1209Limitaciones conocidas (próximas iteraciones):
1210- **Inputs sin teclado**: GPUI no incluye text input; los forms
1211  muestran los `default` del schema y el submit usa esos. Próximo
1212  iter: integración con `yahweh-widget-text-input`.
1213- **Click handlers no wired**: GPUI necesita pasar `Entity<MetaUi>`
1214  a los handlers para mutar estado; refactor con `cx.listener` +
1215  weak refs queda para el próximo iter. Hoy la navegación es
1216  visual; el código de mutación sí funciona via API programática
1217  (los tests lo cubren).
1218- **Acción `Morphism`**: pendiente de cargar el `Manifest` de
1219  nakui-core junto con el `Module` UI para wirear `execute_and_log`.
1220- **Sin persistencia entre runs**: el `MemoryStore` se pierde al
1221  cerrar. Wire con `EventLog` o `SurrealStore` queda para cuando
1222  el daemon Nakui exista.
1223
1224Tests: 16 totales nuevos (10 schema + 6 runtime). 100% verde.
1225
1226Lo que esto desbloquea: cualquiera puede escribir un `module.json`
1227para su dominio (pacientes médicos, alumnos de escuela,
1228reservaciones de hotel) y aparece en la UI sin tocar Rust ni
1229recompilar. La forma de extender Nakui dejó de ser "agregar código
1230al ERP" y pasó a ser "escribir el contrato del módulo".
1231
1232### feat(nakui-explorer): nuevo binario GPUI — Nakui visible en la interfaz
1233Cierra "nakui no tiene UI propia" del audit. Nuevo binario standalone
1234`nakui-explorer` (paralelo a `nouser-explorer`) que renderea el
1235event log de un repo Nakui: timeline scrollable de seeds + morphisms
1236con sus parámetros, breakdown por entity type, polling cada 2s para
1237detectar nuevos eventos appended sin restart del explorer.
1238
1239Diseño:
1240- Lee directamente el archivo `.jsonl` del `nakui_core::event_log::EventLog`.
1241  Path por env `NAKUI_EVENT_LOG`, default `nakui.jsonl` en pwd.
1242- Sin discovery vía broker brahman porque nakui hoy es CLI/library/
1243  demos, no daemon. Cuando se daemonice, sustituir el lector de
1244  archivo por un sidecar consumer (mismo patrón que nouser-explorer
1245  actualmente usa).
1246
1247UI:
1248- **Header**: path del log, count total + breakdown seeds/morphisms,
1249  tiempo del último reload en ms.
1250- **Breakdown line**: top 5 buckets por frecuencia (entities + nombres
1251  de morphisms con prefijo `→`).
1252- **Timeline**: tarjetas color-coded por kind (azul=seed,
1253  verde=morphism). Cada tarjeta muestra `#seq`, kind, entity/morphism
1254  name, id corto (8 hex), preview del data/params (80 chars), schema
1255  hash corto (8 hex) o `(legacy)` si pre-versioning. Mostradas
1256  más-recientes-primero, hasta 200 visibles (suficiente para
1257  navegación; sin scroll virtualizado por ahora).
1258- **Error banner**: si la lectura falla (archivo inexistente o
1259  corrupto), banner rojo con el motivo. El explorer NO crashea —
1260  sigue intentando cada 2s.
1261
1262Wire en workspace:
1263- Nuevo `crates/apps/nakui-explorer/` agregado a `[workspace] members`.
1264- Deps mínimas: `nakui-core` (para EventLog + LogEntry), `gpui`,
1265  `serde_json`, `uuid` (con feature serde para parsear los IDs).
1266- Sin deps de brahman por ahora (Nakui standalone).
1267
1268Tests: 7 unitarios en `tests` mod del bin:
1269- `load_log_returns_all_entries_in_order` — cargar un .jsonl
1270  generado a mano, asserta que devuelve 5 entries con seqs 0..4
1271  contiguous.
1272- `breakdown_counts_seeds_morphisms_and_buckets` — verifica el
1273  conteo (3 seeds + 2 morphisms) y los buckets esperados.
1274- `load_missing_file_yields_empty_not_error` — archivo inexistente
1275  devuelve `[]` sin error (delegado al contrato de `EventLog::open`).
1276- `preview_value_truncates_long_strings` y `_keeps_short_strings_intact`.
1277- `short_uuid_takes_first_8_chars` y `short_hash_takes_first_4_bytes_hex`.
1278
1279Activación:
1280```sh
1281NAKUI_EVENT_LOG=/tmp/nakui_inv_xxx.jsonl cargo run -p nakui-explorer
1282```
1283
1284Estado del CHANGELOG global tras este commit: cero pendientes
1285fundamentados activos. Lo único que queda es `minga-vfs` (FUSE,
1286explícitamente diferido por el usuario) y mejoras nice-to-have
1287(cobertura adicional per-lenguaje, daemon-ización de nakui para
1288sidecar discovery).
1289
1290### chore(nakui): alinear `nakui-core` con `[workspace.package]` y deps compartidas
1291Cleanup de drift de convenciones: `nakui-core` era el único crate del
1292monorepo que mantenía `version = "0.1.0"` / `edition = "2021"` /
1293`thiserror = "1"` hardcoded, mientras el resto heredaba del workspace
1294y usaba `thiserror = "2"`. Eso significaba que un bump global de versión
1295o de edition se olvidaba sistemáticamente de nakui.
1296
1297Cambios:
1298- `[package]`: `version`, `edition`, `rust-version`, `license`, `authors`,
1299  `publish` → todos `*.workspace = true`. Agregado `description` (cumple
1300  convención del resto de crates).
1301- Deps compartidas migradas a `{ workspace = true }`: serde, serde_json,
1302  thiserror (v1→v2), tokio, ulid, sha2.
1303- `uuid` migrado a `{ workspace = true, features = ["serde"] }` — la
1304  feature `serde` no está en el workspace dep porque nakui es el único
1305  user; queda local opt-in en lugar de inflar el dep común.
1306- Deps específicas de nakui (sin compartición posible): rhai, petgraph,
1307  surrealdb permanecen inline con versión local.
1308
1309Verificación: `cargo build -p nakui-core` verde tras el bump de
1310`thiserror` v1→v2 — el `#[derive(Error)]` de los 14+ enums de error
1311en nakui no requirió ajustes (la API de derive es backwards-compatible
1312para los patrones simples). `cargo test -p nakui-core --lib`: 27/27
1313verdes, sin regresión.
1314