1# Changelog — nahual
2
3Motor GPUI: libs + widgets. Renombrado de `yahweh` el 2026-05-19.
4
5### feat(meta-*): relaciones legibles + formato (Fase 2 del ERP nakui)
6
7- **`Column.ref_entity`** — una columna de lista con esto resuelve su
8  valor (un UUID) al label legible del record referido, en vez de
9  mostrar el UUID crudo. `meta-form` carga el record vía el backend y
10  usa `human_label_for_record`.
11- **`Column.format`** (`ValueFormat::{Plain, Number, Currency}`) —
12  formato de la celda: separador de miles, símbolo de moneda
13  (`12000` → `$12,000`). Helper `format_value` en `meta-runtime`.
14- El campo `entity_ref` en formularios ahora muestra el **label del
15  record elegido** (read-only) + el selector, no el UUID crudo.
16- `human_label_for_record` reconoce campos de nombre en español
17  (`nombre`, `titulo`), no sólo inglés.
18
19Tests nuevos en `meta-runtime` (`format_value`, labels ES) y
20`meta-schema`. Ver el changelog de `nakui` para el plan maestro.
21
22### feat(meta-*): FieldKind Select y AutoId (Fase 1 del ERP nakui)
23
24La metainterfaz declarativa gana dos tipos de campo:
25
26- **`Select`** — valor de un conjunto cerrado. `FieldSpec.options`
27  (valor + etiqueta opcional); `Module::validate` exige `options` no
28  vacío. `meta-form` lo renderiza como chips clickables (el chip
29  elegido resaltado), no texto libre.
30- **`AutoId`** — UUID v4 autogenerado. `meta-form` lo rellena al abrir
31  el formulario y lo muestra read-only; el usuario no teclea ids de
32  idempotencia. En modo edición conserva el id del record.
33
34`parse_field_value` trata ambos como string passthrough. Tests nuevos
35en `meta-schema` (validación de Select) y `meta-runtime` (parseo).
36
37### feat(nahual-widget-text-input): modo enmascarado para contraseñas
38
39`TextInput::with_mask()` dibuja el contenido como puntos (`•`, uno por
40carácter Unicode) en vez del texto real; `text()` sigue devolviendo el
41contenido crudo. Lo usa el campo de contraseña de `mirada-greeter`.
42Lógica de enmascarado en la función pura `display_text`, con tests.
43
44### feat(nahual-theme): exportación del tema a GTK (módulo toolkit)
45
46Módulo nuevo `nahual-theme/src/toolkit.rs`: traduce el `Theme` activo a
47`~/.config/gtk-3.0/gtk.css` y `gtk-4.0/gtk.css` con overrides
48`@define-color`. Las apps GTK adoptan el acento exacto del tema + un
49neutro claro/oscuro coherente. Los fondos en gradiente de nahual no se
50pueden reproducir en ventanas GTK sólidas, así que el neutro se sintetiza
51con un ramp de luminancia tintado por el matiz del borde del tema.
52
53- `gtk4_css` / `gtk3_css` — generadores puros (nombres de color de
54  libadwaita y de Adwaita 3 respectivamente).
55- `export_toolkit_configs` + `export_toolkit_configs_to(base)` —
56  escritura; el segundo con directorio base explícito para tests.
57- **Guarda de no-pisar**: si un `gtk.css` ya existe sin la marca de
58  nahual, es del usuario y se respeta (`ExportReport.skipped`).
59- `Theme::set` y `Theme::install_default` exportan best-effort: cambiar
60  de tema en cualquier app GPUI actualiza GTK al instante.
61- `config_path` refactorizado sobre un nuevo `config_home()`.
62- Ejemplo `dump-toolkit-css` para inspeccionar el CSS generado.
63- 8 tests nuevos en `toolkit`.
64
65### feat(yahweh-launcher): F3 — extracción del shell standard de explorers
66Iter 19. Patrón con 4 consumers idénticos (nakui-explorer,
67nouser-explorer, minga-explorer, brahman-broker-explorer) declaraban
68~20 líneas de boot:
69`Application::new + Theme::install_default + cx.open_window
70+ WindowOptions{ window_bounds, titlebar } + cx.activate(true)`.
71Todo idéntico salvo título, tamaño, y root entity factory.
72
73Crate nuevo `crates/modules/ui_engine/libs/launcher/`
74(`yahweh-launcher`):
75- **Deps**: `gpui`, `yahweh-theme`. Sin más.
76- **`pub fn launch_app(title, size, root_factory)`**: 1-line boot.
77- **`pub fn launch_app_with(config, root_factory)`**: variante con
78  `AppLaunchConfig` armado afuera, para casos donde título/tamaño se
79  computan condicionalmente (env var, etc).
80- **`AppLaunchConfig::new(title, size)`**: builder normalizador.
81- 2 tests `#[test]` cubren la normalización de config (no se testea
82  `launch_app` per se porque bloquea el thread main hasta que la
83  ventana se cierra).
84
85Migración 4 consumers:
86- `main()` pasa de 20 líneas a 1: `launch_app("Title", (W, H), Explorer::new)`.
87- Imports de gpui se podan: ya no necesitan `App, Application,
88  Bounds, WindowBounds, WindowOptions` ni `SharedString` ni `prelude::*`.
89- Cada consumer agrega dep `yahweh-launcher` (path local).
90
91Naming: el slot natural era `yahweh-shell`, pero ya existe un crate
92`yahweh-shell` en `crates/apps/` (bootstrap heavyweight con file
93explorer + DB explorer + viewers). El helper es liviano y específico
94al patrón de launch, así que `yahweh-launcher` evita confusión.
95
96Total ahorro: ~75 líneas hardcoded de boilerplate UI a 4 líneas en
97total. Cambios de boot (window opts, theme, etc) ahora viven en un
98solo lugar.
99
100Tests stack: 2 nuevos en launcher; suites de los 4 consumers
101intactas. Todo verde.
102
103### feat(yahweh-widget-app-header): promover el header standard de explorers
104Iter 16. Patrón con 4 consumers idénticos: `nakui-explorer`,
105`nouser-explorer`, `minga-explorer`, `brahman-broker-explorer`
106todos declaraban un header `flex_row + flex_grow(label) +
107theme_switcher + bg(panel) + border-bottom + text_size(14) +
108padding(16/12)`. Ahora es 1 línea.
109
110Crate nuevo `crates/modules/ui_engine/widgets/app-header/`
111(`yahweh-widget-app-header`):
112- **Deps**: `gpui`, `yahweh-theme`, `yahweh-widget-theme-switcher`.
113  El switcher se incluye automáticamente.
114- **`pub fn app_header(cx: &mut App, label: impl Into<SharedString>)
115  -> impl IntoElement`**: caso simple con texto plano.
116- **`pub fn app_header_with(cx, label_child: impl IntoElement)`**:
117  variante para cuando el lado izquierdo no es texto plano (icon
118  + text, múltiples spans, etc.).
119- 3 tests `#[gpui::test]`: smoke con string label, con custom
120  child IntoElement, type-check de label con literal/owned/format!.
121
122Migración de los 4 consumers:
123- Cada uno reemplaza un bloque `let header = div().flex().flex_row()...
124  .child(theme_switcher(cx))` (~13 líneas) por
125  `let header = app_header(cx, header_text)` (~1 línea).
126- Cada uno borra dep `yahweh-widget-theme-switcher` (ya no la
127  necesita directo — el `app_header` la incluye internamente).
128- Cada uno reemplaza `use yahweh_widget_theme_switcher::theme_switcher`
129  por `use yahweh_widget_app_header::app_header`.
130
131Total ahorro: ~50 líneas de código UI hardcoded en consumers.
132Cambios visuales en el header (padding, border, text_size) ahora
133viven en un solo lugar.
134
135Tests stack: 3 nuevos en app-header; suites de los 4 consumers
136intactas. Todo verde.
137
138Decisión: el sidebar header del `MetaApp` (que también incluye
139theme_switcher) NO se migra — es un header de sidebar, no de app
140top, y tiene styling distinto (px(12/10/13), sin bg/border-bottom
141porque ya está dentro del panel). Diferente patrón → diferente
142widget si emerge segundo consumer.
143
144### feat(yahweh-widget-stat-card): promover el patrón stat card como widget
145Iter 15. El patrón "tarjeta de dashboard con border-l accent +
146label + valor grande + descripción + listing opcional" tenía 2
147consumers (`minga-explorer` y `brahman-broker-explorer`); ahora vale
148extraer al stack yahweh para reusabilidad y mantenimiento single-place.
149
150Crate nuevo `crates/modules/ui_engine/widgets/stat-card/`
151(`yahweh-widget-stat-card`):
152- **Deps**: `gpui` + `yahweh-widget-card` (compone `card_themed`).
153  Sin theme directo — el caller pasa `text` y `text_dim` ya
154  resueltos del theme.
155- **`pub fn stat_card(cx, label, value, description, accent,
156  text, text_dim, recent_items)`**:
157  - `cx: &App` (acepta `&Context<T>` por deref auto-coerce).
158  - `value: impl Into<SharedString>` — sirve para counts (`"3"`),
159    status text (`"UP"`), o cualquier label corto.
160  - `recent_items: &[String]` — si no vacío, agrega sub-header
161    `"recent (N):"` + una linea por item.
162- 3 tests `#[gpui::test]` con TestAppContext: smoke con/sin
163  recent_items, type-check de `value` con literal/format/owned.
164- Dev-deps: gpui con `test-support` + yahweh-theme para construir
165  el cx con un theme global.
166
167Cambios consumer:
168- **`minga-explorer`**: sustituye su `fn stat_card` local
169  (~60 líneas) por `use yahweh_widget_stat_card::stat_card`.
170  Borra dep `yahweh-widget-card` (ya no se usa directo). Adapta
171  los 3 callsites para pasar `value.to_string()` (el widget
172  acepta `Into<SharedString>`).
173- **`brahman-broker-explorer`**: refactoriza su `fn state_card`
174  para que sea un wrap de `stat_card` con la traducción
175  `ProbeState → (accent, value, description)`. La función queda
176  como helper local porque la mapping del enum es app-specific,
177  pero el rendering pasa por el widget compartido. Borra dep
178  `yahweh-widget-card`.
179
180Tests stack: nuevos 3 del widget. Suites de los 2 consumers
181intactas (4 minga-explorer, 2 broker-explorer). Stack total ~120
182verdes (varía por compilation cache).
183
184Beneficio operativo:
185- Cualquier app nueva que necesite cards de dashboard usa
186  `stat_card(...)` directo; no re-implementa el pattern.
187- Cambios visuales (text sizes, padding, sub-header format)
188  ahora viven en un solo lugar.
189- `value: impl Into<SharedString>` es más expressive que el
190  `usize` rígido del original local.
191
192Pequeña simplificación documentada: el sub-header del listing
193pasa de `"recent (N de TOTAL):"` a `"recent (N):"`. El "TOTAL"
194ya no se calcula porque el widget no lo conoce — el caller que
195quiera mostrarlo lo formatea en el label/value (ej. label `"Nodos
196AST (5 de 247)"`). Acceptable trade-off por la reusabilidad
197genérica.
198
199### feat(yahweh-theme): persistencia de la preferencia de theme entre runs
200Iter 13. El theme switcher ya cambiaba el chrome en runtime, pero
201al cerrar y reabrir la app el theme volvía a Nebula default. Ahora
202el name del theme se persiste en `$XDG_CONFIG_HOME/yahweh/theme`
203(default `~/.config/yahweh/theme`) y se restaura al boot.
204
205Cambios en `yahweh-theme`:
206- **`pub fn config_path() -> Option<PathBuf>`**: resuelve el path
207  XDG. Devuelve `None` si ni `XDG_CONFIG_HOME` ni `HOME` están
208  set (sandbox/CI).
209- **`pub fn load_persisted() -> Option<Theme>`**: lee el archivo,
210  trim, busca el theme por name vía `Theme::by_name`. `None` si
211  el file no existe, lectura falla, o el name no matchea ningún
212  preset (e.g. preset renombrado entre versiones).
213- **`pub fn persist(theme: &Theme) -> io::Result<()>`**: escribe
214  el name al config file. Crea el dir parent si no existe.
215- **`pub fn load_from_path` y `pub fn persist_to_path`**: variantes
216  con path explícito — útiles para tests con tempfile y para apps
217  que quieren un path custom (multi-user, staging, etc.).
218- **`Theme::install_default(cx)` cambia**: antes hardcoded
219  `nebula()`. Ahora intenta `load_persisted()`, fallback a Nebula.
220- **`Theme::set(cx, theme)` cambia**: antes sólo `cx.set_global`.
221  Ahora también `persist(&theme)` antes (best-effort: ignora io
222  errors). El `theme_switcher` widget ya consume `Theme::set`, así
223  que sin cambios en su código el switching ahora persiste.
224
2255 tests nuevos (`persistence_tests`):
226- `persist_then_load_round_trip` — escribir + leer Aurora.
227- `load_from_missing_file_returns_none` — no rebota.
228- `load_from_unknown_name_returns_none` — name desconocido →
229  `None` (degrada a default cuando se usa).
230- `persist_creates_parent_dir_if_missing` — crea
231  `~/.config/yahweh/` si no existe.
232- `config_path_uses_xdg_config_home_when_set` — respeta el env.
233
234Tests stack: ~5 nuevos en yahweh-theme. Todos los downstream
235(nakui-ui, *-explorer) compilan sin tocar nada — la API pública
236de `Theme::install_default` y `Theme::set` no cambió shape.
237Smoke run del binario verificado: bootstrap OK, panic esperado
238sin display.
239
240Beneficio operativo:
241- Usuario abre `nakui-ui`, cicla a Aurora con el switcher, cierra
242  app. Próxima apertura: Aurora cargado del disco. Todas las
243  apps yahweh-themed (4 del repo) comparten la misma preferencia.
244- Failure mode benigno: sin home dir o sin permisos de write,
245  el theme cambia in-memory pero no se persiste — el switcher
246  sigue usable, sólo no sobrevive al close.
247- Path canónico documentado: usuarios que quieran preset el
248  theme antes de abrir la app pueden hacer
249  `echo Aurora > ~/.config/yahweh/theme`.
250
251### feat(yahweh): caret blinking + slots ornament en theme + MetaApp full themed
252Iters 8-9 combinadas. Tres mejoras pequeñas que cierran la
253integración del theme:
254
255**1. Caret blinking en text-input** (`yahweh-widget-text-input`):
256- Nuevo field `caret_visible: bool` que toggea cada 500ms.
257- Nuevo field `_blink_task: Task<()>` mantiene el loop de blink
258  vivo y lo cancela al drop del widget.
259- En `new()`, `cx.spawn(...)` arranca el loop: `timer.timer(500ms)`
260  + `this.update(...)` que toggea + `cx.notify()`. Si el update
261  falla (entity drop), break.
262- En `render()`, caret `|` se dibuja sólo si
263  `is_focused && self.caret_visible`. Familiar feel del SO.
264
265**2. Slots ornament en yahweh-theme** (5 nuevos):
266- `bg_input() -> Hsla` — bg sutil para fields editables.
267- `bg_button() -> Hsla` + `bg_button_hover() -> Hsla` — controls
268  clickable secundarios.
269- `accent_destructive() -> Hsla` — rojo para acciones peligrosas.
270- `bg_destructive_hover() -> Hsla` — bg de hover sobre destructive.
271- Implementados como **methods** del `Theme` (no fields del
272  struct), derivados via `ornament_slots(self.is_dark)`. Esto
273  evita modificar los 6 presets — el slot vive donde uno lo
274  invoca.
275
276**3. MetaApp ornament cleanup** (`yahweh-widget-meta-form`):
277- 11 colores hardcoded `gpui::rgb(0x...)` migrados a slots del
278  theme:
279  - Sidebar menu items (selected/hover) → `bg_row_active` /
280    `bg_row_hover`.
281  - List row separator + button bgs → `bg_row_active` /
282    `bg_button()` / `bg_button_hover()`.
283  - Icon ✕ delete + hover → `accent_destructive()` /
284    `bg_destructive_hover()`.
285  - EntityRef selector hover/selected → `bg_row_active` /
286    `bg_row_hover`.
287  - EntityRef selector border → `theme.border` (slot existente).
288  - Form fallback input bg + submit button → `bg_input()` /
289    `bg_button()` / `bg_button_hover()`.
290  - Confirm modal hint subtitle + hovers de Cancel/Confirm →
291    `theme.fg_muted` / `bg_button_hover()` / `bg_destructive_hover()`.
292- Pattern: `let X = theme.slot()` antes de las closures + `move |d|
293  d.bg(X)` en hover/when para que el cierre tome ownership.
294
295Antes de este commit MetaApp tenía la **paleta principal** themed
296(iter 5) pero el ornament secundario (hovers, separators, botones
297inline) seguía hardcoded. Ahora el theme switcher cambia
298**absolutamente todo** el chrome del MetaApp en runtime.
299
300Tests: 117 verdes (sin cambios numéricos, pero downstream sigue
301compilando). Smoke run de nakui-ui: bootstrap completo OK.
302
303Limitación restante: `nouser-explorer` todavía no migra al stack
304yahweh themed — patrón idéntico a `nakui-explorer` aplicado pero
305más nuevo. Próxima iter.
306
307### feat(yahweh-widget-text-input): focus-aware border + caret sólo on focus
308Iter 7 (mini-iter — el text-input ya estaba themed, faltaba sólo
309el polish de focus visibility). Antes el border era siempre
310`accent_strong` y el caret `|` siempre estaba presente — imposible
311distinguir cuál input está activo en un form con varios fields.
312
313Cambios en `yahweh-widget-text-input`:
314- **Border focus-aware**: cuando el input está focused, border =
315  `theme.accent_strong` (color vivo). Cuando no, border =
316  `theme.border` (color tenue del chrome). Se obtiene via
317  `self.focus_handle.is_focused(window)`.
318- **Caret `|` sólo on focus**: cuando el input no tiene focus, se
319  muestra el texto plano sin caret. Reduce el "ruido visual" en
320  forms con muchos fields.
321- `render` ahora usa el `Window` arg (antes `_w`) para chequear
322  focus.
323
324Sin cambios en API pública — todo es interno al `render`. El
325binario no requiere migración.
326
327Tests: sin cambios (los tests del crate son struct constructors,
328no rendering). Tests downstream del widget (`yahweh-widget-meta-form`,
329`nakui-ui`) siguen verdes — el cambio es backward compatible.
330
331Beneficio operativo:
332- Forms con 5+ fields ahora son navegables: el usuario ve cuál
333  input recibe sus teclas via el border highlighted.
334- Cambio de theme afecta también a inputs (ya estaban themed; ahora
335  además respetan el `accent_strong` específico del preset
336  cuando focused, vs el `border` cuando no).
337
338Limitación pendiente: el caret `|` literal no parpadea (no hay
339animation timer). Cuando emerja la necesidad, agregar via
340`cx.spawn` con un loop de toggle. Por ahora el caret estático on
341focus es suficiente signal.
342
343### feat(yahweh-widget-theme-switcher): control para ciclar themes en runtime
344Iter 6. Cierra el ciclo del theme: ya teníamos paleta themed +
345widgets que la consumen, faltaba el control UI para rotar entre
346presets en vivo. Ahora hay un botón yahweh que muestra el theme
347actual y al click avanza al siguiente. `nakui-ui` y `nakui-explorer`
348lo incrustan en sus headers — un click cambia toda la paleta.
349
350Crate nuevo: `crates/modules/ui_engine/widgets/theme-switcher/`
351(`yahweh-widget-theme-switcher`):
352- **Deps**: `gpui` + `yahweh-theme`. Sin nada más.
353- **`pub fn theme_switcher(cx: &mut App) -> impl IntoElement`**:
354  botón clickable con `id`, padding consistente (`px(8/4)`),
355  bg = `theme.bg_panel_alt`, hover = `bg_row_hover`. Muestra
356  `"Tema: <name> ▸"` y al click hace
357  `Theme::set(cx, Theme::next_after(current.name))`.
358- 2 tests `#[gpui::test]`:
359  - `switcher_constructs_with_theme_installed` — smoke: el
360    constructor lee el global y devuelve un IntoElement sin panic.
361  - `theme_set_changes_global` — verifica que `Theme::set` reemplaza
362    el global y que el siguiente `Theme::global` devuelve el nuevo.
363- Dev-dep `gpui` con `test-support` para habilitar TestAppContext.
364
365Migración de consumers:
366- **`nakui-explorer`**: nueva dep `yahweh-widget-theme-switcher`.
367  El header pasa de `div().px().py()...child(text)` a
368  `div().flex_row().child(div().flex_grow().child(text)).child(theme_switcher(cx))`.
369  El switcher queda alineado a la derecha vía `flex_grow` del label.
370- **`yahweh-widget-meta-form`**: nueva dep. El sidebar header
371  ("Nakui" + 12px padding) gana el switcher con el mismo patrón
372  flex_row + flex_grow.
373
374Tests stack: 115 → **117** (+2 del switcher). Cada crate compila
375individualmente.
376
377Beneficio operativo:
378- Click en el switcher cambia toda la paleta en vivo: bg del app,
379  panels, banners (los que usan `_themed`), confirm modal, todo.
380- 6 presets disponibles via `Theme::all()` (Nebula, Aurora,
381  Sunset, Flat Dark, Solarized Light, High Contrast). El switcher
382  cicla circularmente.
383- Apps adoptantes del `Theme` heredan el switch sin esfuerzo.
384
385Decisión técnica: el handler usa `Theme::set(cx, ...)` que
386invalida el global. GPUI marca todos los views como dirty y
387re-renderea — los widgets que leen `Theme::global` en su `render`
388ven el nuevo automáticamente. No requiere `cx.observe_global`
389explícito en cada widget consumidor.
390
391Limitación: TextInput entities ya creadas no se actualizan visualmente
392si el theme cambia los colors del input bg/border (esos colors
393están hardcoded en `yahweh-widget-text-input`). Migrar text_input
394al theme es una iter futura — bajo scope porque actualmente vive
395suficientemente bien con sus defaults dark.
396
397### feat(yahweh-widget-meta-form): paleta del chrome migrada a `Theme::global(cx)`
398Iter 5 de integración. El `MetaApp::render` tenía 7 vars locales
399con colors hardcoded (`bg/panel/border/text/text_dim/accent/
400accent_active`) que se pasaban a las funciones internas
401(`render_sidebar`/`render_main`/`render_list`/`render_form`/
402`render_entity_ref_selector`). Ahora salen del `Theme::global(cx)`
403que el binario shell instala al boot. El `confirm_delete_banner`
404también usa `themed_colors(Banner::Warning)` / `themed_colors(Banner::Error)`
405para sus colors base.
406
407Cambios en `MetaApp::render`:
408- 7 `let X = gpui::rgb(0x...)` → derive del theme:
409  - `bg` ← `theme.bg_app` (Background, soporta gradientes).
410  - `panel` ← `theme.bg_panel`.
411  - `border` ← `theme.border` (Hsla).
412  - `text` ← `theme.fg_text`.
413  - `text_dim` ← `theme.fg_muted`.
414  - `accent` ← `theme.accent`.
415  - `accent_active` ← `theme.accent_strong`.
416- `toast_div` y `error_banner`: `banner(...)` → `banner_themed(cx, ...)`.
417
418Cambios de firma (internas, no API público):
419- `render_sidebar` / `render_main` / `render_list` /
420  `render_entity_ref_selector` / `render_form` cambian Rgba →
421  Hsla en sus parámetros de color (Background donde aplica para
422  `panel`). Los métodos `bg/text_color/border_color` de gpui::Div
423  aceptan ambos via `Into`, así que el uso interno no cambia.
424
425Cambios en `render_confirm_delete_banner`:
426- 6 colors hardcoded amber/red/gray → `themed_colors(Warning)` para
427  banner base, `themed_colors(Error)` para botón Confirm,
428  `theme.bg_panel_alt + fg_text` para botón Cancel.
429- Cambiar de Theme ahora cambia toda la paleta del modal.
430
431Lo que **NO** migra esta iter (queda como ornament hardcoded; iter
432futura si emerge la necesidad):
433- Row hovers misceláneos en `render_list` (px 0x232a36 / 0x1f2630
434  para selected/hover de filas).
435- Borders sutiles entre filas (px 0x232a36).
436- Bg de inputs custom (px 0x171a20).
437- Bg de botones en `render_entity_ref_selector` (px 0x2c3540).
438- Color rojo del icon `✕` de delete (px 0xd07070) y su hover
439  (px 0x4a2020).
440
441Estos son detalles ornamentales que un theme switcher real
442querría integrar; los aislo para una pasada futura cuando esté
443claro qué slots semánticos del theme conviene agregar (ej.
444`bg_row_selected` distinto de `bg_row_hover`, `accent_destructive`,
445etc.).
446
447`nakui-ui` shell ya instalaba `Theme::install_default(cx)` desde la
448iter pasada — sigue siendo el contract entre el shell y el widget.
449Smoke test del binario verificado: bootstrap completo OK, panic
450esperado en open_window sin display.
451
452Tests stack: 115 verdes (sin cambio — los tests del widget no
453acceden al render).
454
455Beneficio operativo:
456- El theme switcher (cuando llegue) cambia toda la paleta principal
457  de `MetaApp` con 1 sola llamada `Theme::set(cx, ...)`.
458- `MetaApp` y `nakui-explorer` comparten el mismo theme global en
459  un mismo proceso (si llegan a vivir juntos).
460- Los `confirm_delete_banner` y los toasts del MetaApp respetan
461  is_dark: el contrast ajusta automatic.
462
463### feat(yahweh): theme integration en `banner` + `card` + `nakui-explorer` consume themed
464Iter 4 de la integración. Los widgets `banner` y `card` ahora
465ofrecen variants `_themed(cx, ...)` que leen `Theme::global(cx)`.
466Las versiones sin theme se preservan para apps sin theme global.
467`nakui-explorer` migra a versiones themed + `Theme::install_default`
468al boot — el chrome hardcoded del explorer (5 variables `let bg =
469rgb(...)`) sale del theme.
470
471Cambios en `yahweh-widget-card`:
472- **Nueva dep**: `yahweh-theme`.
473- **`pub fn card_themed(cx: &App) -> Div`**: devuelve [`card`]
474  pre-aplicado con `bg(theme.bg_panel)`. El caller sigue componiendo
475  con borders, accents, children.
476
477Cambios en `yahweh-widget-banner`:
478- **Nueva dep**: `yahweh-theme`.
479- **`pub fn banner_themed(cx: &App, kind, message) -> Div`**:
480  deriva `(bg, fg)` según `kind` + `theme.is_dark`:
481  - `Info`: `theme.bg_panel_alt` + `theme.accent`.
482  - `Success` / `Warning` / `Error`: hue fijo (verde/amber/rojo)
483    + lightness flippeada según `is_dark` (dark = bg low, fg high;
484    light = invertido).
485- **`pub fn themed_colors(kind, theme) -> (Background, Hsla)`**:
486  helper público para callers que quieren computar el par sin
487  construir el div.
488- 3 tests nuevos del derivation: dark/light lightness contrast,
489  kinds distinguidos por hue.
490
491Migración de `nakui-explorer`:
492- Nueva dep `yahweh-theme`.
493- `main()` llama `Theme::install_default(cx)` antes de open_window
494  (el theme default es Nebula).
495- `render`:
496  - 5 `let bg/text/text_dim/card_bg/border = rgb(...)` colors
497    locales → `theme.bg_app/fg_text/fg_muted/bg_panel/border`.
498  - `card().bg(card_bg)` → `card_themed(cx)` (borra los locales).
499  - `banner(Banner::Error, ...)` → `banner_themed(cx, Banner::Error, ...)`.
500  - Los accents `accent_seed` / `accent_morphism` se preservan
501    locales: son **señales semánticas del log** (azul=seed,
502    verde=morphism), no chrome del app.
503
504Distribución de tests: 112 → **115** (+3 del banner derivation).
505Workspace stack pasó por la migración sin errores.
506
507Beneficio operativo:
508- Cambiar de Theme (Nebula → Aurora → Solarized Light, etc.) ahora
509  refleja en `nakui-explorer` automáticamente. Antes había que
510  buscar y reemplazar los hex codes uno a uno.
511- Apps que adopten el patrón `_themed` heredan el switcher de
512  theme cuando emerja.
513
514Decisiones:
515- **Hue fijo por kind**: Success siempre verde, Error siempre rojo,
516  etc. La lightness se ajusta al theme; el hue se mantiene como
517  invariante semántico cross-theme.
518- **API dual**: `banner` (defaults) + `banner_themed` (theme).
519  Apps sin theme global pueden seguir con la versión simple.
520- **Acentos semánticos del explorer (seed/morphism) NO migran**:
521  pertenecen al dominio del log, no al chrome.
522
523Próximas integraciones pendientes:
524- `MetaApp` (en `yahweh-widget-meta-form`) tiene su propia paleta
525  hardcoded de 6 colors que podría migrarse al theme. Scope mayor
526  que esta iter; queda como candidato.
527- Theme switcher widget (botón/menú en chrome para ciclar themes).
528  Cuando emerja la necesidad real.
529
530### feat(yahweh-widget-card): container card-shape compartido para timeline entries
531Iteración 3 de la integración nakui ↔ yahweh. El "card visual"
532pattern (padding consistente + rounded + flex_col + gap) que vivía
533duplicado en cada timeline entry de `nakui-explorer` ahora es un
534widget yahweh reusable. Sin acoplamiento a colores: el caller
535decide bg/border/accent.
536
537Crate nuevo: `crates/modules/ui_engine/widgets/card/`
538(`yahweh-widget-card`):
539- **Dep**: solo `gpui`. App-agnostic.
540- **`pub fn card() -> Div`**: container con `flex_col` + `px(12)`
541  + `py(8)` + `mb(4)` + `rounded(4)` + `gap(2)`. Sin colores
542  aplicados.
543- El return es `Div` GPUI — el caller compone con `.bg(...)`,
544  `.border_l_4()`, `.border_color(...)`, `.child(...)`, hover,
545  on_click, etc., según necesite.
546- 1 test smoke (constructor no panicea).
547
548Migración de `nakui-explorer`:
549- Nueva dep `yahweh-widget-card`.
550- Los 2 patterns de timeline entry (Seed y Morphism) pasan de:
551  ```rust
552  div().flex().flex_col().px(12).py(8).mb(4).bg(card_bg)
553       .rounded(4).border_l_4().border_color(accent).gap(2)...
554  ```
555  a:
556  ```rust
557  card().bg(card_bg).border_l_4().border_color(accent)...
558  ```
559- Reducción ~7 calls → ~3 por entry; legibilidad mejor (la
560  intención "card with accent" emerge del nombre `card()`).
561
562Tests stack: 111 → **112 verdes** (+1 del crate card). Cada crate
563afectado compila y testea individualmente.
564
565Beneficio operativo:
566- Si `MetaApp` o cualquier futura app necesita un container
567  card-shape (ej. info card, expanded list row), `card()` está
568  ya disponible.
569- Cambiar el padding/rounded/gap canónico = un cambio en un solo
570  lugar.
571- El widget no impone colores → no fuerza una paleta y permite
572  themes diversos por app/contexto.
573
574### feat(yahweh-widget-banner): widget compartido para toasts/errores cross-app
575Patrón visual común a `yahweh-widget-meta-form` (toast success +
576error_banner) y `nakui-explorer` (error_banner): un `div` con bg
577+ text colored según severidad. Antes vivía duplicado con colores
578hardcoded en cada consumer; ahora hay un widget yahweh con presets
579consistentes.
580
581Crate nuevo: `crates/modules/ui_engine/widgets/banner/`
582(`yahweh-widget-banner`):
583- **Dep**: solo `gpui` (sin nakui, sin runtime). Reusable por
584  cualquier app GPUI que necesite tiras de status.
585- **`pub enum Banner`** con 4 variants:
586  - `Info` (azul tenue, mensajes neutros).
587  - `Success` (verde, confirmaciones).
588  - `Warning` (amber, llamadas de atención).
589  - `Error` (rojo, errores fatales).
590- **Métodos `Banner::bg()` y `Banner::fg()`**: paleta hardcoded por
591  variant (sin tema dinámico todavía — cuando emerja, se
592  inyecta vía `yahweh-theme`).
593- **`pub fn banner(kind, message) -> Div`**: constructor que
594  devuelve el div ya con padding/text_size defaults; el caller
595  puede agregar children, override pads/sizes, attach handlers.
596- 2 tests sanity: ningún kind comparte bg, ningún kind comparte fg.
597
598Migración de consumers:
599- **`yahweh-widget-meta-form`**: nueva dep `yahweh-widget-banner`.
600  El `toast_div` (Success) y `error_banner` (Error) en
601  `MetaApp::render` pasan de 2x6 líneas hardcoded a una llamada
602  a `banner(...)` cada uno (~12 líneas → 2).
603- **`nakui-explorer`**: nueva dep. El error banner local pasa a
604  `banner(Banner::Error, e).px(16).py(8).text_size(12)` —
605  preserva el padding/size custom del header del explorer via
606  override builder.
607
608Tests stack: 109 → **111 verdes** (+2 del crate banner).
609
610Beneficio operativo:
611- Si emerge un tercer consumer, importa la dep + 1 llamada.
612- Cambiar la paleta de un kind = un cambio en un solo lugar
613  (ej. ajustar tono del Error o el contraste del Warning).
614- Composición preservada: el `banner()` devuelve un `Div` directo,
615  el caller modifica con builder calls (`.child()`, `.px()`,
616  `.on_click()`, etc.) sin rewrap.
617
618Próximo candidato natural: el `confirm_delete_banner` de MetaApp
619es Banner::Warning + 2 botones embedded. Cuando emerja un segundo
620consumer de modal-style banners, extraer un widget compositivo
621arriba del `Banner` base.
622
623### feat(yahweh): `MockBackend` público + tests E2E del widget con `gpui::TestAppContext`
624Cierra el ciclo de testabilidad del widget metainterfaz. Hasta
625ahora los tests del trait `MetaBackend` vivían como impl privada
626en `backend.rs`; el widget no tenía forma de testear handlers
627reales sin levantar `NakuiBackend` (que depende de event log +
628Rhai + nakui-core). Ahora el mock es público y los tests del widget
629lo consumen con `TestAppContext`.
630
631Cambios en `yahweh-meta-runtime`:
632- **Nuevo módulo `pub mod testing`** con
633  `pub struct MockBackend`. Exporta:
634  - `MockBackend::new()` — vacío.
635  - `MockBackend::with_records(iter)` — pre-poblado con
636    `(entity, uuid, value)` tuples.
637  - `MockBackend::with_morphism(name, |inputs, params| -> Result<usize>)` —
638    builder para registrar handlers callable de morphism (sin
639    handler, `morphism()` rebota con error claro).
640  - Métodos de inspección `total_records()` / `records_for(entity)`
641    (último devuelve `Vec<(Uuid, &Value)>` sin clones).
642  - `impl MetaBackend` completo: seed/load/list/update/delete con
643    semantica documentada.
644- **Tests del trait en `backend.rs` simplificados**: el `MemBackend`
645  duplicado se borra; los tests pasan a usar `MockBackend::new()`
646  importado de `crate::testing`. 8 tests del backend.rs intactos +
647  9 tests propios del mock en `testing.rs`.
648- Bajo `pub mod testing` (no `#[cfg(test)]`) deliberadamente: los
649  crates downstream pueden importarlo en sus dev/integ tests
650  vía `yahweh_meta_runtime::testing::MockBackend`.
651
652Cambios en `yahweh-widget-meta-form`:
653- **Dev-dep nueva**: `gpui = { workspace = true, features = ["test-support"] }`.
654  Habilita `TestAppContext` para tests sin abrir window real.
655- **`MetaApp::apply_action` ahora `pub`** (era privado). Necesario
656  para que los tests E2E lo invoquen desde fuera. La function ya
657  era el entry point de los click handlers internos; exponerla no
658  cambia el contract.
659- **Nuevo archivo `tests/widget_with_mock_backend.rs`** con 4 tests
660  `#[gpui::test]`:
661  - `meta_app_constructs_with_mock_backend_and_initial_state`:
662    instancia `MetaApp<MockBackend>` con records pre-poblados +
663    toast inicial; valida que la window construye sin panic.
664  - `open_view_action_does_not_panic`: invoca
665    `apply_action(OpenView)` real a través de
666    `window.update(cx, |meta, _, cx| ...)` → state machine corre
667    sin crash.
668  - `backend_state_visible_from_widget_perspective`: demuestra el
669    patrón "backend pre-poblado para fixtures" (typical para
670    screenshots / demos).
671  - `morphism_handler_can_be_registered_and_called_via_widget`:
672    `MockBackend::with_morphism` registra un counter callback;
673    `apply_action(Morphism)` lo dispara via `commit_morphism`
674    sin tocar nakui-core / Rhai.
675
676Helpers de tests:
677- `customers_module()`: fixture local de un `Module` con entity
678  Customer + view list + view form. Reusable cross-test.
679
680Distribución de tests:
681- `yahweh-meta-runtime`: 47 → **56** (+9 del nuevo testing
682  module).
683- `yahweh-widget-meta-form`: 3 → **7** (+4 E2E reales).
684- Total stack: **109 tests verdes** (56 runtime + 31 cards + 12
685  nakui-ui + 3 explorer + 7 widget).
686
687Beneficio operativo:
688- El widget tiene cobertura runtime real, no sólo type-check.
689- Cualquier app que tome `B: MetaBackend` puede testarse con
690  `MockBackend` en sus dev-deps sin re-implementar el mock.
691- Fixtures pre-pobladas habilitan demos/screenshots/CI con state
692  conocido.
693
694Limitaciones:
695- `render()` no se invoca en los tests (requiere window context
696  más rico). Los tests verifican state machine, no pixels. Pixel
697  comparison (snapshot tests) es scope futuro si emerge la
698  necesidad.
699- `apply_action(Morphism)` con un module que no declara
700  `nakui_module_dir` rebota antes de llamar al mock handler. El
701  4to test acepta ambos outcomes (counter 0 o 1) — si en el futuro
702  agregamos un módulo de fixture con nakui_module_dir poblado, el
703  test puede aserta exactamente.
704
705### feat(yahweh-meta-runtime): promover `short_hash` y `preview_value` desde nakui-explorer
706Continúa la integración de las apps nakui al stack yahweh. Los
707helpers visuales que `nakui-explorer` tenía locales y son reusables
708suben a `yahweh-meta-runtime/format` para que cualquier app pueda
709consumirlos sin duplicar.
710
711Cambios en `yahweh-meta-runtime`:
712- **`pub fn short_hash(h: &[u8; 32]) -> String`**: hex de los
713  primeros 4 bytes (8 chars). Útil para mostrar bundle/schema
714  hashes en UI sin quemar pantalla.
715- **`pub fn preview_value(v: &Value, max: usize) -> String`**:
716  JSON one-liner truncado con `...` al final si excede `max`
717  chars. Edge case: `max < 3` devuelve los primeros `max` chars
718  sin sufijo.
719- Re-exports en lib.
720- 5 tests nuevos: 4 tests + 1 sanity para el caso `max < ellipsis`.
721
722Migración de `nakui-explorer`:
723- Nueva dep `yahweh-meta-runtime` en Cargo.toml.
724- Borrado helpers locales `short_uuid`, `short_hash`,
725  `preview_value` (~30 líneas).
726- `use yahweh_meta_runtime::{preview_value, short_hash, short_uuid}`.
727- Borrados 4 tests duplicados (los runtime los testea).
728
729Tests:
730- `yahweh-meta-runtime`: 42 → **47** (+5 helpers nuevos).
731- `nakui-explorer`: 7 → **3** (–4 duplicados; quedan los 3
732  específicos: load_log, breakdown, missing_file).
733- Resto del workspace intacto.
734
735Beneficio operativo: 3 helpers visuales centralizados. Cualquier
736app nueva que muestre UUIDs/hashes/JSON-previews los importa sin
737re-implementar la heurística de truncamiento.
738
739Pendiente arquitectural: el render del card timeline en
740`nakui-explorer` (border-l-4 colored + flex_col + texto en niveles)
741es un pattern reusable que también aparece en `yahweh-widget-meta-form`
742(render_list filas). Cuando aparezca un tercer consumer de ese
743pattern se extrae a un widget yahweh.
744
745### refactor(yahweh): Fase 2c — extracción del widget al crate `yahweh-widget-meta-form`
746Cierra el refactor de UI: el widget render (forms, lists, modal de
747delete, EntityRef selector, sidebar, key handlers) deja de vivir en
748el binario nakui-ui y pasa a un crate yahweh nuevo, genérico sobre
749`MetaBackend`. nakui-ui queda como un shell de bootstrap de 424
750líneas.
751
752Crate nuevo: `crates/modules/ui_engine/widgets/meta-form/`
753(`yahweh-widget-meta-form`):
754- **Deps**: gpui, yahweh-meta-schema, yahweh-meta-runtime, yahweh-theme,
755  yahweh-widget-text-input, serde_json, uuid. **Cero deps a nakui** o
756  brahman-cards — reusable por cualquier app.
757- **`MetaApp<B: MetaBackend>`** público: estructura genérica con
758  `modules`, `backend: B`, `active`, `form_inputs`, `editing`,
759  `pending_delete`, `toast`, `load_error`. El bound `B: MetaBackend`
760  se propaga a todos los `impl MetaApp<B>` y al `impl Render for
761  MetaApp<B>`.
762- **`MetaApp::new(modules, backend, initial_toast, initial_error, cx)`**:
763  constructor sin lógica de bootstrap. El caller pre-construye
764  modules + backend + cualquier mensaje inicial. La active view
765  default es la primera entry del menú del primer módulo.
766- **Methods preservados** del original (rename simbólico): select_view,
767  open_edit, commit_seed, commit_morphism, commit_delete, apply_action,
768  list_rows, render_*, tick interno via WriteOutcome.post_status.
769- **Helpers locales del widget**: `lookup_field` (path walker JSON
770  por la lista renderer), `append_compact_msg` (concatenador del
771  toast), `format_seed_toast` (decide "creado/actualizado/sin cambios"
772  según `WriteOutcome`).
773- **3 tests funcionales puros**: `lookup_field`, `append_compact_msg`,
774  `format_seed_toast`. Tests con GPUI cx no son posibles sin un
775  TestAppContext setup; quedan implícitos vía type-check del trait
776  bound.
777
778Cambios en `nakui-ui` (shell):
779- **main.rs**: 1959 → **424** líneas (78% reducción). Ahora sólo:
780  1. Carga modules via `brahman_cards::load_cards_from_dir` +
781     `load_ui_modules` (filtra UiModule body, valida, dedup).
782  2. Carga executors para módulos con `nakui_module_dir`.
783  3. `NakuiBackend::open(...)` para inicializar el backend.
784  4. `cx.open_window(...)` con `MetaApp::<NakuiBackend>::new(...)`
785     como root view.
786- **`use yahweh_widget_meta_form::MetaApp`** + dep nueva en
787  Cargo.toml. Los imports de yahweh-meta-runtime/schema desaparecen
788  de main (los consume el widget internamente).
789- **Tests del shell**: 4 tests E2E que tocan nakui-core directamente
790  (event_log_replay, morphism_pipeline_real_sales_vender,
791  load_ui_modules x3). Los tests del NakuiBackend impl quedan en
792  `backend.rs` (8 tests). Los tests del widget viven en su propio
793  crate.
794- **`backend.rs`**: sin cambios (NakuiBackend ya estaba aislado en
795  Fase 2b).
796
797Distribución final del refactor yahweh:
798- `yahweh-meta-schema`: 8 tests (data puro).
799- `yahweh-meta-runtime`: 42 tests (helpers + trait MetaBackend).
800- `yahweh-widget-meta-form`: 3 tests (widget genérico).
801- `brahman-cards`: 26 tests (loader unificado).
802- `nakui-ui`: 12 tests (4 shell + 8 backend impl).
803- **Total: 91 tests** cubriendo el área.
804
805Cada crate compila individualmente. El widget consume el trait sin
806saber qué backend hay debajo; `nakui-ui` provee el trait wireado a
807nakui-core; cualquier futuro shell (mock para tests, otro stack de
808storage) puede reusar el widget sin cambio.
809
810Lo que NO hace Fase 2c:
811- No mueve `format_seed_toast`/`append_compact_msg`/`lookup_field`
812  a `yahweh-meta-runtime`. Son lo bastante widget-flavored
813  (`SharedString` de gpui, decisiones de UX del toast, etc.) que
814  preferí dejarlos al lado del render.
815- No introduce un `MetaApp::with_status` builder pattern. La
816  signature de `new` con 5 args es manejable; si crece, se refactor
817  después.
818- No expone configuración del widget (theme override, layout
819  custom, etc.). Cuando emerja una segunda app que use el widget
820  con preferencias distintas, se agregan opts.
821
822**Pendientes**:
8231. **KCL → Nickel**: kcl_wrapper en nakui-core reemplazado por
824   evaluación de Nickel contracts. Migrar los 3 schemas .k de
825   sales/inventory/treasury a .ncl.
8262. **`card.k` eliminado** (REFERENCE ONLY documentado en su header).
827
828### refactor(yahweh): Fase 2b — `MetaBackend` trait + `NakuiBackend` + MetaUi consume el backend
829Materialización del trait que diseñamos en charla. Tres pasos
830combinados en un solo commit:
831
832**Step A** — trait + WriteOutcome en `yahweh-meta-runtime`:
833- Nuevo módulo `backend.rs` con:
834  - `pub trait MetaBackend: 'static` con 6 métodos:
835    `list_records`, `load_record`, `seed`, `update`, `delete`,
836    `morphism`. Convención de ids como `Uuid` canónico (los
837    backends que internamente usan otros tipos mapean), `set+clear`
838    pre-computados por el caller (no double-roundtrip al store),
839    threshold `'static` sin Send/Sync (suficiente para handlers
840    GPUI single-threaded).
841  - `pub struct WriteOutcome { id, changed, post_status }` con
842    constructor `no_change(id)`. La UI usa `changed = 0` para
843    "sin cambios", `post_status` para concatenar mensajes
844    auto-emitidos por el backend (compact, etc.).
845- 9 tests con un `MemBackend` mínimo (HashMap por
846  `(entity, uuid)`): seed/load round-trip, list/filter/order,
847  update set/clear/no-op, delete/missing, object-safety check.
848
849**Step B** — `NakuiBackend` en `nakui-ui/src/backend.rs`:
850- Estructura que ownea `Arc<Mutex<MemoryStore>>`,
851  `Option<Arc<Mutex<EventLog>>>`, `BTreeMap<id, Arc<Executor>>`,
852  `snap_path`, `snapshot_threshold`, `writes_since_compact`.
853- `NakuiBackend::open(log_path, threshold, executors) -> (Self, OpenStatus)`:
854  abre log, carga snapshot, replay, auto-compact si threshold
855  cruzado; devuelve `OpenStatus { init_toast, load_error }` para
856  que el caller agregue al banner.
857- `tick_compact()` privado que cada write public method invoca
858  tras éxito; devuelve `Option<String>` que se mete en
859  `WriteOutcome.post_status`.
860- `impl MetaBackend for NakuiBackend`:
861  - `seed`: WAL order (log first, store after), `tick_compact`,
862    devuelve `WriteOutcome { id: Some(uuid), changed: 1, post_status }`.
863  - `update`: si `set+clear` vacíos devuelve `WriteOutcome::no_change`;
864    si no construye `FieldOp::Set`+`FieldOp::Clear`, log Morphism
865    `ui.edit_record` con `params.fields/cleared`, store.apply, tick.
866  - `delete`: `FieldOp::Delete`, log Morphism `ui.delete_record`,
867    store.apply, tick.
868  - `morphism`: locks log + store, `execute_and_log_with_recovery`,
869    tick. `WriteOutcome { id: None, changed: ops.len(), post_status }`.
870- Funciones `snapshot_path_for` y `maybe_compact_log` movidas acá
871  desde main.rs (ahora son detalle del backend).
872- 7 tests del impl: round-trip via trait, set+clear, no-op edit
873  no escribe, delete/load, list_records, morphism sin executor da
874  error claro, threshold dispara snapshot.
875
876**Step C** — `MetaUi` consume el backend:
877- Reemplaza fields `store` / `event_log` / `executors` /
878  `snap_path` / `snapshot_threshold` / `writes_since_compact`
879  por un único `backend: NakuiBackend`.
880- `MetaUi::new` colapsa el wiring de persistencia en
881  `NakuiBackend::open(...)` — pasó de ~150 líneas a ~10 líneas.
882- `commit_seed` ya no construye `LogEntry`/`FieldOp` directos:
883  - SEED → `self.backend.seed(entity, obj)`.
884  - EDIT → `self.backend.load_record + compute_field_delta +
885    compute_clear_fields → self.backend.update(set, clear)`.
886  - Devuelve `WriteOutcome` (reemplaza el viejo enum `CommitOutcome`).
887- `commit_morphism` parsea inputs/params del form y delega a
888  `self.backend.morphism(...)`.
889- `commit_delete` es one-liner: `self.backend.delete(entity, id)`.
890- `tick_runtime_compact` eliminado (ahora interno al backend; el
891  msg viaja en `WriteOutcome.post_status`).
892- `list_rows` queda como proxy `self.backend.list_records(entity)`.
893- `validate_entity_refs` callsite usa cierre sobre
894  `backend.load_record` (en vez de `&Store`).
895- Nuevo helper `format_seed_toast(entity, was_editing, &outcome)`
896  reemplaza el match sobre `CommitOutcome`.
897- Imports limpiados: no más `nakui_core::delta::FieldOp`/`FieldPath`,
898  no más `nakui_core::event_log::*` en main.rs (sólo en tests E2E).
899  No más `Arc/Mutex` (vive en backend).
900
901Distribución de tests post-refactor:
902- `yahweh-meta-runtime`: 33 → **42** (+9 trait tests con MemBackend).
903- `nakui-ui`: 14 → **21** (+7 tests del NakuiBackend impl).
904- `yahweh-meta-schema`: 8 (sin cambio).
905- `brahman-cards`: 26 (sin cambio).
906- Total: **97**.
907
908Build: cada crate compila individualmente.
909
910Nota sobre Fase 2b/c estado:
911- ✅ Backend trait + impl + MetaUi usa backend.
912- ⏭ Falta extraer los **widgets render** (form/list/modal/EntityRef
913  selector) de nakui-ui a un crate yahweh nuevo
914  (sugerencia: `yahweh-widget-meta-form`). Esa extracción ahora es
915  trivial: el render code ya consume sólo `&self.modules` +
916  `self.backend` (vía trait). Lo dejo para próximo commit.
917
918**Pendientes**:
9191. **Fase 2c**: extraer widget render al crate yahweh
920   (`yahweh-widget-meta-form` o similar) — `MetaApp<B: MetaBackend>`
921   genérico, `nakui-ui` queda como ~50 líneas de shell con
922   `MetaApp::<NakuiBackend>::new(...)`.
9232. **KCL → Nickel**: kcl_wrapper reemplazado por evaluación de
924   Nickel contracts.
9253. **`card.k` eliminado** (REFERENCE ONLY).
926
927### refactor(yahweh): Fase 2 — extraer helpers puros a `yahweh-meta-runtime`
928Sigue de la Fase 1 (lift del schema a yahweh). Ahora extraemos los
929**helpers puros** que cualquier widget renderer o backend ejecutor
930necesita sobre el schema: parse, delta, validation, format. Sin
931GPUI, sin acoplamiento a un backend específico.
932
933Crate nuevo: `crates/modules/ui_engine/libs/meta-runtime/`
934(`yahweh-meta-runtime`):
935- **Deps**: `serde_json`, `thiserror`, `uuid`, `yahweh-meta-schema`.
936  NO GPUI, NO nakui.
937- **Módulos**:
938  - `parse.rs` — `parse_field_value(kind, raw)`,
939    `infer_param_value(raw)`, `resolve_param_value(name, raw, spec)`.
940  - `delta.rs` — `compute_field_delta(current, proposed)`,
941    `compute_clear_fields(current, to_clear)`.
942  - `refs.rs` — `validate_entity_refs(load: F, refs)` donde `F`
943    es un cierre `Fn(&str, Uuid) -> Option<Value>`. Decoupling vía
944    closure en lugar de trait — evita atar el crate a cualquier
945    backend específico (no hay `Store` trait acá), y los callers
946    pasan `|e, id| store.load(e, id)` trivialmente.
947  - `format.rs` — `human_label_for_record(value, id)`,
948    `render_value(opt_value)`, `value_to_input_text(value)`,
949    `short_uuid(id)`.
950- **33 tests propios** en el crate nuevo (cubren todos los helpers
951  movidos + edge cases).
952
953Cambios en `nakui-ui`:
954- **Nueva dep** `yahweh-meta-runtime` en `Cargo.toml`.
955- **Imports**: agrega `use yahweh_meta_runtime::{...}` con todos los
956  helpers extraídos. Borrado el código local equivalente
957  (~200 líneas).
958- **`validate_entity_refs` callsite**: pasa de
959  `validate_entity_refs(&*store, &refs)` a
960  `validate_entity_refs(|e, id| store.load(e, id), &refs)` — el
961  closure es ergonómico sobre cualquier `Store`.
962- **Tests duplicados borrados** (~34 tests que ahora viven en
963  `yahweh-meta-runtime`):
964  - `parse_field_*` (text/number/boolean variants)
965  - `infer_param_value_*`
966  - `delta_*` (5 tests)
967  - `clear_fields_*` (3 tests)
968  - `validate_entity_refs_*` (5 tests)
969  - `resolve_param_*` (6 tests)
970  - `parse_field_entity_ref_*` (4 tests)
971  - `human_label_*` (3 tests), `render_value_*`,
972    `value_to_input_text_inverse_of_parse`
973- **Tests que se quedan en nakui-ui** (runtime-específicos):
974  - `lookup_field_simple_and_nested` — helper local del list renderer.
975  - `append_compact_msg_handles_both_branches`,
976    `runtime_compact_cycle_resets_counter_after_threshold`,
977    `snapshot_path_for_replaces_extension`,
978    `maybe_compact_log_*` (3) — wiring de persistencia a EventLog.
979  - `load_ui_modules_via_brahman_cards_*` (3) — integración con el
980    brazo de cards.
981  - `value_to_input_then_parse_round_trip` — round-trip del par
982    `value_to_input_text + parse_field_value` (toca ambos lados).
983  - `event_log_replay_restores_memory_store`,
984    `morphism_pipeline_executes_real_sales_vender`,
985    `event_log_replay_handles_full_crud_cycle` — E2E nakui-core.
986
987Distribución de tests:
988- `nakui-ui`: 48 → 14 (los 34 movidos viven en runtime).
989- `yahweh-meta-runtime`: 33 (nuevos).
990- `yahweh-meta-schema`: 8 (sin cambio).
991- `brahman-cards`: 26 (sin cambio).
992- Total cubriendo el área: 81.
993
994Build: cada crate afectado compila y testea limpio individualmente.
995Workspace build full no se completó esta corrida por OOM al
996compilar `surrealdb-core` (problema ambiental no relacionado al
997refactor).
998
999Lo que NO hace Fase 2:
1000- No mueve los widgets render (`render_form`/`render_list`/
1001  `render_entity_ref_selector`/`render_confirm_delete_banner`) a
1002  yahweh — eso es Fase 2b/3, requiere diseñar el `MetaBackend`
1003  trait porque las render functions tocan el state de `MetaUi`
1004  (form_inputs, pending_delete, executors).
1005
1006**Pendientes** (orden):
10071. **Fase 2b**: extraer widget render a un crate yahweh nuevo
1008   (sugerencia: `yahweh-widget-meta-form`). Requiere diseñar
1009   `MetaBackend` trait.
10102. **Fase 3**: thin shell — `nakui-ui` queda reducido a una impl
1011   de backend wireada a `nakui-core`.
10123. **KCL → Nickel** + **card.k eliminado**.
1013
1014### refactor(yahweh): Fase 1 — `nakui-ui-schema` → `yahweh-meta-schema`
1015Primer paso del refactor yahweh. El schema de UI declarativa
1016(entities, menús, listas, formularios, acciones) vivía bajo
1017`crates/modules/nakui/ui-schema/` y se llamaba `nakui-ui-schema` —
1018un nombre que sugería acoplamiento con Nakui que en realidad no
1019existe (el crate sólo depende de `serde`/`serde_json`/`thiserror`).
1020Lo movemos a yahweh para que sea consumible por cualquier app de UI
1021metadata-driven sin hacer pasar la dep "rara" por nakui.
1022
1023Cambios mecánicos:
1024- **`git mv`**: `crates/modules/nakui/ui-schema/` →
1025  `crates/modules/ui_engine/libs/meta-schema/`.
1026- **Cargo.toml del crate movido**:
1027  - `name = "nakui-ui-schema"` → `name = "yahweh-meta-schema"`.
1028  - Description actualizada: "Yahweh — meta-schema: descriptores
1029    declarativos de UI ... independiente del backend".
1030- **Workspace `Cargo.toml`**: la entry del members[] pasa de
1031  `crates/modules/nakui/ui-schema` a
1032  `crates/modules/ui_engine/libs/meta-schema` (en su sección
1033  yahweh, no en la sección nakui).
1034- **`brahman-cards`**:
1035  - Cargo.toml: dep path/name a `yahweh-meta-schema`.
1036  - lib.rs: `pub use nakui_ui_schema::Module` →
1037    `pub use yahweh_meta_schema::Module`.
1038  - readers.rs: comment + doc-link al nuevo nombre.
1039- **`nakui-ui`**:
1040  - Cargo.toml: dep path/name a `yahweh-meta-schema`.
1041  - main.rs: `use nakui_ui_schema::{...}` →
1042    `use yahweh_meta_schema::{...}`.
1043- **Self-test del crate movido**
1044  (`tests/example_modules.rs`): `nakui_ui_schema` → `yahweh_meta_schema`,
1045  y se rebasa el path del repo root (5 niveles arriba ahora, era 4).
1046
1047Cambios documentales:
1048- **Doc de crate** (`lib.rs`): "Schema declarativo de la metainterfaz
1049  Nakui" → "Schema declarativo de la metainterfaz (yahweh
1050  meta-schema)" + "backend-agnostic" en la filosofía. La sección
1051  Persistencia universal pasa de "el runtime conecta cada vista al
1052  `nakui_core::store::Store`" a un wording neutro: "el runtime que
1053  consume este schema conecta vistas a su backend".
1054- **Doc del field `Module.nakui_module_dir`**: ahora marcado como
1055  "path opaco al backend, lo interpreta el runtime concreto". Se
1056  describe la convención actual de Nakui (nsmc.json + KCL + Rhai)
1057  como ejemplo, no como contrato del schema. El nombre del campo
1058  se mantiene por compat con módulos ya escritos; agregado
1059  `#[serde(alias = "backend_module_dir")]` para que un futuro
1060  rename no rompa los actuales.
1061
1062Tests:
1063- yahweh-meta-schema (crate movido): 13 tests propios siguen
1064  verdes tras el path rebase.
1065- brahman-cards: 26/26 verdes (17 integration + 9 nickel).
1066- nakui-ui: 48/48 verdes.
1067- Workspace build verde.
1068
1069Lo que NO hace Fase 1:
1070- No mueve los widgets de UI (form/list/modal/EntityRef selector)
1071  a yahweh — eso es Fase 2.
1072- No introduce un trait `MetaBackend` para desacoplar la lógica
1073  de runtime de Nakui — eso es Fase 3.
1074- No renombra el field `nakui_module_dir`. Se hará cuando aparezca
1075  un segundo backend que también lo necesite.
1076
1077**Pendientes** (orden):
10781. **Fase 2**: extraer widgets render (form/list/modal/EntityRef
1079   selector + helpers parse_field_value/render_value/etc.) a un
1080   nuevo crate `yahweh-widget-meta-form` (o nombre similar).
10812. **Fase 3**: trait `MetaBackend` + thin shell — `nakui-ui` queda
1082   reducido a una impl de backend wireada a `nakui-core`.
10833. **KCL → Nickel**: kcl_wrapper reemplazado por evaluación de
1084   Nickel contracts.
10854. **card.k eliminado** (REFERENCE ONLY).
1086