TEMPLATE_CERTIFICACION_ENTREGA.md define qué se escribe. Este documento define qué se
adjunta, y la diferencia importa: una certificación que afirma «la importación funciona» sin el
archivo que se importó no es evidencia, es un testimonio.
Sale de analizar las cinco certificaciones producidas hasta hoy —HT_CON_023, HT_CON_024,
HT_PRE_006, HT_PRE_007 y HT_PRE_011—, no de un diseño previo. Las tres evidencias numeradas
aparecen en las cinco; las demás aparecen según lo que la HT hace.
Regla de oro. La evidencia se produce contra el ambiente, nunca a mano. Un archivo que
alguien escribió para que se viera bien no es evidencia de nada.
architecture es un repositorio GitLab, y su historia es permanente: lo que entra, pesa para
siempre en cada clone.
| Regla | |
|---|---|
Video (.mp4, .mov, .gif animado, grabación de pantalla) |
PROHIBIDO, sin excepción |
Imagen (.png) |
Solo cuando el hecho no se puede expresar en texto — un render, un layout. Máximo 300 KB por archivo y 3 por HT. Si hay que explicar la imagen con un pie de foto, el pie de foto era la evidencia |
Texto (.txt, .csv, .json, .sql, .md) |
La forma por defecto. Se diffea, se busca con grep y se revisa en un MR |
Binario producido por el sistema (.xlsx, .pdf) |
Solo si la HT lo genera y su contenido no se puede expresar en CSV. Máximo 1 MB |
Un backend no necesita video. Lo que un video mostraría —que la operación respondió, que el dato
quedó escrito— se prueba mejor con la traza HTTP y la consulta a la base, que además son
verificables por un tercero.
Van en las cinco certificaciones existentes y son obligatorias en toda HT, sin importar su alcance.
Se numeran porque son la columna vertebral del expediente.
| Archivo | Qué contiene | Cómo se produce |
|---|---|---|
01_certificacion.txt |
La corrida completa: un bloque por caso (TC-01, TC-02, …) con el HTTP, los datos devueltos y, en los que escriben, un bloque --- verificacion EN BASE --- |
Ejecutando contra api-dev, redirigiendo la salida a archivo |
02_base_datos.txt |
Los objetos del DDL con su STATUS, los tablespaces, los índices columna a columna, la nulabilidad de lo que se alteró, los GRANT y el conteo de claves i18n con sus traducciones |
sqlplus contra el diccionario (all_objects, all_tab_columns, all_ind_columns, all_tab_privs) y psql contra admin.translation_keys |
03_diagnostico_sar.txt |
El veredicto de SAR y el reporte completo: matriz de aserciones, reglas dinámicas y el criterio de cada WARN | sar-diagnose --branch develop, volcando el reporte |
Si SAR no se corrió, se dice. No se omite el archivo.
01_certificacion.txtCinco líneas, y las cinco importan. Sin ellas la traza no es reproducible:
CERTIFICACION HT_XXX_NNN - <Nombre>
Ejecutada contra api-dev (servicio desplegado, no local).
Ambiente DEV - tenant company_id=N - Oracle XE 21c XEPDB1 - Postgres simappe_admin
Los conteos se verifican EN BASE, no en la respuesta HTTP.
Fecha: AAAA-MM-DD HH:MM:SS ZZZ
Cuando la HT depende de datos concretos, se nombran ahí mismo — HT_CON_024 lo hace bien:
cuenta bancaria 876-AH-2222 / banco 87-AH-4898 / cuenta contable 12250 / periodo 202604.
Se adjuntan las que apliquen. Un alcance que la HT no tiene no genera archivo, y eso no se
justifica: se nota en que no está.
<entidad>_import.csvProducidas: conceptos_import.csv, extracto_carga.csv, catalogo_import_qa.csv,
rubros_import.csv, detalle_import.csv.
No basta el archivo feliz. Se adjunta uno por cada comportamiento que la regla promete:
| Archivo | Qué prueba |
|---|---|
<entidad>_import.csv |
El camino normal: las filas válidas se incorporan |
<entidad>_import_mixto.csv |
Una fila inválida NO tumba el lote. Lleva válidas e inválidas mezcladas |
<entidad>_import_<rechazo>.csv |
Un rechazo concreto y nombrado: dup.csv para el duplicado, detalle_import_repetido.csv para el que ya existe |
El archivo del rechazo debe llevar un valor que delate la sobrescritura. En HT_PRE_011,
detalle_import_repetido.csv trae 999000 para un rubro que ya valía 300000: así la consulta en
base prueba que no se sobrescribió, en vez de solo afirmarlo. Un archivo con el mismo valor no
habría probado nada.
En la traza, cada import muestra el summary completo y cada error con su línea, su campo y su
regla.
<entidad>_export.csvProducidas: catalogo_export_qa.csv, listado_export.csv.
Es el archivo que devolvió el endpoint, guardado tal cual con -o. Nunca uno equivalente
escrito a mano.
Sirve además como prueba de i18n end-to-end: si la primera fila trae Ingreso, Adición y
Borrador en vez de budget.…tipoPresupuesto.ingreso, las etiquetas están resueltas. Ese hallazgo
apareció así, no probando i18n de frente.
04_saldos_antes_despues.txtFalta en el corpus. Ninguna HT certificada hasta hoy afecta saldos: HT_PRE_011 es elaboración y
RN-ALC1-13 dice literalmente que no los toca. Las de aprobación del sprint-10 sí, y necesitan:
Sin las tres lecturas la evidencia no prueba nada: un saldo correcto por casualidad se ve igual que
uno correcto por construcción.
01_certificacion.txtToda operación que procesa varios documentos en una llamada declara, documento por documento, cuál
entró y cuál no:
=== TC-NN aprobacion en lote (N documentos) ===
HTTP 200
procesados=N aprobados=X noDisponibles=Y
id=1001 -> APROBADO
id=1002 -> excluido: <motivo que devolvio el servicio>
--- verificacion EN BASE ---
estados reales tras el lote: ...
Un conteo agregado no es evidencia de un lote: no distingue «dos aprobados» de «uno aprobado dos
veces».
05_reversion.txtFalta en el corpus. Lo que hay que probar no es que el documento quedó anulado, sino que lo
que escribió quedó deshecho: el estado antes, el estado después, y el acumulador que había
movido, de vuelta en su valor previo. Si la HT declara que algo NO se revierte —porque nunca se
escribió— eso también se prueba, mostrando que la columna sigue igual.
06_cliente_compartido.txtFalta en el corpus. Cuando la HT lee de otro módulo por WebClient, se adjunta la traza de la
llamada real: el recurso invocado, el dato que devolvió y el dato con el que la regla lo comparó.
Y si el proveedor no tiene dato —el caso de los faltantes declarados—, se prueba que la operación
procede con el valor en cero en lugar de romperse. Eso es justo lo que un faltante declarado
promete.
01_certificacion.txtSe prueba con dos emisiones consecutivas, mostrando el número de cada una y que la segunda es la
siguiente. Si la serie reinicia por vigencia, se prueba el reinicio. Si la emisión es idempotente, se
repite la llamada con la misma clave y se muestra que devuelve el mismo número, no el siguiente.
07_multitenant.txtFalta en el corpus. Toda consulta de negocio es nativa y filtra por tenant. Se prueba pidiendo el
mismo recurso con dos compañías distintas y mostrando que cada una ve lo suyo. Basta un caso por
HT, sobre el listado.
08_descarga.txtFalta en el corpus. Para lo que sale como byte[], la evidencia es textual: el HTTP, el
Content-Type, el Content-Disposition con el nombre resuelto, el tamaño en bytes y el sha256 del
archivo. Se adjunta el binario solo si pesa menos de 1 MB.
Aquí es donde alguien pediría un video. No se sube. El checksum prueba más: identifica el archivo
exacto y se puede volver a calcular.
NN_certificacion_<tema>.txtProducidas: 04_certificacion_cpc_cuipo_fut.txt, 05_certificacion_update_calificadores.txt.
Cuando se cierra algo que la entrega original dejó fuera, no se reescribe la traza anterior: se
agrega un archivo nuevo con el siguiente número, y su cabecera dice qué complementa y de qué fecha.
La certificación principal lo referencia en §5.
| Si la HT… | Adjunta |
|---|---|
| Cualquiera | 01, 02, 03 |
| Importa un archivo | *_import.csv + *_mixto.csv + uno por rechazo nombrado |
| Exporta | *_export.csv, el que devolvió el endpoint |
| Mueve un acumulador | 04_saldos_antes_despues.txt |
| Procesa en lote | Detalle documento por documento en 01 |
| Anula o revierte | 05_reversion.txt |
| Lee de otro módulo | 06_cliente_compartido.txt |
| Emite consecutivo | Dos emisiones seguidas en 01 |
| Publica listado de negocio | 07_multitenant.txt |
| Devuelve un binario | 08_descarga.txt con sha256 |
| Cierra algo de una entrega previa | NN_certificacion_<tema>.txt |
Todos ocurrieron de verdad. Se listan para que no se repitan.
api-dev. Pasó en HT_PRE_006 y en la primeraHT_PRE_011. Un servicio local puede resolver una dependencia que el desplegadoHT_PRE_011 describía la200. Un 200 no prueba que el dato quedó escrito, ni que quedó bien. EnHT_PRE_011 el import respondía 200 y VALIDATE anunciaba un resultado distinto del quePERSIST producía.HT_PRE_011| Ruta | |
|---|---|
| Plantilla del documento | architecture/nebula-erp/pipeline/templates/TEMPLATE_CERTIFICACION_ENTREGA.md |
| Este catálogo | wiki-arquitectura/zona-interna/14-entregas-qa/CATALOGO_EVIDENCIAS_CERTIFICACION.md |
| Certificación de una HT | architecture/sprint-N/entregas/HT_XXX_NNN_Nombre/CERTIFICACION_ENTREGA.md |
| Sus evidencias | architecture/sprint-N/entregas/HT_XXX_NNN_Nombre/evidencias/ |
| Ejemplo más completo | sprint-10/entregas/HT_PRE_011_ModificacionPresupuestalElaboracion/ — ocho evidencias, cinco de ellas datos procesados |
| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 1.0.0 | 2026-08-25 | Carlos Torres | Creacion del catalogo. La plantilla definia QUE SE ESCRIBE y nada definia QUE SE ADJUNTA: la primera certificacion de HT_PRE_011 describia la importacion sin incluir un solo CSV. Sale de analizar las cinco certificaciones ya producidas --CON-023, CON-024, PRE-006, PRE-007 y PRE-011--, no de un diseño previo. Define las tres evidencias obligatorias, las que dependen del alcance, y seis tipos que el corpus todavia no produce y el sprint-10 va a necesitar: saldos antes y despues, reversion, cliente compartido, aislamiento multitenant, descarga binaria y el detalle documento por documento de las operaciones en lote. Deja escrita la restriccion del repositorio: architecture es GitLab y su historia es permanente, asi que NO SE SUBEN VIDEOS. |