Validación inline: al fallar un submit por campos required vacíos, el
form los marca (label destructivo + mensaje debajo), no sólo un toast.
MetaApp.form_errors + validate_required_fields. Secciones de formulario:
FieldSpec.section agrupa campos bajo encabezados; abrir_form del CRM las
usa. Campos condicionales y pulido puramente visual: scope-out conciente.
El plan docs/nakui-erp-masterplan.md queda completo (7/7 fases). Tests
verdes (meta-schema 16, meta-runtime 70, meta-form 8, nakui-ui 14);
clippy limpio en las libs.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Toda vista de lista gana un botón «⬇ CSV» que exporta las filas
filtradas/ordenadas (con refs resueltas y montos formateados) a un
archivo <entity>-<timestamp>.csv. Serializador to_csv (RFC 4180, con
escape) en el módulo nuevo meta-runtime/csv.rs. Refactor:
list_filtered_sorted extraído como helper compartido entre el render
de la lista y el export.
Tests de to_csv; meta-runtime 70 + meta-form 8 verdes, clippy limpio.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
View::Dashboard: grilla de tarjetas de agregados. Metric Count/Sum/
GroupBy con filtro opcional (CardFilter), computado por compute_metric
en meta-runtime (MetricResult Scalar/Breakdown). meta-form render_dashboard
pinta cada tarjeta con el número grande formateado o un breakdown con
barras de texto. El CRM gana una vista «Panorama»: clientes,
oportunidades, pipeline, ganadas, y breakdowns por etapa y canal.
Tests de compute_metric; verificación del panorama en nakui-ui. Clippy
limpio en las libs.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Las vistas de lista de meta-form ganan: orden por columna (clic en
header cicla asc→desc→off con indicador ▲/▼), búsqueda en vivo (caja 🔍
que filtra por search_in mientras se teclea, vía cx.observe del
TextInput) y paginación (25/página, controles ◀▶). Sin cambios de
schema: son estado del widget. Helpers puros cmp_values (meta-runtime)
y next_sort con tests.
Tests verdes (meta-runtime 63, meta-form 8); clippy limpio.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
View::Detail: ficha de un record con sus campos + listas de records
relacionados (RelatedList, back-references por via_field) + botones
Volver/Editar. ListView.row_detail enlaza lista→ficha con un botón 👁
por fila; Module::validate exige que apunte a una vista detail. En
meta-form: render_detail/render_related + select_detail con retorno.
El CRM: 👁 en Clientes y Oportunidades abre su ficha; la del cliente
lista sus oportunidades e interacciones. Tests en meta-schema y
nakui-ui verdes; clippy limpio.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Column.ref_entity resuelve un UUID al label del record referido;
Column.format (ValueFormat Number/Currency) agrupa miles y prefija
símbolo. El campo entity_ref en formularios muestra el record elegido
por su label, no el UUID. human_label_for_record reconoce nombre/titulo
(español). El módulo CRM: las listas muestran el nombre del cliente y
monto como $12,000.
Helper format_value en meta-runtime. Tests en meta-schema, meta-runtime
y nakui-ui verdes; clippy limpio.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Primera fase del plan maestro. La metainterfaz gana dos tipos de campo:
Select (chips de un conjunto cerrado, con options validadas) y AutoId
(UUID autogenerado read-only). NakuiBackend::seed inyecta el id de la
entity = clave del store. El módulo CRM los adopta: etapa/canal son
selects, los ids de idempotencia se autogeneran, el form de cliente ya
no pide id. Ningún formulario pide un UUID a mano.
Tests en meta-schema, meta-runtime y nakui-ui verdes.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
7 fases ordenadas por dependencia e impacto para llevar nakui de
"listas y formularios que funcionan" a ERP terminado: captura sin
fricción, relaciones legibles, ficha de detalle, listas profesionales,
tablero/KPIs, reportes, pulido. Más estado actual y criterios de
"terminado".
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
examples/nakui-modules/crm/module.json: el módulo crm se ve ahora como
un ERP en nakui-ui (sidebar + listas + formularios), no sólo como el
timeline del event log. 7 vistas — lista+form de Clientes, Oportunidades
e Interacciones — con los formularios de morfismo Abrir/Mover/Registrar
que disparan los morfismos reales del kernel (nakui_module_dir engancha
el módulo crm). 2 tests verifican parseo, validación y carga por el
camino brahman_cards.
Correr: NAKUI_MODULES_DIR=examples/nakui-modules cargo run -p nakui-ui
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Módulo CRM declarativo (schema.ncl + nsmc.json + morfismos Rhai) con
tres entities (Cliente, Oportunidad, Interaccion) y tres morfismos:
abrir_oportunidad, mover_oportunidad (pipeline con validación de
transiciones) y registrar_interaccion.
crm_demo: demo realista de 18 eventos que —a diferencia de los otros
demos— conserva el event log e imprime el comando de nakui-explorer,
así el explorador muestra un CRM con cuerpo. tests/crm.rs: 8 tests.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
App GPUI con app_id carmen.greeter: formulario usuario+contraseña que
autentica con brahman-auth en un hilo de fondo y, en éxito, emite un
SessionTicket por stdout para que el compositor haga el traspaso a modo
sesión. Backend mock (MIRADA_GREETER_MOCK) o PAM.
Incluye brahman-auth::SessionTicket (contrato de tiquet greeter→compositor,
serializado a una línea con prefijo versionado) y el modo enmascarado de
nahual-widget-text-input (TextInput::with_mask para contraseñas).
18 tests nuevos; greeter verificado por compilación + clippy.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Base del DM/greeter de carmen. Contrato Authenticator agnóstico:
authenticate(usuario, secreto) -> UserInfo (uid/gid/home/shell).
PamAuthenticator verifica contra PAM (/etc/pam.d/carmen); MockAuthenticator
con credenciales en memoria para tests. AuthError grueso: BadCredentials
vs AccountUnavailable, sin filtrar existencia de cuentas. resolve_user
vía getpwnam. data/carmen como servicio PAM; ejemplo auth-probe.
11 tests; el camino PAM real se ejercita.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Segunda mitad de la uniformización del tema. nahual-theme::toolkit
traduce el Theme activo a gtk-3.0/gtk.css y gtk-4.0/gtk.css con overrides
@define-color (acento exacto + neutro claro/oscuro sintetizado).
Theme::set/install_default exportan best-effort; guarda de no-pisar
respeta un gtk.css ajeno. El compositor inyecta XDG_CURRENT_DESKTOP=mirada
y QT_QPA_PLATFORMTHEME=gtk3 a cada hijo, así GTK y Qt siguen el tema.
8 tests nuevos en toolkit; ejemplo dump-toolkit-css.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Backend de xdg-desktop-portal para carmen: implementa
org.freedesktop.impl.portal.Settings y publica color-scheme,
accent-color y contrast desde el tema activo de nahual. GTK4, Qt6,
Firefox y Chromium voltean claro/oscuro + acento por protocolo, sin
tocar sus configs. Watcher con notify del archivo de nahual-theme →
emite SettingChanged en vivo. 13 tests; smoke verificado sobre un bus
de sesión efímero.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Compilación del input de planificación recibido el 2026-05-19:
21 módulos totales (12 existentes + 9 nuevos + 1 rename), 6 servicios
compartidos como libraries horizontales, ~60-110K LOC nuevo código.
Estructura del plan:
- Fase A (sem 1-2): foundations cleanup (rename, brain split, lifecycle
extract, pivot_root+overlayfs, transport-ssh)
- Fase B (sem 2-5): core libraries (sandokan, dime, discovery-dht)
- Fase C (sem 4-12): apps standalone paralelos (carmen, akashi, matilda,
takiy, dominium, ágora)
- Fase D (multi-mes): charka outlier (parser COBOL completo)
- Fase E (sem 12-18): yachay integrador
- Fase F (continuo): cobertura tests + cerrar stubs cosmo/pineal
- Fase G (post): backlog (rimay, yuyay, apu, tinkuy, nutu + 4)
Critical path: 17-23 semanas (4-5.5 meses) sin charka completo.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Errores detectados al auditar afirmaciones técnicas contra el código:
1. minga-vfs: NO está relacionado con Mónadas (esas son de akasha).
Es FUSE que proyecta el índice de minga (git semántico) como
filesystem, resolviendo paths virtuales a blobs por hash.
2. protocol/SDD.md: Card tiene 19 campos, no 6. Añadido bloque con
anatomía completa del struct.
3. STATUS.md: LOC por capa corregidos contra wc -l real
- protocol: 6,260 → 7,278
- init: ~3,600 → 4,301
- compat: ~5,000 → 3,435 (estaba sobrestimado)
4. pineal: 6 stubs (<30 LOC c/u), no 5. Export (23 LOC) también es
stub funcional. LOC reales por sub-crate documentados.
5. init/SDD.md: ente-soma es wrapper de 44 LOC, no ~30.
6. akasha/SDD.md: fastembed está detrás de feature `embeddings`,
ort es transitivo. Sin feature, akasha-nous-real es stub mínimo.
7. vista/barra: LOC ajustados (vista-core 177, barra-core 108).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Flujo seguro de adopción: arje se instala como entrada GRUB
alternativa, no toca systemd ni /sbin/init. Booteás arje cuando
querés, volvés a systemd si rompe (rollback instantáneo desde el
menú).
Artefactos nuevos:
- scripts/install-arje-as-init.sh: instala binarios musl-static a
/usr/sbin/ y /usr/bin/, copia seed a /ente/seed.card.json, agrega
menuentry "arje" a /etc/grub.d/40_custom usando init=/sbin/ente-zero
con kernel + initrd nativos. NO cambia GRUB_DEFAULT. Idempotente
(regenera el bloque ARJE-MENUENTRY si existe).
- scripts/uninstall-arje.sh: revierte binarios + menuentry. Conserva
/ente/seed.card.json por si la editaste.
- seeds/arje-host.card.json: seed para máquina real con 15 cards:
tmpfiles + mount-fstab + swap-on + dbus-system + 11 compat shims +
dhcpcd + sshd + agetty. Validada.
- docs/arje-replace-systemd.md: filosofía vs systemd ("no acapara
porque no genera, sólo arranca lo declarado"), lista exhaustiva de
servicios systemd que NO deben migrarse (ModemManager, snapd, cups,
unattended-upgrades, etc.), tabla diferencial de UX vs systemd
(systemctl restart → kill PID, systemctl enable → editar seed),
checklist pre-primer-boot, instrucciones de rollback y cómo hacer
arje default sólo cuando estés seguro.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Para "ver" la administración del init desde el shell que arrancó dentro
del initramfs hacían falta clientes que hablen los 4 sockets Unix. Los
exists como examples de cada crate; los empaquetamos ahora.
build-arje-initrd.sh:
- cargo build --example brahman-status -p brahman-admin
- cargo build --example busctl -p ente-bus
- cargo build --example brainctl -p ente-brain
- Copia los 3 a /usr/bin/ del initrd.
docs/arje-boot.md §6b reescrita con:
- Tabla de sockets corregida (defaults a /tmp/ cuando no hay
XDG_RUNTIME_DIR/TMPDIR, que es el caso en initrd).
- Cookbook de los 3 CLIs con ejemplos de sesión típica dentro de la VM.
- Nota para vendorear socat-static via EXTRA_BINS si querés conectar
crudo a un socket.
§1 layout actualizado con /usr/bin/{brahman-status,busctl,brainctl}.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sin musl, PID 1 panic con "error while loading shared libraries:
libgcc_s.so.1" porque el initramfs no incluye libgcc/glibc/ld-linux.
Solución estándar: target x86_64-unknown-linux-musl produce un ELF
totalmente estático.
Cambios en scripts/build-arje-initrd.sh:
- ARJE_TARGET=x86_64-unknown-linux-musl por default (override con env).
- Chequeo del target instalado antes de buildear; mensaje accionable
con los comandos exactos (rustup target add..., apt install
musl-tools, etc.) si falta.
- Sanity check con `file`: aborta si ente-zero quedó dinámico.
- Sanity check para busybox: aborta si el BUSYBOX_BIN apunta a un
binario dinámico (la otra causa #1 de panic).
- BIN_DIR ahora apunta a target/$TARGET/release/.
Docs (docs/arje-boot.md):
- §2a explica el porqué de musl.
- §2b lista requisitos del host (rustup target, musl-tools, busybox-static).
- §7 sección nueva de troubleshooting con el síntoma exacto del
libgcc_s panic + 3 escenarios comunes más.
- Checklist pre-deploy actualizado con el chequeo de "statically linked".
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
sergio