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