Version: 1.3 · Fecha: 2026-04-21
Estado: Sprint-02 de Contabilidad · HU V1 → V2 completado para las 7 HUs pendientes + HU-TES-001 incorporada por consultoría (reemplaza HU-CON-019 con mayor alcance).
Registrar los resultados de la aplicación real del pipeline V1→V2 sobre las HUs pendientes del Sprint-02. Este documento es la evidencia operativa de que el proceso funciona end-to-end y es replicable.
| HU | Estado | Entregable |
|---|---|---|
| HU-CON-002 Maestro Terceros | HT existente | — |
| HU-CON-004 Plan de Cuentas | HT existente | — |
| HU-CON-009 Formatos Contables | V2 + HT existentes | — |
| HU-CON-017 Maestro Monedas | HT existente | — |
| HU-CON-012 Causación Cuentas | ✅ V2 piloto canónico | HU-CON-012-VGEN-FULL.docx |
| HU-CON-013 Aprobación Causación | ✅ V2 generado | HU-CON-013-V2.docx |
| HU-CON-014 Anulación Causación | ✅ V2 generado | HU-CON-014-V2.docx |
| HU-CON-016 Elaboración Asiento | ✅ V2 generado | HU-CON-016-V2.docx |
| HU-CON-018 Anulación Asientos | ✅ V2 generado | HU-CON-018-V2.docx |
| HU-CON-019 Maestro Diferidos | ⚠ Obsoleta — reemplazada por HU-TES-001 (consultoría, 2026-04-21) | HU-CON-019-V2.docx · análisis diferencias |
| HU-CON-020 Proceso Diferidos | ✅ V2 generado | HU-CON-020-V2.docx |
| HU-CON-021 Proceso Depreciación | ✅ V2 generado | HU-CON-021-V2.docx |
| HU-TES-001 Crear Diferidos | ✅ V2 validado (PROCESABLE POR PIPELINE) · primera HU con los 3 gates E1/E2/E4 en verde | HU-TES-001-V2.docx |
7 de 7 HUs pendientes quedaron con DOCX V2 generado por el pipeline. HU-TES-001 incorporada 2026-04-21 como entrega de consultoría en formato V2 directo (no requirió Fases A-C del pipeline), con mayor alcance que HU-CON-019 (3 INTs vs 2, 60% más FN/RN en ALC2).
| HU | Alcances | FN | RN | CA | INTs | DOCX | Wireframes Nebula |
|---|---|---|---|---|---|---|---|
| HU-CON-012 (piloto) | 2 | 14 | 155 | 199 | 10 | 629 KB | 10 |
| HU-CON-013 Aprobación | 3 | 12 | 22 | 21 | 4 | 342 KB | 4 |
| HU-CON-014 Anulación Causación | 2 | 8 | 10 | 8 | 2 | 154 KB | 2 |
| HU-CON-016 Elaboración Asiento | 2 | 9 | 11 | 10 | 2 | 234 KB | 2 |
| HU-CON-018 Anulación Asientos | 2 | 6 | 7 | 7 | 2 | 150 KB | 2 |
| HU-CON-019 Maestro Diferidos (obsoleta) | 2 | 7 | 7 | 5 | 2 | 212 KB | 2 |
| HU-CON-020 Proceso Diferidos | 1 | 4 | 4 | 3 | 1 | 139 KB | 1 |
| HU-CON-021 Proceso Depreciación | 1 | 4 | 6 | 4 | 1 | 110 KB | 1 |
| HU-TES-001 Crear Diferidos | 2 | 20 | 58 | 53 | 4 | 441 KB | 4 |
| TOTAL | 17 | 84 | 280 | 310 | 28 | ~2.4 MB | 28 |
Alcances generados:
Listado de Documentos Causados Aprobados (list_view)
Modal Motivo de Anulación (modal + textarea full-width)
Reglas clave cubiertas (del V1):
Alcances generados:
Listado de Asientos Contables (list_view)
Formulario Crear Asiento (form + tabla de detalle con totales)
Reglas clave cubiertas (del V1):
Alcances generados:
Listado de Asientos Elaborados (list_view)
Modal Motivo de Anulación (modal + textarea full-width)
Reglas clave cubiertas (del V1):
Alcances generados:
Listado de Diferidos (list_view con badges semánticos)
Formulario Crear/Editar Diferido (form + tabla Centros de Costo)
Reglas clave cubiertas (del V1):
Alcance generado:
form + tabla)
Reglas clave cubiertas (del V1):
Alcance generado:
form con 3 métodos)
Reglas clave cubiertas (del V1):
Transparencia: los tiempos siguientes distinguen entre (a) lo medido
efectivamente en la ejecución del piloto, (b) costos de setup que sólo se
pagan una vez, y (c) proyecciones basadas en supuestos que aún no están
validados en producción. Se marca cada dato con su categoría.
Trabajo realizado para construir el pipeline desde cero. No se repite por cada HU.
| Componente | Dedicación (h) | Medición |
|---|---|---|
| Diseño del pipeline (5 fases, prompts maestro, contratos de interfaces) | ~2 | ✅ medido |
| Scripts del pipeline (01_extract, 02_parse, 03_validate, 04_generate, 05_render) | ~3 | ✅ medido |
| CSS Nebula v1.4 + 5 templates HTML (list_view, form, modal, detail, wizard) | ~3 | ✅ medido |
| Iconos lucide + renderer de wireframes | ~2 | ✅ medido |
| Iteración de bugs de renderizado (inputs, botones, textarea, viewport, altura adaptable) | ~4 | ✅ medido |
| Piloto canónico HU-CON-012 (ALCANCE 1 + completo con 10 INTs) | ~5 | ✅ medido |
| Wiki PROCESO_HU_NEBULA (10 documentos) | ~2 | ✅ medido |
| Configuración Claude Code (subagentes, skills, settings) | ~1 | ✅ medido |
| Plantilla wireframe-first + guía de replicación | ~1 | ✅ medido |
| Total setup inicial | ~23 h | ✅ medido |
Este costo quedó amortizado al finalizar el piloto HU-CON-012.
Las 7 HUs pendientes del Sprint-02 se procesaron usando Claude como asistente vía conversación. Esto incluye: lectura del V1 extraído, inferencia de layouts desde narrativa (Fase B0 cuando no había mockups gráficos), construcción del hu_spec.yaml con layouts + campos + FN + RN + CA, invocación de scripts, validación.
| HU | Alcances generados | Tiempo real |
|---|---|---|
| HU-CON-013 (primera tras piloto) | 3 alcances, 4 INTs | ~1 h 25 min |
| HU-CON-014 | 2 alcances, 2 INTs | ~35 min |
| HU-CON-016 | 2 alcances, 2 INTs | ~40 min |
| HU-CON-018 | 2 alcances, 2 INTs | ~30 min |
| HU-CON-019 | 2 alcances, 2 INTs | ~35 min |
| HU-CON-020 | 1 alcance, 1 INT | ~25 min |
| HU-CON-021 | 1 alcance, 1 INT | ~25 min |
| Ajustes de última hora (textarea del modal de rechazo que obligó a actualizar templates) | — | ~35 min |
| Total Sprint-02 | 13 alcances, 14 INTs, 7 DOCX | ~5 h 30 min |
| Modo | Estado | Tiempo por HU |
|---|---|---|
| A. Manual puro · humano redacta el YAML sin asistencia IA | ⚠ No medido | Estimado >2 h (construir YAML desde cero requiere dominio del template) |
| B. Claude asistido vía conversación · lo hecho en el Sprint-02 | ✅ Medido | 25–45 min (promedio ~35 min con patrón establecido) |
| C. Claude automatizado push-button · subagentes + skills invocándose sin conversación | ⚠ No ejecutado | Proyectado 15–25 min (incluye gate C4 humano) |
El modo B es el que validamos en este piloto. Funciona y produce los 7 DOCX entregables.
El modo C (skill /reprocesar-hu <CODIGO> que orquesta todos los subagentes) está diseñado en .claude/skills/reprocesar-hu/SKILL.md pero no se ha ejecutado aún. La diferencia práctica respecto al modo B es que elimina la ida-y-vuelta conversacional: el humano sólo interviene en el gate C4 (decisiones de mapeo ambiguo). Se proyecta una reducción adicional del 30–50 % en tiempo humano, pero esa cifra es estimación, no medición.
Se ha mencionado en iteraciones previas la cifra "8 días por HU" como referencia. Es importante contextualizar:
| Dato | Aclaración |
|---|---|
| "8 días" del piloto HU-CON-012 V2 | Caso específico: consultoría (Eramis Olivero) construyó el V2 siguiendo el nuevo formato que QA había definido para cerrar brechas identificadas en Sprint-02. QA actuó como guía del estándar y revisor; la redacción estuvo a cargo de consultoría. Alta complejidad (2 alcances, 10 INTs, 199 CA). No es representativo de todas las HUs. |
| Tiempo de consultoría V1 típica (Eramis/Alejandra) | No medido formalmente. No hay registro de horas por HU. |
| Tiempo de consultoría V1→V2 sin pipeline | No medido. El único dato disponible es el piloto HU-CON-012. |
Lo que sí se puede afirmar con datos:
_pipeline_runs/).Con esos datos, en Sprint-03 o Sprint-04 se podrá publicar una comparación objetiva defendible.
El piloto confirma que los 5 tipos de layout cubren el 100% del Sprint-02:
| Layout | HUs donde se usa |
|---|---|
list_view |
014, 016, 018, 019 (listados con filtros + tabla + FAB) |
form + tabla |
016 (creación asiento), 019 (diferido), 020 (proceso), 021 (depreciación), 013 (pestañas) |
modal + textarea |
014, 018 (motivo anulación), 013 (motivo rechazo) |
modal campos |
012 (ya en piloto) |
detail |
no requerido en Sprint-02 |
wizard |
no requerido en Sprint-02 |
| HU | E1 Trazabilidad | E2 Campos por INT | E3 Cobertura V1→V2 | E4 Gherkin válido | Veredicto final |
|---|---|---|---|---|---|
| HU-CON-013 | ⚠ 3 RN sin CA directa | ⚠ (pre-fix validador) | ✅ 94% | ✅ 100% | REQUIERE AJUSTES |
| HU-CON-014 | ✅ | ⚠ (pre-fix validador) | ✅ ≥90% | ✅ 100% | REQUIERE AJUSTES |
| HU-CON-016 | ✅ | ⚠ (pre-fix validador) | ✅ ≥90% | ✅ 100% | REQUIERE AJUSTES |
| HU-CON-018 | ✅ | ⚠ (pre-fix validador) | ✅ ≥90% | ✅ 100% | REQUIERE AJUSTES |
| HU-CON-019 (obsoleta) | ✅ | ⚠ | ✅ ≥85% | ✅ 100% | obsoleta |
| HU-CON-020 | ✅ | ⚠ (pre-fix validador) | ✅ ≥85% | ✅ 100% | REQUIERE AJUSTES |
| HU-CON-021 | ✅ | ⚠ (pre-fix validador) | ✅ ≥85% | ✅ 100% | REQUIERE AJUSTES |
| HU-TES-001 | ✅ | ✅ (ALC1: 10 · ALC2: 31) | — (V2 directo) | ✅ 100% (53/53) | ✅ PROCESABLE POR PIPELINE |
Nota sobre E2: las 6 HUs del Sprint-02 fallaban E2 por un bug estructural del validador (el regex de header
ALCANCE Nno matcheaba el formato| ALCANCE N |generado al convertir DOCX a pseudo-markdown). El fix se entregó en el validador v1.1 (2026-04-21) junto con HU-TES-001. Al re-validar las 6 HUs con el validador corregido, su veredicto E2 debe pasar sin tocar el contenido. Tarea pendiente del QA.
Gate E5 formal (QA 7 dimensiones): pendiente de aplicación por el equipo QA. Los DOCX están listos para esa revisión.
docx-synthesizer cuando se integre Claude API.ALCANCE N ahora acepta también el formato | ALCANCE N | (celda de tabla en el pseudo-markdown DOCX), y extract_campos_alcance corta la tabla de campos en REGLAS DE NEGOCIO/CRITERIOS DE ACEPTACIÓN para evitar contaminación de filas posteriores. Validado contra HU-TES-001 (ALC1: 10 · ALC2: 31 campos detectados).actions_by_state (pipeline v1.1 · 2026-04-21)A raíz del procesamiento de HU-TES-001 se detectó que los list_view con acciones por fila y estados por registro (edit solo en Pendiente, delete solo en Borrador, etc.) no comunicaban la habilitación condicional en el wireframe: los iconos aparecían genéricos aunque las RN las describían explícitamente. Se incorporó al estándar visual Nebula v1.1 el patrón actions_by_state, documentado en 04_ESTANDAR_VISUAL_NEBULA.md §list_view.
Resumen: el layout del list_view puede declarar actions_by_state: {<estado>: [<acciones>]} y el renderer pinta con opacidad 0.4 los iconos no aplicables a cada fila según su badge de estado. Retrocompat con el comportamiento previo (si la clave no se declara, todos los iconos se renderizan activos uniformemente).
Se revisaron las 6 HUs ya procesadas del Sprint-02 para identificar candidatos al nuevo patrón:
| HU | Layout principal | Usa acciones por fila | ¿Requiere actions_by_state? |
|---|---|---|---|
| HU-CON-013 Aprobación Causación | list_view + checkbox | [view] |
No — habilitación en botones globales Aprobar/Rechazar por selección masiva (RN-ALC1-07/09) |
| HU-CON-014 Anulación Causación | list_view + checkbox | [view] |
No — habilitación global Anular por selección masiva (RN-ALC1-05) |
| HU-CON-016 Elaboración Asiento | list_view sin checkbox | [view] |
No — sin acciones condicionales por fila; lógica en campos/botón Guardar |
| HU-CON-018 Anulación Asientos | list_view + checkbox | [view] |
No — habilitación global Aceptar por selección masiva (RN-ALC1-03) |
| HU-CON-020 Proceso Diferidos | form (sin list_view) | n/a | No aplica |
| HU-CON-021 Proceso Depreciación | form (sin list_view) | n/a — deshabilitación a nivel pantalla cuando no hay periodos abiertos | No aplica |
Veredicto: ninguna de las 6 HUs del Sprint-02 requiere ajuste; todas siguen un patrón distinto (selección masiva + botón global, o form puro) que queda correctamente modelado sin el nuevo mapping. El único caso que se beneficia del patrón es HU-TES-001 (único list_view del sprint con acciones por fila + estados por registro).
HU-CON-019 (obsoleta): tiene la misma divergencia que HU-TES-001 (RN-ALC1-04 "El botón Editar solo se habilita para diferidos en estado ACTIVE" vs wireframe con icono siempre activo), pero al estar reemplazada por HU-TES-001 no se alinea. Queda archivada con su divergencia documentada.
Para cada HU-CON-0XX procesada, la carpeta contiene:
HU_CON_0XX/
├── 02_fase_A_extraccion/
│ ├── extracted.yaml ← ⭐ insumo parseado
│ ├── hu-v1.txt
│ ├── anexo1.txt
│ ├── anexo2.txt (si aplica)
│ ├── wireframes*/ ← imágenes del V1
│ └── _rendered/ ← wireframes Nebula generados
├── hu_spec.yaml ← ⭐ spec consolidada
├── HU-CON-0XX-V2.docx ← ⭐⭐ ENTREGABLE
└── reporte_validacion.md ← ⭐ validación Fase E
Pipeline HTU v5.0 para generar las HTU de desarrollo.Aviso: estos son estimados preliminares, no cifras validadas. Se irán
ajustando con los datos reales que se registren en Sprint-03 en adelante.
Basado en el tiempo medido del Sprint-02 en modo B (Claude asistido) con patrón ya establecido (~35 min promedio por HU), sin contar setup inicial que ya está amortizado:
| Sprint | # HU estimadas | Tiempo estimado pipeline modo B | Tiempo estimado modo C (push-button) |
|---|---|---|---|
| Sprint-03 Contabilidad (Tesorería integrada) | 8-10 HUs | ~5-6 horas | ~3-4 horas (proyección) |
| Sprint-04 Presupuesto | 10-12 HUs | ~6-7 horas | ~4-5 horas (proyección) |
| Sprint-05 Nómina | 8-10 HUs | ~5-6 horas | ~3-4 horas (proyección) |
Comparación con consultoría tradicional: pendiente de medir (ver sección "Sobre la comparación con consultoría tradicional"). Hasta no registrar horas reales de consultoría entregando V1 o V1→V2, cualquier cifra de "ahorro" es estimación no validada.
| Campo | Valor |
|---|---|
| Fecha | 2026-04-20 (Sprint-02 base) · 2026-04-21 (HU-TES-001 + patrón v1.1) |
| Ejecutor | Carlos Torres (arquitecto) |
| Pipeline versión | v1.1 (fix E2 validador + patrón actions_by_state) |
| Manual visual | v1.4 · Estándar Nebula v1.1 |
| HUs procesadas esta iteración | HU-CON-013, 014, 016, 018, 019, 020, 021 · HU-TES-001 (V2 directo consultoría) |
| Total entregables | 8 DOCX + 28 wireframes Nebula + 8 reportes validación |
| Modo de operación | B · Claude asistido vía conversación |
| Tiempo total medido procesamiento Sprint-02 | ~5 h 30 min (7 HUs) + ~45 min (HU-TES-001 alineación consultoría + patrón v1.1 + auditoría) |
| Tiempo setup inicial (una sola vez, amortizado) | ~23 h |
| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 1.3.0 | 2026-04-21 | Carlos Torres | Incorporacion de HU-TES-001 (V2 directo consultoria, reemplaza HU-CON-019 obsoleta). Fix del bug estructural E2 del validador. Documentacion del patron actions_by_state y auditoria sobre las 6 HUs del Sprint-02 (ninguna requiere ajuste, HU-TES-001 es la unica beneficiaria). |
| 1.2.0 | 2026-04-20 | Carlos Torres | Ajuste de seccion "Desempeño medido": separacion de setup inicial vs procesamiento, distincion entre 3 modos de operacion (A/B/C), clarificacion de roles QA vs consultoria en piloto HU-012, retiro de cifras de ahorro no validadas |
| 1.1.0 | 2026-04-20 | Carlos Torres | Ampliacion a las 7 HUs pendientes del Sprint-02 |
| 1.0.0 | 2026-04-20 | Carlos Torres | Primera prueba real sobre HU-CON-013 |