feat(sprint-1.5): PDFs Actual/Auto con identidad InQ + badge ⚡ naranja (Etapas 8-9)
Etapa 8 — PDFs Actual y Automatizado: - Página 1: header denso + metadata strip + grid 2×2 KPI cards con paleta #FEF3E2 (naranja claro InQ), sin gradiente (jerarquía visual preservada) - Página 3: tabla con header naranja claro #FFF8ED + #92400E, em dash en filas no-automatizables, título ANÁLISIS DE COMPOSICIÓN uppercase - Página 4: NOTA METODOLÓGICA uppercase + caja contenedora slate-50 - 526 tests verdes (+ 15 tests nuevos) Etapa 9 — Badge ⚡ en BpmnCanvas: - Reemplaza badge legacy (Bot SVG ámbar #fffbeb) por círculo naranja sólido #F59845 con símbolo ⚡ blanco, 14×14px, border white 1.5px - Usa var(--inq-orange) definido en globals.css (sin hex hardcodeados) - Elimina los 3 hex legacy del audit Etapa 1: #f59e0b, #fffbeb, #e2e8f0 - 5 tests E2E de lifecycle del badge + 2 screenshots Política de iniciativa refinada post-Sprint 1.5 (CLAUDE.md actualizado) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
396
sprints/sprint-1-5/ETAPA_8_PROMPT.md
Normal file
396
sprints/sprint-1-5/ETAPA_8_PROMPT.md
Normal file
@@ -0,0 +1,396 @@
|
||||
# Sprint 1.5 — Etapa 8: PDFs Actual y Automatizado con identidad InQ
|
||||
|
||||
> **Objetivo:** aplicar el sistema de design InQ a los PDFs Actual y Automatizado de forma consistente con el PDF ROI, manteniendo una jerarquía visual clara: el PDF ROI es el "reporte de cierre" (con KPI Hero gradiente), los PDFs Actual/Automatizado son "reportes de soporte" (con paleta consistente pero sin gradiente).
|
||||
>
|
||||
> **Pre-requisitos:** Etapas 1-7 cerradas. Sistema de design tokens InQ disponible. Módulo `pdf-sections-shared.ts` con header/footer compartidos. Layout híbrido funcionando (portrait/landscape/portrait/portrait).
|
||||
>
|
||||
> **Etapa siguiente:** Etapa 9 — Badge ⚡ naranja en BpmnCanvas del web app.
|
||||
|
||||
---
|
||||
|
||||
## 1. Decisión arquitectónica de esta etapa
|
||||
|
||||
**Jerarquía visual entre los 3 PDFs del producto:**
|
||||
|
||||
| PDF | Rol | Tratamiento visual |
|
||||
|---|---|---|
|
||||
| **ROI** | Reporte de cierre / discusión con cliente | KPI Hero gradiente, banner narrativo, top 3, trayectoria |
|
||||
| **Actual** | Reporte de soporte: detalla escenario actual | Paleta InQ + cards consistentes, **SIN KPI Hero gradiente** |
|
||||
| **Automatizado** | Reporte de soporte: detalla escenario automatizado | Paleta InQ + cards consistentes, **SIN KPI Hero gradiente** |
|
||||
|
||||
**Justificación:** si los 3 PDFs tuvieran KPI Hero gradiente, el impacto del ROI se diluye. El gradiente debe ser exclusivo del "reporte principal" para que funcione como anchor visual.
|
||||
|
||||
---
|
||||
|
||||
## 2. Alcance estricto
|
||||
|
||||
### Sí entra
|
||||
- ✅ Página 1 de PDFs Actual/Automatizado: aplicar paleta InQ a las 4 KPI cards (Costo Total, Directo/Overhead, Tiempo, Actividades)
|
||||
- ✅ Página 1: header denso similar al ROI (con título "ANÁLISIS DE COSTOS — ESCENARIO ACTUAL" / "ESCENARIO AUTOMATIZADO")
|
||||
- ✅ Página 3 (Análisis de composición + Tabla): aplicar paleta InQ a tabla, mantener estructura
|
||||
- ✅ Página 4 (Nota metodológica): aplicar paleta InQ al título y tipografía
|
||||
- ✅ Estilo de KPI cards de página 1 consistente con el grid 2x2 del ROI (fondo `#FEF3E2`, labels `#92400E`, cifras `#0F172A`)
|
||||
- ✅ Mantener footer compartido (Etapa 4) — sin cambios
|
||||
- ✅ Mantener página 2 landscape con diagrama BPMN — sin cambios estructurales
|
||||
|
||||
### NO entra
|
||||
- ❌ KPI Hero gradiente en página 1 — **exclusivo del PDF ROI**
|
||||
- ❌ Banner narrativo en página 1 — los PDFs Actual/Automatizado no narran resultado de inversión
|
||||
- ❌ Top 3 actividades con barras horizontales en página 1 — los PDFs ya tienen tabla detallada
|
||||
- ❌ Cambios al PDF ROI (cerrado en Etapas 6 y 7)
|
||||
- ❌ Cambios al diagrama BPMN landscape (cerrado en Etapa 5)
|
||||
- ❌ Resolver fórmulas truncadas o Unicode roto (Sprint 2)
|
||||
- ❌ Cambios al web app (no es scope de esta etapa)
|
||||
|
||||
---
|
||||
|
||||
## 3. Decisiones ya tomadas (no consultar de nuevo)
|
||||
|
||||
| Decisión | Justificación |
|
||||
|---|---|
|
||||
| PDFs Actual/Automatizado mantienen 4 páginas | Sin cambios estructurales |
|
||||
| KPI cards de página 1 usan paleta InQ (fondo `#FEF3E2`) | Consistencia con grid 2x2 del ROI |
|
||||
| NO incluir gradiente naranja → magenta en estos PDFs | Decisión Camino B — preserva jerarquía visual |
|
||||
| Título de página 1 diferencia el escenario | "ANÁLISIS DE COSTOS — ESCENARIO ACTUAL" vs "ESCENARIO AUTOMATIZADO" |
|
||||
| Tabla página 3 con header naranja claro `#FFF8ED` + border `#F59845` | Mismo tratamiento que tabla del ROI Etapa 7 |
|
||||
| Nota metodológica página 4 con título naranja oscuro | Mismo tratamiento que nota del ROI Etapa 7 |
|
||||
|
||||
---
|
||||
|
||||
## 4. Especificación detallada por página
|
||||
|
||||
### 4.1 Página 1 — Header denso + KPI cards
|
||||
|
||||
**Estado actual (post-Etapa 7):**
|
||||
- Header básico con "InQ ROI" y "medium-with-gateways"
|
||||
- 4 KPI cards en grid 2x2 (Costo Total, Directo/Overhead, Tiempo, Actividades)
|
||||
- KPI "Costo Total" con cifra en naranja (decisión retroactiva de Etapa 4)
|
||||
- Footer estándar
|
||||
|
||||
**Cambios en Etapa 8:**
|
||||
|
||||
#### Header denso (similar al ROI página 1, sin subtítulo de "Análisis de retorno")
|
||||
|
||||
```
|
||||
Layout: flex justify-between, border-bottom 3px solid #F59845
|
||||
Padding-bottom: 12mm
|
||||
Margin-bottom: 14mm
|
||||
|
||||
Izquierda (60% ancho):
|
||||
Línea 1: "InQ ROI"
|
||||
- Tamaño: 22pt
|
||||
- Peso: 700 (bold)
|
||||
- Color: #F59845
|
||||
- Tracking: -0.5pt
|
||||
Línea 2: "ANÁLISIS DE COSTOS — ESCENARIO ACTUAL"
|
||||
(o "ANÁLISIS DE COSTOS — ESCENARIO AUTOMATIZADO")
|
||||
- Tamaño: 9pt
|
||||
- Peso: 500
|
||||
- Color: #94A3B8 (text-tertiary)
|
||||
- Letter-spacing: 1.5pt
|
||||
- Margin-top: 4mm
|
||||
|
||||
Derecha (40% ancho):
|
||||
Línea 1: "UN PRODUCTO DE"
|
||||
- Tamaño: 9pt
|
||||
- Color: #94A3B8
|
||||
- Letter-spacing: 1pt
|
||||
- Align: right
|
||||
Línea 2: "InQ"
|
||||
- Tamaño: 16pt
|
||||
- Peso: 700
|
||||
- Color: #475569
|
||||
- Align: right
|
||||
Línea 3: "InQuality"
|
||||
- Tamaño: 9pt
|
||||
- Color: #64748B
|
||||
- Align: right
|
||||
```
|
||||
|
||||
#### Strip de metadata (similar al ROI)
|
||||
|
||||
```
|
||||
Fondo: #FAFBFC
|
||||
Padding: 8mm horizontal, 5mm vertical
|
||||
Border-radius: 4mm
|
||||
Layout: grid 3 columnas (proceso 2fr, fecha 1fr, moneda 1fr)
|
||||
Margin-bottom: 10mm
|
||||
|
||||
Cada celda:
|
||||
Label (top): 8pt, color #94A3B8, uppercase, letter-spacing 1pt
|
||||
Valor (bottom): 11pt, peso 500, color #0F172A
|
||||
```
|
||||
|
||||
**Contenido:**
|
||||
- Proceso: nombre del proceso BPMN
|
||||
- Fecha: fecha de simulación
|
||||
- Moneda: USD u otra
|
||||
|
||||
#### Grid 2x2 de KPI cards (estilo consistente con ROI página 1)
|
||||
|
||||
```
|
||||
Layout: grid 2 columnas × 2 filas
|
||||
Gap: 4mm horizontal, 4mm vertical
|
||||
Margin-bottom: 10mm
|
||||
|
||||
Cada card:
|
||||
Fondo: #FEF3E2 (inq-orange-light)
|
||||
Padding: 10mm 12mm
|
||||
Border-radius: 4mm
|
||||
|
||||
Label superior:
|
||||
- Tamaño: 9pt
|
||||
- Peso: 500
|
||||
- Color: #92400E (inq-orange-dark)
|
||||
- Letter-spacing: 1pt
|
||||
- Uppercase
|
||||
- Margin-bottom: 5mm
|
||||
|
||||
Cifra:
|
||||
- Tamaño: 18pt
|
||||
- Peso: 700 (bold)
|
||||
- Color: #0F172A
|
||||
- Font-family: mono (alineación)
|
||||
|
||||
Subtítulo (opcional, contexto):
|
||||
- Tamaño: 9pt
|
||||
- Peso: 400
|
||||
- Color: #B45309 (inq-orange-dark)
|
||||
- Margin-top: 3mm
|
||||
```
|
||||
|
||||
**Contenido de los 4 cards (mismo orden actual):**
|
||||
|
||||
| Card | Label | Cifra | Subtítulo |
|
||||
|---|---|---|---|
|
||||
| 1 | COSTO TOTAL ESPERADO | `formatCurrency(totalCost)` | (vacío) |
|
||||
| 2 | COSTO DIRECTO / OVERHEAD | `formatCurrency(direct) / formatCurrency(overhead)` | `{percentDirect}% directo` |
|
||||
| 3 | TIEMPO TOTAL ESPERADO | `{totalMinutes} min` | (vacío) |
|
||||
| 4 | ACTIVIDADES COSTEADAS | `{count}` | (vacío) |
|
||||
|
||||
**Importante:** la altura de página 1 con header denso + metadata strip + grid 2x2 debe **dejar espacio razonable abajo** (no apretar contra el footer). Si no entra, el grid pasa a una sola columna apilada, o reducir padding de cards. Reportar la decisión.
|
||||
|
||||
### 4.2 Página 2 — Diagrama BPMN landscape (sin cambios)
|
||||
|
||||
Mantener tal como quedó en Etapa 5. **NO TOCAR.**
|
||||
|
||||
Validar visualmente que sigue funcionando correctamente.
|
||||
|
||||
### 4.3 Página 3 — Análisis de composición + Tabla
|
||||
|
||||
**Estado actual (post-Etapa 5):**
|
||||
- "Análisis de composición: 83.3% directo (USD 500,00) · 16.7% overhead (USD 100,00)"
|
||||
- "Top 3 actividades por costo: 1. ... 2. ... 3. ..."
|
||||
- "Sin recursos asignados (costos son fijos por actividad)"
|
||||
- Tabla con header simple y filas
|
||||
|
||||
**Cambios en Etapa 8:**
|
||||
|
||||
#### Sección "Análisis de composición" (tratamiento ligero)
|
||||
|
||||
```
|
||||
Título:
|
||||
- Texto: "ANÁLISIS DE COMPOSICIÓN"
|
||||
- Tamaño: 11pt
|
||||
- Peso: 500
|
||||
- Color: #92400E (inq-orange-dark)
|
||||
- Letter-spacing: 1pt
|
||||
- Uppercase
|
||||
- Margin-bottom: 6mm
|
||||
|
||||
Texto descriptivo:
|
||||
- Tamaño: 11pt
|
||||
- Color: #0F172A
|
||||
- Line-height: 1.5
|
||||
- Margin-bottom: 4mm
|
||||
```
|
||||
|
||||
#### Tabla (mismo tratamiento que tabla del ROI Etapa 7)
|
||||
|
||||
```
|
||||
TABLA (autotable):
|
||||
|
||||
Header row:
|
||||
- Fondo: #FFF8ED (inq-orange-lighter)
|
||||
- Border-bottom: 1.5pt solid #F59845
|
||||
- Padding: 8pt 6pt
|
||||
- Texto: 10pt / peso 500 / color #92400E
|
||||
- Letter-spacing: 0.5pt
|
||||
- Uppercase
|
||||
|
||||
Body row (default):
|
||||
- Fondo: white
|
||||
- Border-bottom: 0.5pt solid #E2E8F0
|
||||
- Padding: 7pt 6pt
|
||||
- Texto: 10pt / peso 400 / color #0F172A
|
||||
- Números: font mono, color #0F172A
|
||||
|
||||
Body row (probabilidad < 100%):
|
||||
- Fondo: #F8FAFC (slate-50)
|
||||
- Texto: color #64748B (más tenue)
|
||||
- Comunica visualmente que es "ejecución condicional"
|
||||
```
|
||||
|
||||
**Columnas existentes:** Actividad | Dir. (USD) | Indir. (USD) | Total (USD) | % total | Tiempo | Prob.
|
||||
|
||||
Mantener estructura de columnas.
|
||||
|
||||
### 4.4 Página 4 — Nota metodológica
|
||||
|
||||
**Estado actual:**
|
||||
- Título "Nota metodológica"
|
||||
- Fórmulas matemáticas con caracteres Unicode rotos (Sprint 2)
|
||||
|
||||
**Cambios en Etapa 8:**
|
||||
|
||||
```
|
||||
Título:
|
||||
- Texto: "NOTA METODOLÓGICA"
|
||||
- Tamaño: 11pt
|
||||
- Peso: 500
|
||||
- Color: #92400E (inq-orange-dark)
|
||||
- Letter-spacing: 1pt
|
||||
- Uppercase
|
||||
- Margin-bottom: 10mm
|
||||
|
||||
Caja contenedora (opcional, sutil):
|
||||
- Fondo: #F8FAFC
|
||||
- Padding: 14pt
|
||||
- Border-radius: 4pt
|
||||
- Border-left: 2pt solid #94A3B8
|
||||
|
||||
Cada fórmula:
|
||||
Sub-título:
|
||||
- Tamaño: 10pt
|
||||
- Peso: 600
|
||||
- Color: #0F172A
|
||||
- Margin-bottom: 2mm
|
||||
|
||||
Fórmula:
|
||||
- Tamaño: 10pt
|
||||
- Font-family: mono
|
||||
- Color: #475569
|
||||
- Line-height: 1.5
|
||||
- Margin-bottom: 6mm
|
||||
```
|
||||
|
||||
**Contenido textual:** mantener el actual. NO arreglar caracteres rotos (Sprint 2).
|
||||
|
||||
---
|
||||
|
||||
## 5. Validaciones automatizadas mandatorias
|
||||
|
||||
```
|
||||
Para CADA uno de los 2 PDFs (Actual y Automatizado):
|
||||
|
||||
1. Cantidad de páginas: 4
|
||||
2. Orientaciones: ['portrait', 'landscape', 'portrait', 'portrait']
|
||||
|
||||
3. Página 1 contiene:
|
||||
- Texto "ANÁLISIS DE COSTOS — ESCENARIO ACTUAL" (o "AUTOMATIZADO")
|
||||
- 4 KPI cards detectables (al menos 4 ocurrencias del fondo #FEF3E2)
|
||||
- Strip de metadata con label "PROCESO"
|
||||
- Análisis de píxeles confirma paleta naranja InQ dominante
|
||||
|
||||
4. Página 1 NO contiene:
|
||||
- Gradiente naranja → magenta (verificar ausencia de píxeles magenta #ED3E8F)
|
||||
- Es decir: NO debe parecerse al KPI Hero del ROI
|
||||
|
||||
5. Página 3 contiene:
|
||||
- Título "ANÁLISIS DE COMPOSICIÓN"
|
||||
- Tabla con header de fondo naranja claro (#FFF8ED visible)
|
||||
- Border-bottom naranja en header de tabla
|
||||
|
||||
6. Página 4 contiene:
|
||||
- Título "NOTA METODOLÓGICA" en naranja oscuro
|
||||
- Caracteres £ y " presentes (esperado, Sprint 2)
|
||||
|
||||
7. Footers correctos en TODAS las páginas:
|
||||
- "InQ ROI · Powered by InQuality · ..."
|
||||
- "Página X de 4"
|
||||
|
||||
8. Sin regresiones de marca:
|
||||
- "InQ ROI" presente
|
||||
- "Process Cost Platform" ausente
|
||||
- "v0.1.0" ausente
|
||||
|
||||
PDF ROI: SIN CAMBIOS respecto a Etapa 7
|
||||
- 5 páginas, todas portrait
|
||||
- Página 1 con KPI Hero gradiente intacto
|
||||
- Hash del archivo igual o muy similar al de Etapa 7
|
||||
|
||||
Tests previos verdes: >= 489 (estimado, ajustar al real)
|
||||
```
|
||||
|
||||
Si CUALQUIER validación falla, NO uses `present_files`. Reportá qué falló.
|
||||
|
||||
---
|
||||
|
||||
## 6. Entregables (Definition of Done)
|
||||
|
||||
```
|
||||
[ ] PDF Actual: páginas 1, 3 y 4 rediseñadas con identidad InQ
|
||||
[ ] PDF Automatizado: páginas 1, 3 y 4 rediseñadas con identidad InQ
|
||||
[ ] Página 1 de ambos: NO incluye KPI Hero gradiente
|
||||
[ ] Página 2 de ambos: SIN CAMBIOS (BPMN landscape de Etapa 5)
|
||||
[ ] Header denso aplicado en página 1 (con título diferenciador)
|
||||
[ ] Strip de metadata en página 1
|
||||
[ ] Grid 2x2 de KPI cards con paleta consistente
|
||||
[ ] Tabla página 3 con header naranja claro
|
||||
[ ] Nota metodológica página 4 con título naranja oscuro
|
||||
[ ] PDF ROI NO MODIFICADO
|
||||
[ ] 8 validaciones automatizadas confirmadas
|
||||
[ ] PDFs presentados con paths absolutos del filesystem
|
||||
[ ] Tests previos verdes + nuevos tests específicos (al menos 3 casos por PDF)
|
||||
[ ] npm run build limpio
|
||||
[ ] Decisiones por iniciativa documentadas según política CLAUDE.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. Reporte final a entregar
|
||||
|
||||
1. **Tabla de archivos modificados/creados** con líneas
|
||||
2. **8 validaciones automatizadas confirmadas** (resultado de cada una)
|
||||
3. **Cantidad final de tests verdes**
|
||||
4. **3 PDFs presentados con paths absolutos del filesystem**:
|
||||
- `/Users/marcos/.../tests/e2e/__output__/etapa-8-actual.pdf`
|
||||
- `/Users/marcos/.../tests/e2e/__output__/etapa-8-automatizado.pdf`
|
||||
- `/Users/marcos/.../tests/e2e/__output__/etapa-8-roi.pdf` (regenerar para confirmar no-regresión)
|
||||
5. **Comparación lado a lado** del antes y después de los PDFs Actual/Automatizado:
|
||||
- Cantidad de píxeles naranja InQ antes vs después
|
||||
- Tamaño de archivo antes vs después
|
||||
6. **Hallazgos no esperados**
|
||||
7. **Decisiones tomadas por iniciativa** según política CLAUDE.md con clasificación por nivel
|
||||
|
||||
---
|
||||
|
||||
## 8. Reglas operativas
|
||||
|
||||
1. **NO TOCAR PDF ROI.** Cerrado en Etapas 6 y 7. Cualquier cambio ahí es Nivel 3 (consulta previa).
|
||||
|
||||
2. **NO TOCAR PÁGINA 2 (BPMN landscape).** Cerrada en Etapa 5.
|
||||
|
||||
3. **NO INCLUIR KPI Hero gradiente** en página 1 de Actual/Automatizado. Decisión arquitectónica de jerarquía visual.
|
||||
|
||||
4. **NO ARREGLAR caracteres Unicode rotos o fórmulas truncadas.** Sprint 2.
|
||||
|
||||
5. **Política de iniciativa proactiva refinada (post-Etapa 5):**
|
||||
- Cualquier cambio que afecte layout, paginación, contenido visible más allá del scope: mínimo Nivel 2
|
||||
- Cambio que choca con restricción explícita del prompt: Nivel 3 (consultar previo)
|
||||
- Cambio en página 2 (BPMN), PDF ROI, o web app: SIEMPRE Nivel 3 en esta etapa
|
||||
- Cambio en `pdf-sections-shared.ts` (módulo compartido de Etapa 4): SIEMPRE Nivel 3
|
||||
|
||||
6. **Si encontrás contradicción** entre prompt y código: PARÁ y consultá.
|
||||
|
||||
7. **Validación visual antes de declarar etapa terminada.** Los tests verdes no sustituyen mirar el PDF con tus ojos antes de present_files.
|
||||
|
||||
---
|
||||
|
||||
## 9. Por qué esta etapa importa
|
||||
|
||||
Los PDFs Actual y Automatizado son **el material de soporte que un consultor lleva a la reunión cuando el cliente pregunta "¿de dónde sale este número del ROI?"**. El PDF ROI le da el headline. Los PDFs Actual/Automatizado le dan la evidencia.
|
||||
|
||||
Si los PDFs de soporte se ven inconsistentes con el reporte principal, el consultor pierde credibilidad. Si se ven coherentes pero diferenciados (mismo sistema, distinta jerarquía), el consultor proyecta profesionalismo.
|
||||
|
||||
**El éxito de esta etapa se mide en consistencia visual**, no en wow factor. El wow ya está en el ROI.
|
||||
343
sprints/sprint-1-5/ETAPA_9_PROMPT.md
Normal file
343
sprints/sprint-1-5/ETAPA_9_PROMPT.md
Normal file
@@ -0,0 +1,343 @@
|
||||
# Sprint 1.5 — Etapa 9: Badge ⚡ naranja en BpmnCanvas (web)
|
||||
|
||||
> **Objetivo:** rediseñar el overlay del badge "automatizable" sobre los nodos del diagrama BPMN en el workspace web. Migrar de fondo blanco/ámbar con ícono Bot a fondo naranja sólido con símbolo ⚡, posición robusta basada en `left` (no `right`), y consistencia con la identidad InQ aplicada en Sprint 1.5.
|
||||
>
|
||||
> **Pre-requisitos:** Etapas 1-8 cerradas. Sistema de design tokens InQ disponible en `tailwind.config.ts`. Tokens `--inq-orange`, `--inq-orange-lighter`, etc., definidos.
|
||||
>
|
||||
> **Etapa siguiente:** Etapa 10 — Validación E2E final del Sprint 1.5 (suite completa, generación de artefactos de verificación, reporte de cobertura).
|
||||
|
||||
---
|
||||
|
||||
## 1. Alcance estricto
|
||||
|
||||
### Sí entra
|
||||
- ✅ Rediseño visual del badge en `BpmnCanvas.tsx`: fondo `#F59845` (inq-orange), símbolo ⚡ blanco
|
||||
- ✅ Cambio de posición del badge: de `{ top, right }` a `{ top, left: elementWidth - 12 }` para robustez con bpmn-js v18
|
||||
- ✅ Migración de hex hardcodeados pendientes en `BpmnCanvas.tsx`: `#f59e0b`, `#fffbeb`, `#e2e8f0` a tokens CSS
|
||||
- ✅ Tests visuales del overlay con Playwright
|
||||
- ✅ Verificar que el badge aparece solo en actividades con `automatable === true`
|
||||
- ✅ Verificar que el badge se actualiza correctamente cuando se toggle del switch en ActivityPanel
|
||||
|
||||
### NO entra
|
||||
- ❌ Cambios en los PDFs (cerrados en Etapas 4-8)
|
||||
- ❌ Cambios en la lógica de detección de automatable (solo presentación)
|
||||
- ❌ Reemplazo del emoji ⚡ por `<Bot />` de Lucide (anotado para Sprint 2-3 — requiere assets refinados)
|
||||
- ❌ Cambios en el panel de Automatización del ActivityPanel (cerrado en Etapa 3)
|
||||
- ❌ Cambios en otros overlays de bpmn-js (highlight de selección, gateways, etc.)
|
||||
|
||||
---
|
||||
|
||||
## 2. Decisiones ya tomadas (no consultar de nuevo)
|
||||
|
||||
| Decisión | Justificación |
|
||||
|---|---|
|
||||
| Fondo del badge: `#F59845` (inq-orange sólido) | Brief sección 2.8, BRIEF.md Sprint 1.5 |
|
||||
| Símbolo: ⚡ blanco | Brief sección 2.8 |
|
||||
| Tamaño: 14px diameter | Brief sección 2.8 |
|
||||
| Border: 1.5px solid white | Brief sección 2.8 — para contraste sobre fondos claros |
|
||||
| Posición: `{ top: -8, left: elementWidth - 12 }` | Brief sección 2.8 — evita bug de `right` en bpmn-js v18 |
|
||||
| Emoji ⚡ se mantiene en Sprint 1.5 | Refinamiento a `<Bot />` agendado para Sprint 2-3 |
|
||||
|
||||
---
|
||||
|
||||
## 3. Estado actual del componente
|
||||
|
||||
`src/features/workspace/BpmnCanvas.tsx` tiene actualmente:
|
||||
|
||||
```tsx
|
||||
// Líneas aproximadas según audit Etapa 1:
|
||||
|
||||
// Línea 24: stroke del ícono Bot en SVG inline
|
||||
stroke="#f59e0b" // amber-500 (hardcodeado)
|
||||
|
||||
// Línea 40: fondo del badge
|
||||
backgroundColor: '#fffbeb', // amber-50 (hardcodeado)
|
||||
|
||||
// Línea 41: borde del badge
|
||||
border: '1.5px solid #e2e8f0', // slate-200 (hardcodeado)
|
||||
```
|
||||
|
||||
**Audit Etapa 1 dijo (entrada para `BpmnCanvas.tsx`):**
|
||||
|
||||
> Etapa 9 (Badge ⚡): rediseño completo del badge a naranja sólido.
|
||||
|
||||
Es decir, esta etapa es **el cumplimiento de un trabajo ya planificado**, no exploración nueva.
|
||||
|
||||
---
|
||||
|
||||
## 4. Especificación detallada del badge nuevo
|
||||
|
||||
### 4.1 Estructura visual
|
||||
|
||||
```
|
||||
Badge automatizable (overlay sobre nodo BPMN):
|
||||
|
||||
┌────────────────┐
|
||||
│ Nodo BPMN │
|
||||
│ "task_recv" │ ← actividad automatizable
|
||||
│ ⚡ │ ← badge en esquina superior derecha
|
||||
│ │ (posicionado con left, no right)
|
||||
└────────────────┘
|
||||
|
||||
Estilo del badge:
|
||||
- Diámetro: 14px
|
||||
- Fondo: #F59845 (var(--inq-orange))
|
||||
- Border: 1.5px solid white
|
||||
- Border-radius: 50% (círculo perfecto)
|
||||
- Box-shadow: 0 1px 2px rgba(0,0,0,0.1) (sutil elevación)
|
||||
|
||||
Símbolo ⚡:
|
||||
- Color: white
|
||||
- Tamaño: 8px (font-size)
|
||||
- Font-weight: 700
|
||||
- Text-align: center
|
||||
- Line-height: 14px (centrado vertical)
|
||||
|
||||
Posición:
|
||||
- top: -8px (sale 8px por encima del nodo)
|
||||
- left: elementWidth - 12px (calculado dinámicamente desde bpmn-js)
|
||||
- z-index: 10 (sobre el nodo, debajo de tooltips)
|
||||
```
|
||||
|
||||
### 4.2 Implementación técnica
|
||||
|
||||
bpmn-js usa el sistema de overlays para posicionar elementos sobre nodos del diagrama. La API relevante:
|
||||
|
||||
```typescript
|
||||
const overlays = modeler.get('overlays');
|
||||
|
||||
overlays.add(elementId, 'automatable-badge', {
|
||||
position: {
|
||||
top: -8,
|
||||
left: elementWidth - 12, // NO usar right (bug v18)
|
||||
},
|
||||
html: `<div class="automatable-badge">⚡</div>`,
|
||||
});
|
||||
```
|
||||
|
||||
**CSS del badge** (en `BpmnCanvas.tsx` o archivo asociado):
|
||||
|
||||
```css
|
||||
.automatable-badge {
|
||||
width: 14px;
|
||||
height: 14px;
|
||||
background: var(--inq-orange); /* #F59845 */
|
||||
border: 1.5px solid white;
|
||||
border-radius: 50%;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
color: white;
|
||||
font-size: 8px;
|
||||
font-weight: 700;
|
||||
box-shadow: 0 1px 2px rgba(0, 0, 0, 0.1);
|
||||
cursor: default;
|
||||
}
|
||||
```
|
||||
|
||||
### 4.3 Lifecycle del badge
|
||||
|
||||
El badge debe:
|
||||
|
||||
1. **Aparecer** cuando una actividad se marca como `automatable === true`
|
||||
2. **Desaparecer** cuando se desmarca (toggle del switch en ActivityPanel)
|
||||
3. **Persistir** al hacer zoom, pan, o re-render del canvas
|
||||
4. **Re-renderizar correctamente** después de hot-reload en desarrollo
|
||||
|
||||
**Patrón recomendado:**
|
||||
|
||||
```typescript
|
||||
useEffect(() => {
|
||||
const overlays = modeler.get('overlays');
|
||||
const overlayIds: Record<string, string> = {};
|
||||
|
||||
activities.forEach(activity => {
|
||||
if (activity.automatable) {
|
||||
const element = elementRegistry.get(activity.bpmnElementId);
|
||||
if (!element) return;
|
||||
|
||||
const id = overlays.add(activity.bpmnElementId, 'automatable-badge', {
|
||||
position: {
|
||||
top: -8,
|
||||
left: element.width - 12,
|
||||
},
|
||||
html: '<div class="automatable-badge">⚡</div>',
|
||||
});
|
||||
overlayIds[activity.bpmnElementId] = id;
|
||||
}
|
||||
});
|
||||
|
||||
return () => {
|
||||
Object.values(overlayIds).forEach(id => overlays.remove(id));
|
||||
};
|
||||
}, [activities, modeler]);
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Migración de hex hardcodeados pendientes
|
||||
|
||||
Según audit Etapa 1, `BpmnCanvas.tsx` tiene 3 hex residuales que deben migrarse:
|
||||
|
||||
| Línea aprox. | Hex actual | Significado actual | Nueva referencia |
|
||||
|---|---|---|---|
|
||||
| 24 | `#f59e0b` | stroke ícono Bot en SVG inline (legacy) | **ELIMINAR**: el ícono Bot se reemplaza por el badge ⚡ |
|
||||
| 40 | `#fffbeb` | fondo del badge (legacy amber-50) | **ELIMINAR**: el badge nuevo usa `var(--inq-orange)` |
|
||||
| 41 | `#e2e8f0` | borde del badge (legacy slate-200) | **ELIMINAR**: el badge nuevo usa border blanco |
|
||||
|
||||
**El badge legacy se reemplaza completo.** No se trata de migrar colores, sino de rediseñar el componente.
|
||||
|
||||
---
|
||||
|
||||
## 6. Validaciones automatizadas mandatorias
|
||||
|
||||
```
|
||||
Antes de present_files, ejecutá y confirmá:
|
||||
|
||||
1. El componente BpmnCanvas.tsx renderiza sin errores
|
||||
- npm run build limpio
|
||||
- npm run typecheck sin errores
|
||||
- Sin warnings nuevos de React
|
||||
|
||||
2. Tests unitarios:
|
||||
- El badge aparece cuando activity.automatable === true
|
||||
- El badge NO aparece cuando activity.automatable === false
|
||||
- El badge tiene fondo naranja InQ (#F59845)
|
||||
- El badge usa posición left, no right
|
||||
- Cleanup del badge al desmontar componente
|
||||
|
||||
3. Tests E2E (Playwright):
|
||||
- Cargar simple-linear, marcar primera actividad como automatable
|
||||
- Verificar que el badge ⚡ naranja aparece sobre el nodo correcto
|
||||
- Toggle del switch off — verificar que el badge desaparece
|
||||
- Toggle on de nuevo — verificar que el badge reaparece
|
||||
|
||||
4. Screenshot Playwright en tests/screenshots/etapa-9/:
|
||||
- workspace-badge-on.png: workspace con simple-linear y 2-3
|
||||
actividades automatizables, badges naranja visibles
|
||||
- workspace-badge-detail.png: zoom in sobre un nodo automatizable
|
||||
mostrando el badge con detalle
|
||||
|
||||
5. Sin regresiones:
|
||||
- Otros tests del web app siguen verdes (~515+ del sprint)
|
||||
- PDFs no se regeneran en esta etapa (no aplica validación)
|
||||
```
|
||||
|
||||
Si CUALQUIER validación falla, NO uses `present_files`. Reportá qué falló.
|
||||
|
||||
---
|
||||
|
||||
## 7. Entregables (Definition of Done)
|
||||
|
||||
```
|
||||
[ ] BpmnCanvas.tsx rediseñado: badge ⚡ naranja sólido reemplaza al
|
||||
badge legacy amber con Bot
|
||||
[ ] Posición del badge usa left (no right) — robusto a bpmn-js v18
|
||||
[ ] CSS del badge usa var(--inq-orange) y var(--inq-orange-lighter)
|
||||
según corresponda (sin hex hardcodeados)
|
||||
[ ] 3 hex hardcodeados pendientes del audit Etapa 1 eliminados
|
||||
[ ] Tests unitarios del overlay (al menos 5 casos)
|
||||
[ ] Tests E2E del lifecycle del badge (al menos 3 escenarios)
|
||||
[ ] 2 screenshots Playwright generados y commiteados
|
||||
[ ] 515+ tests previos siguen verdes
|
||||
[ ] Build limpio, typecheck limpio, lint limpio
|
||||
[ ] Screenshot presentado para validación visual
|
||||
[ ] Decisiones tomadas por iniciativa documentadas según política
|
||||
refinada (post-Etapa 8) de CLAUDE.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. Validación visual del director
|
||||
|
||||
Después de Claude Code presente los screenshots, abrí el dev server y validá:
|
||||
|
||||
1. Cargá un proceso (idealmente `simple-linear` o `medium-with-gateways`)
|
||||
2. Marcá 2-3 actividades como automatizables desde el ActivityPanel
|
||||
3. Mirá el canvas BPMN y verificá:
|
||||
|
||||
```
|
||||
[ ] El badge ⚡ aparece sobre cada actividad marcada
|
||||
[ ] El badge tiene fondo naranja sólido (#F59845)
|
||||
[ ] El símbolo ⚡ se ve nítido en blanco
|
||||
[ ] El badge está en la esquina superior derecha del nodo
|
||||
[ ] El badge NO se sale del área del nodo al hacer zoom in/out
|
||||
[ ] El badge desaparece al desmarcar la actividad
|
||||
[ ] No hay badges huérfanos al cambiar de proceso o limpiar
|
||||
```
|
||||
|
||||
**Tu impresión visceral:** ¿el badge se siente parte de la identidad InQ o se siente "agregado"? Es un detalle pequeño pero importante para coherencia visual.
|
||||
|
||||
---
|
||||
|
||||
## 9. Reporte final a entregar
|
||||
|
||||
1. **Tabla de archivos modificados** con líneas
|
||||
2. **5 validaciones automatizadas confirmadas** (resultados específicos)
|
||||
3. **Cantidad final de tests verdes**
|
||||
4. **2 screenshots Playwright** presentados con paths absolutos
|
||||
5. **Confirmación de migración de hex hardcodeados** (los 3 del audit Etapa 1)
|
||||
6. **Hallazgos no esperados**
|
||||
7. **Decisiones tomadas por iniciativa** clasificadas según política refinada de CLAUDE.md
|
||||
|
||||
---
|
||||
|
||||
## 10. Reglas operativas (recordatorios)
|
||||
|
||||
1. **NO TOCAR los PDFs.** Cerrados en Etapas 4-8. Esta etapa es solo web app.
|
||||
|
||||
2. **NO REEMPLAZAR el emoji ⚡ con `<Bot />` u otro icono.** Está agendado para Sprint 2-3 cuando InQuality tenga assets refinados.
|
||||
|
||||
3. **NO CAMBIAR la lógica de detección de automatable.** Solo la presentación visual.
|
||||
|
||||
4. **USAR POSICIÓN basada en `left`, no `right`.** Está documentado como bug conocido de bpmn-js v18 en el brief (sección 5.3). El position calculado dinámicamente con `elementWidth - 12` es la solución probada.
|
||||
|
||||
5. **Política de iniciativa proactiva refinada (post-Etapa 8):**
|
||||
- Si el cambio resuelve un ítem listado en TECH_DEBT.md o BACKLOG.md → Nivel 3 (consultar previa)
|
||||
- Si choca con restricción explícita del prompt ("NO entra", "NO tocar") → Nivel 3
|
||||
- Si modifica paginación, layout, estructura de salida, o contenido visible → Nivel 2 mínimo (reportar)
|
||||
- Si afecta marca, identidad, dependencias o configuración → Nivel 3
|
||||
- Si nada aplica → Nivel 1
|
||||
- Argumentos NO válidos: "mejora de legibilidad", "consistencia con etapa anterior", "trivial de revertir", "resuelve bug menor"
|
||||
|
||||
6. **Si encontrás que el badge actual usa Bot de Lucide en lugar de algún SVG genérico**, NO migres a `<Bot />` ni a otro componente. **Reemplaza el badge completo** según especificación de §4.
|
||||
|
||||
7. **Validación visual del director es mandatoria.** No declarar etapa terminada sin que el director haya visto los screenshots y verificado el dev server.
|
||||
|
||||
8. **Si encontrás contradicción** entre prompt y código: PARÁ y consultá.
|
||||
|
||||
---
|
||||
|
||||
## 11. Contexto: por qué esta etapa importa
|
||||
|
||||
El badge ⚡ es **el indicador visual más importante del workspace BPMN**. Cuando un consultor importa un proceso de 15 actividades y empieza a marcar automatizables, necesita ver de un vistazo cuáles ya marcó y cuáles faltan. Un badge legítimo, visible y consistente con la marca es la diferencia entre "herramienta profesional" y "prototipo".
|
||||
|
||||
Hasta ahora el badge era ámbar tenue con un ícono Bot que pasaba desapercibido. Con esta etapa el badge se vuelve **el segundo elemento visual más identitario del producto** después del logo y los KPI Hero (los dos elementos donde aparece el naranja InQ con peso).
|
||||
|
||||
Si el badge queda bien:
|
||||
- El workspace transmite "identidad de marca" sin texto
|
||||
- Las screenshots de pre-venta muestran un producto cohesivo
|
||||
- El consultor tiene feedback visual claro de qué activó
|
||||
|
||||
Si queda mal:
|
||||
- Inconsistencia visual entre web y PDFs
|
||||
- Sensación de "componente legacy no actualizado"
|
||||
|
||||
Apuntá al primero.
|
||||
|
||||
---
|
||||
|
||||
## 12. Esta etapa cierra el rediseño visual del Sprint 1.5
|
||||
|
||||
Después de Etapa 9, los componentes visuales clave del producto están todos rediseñados:
|
||||
|
||||
- ✅ Web app workspace (Etapa 3)
|
||||
- ✅ Web app reporte ROI (Etapa 3)
|
||||
- ✅ PDFs header/footer compartidos (Etapa 4)
|
||||
- ✅ PDFs layout híbrido (Etapa 5)
|
||||
- ✅ PDF ROI página 1 completa (Etapa 6)
|
||||
- ✅ PDF ROI páginas 2-5 (Etapa 7)
|
||||
- ✅ PDFs Actual/Automatizado (Etapa 8)
|
||||
- ⏳ Badge ⚡ en BpmnCanvas (Etapa 9 — esta)
|
||||
|
||||
Lo que queda después es **validación final** (Etapa 10) y **polish + documentación** (Etapa 11). El rediseño visual del producto está completo después de Etapa 9.
|
||||
Reference in New Issue
Block a user