develop. Está entregada cuando tiene su certificación: un documento CERTIFICACION_ENTREGA.md con evidencias producidas contra el ambiente DEV. Sin certificación no se declara entregada ni se cierra su work package.develop y desplegada en DEV. La certificación la ordena Carlos.architecture/sprint-N/entregas/HT_XXX_NNN_Nombre/CERTIFICACION_ENTREGA.md.api-dev), en la compañía de prueba que corresponde al perfil de la HT (§3.8).evidencias/ lo que pide §3.5: siempre 01, 02 y 03, y lo que dependa del alcance.sprint-10/entregas/HT_PRE_011_ModificacionPresupuestalElaboracion/ y sprint-9/entregas/HT_PRE_007_CreacionRubros/.ESTADO: Aprobado
FECHA: 2026-10-15
AUTOR: Carlos Alberto Torres Camargo (arquitecto)
ALCANCE: la certificación de entrega de cada HT de backend del ERP Nebula —servicios, scripts de base de datos, i18n y menú—: qué documento se produce, cuándo, con qué evidencias, contra qué ambiente y con qué datos de prueba
RELACIONADOS: ADR-003 Política formal de entrega a QA (§3.2.1, las dos actas), ADR-019 Certificación de entrega — Frontend, Entregas Backend, Plantilla, Catálogo de evidencias, Ejemplo HT_PRE_011, Definition of Done
IMPLEMENTACIÓN DE REFERENCIA: HT_PRE_011 (sprint-10, once evidencias, cinco de ellas datos procesados) y HT_PRE_007 (sprint-9, recertificada el 14 y 15-oct-2026 con backend nebula-budget-core 1.13.2 a 1.13.5)
La certificación por HT existe desde el 9-ago-2026, pero sus reglas quedaron repartidas en tres lugares: el comentario de la plantilla (architecture/nebula-erp/pipeline/templates/TEMPLATE_CERTIFICACION_ENTREGA.md v1.1.0), el catálogo de evidencias de la wiki (v1.0.0, 25-ago-2026) y el índice de entregas de backend (v1.2.0). Ninguna decisión de arquitectura las sostenía. El ADR-003 solo nombra la certificación en su §3.2.1 para distinguirla del QA_HANDOFF.md.
Cómo se llegó aquí:
| Fecha | Hecho |
|---|---|
| Sprint-8 | Dos documentos sueltos en auditorias/, de criterio distinto: EVIDENCIA_PRUEBAS_CIERRE_CONTABLE_CON_022.md (la corrida) y GUIA_QA_AMBIENTE_FACTURACION_FAT_004.md (el ambiente). Sin la configuración, QA no podía repetir la prueba; sin la prueba, no había evidencia |
| 9-ago-2026 | Se estandariza CERTIFICACION_ENTREGA.md, que fusiona las dos mitades |
| 25-ago-2026 | Catálogo de evidencias. La primera certificación de HT_PRE_011 describía una importación sin incluir un solo CSV: la plantilla decía qué se escribe y nada decía qué se adjunta |
| 14 y 15-oct-2026 | Certificación integral de HT_PRE_007 (backend y front). Salieron ocho defectos de backend, base de datos, i18n y menú que las pruebas unitarias no veían: vigencias de regalías, PAC desde enero, saldo huérfano al eliminar, dependencias sin validar en la carga masiva, error atribuido al campo equivocado, permisos cargados en la opción equivocada, opción sin mapa de acciones y el conteo de movimientos fijo en 0 |
La certificación de HT_PRE_007 dejó además dos lecciones que ningún documento recogía:
CERTIFICACION_ENTREGA.md cuando queda mergeada a develop y desplegada en DEV. Ese es el momento en que se asume entregada.QA_HANDOFF.md del sprint (ADR-003) mira hacia adelante, al lote que se promueve a QA, y se apoya en las certificaciones de sus HT; no las reemplaza.CERTIFICACION_ENTREGA.md |
QA_HANDOFF.md |
|
|---|---|---|
| Alcance | UNA HT | EL LOTE del sprint |
| Momento | Al quedar mergeada y desplegada en DEV | Antes de promover develop → qa |
| Dirección | Hacia atrás: evidencia de lo entregado | Hacia adelante: qué debe probar QA |
| Ubicación | architecture/sprint-N/entregas/HT_XXX_NNN_Nombre/ |
architecture/sprint-N/ |
| Owner | Quien implementa la HT | Backend Lead |
architecture/sprint-N/entregas/HT_XXX_NNN_Nombre/
├── CERTIFICACION_ENTREGA.md certificación de backend (este ADR)
├── CERTIFICACION_FRONT.md certificación de frontend (ADR-019), si la HT tiene pantalla
└── evidencias/
├── 01_certificacion.txt
├── 02_base_datos.txt
├── 03_diagnostico_sar.txt
├── <entidad>_import.csv, <entidad>_export.csv, ...
└── front/ evidencias del frontend (ADR-019)
La plantilla canónica es architecture/nebula-erp/pipeline/templates/TEMPLATE_CERTIFICACION_ENTREGA.md; la wiki publica una copia literal en TEMPLATE_CERTIFICACION_ENTREGA. Ninguna sección se elimina: si no aplica, se escribe por qué no aplica.
| # | Sección | Qué resuelve |
|---|---|---|
| 1 | Identificación y build certificado | HT y HU, work package, servicio y esquema, ambiente, tenant de prueba, fecha, responsable. Versiones, MR y merge commits: las librerías antes que sus consumidores, con la publicación en Nexus verificada |
| 2 | Alcance entregado | Endpoints o procesos con la regla que cubren; decisiones de arquitectura con su porqué; desviaciones respecto al SDD (incluidas las @SARContractDeviation) |
| 3 | Configuración aplicada | Maestros y parámetros con el porqué de cada valor (sin él, QA no sabe qué puede cambiar); permisos y configuración de base |
| 4 | DDL e i18n aplicados | Scripts del repositorio nebula-erp-scripts-db-i18n, estado de los objetos, índices fuera de su tablespace, claves i18n sin par ES/EN |
| 5 | Pruebas ejecutadas | Caso, qué se verificó y resultado; rechazos de negocio con el mensaje que devuelve el servicio; diagnóstico SAR; pruebas unitarias; lista de archivos de evidencia |
| 6 | Defectos que las unitarias NO vieron | Los que solo aparecen contra el ambiente: qué era, por qué las unitarias no podían verlo y si quedó corregido o abierto |
| 7 | Lo que NO se puede probar y por qué | Alcance, motivo y cuándo se podrá |
| 8 | Cómo reproducir en QA | Scripts en orden, datos mínimos y flujo de la prueba |
| 9 | Datos sembrados que quedan | Lo que queda en DEV para QA y para el siguiente sprint |
| 10 | PENDIENTE | Qué falta, qué requiere decisión y deuda documentada |
200 no prueba que el dato quedó bien escrito.api-dev), no contra un servicio local. Si no se puede, se declara como desviación y se recertifica.Siempre, numeradas:
| Archivo | Contenido | Cómo se produce |
|---|---|---|
01_certificacion.txt |
La corrida: un bloque por caso con el HTTP, los datos devueltos y, en los que escriben, un bloque --- verificacion EN BASE --- |
Ejecutando contra api-dev y redirigiendo la salida |
02_base_datos.txt |
Objetos del DDL con su STATUS, tablespaces, índices, nulabilidad de lo alterado, GRANT y conteo de claves i18n con sus traducciones |
sqlplus contra el diccionario y psql contra admin.translation_keys |
03_diagnostico_sar.txt |
Veredicto y reporte completo de SAR, con el criterio de cada WARN | sar-diagnose --branch develop. Si SAR no se corrió, se dice; el archivo no se omite |
La cabecera de 01_certificacion.txt lleva cinco líneas: HT y nombre, ambiente contra el que se ejecutó, tenant y bases, la frase «Los conteos se verifican EN BASE» y la fecha con zona.
Según el alcance de la HT:
| Si la HT… | Adjunta |
|---|---|
| Importa un archivo | *_import.csv (camino normal), *_import_mixto.csv (una fila inválida no tumba el lote) y uno por cada rechazo nombrado. El archivo del rechazo lleva un valor que delate la sobrescritura |
| Exporta | *_export.csv: el archivo que devolvió el endpoint, guardado tal cual |
| Mueve un acumulador | 04_saldos_antes_despues.txt: antes, operación, después y la diferencia comparada contra el documento |
| Procesa en lote | El detalle documento por documento dentro de 01 |
| Anula o revierte | 05_reversion.txt: el estado y el acumulador, de vuelta en su valor previo |
| Lee de otro módulo | 06_cliente_compartido.txt: la llamada real, el dato devuelto y el dato contra el que se comparó |
| Emite consecutivo | Dos emisiones seguidas dentro de 01 |
| Publica un listado de negocio | 07_multitenant.txt: el mismo recurso con dos compañías distintas |
| Devuelve un binario | 08_descarga.txt: HTTP, Content-Type, Content-Disposition, tamaño y sha256 |
| Cierra algo de una entrega previa | NN_certificacion_<tema>.txt, con el siguiente número; no se reescribe la traza anterior |
El detalle de cada evidencia vive en el catálogo de evidencias.
architecture es GitLab y su historia es permanente: lo que entra pesa para siempre en cada clone.
| Tipo | Regla |
|---|---|
Video (.mp4, .mov, .gif animado, grabación de pantalla) |
Prohibido, sin excepción |
| Imagen | Solo si el hecho no se puede escribir. Máximo 300 KB por archivo y 3 por HT |
Texto (.txt, .csv, .json, .sql, .md) |
La forma por defecto |
Binario generado por la HT (.xlsx, .pdf) |
Solo si su contenido no se puede expresar en CSV. Máximo 1 MB |
nebula-budget-core 1.13.4 y 1.13.5 en HT_PRE_007), se despliega en DEV y el caso se repite. No se da por bueno con la prueba unitaria.nebula-erp-scripts-db-i18n, se registran en la auditoría y quedan listados en §4.NN_certificacion_<tema>.txt y un comentario nuevo en el work package; no se edita el anterior.Decisión de Carlos del 15-oct-2026 («cliente aparte»; «lo importante es que se pueda certificar todo»):
nebula-erp-scripts-db-i18n/docs/PROCEDIMIENTO_FOTOS.md §1.certificacion.total, certificacion.operador, certificacion.consulta, certificacion.sinacceso). Si una HT necesita otro alcance (aprobar, anular), se agrega un usuario y se documenta.nebula-erp-scripts-db-i18n/fotos/), que se verifica y se restaura con herramientas/foto.py. Lo que una certificación siembra para un caso concreto va como capa de certificación: un script propio, aplicado encima de la foto y listado en §9.El work package pasa por Nuevo → En curso → En prueba → Por mergear → Cerrado, al quedar mergeado y desplegado. El comentario de cierre lleva seis secciones fijas: merges, qué quedó, certificación en runtime, defectos que la suite unitaria no podía ver, ruta del CERTIFICACION_ENTREGA.md y PENDIENTE.
| Rol | Responsabilidad |
|---|---|
| Carlos (arquitecto) | Ordena la certificación, decide las desviaciones y la deuda, y acepta el veredicto |
| Quien implementa la HT | Produce la certificación y sus evidencias contra DEV |
| Sesión de backend (sprint-11b) | Corrige y despliega los defectos de backend, base de datos, i18n y menú que salgan, y crea las claves i18n en DEV y QA |
| Backend Lead | Arma el QA_HANDOFF.md del lote sobre las certificaciones (ADR-003) |
| Alternativa | Por qué no |
|---|---|
Dar por entregada una HT al mergear a develop |
Es lo que había antes del sprint-8: nadie podía saber qué se probó ni cómo repetirlo. En HT_PRE_007 aparecieron ocho defectos con el código ya en develop |
| Dejar las reglas en la plantilla y en la wiki, sin ADR | Las reglas existían pero nada las hacía obligatorias, y el frontend no tenía equivalente |
| Probar con mocks o contra un servicio local | Un servicio local puede resolver una dependencia que el desplegado no tiene. Los defectos de HT_PRE_007 solo aparecían contra la base y la caché reales |
| Certificar en las compañías del cliente Centrica | Todos los usuarios del cliente las veían; una prueba larga se contamina y los casos de permisos no se pueden probar |
| Evidencia en video | El repositorio es permanente. Un checksum, una traza HTTP y una consulta a la base prueban más y se pueden volver a verificar |
Positivas
Costos
| Versión | Fecha | Autor | Descripción |
|---|---|---|---|
| 1.0.0 | 2026-10-15 | Carlos Torres | Versión inicial. Reúne en una decisión la plantilla (v1.1.0), el catálogo de evidencias (v1.0.0) y el índice de entregas (v1.2.0), con las lecciones de la certificación de HT_PRE_007 del 14 y 15-oct-2026: recertificar cada corrección desplegada, revisar la caché de mensajes y certificar en el cliente 9 con compañías por perfil, usuarios por alcance, foto de procesos y capas de certificación. Incluye la socialización para el equipo. |