Versión: 1.0
Fecha: 2026-05-11
Autor: Carlos Alberto Torres Camargo (arquitecto)
Documentos relacionados: ADR-003 Política Entrega QA, FLUJO_HT_A_PROD, GITFLOW_DETALLADO
Definir, de manera única y centralizada, los criterios que debe cumplir una Historia Técnica (HT) para considerarse "Done" en cada nivel del flujo de entrega:
develop (GATE-C).qa (GATE-D).main (GATE-G).Cualquier checklist en PR templates, HTU 05_Checklist.md, QA_HANDOFF.md o pipeline debe referenciar este documento, no duplicarlo.
develop (GATE-C)Una HT cumple DoD-DEV cuando todos los criterios siguientes son verdaderos. El Gatekeeper Backend verifica y aprueba el PR cuando es así.
feature/HT-CON-XXX-slug-descriptivo (ver GITFLOW_DETALLADO).develop (no a otra rama).feat:, fix:, refactor:, chore:, etc.).feat(causacion): HT-CON-012 implementa partida doble.System.out.println/console.log residuales.src/test/java/.../component/.develop después del merge.mvn clean verify SUCCESS sin warnings nuevos.feature/* SUCCESS (build + sonar; sin docker push ni deploy).develop post-merge SUCCESS (build + sonar + docker push + deploy nodo-01 DEV).05_Checklist.md con todas las casillas técnicas marcadas.08_Contracts.md actualizado (OpenAPI).02_Data.md actualizado y migración aplicada en V<N>__<nombre>.sql.[Unreleased] con la HT.@PreAuthorize o equivalente).@Valid, bean validation) en payloads.develop → qa (GATE-D)Un lote (conjunto de HTs del sprint) cumple DoD-QA cuando todos los criterios siguientes son verdaderos. El Backend Lead produce el QA_HANDOFF.md, el Arquitecto revisa y firma el GATE-D antes del MR.
develop con DoD-DEV cumplido.QA_HANDOFF.md sección "No entra".develop (parcialmente implementadas pero sin closing).architecture/sprint-N/QA_HANDOFF.md completado siguiendo plantilla QA_HANDOFF_TEMPLATE.md.architecture/sprint-N/postman/ con collection completa para las HTs del lote.architecture/sprint-N/data-fixtures/ con SQL seed si las HTs lo requieren.architecture/sprint-N/regression-suite.md (si aplica) — lista de casos previos a re-validar para asegurar no-regresión.develop con último commit SUCCESS en Jenkins.10.110.0.2:5000 con tag develop-<sha>-<build#> y latest-dev.v0.X.0-rc1).tenant_qa_01 configurado y accesible.nebula-erp frontend repo o mail al Sr. Frontend).QA_HANDOFF.md referencia el folder htu/HT_CON_XXX_*/ para cada una.QA_HANDOFF.md lista commits clave (al menos los merges a develop).qa → main (GATE-G)Un lote cumple DoD-PROD cuando todos los criterios siguientes son verdaderos. El Arquitecto firma el GATE-G y autoriza el merge a main + tag SemVer.
architecture/sprint-N/QA_CLOSURE.md firmado por QA Lead con decisión APROBAR (o APROBAR CON DEUDA documentada).architecture/sprint-N/QA_EXECUTION_REPORT.md completo, con matriz casos vs resultado.QA_CLOSURE.md.GITFLOW_DETALLADO).pom.xml de cada repo del lote bumpeado: sin -SNAPSHOT.[Unreleased] se convierte en [vX.Y.Z] con fecha.architecture/sprint-N/RELEASE_NOTES.md con resumen para stakeholders (PO, gerencia, clientes).QA_CLOSURE.md + en Jenkins UI (input manual del stage Deploy PROD).Para hotfixes urgentes (incidentes en PROD) o exploratorios cortos, aplica un DoD reducido:
| Tipo | DoD-DEV reducido | DoD-QA reducido | DoD-PROD |
|---|---|---|---|
Hotfix PROD (hotfix/* branch) |
Test específico del bug + Sonar QG verde | Casos críticos del flujo afectado + smoke test | Mismo DoD-PROD pleno (no se reduce) |
| Exploratorio (spike, no productivo) | N/A — no se mergea a develop | N/A | N/A |
El uso de fast-track requiere justificación documentada en el commit ([FAST-TRACK] hotfix: ...) y notificación inmediata al Arquitecto.
| Criterio | Verificación automática | Verificación manual |
|---|---|---|
| Cobertura tests, Sonar QG, build verde | Pipeline Jenkins + Sonar | - |
| Conventional Commits, branch naming | Pre-receive hook GitLab (futuro) | Gatekeeper en PR review |
| HTU checklist, Postman, CHANGELOG | - | Gatekeeper en PR review (DEV); Backend Lead en GATE-D |
| Datos seed, ambiente QA | - | Backend Lead en GATE-D |
| QA_CLOSURE firmado | - | Arquitecto en GATE-G |
El plan a futuro (post ADR-003 aprobado) es automatizar más verificaciones del DoD-QA via stage Verify QA_HANDOFF en el pipeline.
| Versión | Fecha | Autor | Cambio |
|---|---|---|---|
| 1.0 | 2026-05-11 | Carlos Torres | Versión inicial. Consolida criterios dispersos en PR template, HTU checklist y GITFLOW_DETALLADO. Estructura 3 niveles (DoD-DEV, DoD-QA, DoD-PROD). |