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