CERTIFICACION_ENTREGA.mdLa plantilla vive en architecture/nebula-erp/pipeline/templates/TEMPLATE_CERTIFICACION_ENTREGA.md,
donde el equipo no la ve. Esta página la publica literal, para leerla y copiarla.
Se copia el bloque completo de la §2 a
architecture/sprint-N/entregas/HT_XXX_NNN_Nombre/CERTIFICACION_ENTREGA.md y se diligencia.
Las diez secciones marcadas (OBLIGATORIA) no se eliminan: si una no aplica, se escribe por qué
no aplica.
Qué se ESCRIBE lo define esta plantilla. Qué se ADJUNTA lo define
CATALOGO_EVIDENCIAS_CERTIFICACION, que lista las tres
evidencias obligatorias, las que dependen del alcance de la HT y la restricción del repositorio:
architecture es GitLab y no recibe videos.
La fuente canónica es el repositorio, no esta página. Editar aquí no cambia la plantilla que
usa la fábrica.
<!--
=============================================================================
TEMPLATE — CERTIFICACION_ENTREGA.md (evidencia de UNA HT entregada)
=============================================================================
Ubicación: sprint-N/entregas/HT_XXX_NNN_Nombre/CERTIFICACION_ENTREGA.md
sprint-N/entregas/HT_XXX_NNN_Nombre/evidencias/ (payloads, SQL, salidas)
UNO POR HT. Se produce cuando la HT queda MERGEADA A DEVELOP Y DESPLEGADA EN
DEV, que es el momento en que se asume entregada. Sin este documento la HT no
se declara entregada ni se cierra su work package.
NO CONFUNDIR con `sprint-N/QA_HANDOFF.md` (ADR-003), que es OTRO artefacto:
aquel es POR SPRINT, describe el LOTE que se promueve `develop -> qa` y mira
hacia ADELANTE (qué debe probar QA). Este es POR HT, mira hacia ATRÁS y prueba
lo que ya se entregó a dev. El QA_HANDOFF del lote se apoya en estas
certificaciones; no las reemplaza.
Origen del formato: estandariza lo que se hizo suelto en sprint-8
(EVIDENCIA_PRUEBAS_CIERRE_CONTABLE_CON_022.md documentaba la CORRIDA y
GUIA_QA_AMBIENTE_FACTURACION_FAT_004.md documentaba el AMBIENTE). Este
documento fusiona las dos mitades: sin la configuración QA no puede repetir la
prueba, y sin la prueba no hay evidencia de que lo entregado funcione.
REGLAS DE DILIGENCIAMIENTO
1. Todo dato es VERIFICADO, no esperado. Si no se ejecutó, se dice que no se
ejecutó; no se escribe lo que "debería" pasar.
2. Las pruebas se verifican EN BASE, no en la respuesta HTTP. Un 200 no
prueba que el dato quedó bien escrito.
3. La sección de defectos que las unitarias no vieron es OBLIGATORIA. Si no
hubo, se escribe "ninguno" — pero se escribe. En las últimas entregas
siempre hubo, y son el mayor valor del documento.
4. Lo que NO se pudo probar se declara. Un alcance silenciado es un defecto
que QA descubre en el peor momento.
5. Los datos sembrados en dev se listan. QA y el siguiente sprint trabajan
sobre ese ambiente.
6. Sin secciones vacías: si una no aplica, se escribe por qué no aplica.
7. Lo que la HT procesó SE ADJUNTA. Una certificación que afirma "la
importación funciona" sin el archivo que se importó no es evidencia, es un
testimonio. La evidencia se produce CONTRA EL AMBIENTE, nunca a mano.
8. NO SE SUBEN VIDEOS: `architecture` es GitLab y su historia es permanente.
La evidencia es texto. Qué adjuntar según el alcance lo define el catálogo
de la wiki (zona-interna/14-entregas-qa/CATALOGO_EVIDENCIAS_CERTIFICACION.md).
Las secciones marcadas (OBLIGATORIA) no se eliminan.
=============================================================================
-->
# Certificación de entrega — `<NOMBRE DE LA HT>` (`HT_XXX_NNN`)
> Qué se ESCRIBE lo define este documento; qué se ADJUNTA, el
> `CATALOGO_EVIDENCIAS_CERTIFICACION` de la wiki.
## 1. Identificación (OBLIGATORIA)
| Campo | Valor |
|---|---|
| **HT / HU** | `HT_XXX_NNN` · `HU-XXX-NNN V<n>` |
| **Work package** | `#<id>` (OpenProject, sprint-N = versión `<id>`) |
| **Microservicio · esquema** | `<servicio>` · `<esquema>` |
| **Ambiente** | DEV · Oracle XE 21c `XEPDB1` · Postgres `simappe_admin` |
| **Tenant de prueba** | `client_id = <n>` · `company_id = <n>` · `subsidiary_id = <n o NULL>` |
| **Fecha de entrega** | `<dd-mmm-aaaa>` |
| **Responsable** | `<persona>` |
### Build certificado
| Repo | Versión | MR | Merge commit |
|---|---|---|---|
| `<libreria>` | `<x.y.z-SNAPSHOT>` | `!<n>` | `<sha>` |
| `<servicio>` | `<x.y.z-SNAPSHOT>` | `!<n>` | `<sha>` |
> Las librerías se mergean ANTES que sus consumidores y se espera la
> publicación en Nexus entre eslabón y eslabón. Indicar el timestamp del
> artefacto publicado y si se verificó borrando el `.m2` local.
## 2. Alcance entregado (OBLIGATORIA)
| Endpoint / proceso | Función | Regla que cubre |
|---|---|---|
### Decisiones de arquitectura tomadas
> Solo las que cambian el comportamiento o se apartan de lo que dice la HT, con
> su razón. Las que un tercero no podría deducir leyendo el código: pertenencia
> de entidades, resolución por código vs id, qué deriva el servidor.
### Desviaciones respecto al SDD
> Tabla explícita de lo que la HU contrató contra lo que se implementó. Incluye
> los renombres al patrón canónico de rutas y toda desviación anotada con
> `@SARContractDeviation`. Si no hubo, se escribe "ninguna" — pero se escribe.
| La HU contrató | Se implementó | Motivo |
|---|---|---|
## 3. Configuración aplicada (OBLIGATORIA)
> Lo que QA debe replicar. Por cada maestro o parámetro: qué se configuró, con
> qué valores y **por qué** — sin el porqué, QA no sabe qué puede cambiar.
| Maestro / parámetro | Valor aplicado | Por qué |
|---|---|---|
### Permisos y configuración de base
> Grants cross-esquema, usuarios, tablespaces. Si no hubo, decirlo.
## 4. DDL e i18n aplicados (OBLIGATORIA)
| Script | Objeto | Verificación |
|---|---|---|
- **Estado de los objetos:** `<VALID / INVALID>`
- **Índices fuera de su tablespace `*_INDEX`:** `<n>`
- **Claves i18n:** `<n>` × ES/EN · claves sin par: `<n>`
## 5. Pruebas ejecutadas (OBLIGATORIA)
> Verificadas EN BASE. Indicar contra qué se probó: servicio local pegado a dev,
> o api-dev tras el despliegue.
| # | Caso | Qué se verificó | Resultado |
|---|---|---|---|
### Rechazos de negocio
> El mensaje es el que DEVUELVE el servicio, no el que dice la HT: es la prueba
> de que el i18n resuelve contra la BD y la caché reales.
| Código | Escenario | HTTP | Mensaje |
|---|---|---|---|
### Diagnóstico SAR
> Veredicto y conteo (`PASS / FAIL / WARN / N-A`), los FAIL corregidos durante la
> entrega y el criterio aplicado a cada WARN que se deja abierto. Si no se corrió
> SAR sobre la HT, se dice que no se corrió.
- **Pruebas unitarias:** `<n>` en verde.
### Archivos de evidencia
> Listar **cada archivo de `evidencias/` con lo que contiene**. La carpeta sin
> esta lista no dice qué prueba cada cosa. Si falta alguno de los estándar, se
> declara cuál y por qué.
>
> QUÉ ADJUNTAR lo define el CATALOGO DE EVIDENCIAS de la wiki
> (`zona-interna/14-entregas-qa/CATALOGO_EVIDENCIAS_CERTIFICACION.md`). Resumen:
>
> SIEMPRE, las tres numeradas:
> 01_certificacion.txt la corrida, caso por caso, con verificación EN BASE
> 02_base_datos.txt objetos, tablespaces, índices, GRANT y conteo i18n
> 03_diagnostico_sar.txt veredicto y reporte completo de SAR
>
> SEGÚN EL ALCANCE:
> importa -> *_import.csv + *_mixto.csv + uno por rechazo nombrado
> exporta -> *_export.csv, el que DEVOLVIÓ el endpoint
> mueve un saldo -> 04_saldos_antes_despues.txt (antes, operación, después)
> procesa en lote -> detalle documento por documento dentro de 01
> anula o revierte -> 05_reversion.txt
> lee de otro módulo -> 06_cliente_compartido.txt
> emite consecutivo -> dos emisiones seguidas dentro de 01
> publica listado -> 07_multitenant.txt
> devuelve binario -> 08_descarga.txt con sha256
>
> NO SE SUBEN VIDEOS. `architecture` es GitLab y su historia es permanente.
> La evidencia es TEXTO. PNG solo si el hecho no se puede escribir: máx. 300 KB
> y 3 por HT. Para una descarga, el checksum prueba más que una grabación.
>
> El archivo de un rechazo debe llevar un valor que DELATE la sobrescritura:
> si el registro vale 300000, el archivo trae 999000, y así la consulta en base
> prueba que no se sobrescribió en vez de solo afirmarlo.
| Archivo | Contenido |
|---|---|
## 6. Defectos que las unitarias NO vieron (OBLIGATORIA)
> Los que solo aparecen contra el ambiente. Por cada uno: qué era, por qué las
> unitarias no podían verlo, y si quedó corregido o ABIERTO.
| # | Defecto | Por qué no lo veían las unitarias | Estado |
|---|---|---|---|
## 7. Lo que NO se puede probar y por qué (OBLIGATORIA)
| Alcance | Motivo | Cuándo se podrá |
|---|---|---|
## 8. Cómo reproducir en QA (OBLIGATORIA)
> Pasos ordenados y ejecutables: scripts a aplicar y en qué orden, datos
> mínimos a sembrar, y el flujo de la prueba.
## 9. Datos sembrados que quedan en el ambiente (OBLIGATORIA)
| Objeto | Identificación | Nota |
|---|---|---|
## 10. PENDIENTE (OBLIGATORIA)
> Qué falta, qué requiere decisión, y deuda documentada. Si no hay, se escribe
> "ninguno".
---
*Certificación de entrega — `HT_XXX_NNN` — Pipeline HTU v8.0 — Nebula ERP · Sprint-N.*
<!--
=============================================================================
CARPETA DE EVIDENCIAS — nombres estándar
=============================================================================
sprint-N/entregas/HT_XXX_NNN_Nombre/
├── CERTIFICACION_ENTREGA.md
└── evidencias/
├── 01_certificacion.txt traza de la corrida: cada caso con los valores
│ que devolvió el servicio y los rechazos con su
│ mensaje i18n real
├── 02_base_datos.txt objetos creados, tablespaces e i18n verificados
│ contra el ambiente; cierra con el residuo
├── 03_diagnostico_sar.txt veredicto de SAR con el criterio de cada WARN
└── *.csv archivos usados en import/export, incluyendo las
filas inválidas a propósito
Las evidencias se GENERAN contra el ambiente, nunca se redactan a mano: son la
traza de lo que respondió el servicio. Una evidencia que muestra un resultado
distinto al real es peor que no tenerla.
=============================================================================
-->
Un ejemplo ya diligenciado:
EJEMPLO_CERTIFICACION_HT_PRE_011
— la entrega completa del sprint-10, con el documento y sus once evidencias literales.
| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 1.1.0 | 2026-08-25 | Carlos Torres | El ejemplo diligenciado pasa a pagina propia --EJEMPLO_CERTIFICACION_HT_PRE_011-- y aqui queda su enlace. Embebido debajo de la plantilla confundia los tres artefactos: esta pagina es la PLANTILLA, y el ejemplo es otra cosa. |
| 1.0.0 | 2026-08-25 | Carlos Torres | Publicacion de la plantilla de certificacion en la wiki, literal y completa. Vivia solo en el repositorio nebula-erp, de modo que quien navegaba la wiki no la veia; ya habia precedente de publicar plantillas --las tres de 10-backlog-- y esta se habia quedado fuera. Se publica junto al Catalogo de Evidencias, que define que se adjunta segun el alcance de la HT. |