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