Estado: NORMATIVO. Documento 02 del proyecto-patron canonico de feature backend.
Audiencia: equipo de fabrica (desarrolladores backend).
Alcance: desde la llegada de la HT hasta el diseno (HTU) listo para construir. La construccion del codigo se trata en 03_CONSTRUCCION_POR_CAPAS.md.
Una feature backend no arranca cuando llega la HT, sino antes: cuando llega el insumo (HU V2 aprobada o V1 cruda + anexos). Ese insumo pasa por un gate de ENTRADA; solo si es viable se genera la HTU; y la HTU generada pasa por un gate de SALIDA (audit-htu) antes de poder construirse o entregarse.
Fuente: pipeline/prompts/PROMPT_GATE_ENTRADA_VIABILIDAD.md (v1.0, 2026-06-01).
Es OBLIGATORIO. Cita literal del documento: "PROHIBIDO iniciar la generacion de una HT sin haber ejecutado este gate y registrado su veredicto."
Audita la viabilidad del insumo (calidad/consistencia de la HU), NO la viabilidad de mercado y NO la HT generada. Antes de evaluar, el orquestador construye un mapa del estado entregado (paso 0, NO DELEGABLE): lee las HTs de sprints previos y el codigo real para mapear entidades, campos, estados, catalogos, tipos y parametros ya existentes, porque "Es un ERP: todo esta hilado, las HU de Sprint-N consumen lo entregado en Sprint-0..N-1."
Las 7 dimensiones evaluadas:
Rubrica de ponderacion (0 a 100):
| Criterio | Peso |
|---|---|
| Explicitud de RN | 25% |
| Completitud campos ↔ wireframe | 20% |
| Casos de prueba presentes y usables | 15% |
| Coherencia RN ↔ CA | 15% |
| Autonomia / navegacion / modales | 15% |
| Consistencia de tipos / estados | 10% |
Veredicto:
| Score | Veredicto | Efecto |
|---|---|---|
| >= 80 | VIABLE | Procede a generar HT. |
| 60–79 | VIABLE CON AJUSTES | Procede SOLO si los bloqueantes CRITICOS se resuelven o se acuerdan supuestos firmados; los no criticos se marcan [pendiente validacion PO]. |
| < 60 | NO VIABLE | NO generar HT. Devolver a consultoria y reauditar tras correccion. |
Reglas adicionales del gate: insumo V1 (no V2 aprobada) tiene veredicto tope REQUIERE V1→V2 sin importar el score; un hallazgo CRITICO bloquea la generacion aunque el score global sea alto. Toda evidencia se cita literal con ubicacion exacta (regla INQUEBRANTABLE); sin cita literal + ubicacion, no se reporta. El reporte se entrega a consultoria en lenguaje FUNCIONAL, no tecnico.
Opera sobre la HTU ya generada. Verifica estructura y aserciones mecanicas (no contenido funcional). En el pipeline v8.0 es version-aware: lee htu.manifest.yaml, despacha por schema; para resources aplica ASR-08-LOSSLESS y delega las 7 aserciones probadas a v7.2.
Las 7 ASR del TRIPLE-LOCK + la asercion lossless:
| ASR | Verifica |
|---|---|
| ASR-00-001 | Matriz de Cobertura de Campos en README (o 00_Coverage.md). |
| ASR-00-002 | Matriz de Cobertura de Procesos en 08_Contracts. |
| ASR-00-003 | Cero filas ❌ en matriz de campos. |
| ASR-00-004 | Cero filas ❌ en matriz de procesos. |
| ASR-00-005 | Cada fila ⚠️ tiene texto en Justificacion. |
| ASR-01-011 | Toda fila ✅ R-AUD-COV-01 con destino DTO/Entity tiene campo en 01_Model. |
| ASR-05-011 | Toda fila ✅ R-AUD-COV-02 con endpoint definido tiene endpoint en 08_Contracts. |
| ASR-08-LOSSLESS | Para cada artefacto con resources, NN/NN.md es copia byte-exacta de resources/body.md, o FAIL. |
Fuente: pipeline/v8.0/README.md. En v8.0 cada artefacto pasa de archivo plano a directorio. La garantia dura es: NN_Artefacto/NN_Artefacto.md == resources/body.md byte a byte (cero perdida). Lo estructurado se indexa para SAR, no sustituye la prosa.
NN_Artefacto/
NN_Artefacto.md # DERIVADO: copia byte-exacta de resources/body.md
resources/
body.md # CANONICO verbatim — la prosa NUNCA se regenera
structured.yaml # tablas/codigo extraidos (insumo SAR)
sar_view.yaml # (solo artefactos estructurados) vista tipada para SAR
README.md # PLANO en la raiz (autored, no directorio)
htu.manifest.yaml # estampa de version + inventario + rutas del gate
artifacts/sar/ # 4 YAML proyectados desde resources
| Artefacto | Que contiene | Tipado SAR |
|---|---|---|
| README (raiz) | Objetivo, alcances, decisiones de arquitectura, reuso del estado entregado, Matriz de Cobertura de Campos (R-AUD-COV-01). | no |
| 01_Model | Campos y entidades del dominio (DTO/Entity/record). | si (sar_view.yaml) |
| 02_Data | Datos: DDL, semillas. | si |
| 03_Rules | Reglas de negocio (RN). | si |
| 04_References | Referencias y reuso del estado entregado. | no |
| 05_Checklist | Checklist de la HT. | no |
| 06_Delivery | Frontera de entrega (handoff a frontend, etc.). | no |
| 07_TestCases | Casos de prueba derivados de los CA (Gherkin). | si |
| 08_Contracts | Contratos REST (endpoints) + Matriz de Cobertura de Procesos (R-AUD-COV-02). | si |
| 09_Simulator | Simulador / sandbox. | no |
| 10_TraceMatrix | Matriz de trazabilidad. | si |
htu.manifest.yamlEstampa de version + inventario + rutas del gate. Declara pipelineVersion, schema: resources, el inventario de artefactos con su md y resources, el bloque sar (4 YAML: contracts.openapi.yaml, seed.yaml, sandbox-responses.yaml, test-cases.yaml) y el bloque audit que le dice al gate donde estan las matrices: matrixCoverFields: README.md, matrixCoverProcess: 08_Contracts/08_Contracts.md, modelFile: 01_Model/01_Model.md.
artifacts/sar/Cuatro YAML proyectados desde resources (best-effort; lo no parseable queda pendiente), insumo del Simappe Api Runner (SAR). Nota: la proyeccion SAR esta diferida a fase posterior; las HT del bloque actual se generaron sin artifacts/sar poblado.
La HTU no se lee entera para construir; cada artefacto alimenta una capa distinta:
| Artefacto | Que extraer | Para que capa |
|---|---|---|
| 01_Model | Campos y entidades del dominio. | Entity + DTO/record + DDL. |
| 03_Rules | Reglas de negocio (RN): precondicion, proceso, postcondicion. | Componente de validacion (validar*) + Service. |
| 07_TestCases | Casos (CA → TC en Gherkin) con su traza. | Pruebas + cobertura. |
| 08_Contracts | Endpoints + matriz de Cobertura de Procesos (R-AUD-COV-02). | Controller + contrato REST. |
| README | Matriz de Cobertura de Campos (R-AUD-COV-01). | Verificacion campo↔modelo. |
Las matrices R-AUD-COV son el eje de verificacion: cada campo de la HU debe mapear a un destino en 01_Model (COV-01) y cada funcionalidad debe mapear a un endpoint en 08_Contracts (COV-02). Una fila ❌ rompe el gate.
Referencia transaccional canonica. Resultado de AUDIT_REPORT.json:
verdict: PASSauditHtuVersion: 8.0, schema: resourceslossless.pass: true — los 11 artefactos marcados lossless: true (ASR-08-LOSSLESS)legacy7.pass: true, exit 0. Las 7 ASR PASS (cita literal del reporte):HT_TES_002_Embargos → PASS (PASS=7, FAIL=0)
ASR-00-001: PASS — Matriz Cobertura de Campos en README (o 00_Coverage.md)
ASR-00-002: PASS — Matriz Cobertura de Procesos en 08_Contracts
ASR-00-003: PASS — Cero filas ❌ en matriz de campos
ASR-00-004: PASS — Cero filas ❌ en matriz de procesos
ASR-00-005: PASS — Cada fila ⚠️ tiene texto en Justificación
ASR-01-011: PASS — Toda fila ✅ R-AUD-COV-01 con destino DTO/Entity tiene campo en 01_Model
ASR-05-011: PASS — Toda fila ✅ R-AUD-COV-02 con endpoint definido tiene endpoint en 08_Contracts
08_ContractsBase path: /api/v1/embargos. ResponseEntity plano, HTTP 200 exito / 204 delete. El resumen de endpoints declara 9 rutas (incluye el probe /index de sistema y el listado de negocio /listado); la matriz de Cobertura de Procesos (R-AUD-COV-02) cubre 11 FN (9 por endpoint ✅, 2 ⚠️: UI/seguridad + egresos [pendiente]), con 0 ❌.
| # | Metodo | Path | Alcance |
|---|---|---|---|
| 1 | GET |
/api/v1/embargos/index |
Disponibilidad del servicio (sistema) |
| 1b | POST |
/api/v1/embargos/listado |
Listado por estado (paginado, ALC1) |
| 2 | GET |
/api/v1/embargos/read |
Consulta (acordeon) |
| 3 | POST |
/api/v1/embargos/create |
Registro |
| 4 | PATCH |
/api/v1/embargos/update |
Edicion (solo cuenta + estado) |
| 5 | POST |
/api/v1/embargos/levantar |
Levantamiento (estado → LEVANTADO) |
| 6 | DELETE |
/api/v1/embargos/delete |
Eliminacion fisica (ALC5) |
| 7 | GET |
/api/v1/embargos/terceros |
Buscador terceros activos |
| 8 | GET |
/api/v1/embargos/cuentas-contables |
Buscador cuenta movimiento |
Nota de conteo: el documento
08_Contractstitula la seccion 9 como "Resumen de endpoints" con 8 rutas. El enunciado de referencia menciona "9 endpoints"; en el cuerpo verificado de08_Contractsfiguran 8 rutas (1 GET index, 1 GET read, 1 POST create, 1 PATCH update, 1 POST levantar, 1 DELETE delete, 2 GET buscadores). Se reporta lo verificado verbatim.
07_TestCases y 08_ContractsTC-01..TC-20), Escenario, Esperado (con codigo HTTP y mensaje, p.ej. HTTP 200 · MSG-SUCCESS-001) y Traza al CA/RN. Casos sin CP explicito se marcan [derivado]; dependencias no resueltas se marcan [pendiente egresos]. Cierra con tabla de Cobertura CA→TC.409 ... (MSG-ERR-001)). Cierra con el "Resumen de endpoints" y la Matriz de Cobertura de Procesos (R-AUD-COV-02) con su resumen.| Documento | Por que |
|---|---|
| 03_CONSTRUCCION_POR_CAPAS.md | Siguiente paso: construir el codigo desde la HTU verificada. |
| 05_PRUEBAS_Y_CALIDAD.md | Como los casos de 07_TestCases se convierten en pruebas. |
02_DE_LA_HT_AL_DISENO_HTU.md — Patron canonico de feature backend — Nebula ERP / Centrica