1# Plan maestro — Nakui como ERP profesional
2
3Estado: 2026-05-21 · Subproyecto: `nakui` + la metainterfaz `nahual` (meta-schema / meta-runtime / meta-form) + `nakui-ui`.
4
5## 1 · Visión
6
7Un ERP **dirigido por datos**: cada módulo de negocio es un manifiesto
8declarativo (entities + morfismos + UI), sin código compilado por
9módulo. El kernel garantiza integridad (validación Nickel, event-log
10con replay, morfismos verificados). La metainterfaz lo presenta como un
11ERP de verdad: tableros, listas, fichas, formularios.
12
13Hoy el kernel está sólido. Lo que falta es subir la metainterfaz de
14"listas y formularios que funcionan" a "ERP terminado".
15
16## 2 · Estado actual
17
18**Kernel (`nakui-core`)** — maduro. Event-log + replay + snapshots,
19morfismos Rhai, validación Nickel pre/post, drift, persistencia
20SurrealDB opcional. Módulos: `inventory`, `sales`, `treasury`, `crm`.
21
22**Metainterfaz (`nahual` meta-*)** — funcional, base:
23- `meta-schema`: `Module` → `entities` + `menu` + `views` (`List`/`Form`).
24 `FieldKind`: text/multiline/number/boolean/date/entity_ref.
25 `Action`: open_view / seed_entity / morphism.
26- `meta-runtime`: trait `MetaBackend` (list/load/seed/update/delete/
27 morphism), parse, delta, format, validación de refs.
28- `meta-form` (widget GPUI): sidebar + list/form, **edit** y **delete**
29 ya implementados, selector de `entity_ref`.
30- `nakui-ui`: shell + `NakuiBackend` (event-log + store + executors).
31
32**Brechas hacia "ERP profesional"** — capturar datos tiene fricción
33(UUIDs a mano, enums como texto libre); las relaciones se muestran como
34UUID crudo; no hay ficha de detalle, ni tablero, ni orden/filtros en
35listas, ni formato de moneda/fecha, ni reportes.
36
37## 3 · Hoja de ruta por fases
38
39Ordenadas por dependencia y por impacto visible. Cada fase toca
40`meta-schema` (constructo declarativo nuevo) → `meta-runtime` (helper
41puro) → `meta-form` (render) → módulos de ejemplo + tests.
42
43### Fase 1 · Captura sin fricción — HECHA
44
45- `FieldKind::Select` — campos enumerados como desplegable/chips, con
46 `options` (valor + etiqueta) declaradas.
47- `FieldKind::AutoId` — UUIDs de idempotencia autogenerados; el usuario
48 no los teclea.
49- `NakuiBackend::seed` inyecta el `id` de la entity = clave del store
50 (hoy quedan desacoplados).
51- **Resultado**: ningún formulario pide un UUID a mano; etapa, canal y
52 similares son selects. El CRM se siente correcto al cargar datos.
53
54### Fase 2 · Relaciones legibles + formato — HECHA
55
56- Columnas con `ref_entity` muestran el **label** del record referido
57 (vía `human_label_for_record`), no el UUID. El campo `entity_ref` en
58 formularios muestra el record elegido, no el UUID crudo.
59- Formato declarable por columna: `ValueFormat::{Number, Currency}` —
60 separador de miles + símbolo (`12000` → `$12,000`).
61- **Resultado**: las listas se leen como un ERP, no como un volcado.
62
63### Fase 3 · Ficha de detalle — HECHA
64
65- `View::Detail` — el botón 👁 de una fila abre la ficha del record:
66 sus campos + listas de records relacionados (back-refs: las
67 oportunidades e interacciones de un cliente) + botones Volver/Editar.
68- `ListView.row_detail` enlaza lista → ficha; `RelatedList` declara los
69 back-references por `via_field`.
70- **Resultado**: navegación de ERP — lista → ficha → relacionados.
71
72### Fase 4 · Listas profesionales
73
74- Orden por columna (clic en header), filtros por columna, paginación.
75- Columnas computadas / agregadas.
76- **Resultado**: listas usables con cientos/miles de registros.
77
78### Fase 5 · Tablero y KPIs
79
80- `View::Dashboard` — tarjetas de agregados: conteos, sumas, breakdown
81 por grupo (oportunidades por etapa, monto en pipeline, ventas del
82 mes). Reusa los charts de `pineal`.
83- **Resultado**: panorama ejecutivo al abrir el módulo.
84
85### Fase 6 · Reportes y exportación
86
87- Export CSV de cualquier lista; impresión (los temas `Print` de
88 `nahual-theme` ya existen).
89
90### Fase 7 · Pulido de producto
91
92- Validación inline (error por campo, resaltado de requeridos),
93 secciones de formulario, campos condicionales, pulido visual.
94
95### Fase 8 · Operación (futuro)
96
97- Persistencia SurrealDB por defecto, multiusuario, permisos, auditoría
98 (el event-log ya es la base de la pista de auditoría).
99
100## 4 · Criterios de "terminado"
101
102- Cargar un módulo nuevo = escribir un `module.json`; cero recompilado.
103- El CRM (y un segundo módulo no trivial) operables de punta a punta:
104 alta, edición, pipeline, ficha, tablero — sin tocar un UUID.
105- Listas con orden/filtro/paginación; valores formateados.
106- Tablero con KPIs reales por módulo.
107- Cobertura de tests en cada crate meta-*; el render se verifica en
108 máquina con pantalla.
109
110## 5 · Cronograma indicativo
111
112```
113Fase 1 Fase 2 Fase 3 Fase 4 Fase 5 Fase 6-7
114[hoy ] [~3-4d] [~1 sem] [~3-4d] [~1 sem] [~1 sem]
115```
116
117~4-6 semanas en solitario para Fases 1-7. La Fase 8 es trabajo aparte.
nakui-erp-masterplan.md
Plan maestro — Nakui como ERP profesional
Estado: 2026-05-21 · Subproyecto: nakui + la metainterfaz nahual (meta-schema / meta-runtime / meta-form) + nakui-ui.
1 · Visión
Un ERP dirigido por datos: cada módulo de negocio es un manifiesto
declarativo (entities + morfismos + UI), sin código compilado por
módulo. El kernel garantiza integridad (validación Nickel, event-log
con replay, morfismos verificados). La metainterfaz lo presenta como un
ERP de verdad: tableros, listas, fichas, formularios.
Hoy el kernel está sólido. Lo que falta es subir la metainterfaz de
"listas y formularios que funcionan" a "ERP terminado".
2 · Estado actual
Kernel (nakui-core) — maduro. Event-log + replay + snapshots,
morfismos Rhai, validación Nickel pre/post, drift, persistencia
SurrealDB opcional. Módulos: inventory, sales, treasury, crm.
Metainterfaz (nahual meta-*) — funcional, base:
meta-schema: Module → entities + menu + views (List/Form).
FieldKind: text/multiline/number/boolean/date/entity_ref.
Action: open_view / seed_entity / morphism.
meta-runtime: trait MetaBackend (list/load/seed/update/delete/
morphism), parse, delta, format, validación de refs.
meta-form (widget GPUI): sidebar + list/form, edit y delete
ya implementados, selector de entity_ref.
nakui-ui: shell + NakuiBackend (event-log + store + executors).
Brechas hacia "ERP profesional" — capturar datos tiene fricción
(UUIDs a mano, enums como texto libre); las relaciones se muestran como
UUID crudo; no hay ficha de detalle, ni tablero, ni orden/filtros en
listas, ni formato de moneda/fecha, ni reportes.
3 · Hoja de ruta por fases
Ordenadas por dependencia y por impacto visible. Cada fase toca
meta-schema (constructo declarativo nuevo) → meta-runtime (helper
puro) → meta-form (render) → módulos de ejemplo + tests.
Fase 1 · Captura sin fricción — HECHA
FieldKind::Select — campos enumerados como desplegable/chips, con
options (valor + etiqueta) declaradas.
FieldKind::AutoId — UUIDs de idempotencia autogenerados; el usuario
no los teclea.
NakuiBackend::seed inyecta el id de la entity = clave del store
(hoy quedan desacoplados).
- Resultado: ningún formulario pide un UUID a mano; etapa, canal y
similares son selects. El CRM se siente correcto al cargar datos.
Fase 2 · Relaciones legibles + formato — HECHA
- Columnas con
ref_entity muestran el label del record referido
(vía human_label_for_record), no el UUID. El campo entity_ref en
formularios muestra el record elegido, no el UUID crudo.
- Formato declarable por columna:
ValueFormat::{Number, Currency} —
separador de miles + símbolo (12000 → $12,000).
- Resultado: las listas se leen como un ERP, no como un volcado.
Fase 3 · Ficha de detalle — HECHA
View::Detail — el botón 👁 de una fila abre la ficha del record:
sus campos + listas de records relacionados (back-refs: las
oportunidades e interacciones de un cliente) + botones Volver/Editar.
ListView.row_detail enlaza lista → ficha; RelatedList declara los
back-references por via_field.
- Resultado: navegación de ERP — lista → ficha → relacionados.
Fase 4 · Listas profesionales
- Orden por columna (clic en header), filtros por columna, paginación.
- Columnas computadas / agregadas.
- Resultado: listas usables con cientos/miles de registros.
Fase 5 · Tablero y KPIs
View::Dashboard — tarjetas de agregados: conteos, sumas, breakdown
por grupo (oportunidades por etapa, monto en pipeline, ventas del
mes). Reusa los charts de pineal.
- Resultado: panorama ejecutivo al abrir el módulo.
Fase 6 · Reportes y exportación
- Export CSV de cualquier lista; impresión (los temas
Print de
nahual-theme ya existen).
Fase 7 · Pulido de producto
- Validación inline (error por campo, resaltado de requeridos),
secciones de formulario, campos condicionales, pulido visual.
Fase 8 · Operación (futuro)
- Persistencia SurrealDB por defecto, multiusuario, permisos, auditoría
(el event-log ya es la base de la pista de auditoría).
4 · Criterios de "terminado"
- Cargar un módulo nuevo = escribir un
module.json; cero recompilado.
- El CRM (y un segundo módulo no trivial) operables de punta a punta:
alta, edición, pipeline, ficha, tablero — sin tocar un UUID.
- Listas con orden/filtro/paginación; valores formateados.
- Tablero con KPIs reales por módulo.
- Cobertura de tests en cada crate meta-*; el render se verifica en
máquina con pantalla.
5 · Cronograma indicativo
Fase 1 Fase 2 Fase 3 Fase 4 Fase 5 Fase 6-7
[hoy ] [~3-4d] [~1 sem] [~3-4d] [~1 sem] [~1 sem]
~4-6 semanas en solitario para Fases 1-7. La Fase 8 es trabajo aparte.