CERTIFICACION_FRONT.md con la matriz de todos los casos de prueba de la HT, ejecutados en la pantalla contra el backend desplegado en DEV, cada uno con su veredicto y su evidencia.architecture/sprint-N/entregas/HT_XXX_NNN_Nombre/CERTIFICACION_FRONT.md, junto a la certificación de backend.nx serve nebula-shell, puerto 4200) contra api-dev.evidencias/front/ con el prefijo CP-NN_.nebula-ui-kit está bloqueado en 2.17.0). No se corrige el backend desde el front: se reporta. No se usan contraseñas: las digita Carlos. No se suben videos.architecture/sprint-9/entregas/HT_PRE_007_CreacionRubros/CERTIFICACION_FRONT.md: 65 de 65 casos, nueve defectos de front y ocho de backend corregidos durante la certificación.ESTADO: Aprobado
FECHA: 2026-10-15
AUTOR: Carlos Alberto Torres Camargo (arquitecto)
ALCANCE: la certificación de entrega de cada pantalla del ERP Nebula (Angular, motor y perfil visual 3.0): qué documento se produce, contra qué ambiente, con qué compañías y usuarios, qué veredictos existen, qué evidencias se adjuntan y cómo se coordina con el backend
RELACIONADOS: ADR-018 Certificación de entrega — Backend (del que sale este), ADR-003 Política formal de entrega a QA, ADR-014 Estrategia de pruebas E2E del frontend, ADR-017 Gobierno de nebula-ui-kit, Entregas Frontend
IMPLEMENTACIÓN DE REFERENCIA: HT_PRE_007 Creación de Rubros, certificada el 14 y 15-oct-2026 (architecture/sprint-9, commit 35f19e6)
Hasta el 15-oct-2026 el frontend no tenía plantilla ni catálogo de certificación. Sus entregas a QA eran documentos por sprint (INDICE_FRONTEND_ERP), sin la evidencia caso por caso de cada pantalla. La certificación de HT_PRE_007 adaptó sobre la marcha la plantilla de backend, y en esa adaptación salieron las reglas que este ADR fija.
Lo que mostró esa certificación:
| Hallazgo | Por qué importa para el frontend |
|---|---|
| Nueve defectos de front que las pruebas unitarias no veían: rótulos del bienio, nombre precargado, aviso al eliminar, exportar sin filas, PDF que el servicio rechaza, archivo sin columnas, permisos por rol, menú con un solo producto | Solo aparecen con el menú, los roles, el catálogo y los servicios reales |
| Ocho defectos de backend, base de datos, i18n y menú encontrados desde la pantalla | La certificación de front es también la prueba de integración del backend |
| La pantalla no consultaba los permisos por rol, y la opción no tenía su mapa de acciones | Los casos de permisos requieren usuarios de un solo rol y una configuración de menú verificada |
| El diseño de la HU y el motor 3.0 no siempre coinciden | Hace falta una regla de qué prevalece para no fallar casos por diferencias que el motor resuelve a propósito |
| Las compañías de prueba eran visibles para todo el cliente Centrica | Una certificación larga se contamina sin un cliente aparte |
CERTIFICACION_FRONT.md, en la misma carpeta que la certificación de backend (ADR-018 §3.2). Su evidencia va en evidencias/front/.nx serve nebula-shell, puerto 4200, un solo puerto) contra el backend desplegado en DEV (api-dev). El front no se certifica contra mocks ni contra un backend local.feat/bloque-AAAA-MM-DD). Cada corrección de la certificación es un commit propio, con build de nebula-shell y pruebas en verde, y se lista en §6 del documento.Las mismas diez secciones obligatorias del ADR-018 §3.3. Ninguna se elimina: si no aplica, se escribe por qué.
| # | Sección | En el frontend |
|---|---|---|
| 1 | Identificación y build certificado | HT y HU; pantalla con su ruta y su opción de menú; servicio que consume; ambiente (front local contra api-dev); cliente, compañía y usuarios de prueba; rama y HEAD del front, versión del kit, versión del backend y scripts de menú aplicados |
| 2 | Alcance entregado | Tabla proceso de la pantalla · endpoint que consume · regla que cubre; decisiones tomadas con quién y cuándo; desviaciones respecto a la HU, incluidas las que resuelve el motor (§3.5) |
| 3 | Configuración aplicada | Parámetros y maestros de la compañía de prueba con su porqué; permisos por rol: opción de menú, mapa de acciones de la opción y acciones por rol del cliente |
| 4 | DDL e i18n aplicados | El front no tiene DDL. Se listan las claves i18n que pidió la pantalla, con su script, y las constantes del front que las usan |
| 5 | Pruebas ejecutadas | La matriz de casos (§3.3), los rechazos con el mensaje que mostró la pantalla, las pruebas unitarias del front y el build. SAR no aplica al front y se dice |
| 6 | Defectos que las unitarias NO vieron | Dos tablas: de front, corregidos con su commit; de backend, base de datos, i18n o menú, reportados a la sesión de backend con su corrección |
| 7 | Lo que NO se puede probar y por qué | Alcance, motivo y cuándo se podrá |
| 8 | Cómo reproducir en QA | Qué front y qué backend llevar, qué scripts de menú e i18n aplicar antes, qué compañía y qué usuarios usar, y el orden de los bloques |
| 9 | Datos sembrados que quedan | Lo que la certificación creó, modificó o dejó como capa de certificación |
| 10 | PENDIENTE | Deuda de HT, scripts pendientes en QA y observaciones de UX del motor y del kit que no se cambiaron por orden |
Una fila por caso de prueba de la HT, todos, sin excepción:
| CP | CA | RN | Flujo | Operación | Resultado | Experiencia | Veredicto | Evidencia |
|---|---|---|---|---|---|---|---|---|
| caso | criterio de aceptación | regla | lo que hace el usuario | endpoint que se llama, o «front» | lo verificado | lectura de uso contra el Manual 3.0 y el motor | §3.4 | archivos CP-NN_* |
Los casos se recorren por bloques (B1, B2, …) en el orden de la HT. Al cerrar cada bloque se informan a la sesión de backend los veredictos y los datos creados, con su id.
| Veredicto | Significa |
|---|---|
| CUMPLE | Verificado en la pantalla y contra el servicio |
| NO CUMPLE | Defecto de front abierto |
| EN CORRECCIÓN BACKEND | Defecto de backend, base de datos, i18n o menú, reportado y en corrección. Se repite el caso cuando se despliegue |
| EN PREPARACIÓN | Falta un dato, un usuario o una configuración para probarlo. No es un fallo |
| OBSERVADO | Cumple, con una diferencia de experiencia que decide Carlos |
El veredicto final es CERTIFICADA solo con todos los casos en CUMPLE. Una deuda de HT —algo que la HU pide y la HT no trae— se declara en §10 y no cuenta como caso fallido.
Igual que el backend (ADR-018 §3.8):
certificacion.total para operar, certificacion.consulta para lo que no se puede crear, certificacion.operador para los límites por acción y certificacion.sinacceso para el acceso denegado.gateActionsByPermissions). Antes de probarlos se verifica que la opción tenga su mapa de acciones (admin.option_action) y que cada rol tenga las suyas; sin el mapa, ningún rol recibe acciones.Van en evidencias/front/, con el prefijo del caso (CP-NN_):
| Evidencia | Cuándo |
|---|---|
Captura de pantalla CP-NN_*.jpg |
Cada caso con resultado visual. JPG de menos de 100 KB: el front certifica experiencia de uso. Es la excepción al límite de tres imágenes del ADR-018, decidida por Carlos el 15-oct-2026 |
Respuesta del servicio CP-NN_*.json |
Cada caso que lee o escribe: page-response, get-record, acciones por rol |
Archivo procesado CP-NN_*.csv |
Cada carga masiva: el archivo que se cargó, incluido el inválido a propósito |
Archivo devuelto CP-NN_*.csv / .xlsx |
Cada exportación y descarga de errores: el archivo que generó la pantalla o el servicio |
Estado del DOM CP-NN_*.json |
Cuando el hecho es un estado del componente (por ejemplo, un interruptor deshabilitado) |
Banderas del servidor CP-NN_*.json |
Cuando la pantalla oculta o muestra una acción por una bandera del servicio (permiteEditar, permiteEliminar) |
No se suben videos, por la misma razón que en el backend. Los antecedentes de corridas previas que no forman parte del veredicto no se suben.
| Rol | Responsabilidad |
|---|---|
| Carlos (arquitecto) | Ordena la certificación, digita las claves, decide desviaciones, deuda y observaciones |
| Sesión de certificación de front | Recorre la matriz, corrige los defectos de front en la rama del bloque y produce el documento |
| Sesión de backend (sprint-11b) | Corrige y despliega los defectos de backend, base de datos, i18n y menú; crea las claves i18n; mantiene las compañías, usuarios, foto y capas de certificación |
| Gatekeeper de frontend | Revisa que el documento cumpla este ADR antes de llevar la pantalla a QA |
| Alternativa | Por qué no |
|---|---|
| Que cada pantalla use la plantilla de backend tal cual | Sus secciones de DDL, SAR y verificación en base no aplican a una pantalla, y no tiene matriz de casos, usuarios por alcance ni veredictos de integración |
| Certificar con pruebas unitarias o E2E | El ADR-014 cubre las E2E, pero los nueve defectos de front de HT_PRE_007 dependían del menú, los roles y el catálogo reales del ambiente |
| Que el front corrija el backend | Rompe el reparto por responsabilidades y deja cambios de backend sin desplegar ni registrar |
| Fallar los casos donde el motor difiere de la HU | El motor y el Manual 3.0 son la fuente del diseño; fallarlos obligaría a romper el estándar en cada pantalla |
| Grabar video de cada caso | El repositorio es permanente; una captura liviana y la respuesta del servicio prueban lo mismo y se pueden revisar en un MR |
Positivas
Costos
| Versión | Fecha | Autor | Descripción |
|---|---|---|---|
| 1.0.0 | 2026-10-15 | Carlos Torres | Versión inicial, derivada del ADR-018 y de la certificación de HT_PRE_007 del 14 y 15-oct-2026: diez secciones adaptadas a la pantalla, matriz de casos, veredictos, qué prevalece entre el motor y la HU, compañía por perfil y usuarios por alcance en el cliente 9, coordinación con el backend y evidencias del front. Incluye la socialización para el equipo. |