Version: 1.0 · Fecha: 2026-04-20
Documentar el sistema de validación automática + auditoría manual que cierra cada HU procesada por el pipeline. Garantiza que:
┌────────────────────────────────────────────────────────────┐
│ SALIDA DE FASE D: HU-<COD>-V2.docx │
└────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ CAPA 1 · VALIDACIÓN AUTOMÁTICA (E1-E4) │
│ │
│ 03_validate_v2.py │
│ │
│ E1 Trazabilidad grafo FN↔RN↔CA↔INT │
│ E2 Cobertura campos por INT │
│ E3 Cobertura semántica V1→V2 │
│ E4 Gherkin válido │
└──────────────────┬───────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ CAPA 2 · VALIDACIÓN SEMÁNTICA QA (E5) │
│ │
│ PROMPT_VALIDACION_HU.md · 7 dimensiones │
│ │
│ 1 Vinculación campo↔prototipo │
│ 2 Explicitud de RN │
│ 3 Consistencia tipos │
│ 4 Coherencia RN↔CA │
│ 5 Navegación y modales │
│ 6 Autonomía HU vs anexos │
│ 7 Conformidad estructural │
└──────────────────┬───────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ CAPA 3 · AUDITORÍA + FIRMA │
│ │
│ Log de ejecución con: │
│ - Versión del pipeline │
│ - Timestamps por fase │
│ - Checksums │
│ - Firmas del arquitecto (C4) y QA (E5) │
└──────────────────┬───────────────────────────────────┘
│
▼
HU APROBADA
(o devuelta a la fase fallida)
.venv/bin/python3 03_validate_v2.py <docx> \
--v1-yaml <extracted.yaml> \
--output <reporte.md>
Qué valida: cada nodo del grafo FN ↔ RN ↔ CA ↔ INT debe estar conectado.
Reglas:
Umbral: sin huérfanos no justificados.
Qué valida: cada INT con layout: tiene su tabla de especificación con todos los campos visibles.
Umbral: 100%.
Qué valida: todas las RN, CA y campos del V1 tienen equivalente en el V2 (por matching de tokens significativos).
Umbral: ≥ 85%.
Qué valida: cada CA tiene:
Dado al inicio.Cuando.Entonces.RN-ALCn-## y opcionalmente INT-ALCn-##.Umbral: ≥ 85%.
reporte_validacion.md:
# Reporte Fase E · HU-CON-013
## Resumen
| Validación | Resultado | ¿Pasa? |
|---|---|---|
| E1 Trazabilidad | Sin huérfanos | ✅ |
| E2 Cobertura campos | 100% (29/29) | ✅ |
| E3 Cobertura V1→V2 | 94% (17/18 RN) | ✅ |
| E4 Gherkin válido | 92% (23/25) | ✅ |
## Detalle E3 — faltantes
- RN09 ("Valor Recibido > 0") no detectada en V2. Verificar RN-ALC2-11.
## Detalle E4 — faltantes
- CA-ALC2-08 sin `Entonces`. Ajustar.
- CA-ALC2-22 sin `Y aplica RN-##`. Ajustar.
## Veredicto
REQUIERE AJUSTES MENORES (2 CA).
QA aplica el prompt de PROMPT_VALIDACION_HU.md al contenido del DOCX. El prompt cubre 7 dimensiones:
| # | Dimensión | Qué verifica |
|---|---|---|
| 1 | Vinculación campo-prototipo | Cada campo está ligado a un INT visible |
| 2 | Explicitud de RN | Cada RN tiene trigger + precondición + proceso + postcondición |
| 3 | Consistencia tipos | Tipos funcionales (no SQL), estados canónicos, booleanos uniformes |
| 4 | Coherencia RN↔CA | Todo RN tiene CA, todo CA referencia RN |
| 5 | Completitud navegación y modales | Cada modal tiene trigger, condiciones, comportamiento al cerrar |
| 6 | Autonomía HU vs anexos | La HU es autocontenida, los anexos solo complementan |
| 7 | Conformidad estructural | Sigue el formato V2 canónico (cabecera + descripción + alcances + anexos) |
| Estado | Severidad | Acción |
|---|---|---|
| CUMPLE | — | Aceptar |
| CUMPLE PARCIAL | BAJA | Aceptar con observación |
| CUMPLE PARCIAL | MEDIA | Aceptar con ajuste recomendado |
| CUMPLE PARCIAL | ALTA | Ajustar antes de aprobar |
| NO CUMPLE | CRÍTICA | Volver a fase C o D |
Cada ejecución del pipeline genera:
_pipeline_runs/HU-<COD>/YYYY-MM-DD_HHMMSS.log
# _pipeline_runs/HU-CON-013/2026-04-21_101530.log
pipeline:
version: "1.0"
nebula_visual_manual: "v1.4"
executor: "Claude Code · Carlos Torres"
entrada:
pdf_v1:
ruta: "/ruta/HU-CON-013-V1.pdf"
sha256: "abc123..."
tamaño_bytes: 4108578
anexo_flujo:
ruta: "/ruta/Anexo 1 HU-CON-013-V1 Flujo.pdf"
sha256: "def456..."
anexo_casos_prueba:
ruta: "/ruta/Anexo 2 CASOS DE PRUEBA HU-CON-013.pdf"
sha256: "ghi789..."
fases:
fase_a_extraccion:
inicio: "2026-04-21T10:15:30-05:00"
fin: "2026-04-21T10:16:02-05:00"
duracion_seg: 32
script: "01_extract_hu.sh + 02_parse_hu.py"
salida: "fase_A/extracted.yaml"
items_detectados:
campos_v1: 15
reglas_v1: 22
criterios_v1: 18
mockups: 6
fase_b_wireframes:
inicio: "2026-04-21T10:16:10-05:00"
fin: "2026-04-21T10:19:02-05:00"
duracion_seg: 172
modelo_llm: "claude-sonnet-4-6"
temperature: 0
salida: "fase_B/catalog-interfaces.yaml"
ints_detectados: 6
fase_c_mapeo:
inicio: "2026-04-21T10:19:15-05:00"
fin_llm: "2026-04-21T10:22:00-05:00"
gate_c4_inicio: "2026-04-21T10:22:05-05:00"
gate_c4_fin: "2026-04-21T10:42:30-05:00"
duracion_total_seg: 1395
gate_c4_duracion_seg: 1225
arquitecto_firma: "Carlos Torres"
items_ambiguos_resueltos: 4
decisiones_c4:
- item: "Campo '# Contrato'"
decision: "fuera-de-alcance"
- item: "RN17 validaciones guardar"
decision: "INT-03"
salida: "fase_C/mapping-approved.yaml"
fase_d_sintesis:
inicio: "2026-04-21T10:42:35-05:00"
fin_llm: "2026-04-21T10:44:10-05:00"
fin_script: "2026-04-21T10:44:18-05:00"
duracion_total_seg: 103
modelo_llm: "claude-opus-4-7"
salida_hu_spec: "hu_spec.yaml"
salida_docx:
ruta: "HU-CON-013-V2.docx"
sha256: "jkl012..."
tamaño_bytes: 625487
wireframes_generados: 6
fase_e_validacion:
inicio: "2026-04-21T10:44:20-05:00"
fin_auto: "2026-04-21T10:44:22-05:00"
fin_e5: "2026-04-21T10:50:15-05:00"
duracion_total_seg: 355
e1_trazabilidad: "PASS"
e2_cobertura_campos: "100% (21/21)"
e3_cobertura_semantica: "94%"
e4_gherkin_valido: "92%"
e5_7_dimensiones:
1_vinculacion: "CUMPLE"
2_explicitud_rn: "CUMPLE"
3_consistencia_tipos: "CUMPLE"
4_coherencia_rn_ca: "CUMPLE PARCIAL (MEDIA)"
5_navegacion: "CUMPLE"
6_autonomia: "CUMPLE"
7_conformidad: "CUMPLE"
qa_firma: "QA equipo Centrica"
veredicto: "REQUIERE AJUSTES MENORES"
resultados:
docx_entregable: "HU-CON-013-V2.docx"
pdf_generado: "(pendiente, export manual WPS)"
duracion_total_calendario_seg: 2087
tiempo_humano_seg: 1225
pipeline_idempotente: true
regenerable_desde_log: true
Dos firmas obligatorias:
Sin estas firmas, la HU no puede pasar a downstream.
El pipeline es idempotente: ejecutar dos veces con la misma entrada produce exactamente el mismo DOCX (mismo sha256).
Garantía técnica:
temperature=0.Prueba: regenerar la misma HU 3 veces y comparar checksums. Si los checksums difieren, es un bug y se reporta en Issues.
Con el log completo, se puede regenerar exactamente la misma HU meses después:
./replay_pipeline_run.sh _pipeline_runs/HU-CON-013/2026-04-21_101530.log
Esto reproduce:
temperature=0).Por qué es importante: auditoría legal, reproducibilidad científica, comparación histórica entre versiones del pipeline.
En _pipeline_runs/, se mantiene el histórico por HU:
_pipeline_runs/
├── HU-CON-012/
│ ├── 2026-04-20_181500.log ← piloto inicial
│ ├── 2026-04-21_093000.log ← re-ejecución tras ajuste
│ └── _latest → 2026-04-21_093000.log (symlink)
├── HU-CON-013/
│ └── 2026-04-21_101530.log
└── HU-CON-014/
└── 2026-04-21_143020.log
Previsto: un dashboard que lea todos los logs y muestre:
Implementación: script Python que agrega los YAMLs y genera HTML con Chart.js.
Antes de dar una HU como "entregable":
_pipeline_runs/<HU>/.| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 1.0.0 | 2026-04-20 | Carlos Torres | Validacion y auditoria iniciales |