Version: 2.0 · Fecha: 2026-09-27
Referencia: Manual de Diseño 3.0, desplegado en http://10.120.0.2:8552/propuesto/ — reemplaza al Manual de Identidad Visual 1.4
Decir cómo pinta el generador de wireframes del proceso de HU (05_render_wireframe.py) y qué se comprueba en un wireframe. Los valores visuales —paleta, tipografía, medidas, componentes— no se repiten aquí: son los del Manual de Diseño 3.0, que se genera desde el código del kit. El estilo del generador vive en architecture/nebula-erp → pipeline/scripts/templates/nebula.css y aplica el perfil 3.0.
| Qué | Dónde se consulta |
|---|---|
| Paleta, superficies y tokens claro/oscuro | Perfil 3.0 |
| Campo, botón, tabla, modal, badge: medida por medida frente al 1.6 | Del 1.6 al 3.0 |
| Tipografía e iconografía | Tipografía · Iconografía |
| Reglas de comportamiento (consulta, bandejas, avisos, fechas) | Reglas del 3.0 |
| Pantallas reales como referencia | Ejemplos de formulario · Ejemplos de tabla |
| Lo que no se usa | Deprecado: qué no usar |
Los iconos usados están precargados en pipeline/scripts/icons/lucide_icons.py: search, plus, edit, trash, eye, calendar, x, check, filter, arrow-right, chevron-down, download, upload, home, alert-triangle, info. Para agregar uno nuevo, se copia su SVG desde lucide.dev y se añade al diccionario.
El pipeline soporta 5 tipos (layout.type):
list_viewPantalla de listado con tabla + filtros + acciones + botón Crear.
Elementos: cabecera (migas + título + un solo botón Crear), búsqueda en los resultados y rango de fechas en un campo, tabla de datos, paginación.
Cuándo usarlo: pantallas principales de consulta (ej. "Listado de Causaciones").
actions_by_state)Cuando las reglas de negocio definen que ciertas acciones solo aplican en ciertos estados (p. ej. "Editar solo si estado = Pendiente"), el wireframe debe reflejarlo visualmente. El renderizador acepta tres niveles de configuración en el YAML de la HU, en orden de prioridad:
| Nivel | Clave YAML | Ámbito | Cuándo usar |
|---|---|---|---|
| 1 | row.enabled_actions: [view, edit] |
Fila específica | Casos puntuales (excepciones manuales) |
| 2 | layout.actions_by_state: {Pendiente: [...], Finalizado: [view]} |
Todas las filas según el texto del badge de estado | Patrón estándar — debe usarse siempre que las RNs enumeran habilitación por estado |
| 3 | layout.actions_per_row: [view, edit, delete] |
Todas las filas sin distinción | Default cuando no hay lógica condicional |
Regla obligatoria: si existe una RN del tipo "El botón X solo se habilita cuando el estado es Y", la HU debe declarar actions_by_state en el layout. De lo contrario el wireframe está divergiendo de las RN y QA puede rechazarlo.
Representación visual: los iconos no habilitados se renderizan atenuados (opacity: 0.35). El title del icono incluye automáticamente el sufijo "· no aplica en estado <Estado>" para que el lector entienda por qué está gris.
Ejemplo (extracto de HU-TES-001 Crear Diferidos):
layout:
type: list_view
actions_per_row: [view, edit, delete]
actions_by_state:
Pendiente: [view, edit, delete] # permite todo (RN-ALC1-08/09/10)
En proceso: [view, edit] # no permite eliminar
Finalizado: [view] # solo lectura (RN-ALC2-13)
Inactivo: [view]
Detección del estado: el template toma el texto de la primera celda con badge: true de cada fila. Las claves del mapping deben coincidir literalmente con el text del badge (case y acentos sensibles).
Excepción: listados con checkbox de selección múltiple + botón global (patrón de HU-CON-013/014/018 Aprobación/Anulación) no usan actions_by_state. En ese patrón la habilitación vive en el botón global ("Anular" activo si ≥1 fila seleccionada) y actions_per_row queda como [view] estático: en una bandeja de aprobación la fila solo lleva Consultar (regla R3-07 del manual).
formFormulario con tarjetas agrupadas + tabla embebida opcional + botones.
Elementos: cabecera, form-card por sección con field-group de campos, tabla de detalle opcional con totales, fila de botones.
Cuándo usarlo: pantallas de creación/edición con campos agrupados (ej. "Datos de la Factura").
modalVentana emergente centrada con campos + tabla opcional + botones.
Elementos: header con icono semántico + título, body de texto opcional, groups con campos en grid 2-cols, table opcional, fila de botones.
Cuándo usarlo: ventanas de configuración o búsqueda (ej. "Formato Contable", "Diferido", "Maestro Terceros").
detailVista de solo lectura en grid label-valor.
Elementos: cabecera, form-card con detail-grid (label + valor, en caja de solo lectura). Una consulta lleva solo Volver y no marca obligatorios (reglas R3-06 y R3-13).
Cuándo usarlo: pantallas de consulta con datos no editables.
wizardFormulario multi-paso con indicador de progreso.
Elementos: steps horizontales con círculos numerados, contenido del paso actual (form-card + fields), navegación (Cancelar / Anterior / Siguiente).
Cuándo usarlo: procesos lineales de 3-5 pasos (ej. "Crear Formato Contable").
Al revisar un wireframe generado, confirma que sigue el Manual de Diseño 3.0:
#C4C6CF; menú lateral en #0E58A9 con el ítem activo resaltado.#F9F9FF; título de página en 20 px negrita.#EEF3F9 y título en 12 px, negrita, mayúsculas.#C4C6CF, radio 8; rótulo de 14 px encima.#D6E3FF.#0E58A9, filas de 44 px y zebra #F9F9FF / #D6E3FF.lib-alert está deprecado): el resultado de una acción es un toast.list_view con RNs de habilitación por estado: actions_by_state declarado y los iconos inaplicables atenuados.| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 2.0.0 | 2026-09-27 | Carlos Torres | El generador pasa al Manual de Diseño 3.0 (nebula.css reescrito con el perfil 3.0). Paleta, tipografía y componentes dejan de repetirse aquí y remiten al manual desplegado; checklist en valores 3.0 |
| 1.1.0 | 2026-04-21 | Carlos Torres | Patrón actions_by_state para listados con habilitación de acciones por estado de fila. Piloto HU-TES-001. CSS icon-btn.disabled con opacity 0.4. Checklist actualizado. |
| 1.0.0 | 2026-04-20 | Carlos Torres | Estandar visual documentado |