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>

methodology/PATTERNS.md

@@ -240,6 +240,95 @@ Cuando el agente detecta una oportunidad de mejora **fuera del scope del prompt*
 - Complementa **E.2** (Hallazgos no esperados) — pero E.2 es para descubrimientos pasivos (cosas que el agente notó), C.6 es para decisiones activas (cosas que el agente hizo).
 - Refuerza **C.3** (Auditoría adversarial) — provee al humano una sección concreta donde buscar cambios silenciosos.
 
+## Refinamiento — criterios explícitos de clasificación (aprendizajes de Sprint 1.5)
+
+Durante Sprint 1.5 InQ ROI se detectaron dos casos de mala clasificación de impacto. A partir de esos casos, se refinaron los criterios para distinguir entre Niveles 1, 2 y 3:
+
+### Reglas de clasificación (en orden de evaluación)
+
+Evaluar en este orden estricto. El primer criterio que aplique determina el nivel — no seguir evaluando los siguientes.
+
+**1. ¿El cambio resuelve un ítem listado en `TECH_DEBT.md`, `BACKLOG.md`, o archivos de planificación?**
+→ Nivel 3 (consulta previa). Sin importar el tamaño técnico.
+
+**Justificación:** ítems en archivos de planificación son decisiones del director sobre cuándo trabajarlos. El agente no puede promover ítems al sprint en curso por iniciativa.
+
+**2. ¿El cambio choca con una restricción explícita del prompt de la etapa?**
+→ Nivel 3 (consulta previa). Sin excepciones.
+
+Ejemplo de restricciones explícitas:
+- "NO entra: X" en sección de alcance
+- "NO tocar Y" en reglas operativas
+- "X está agendado para Etapa Z" en decisiones tomadas
+
+**3. ¿El cambio modifica paginación, layout, cantidad de archivos generados, o estructura de salida?**
+→ Nivel 2 mínimo. Reportar.
+
+**4. ¿El cambio es visible al usuario final (texto en interfaz, color, posición de elemento, contenido de PDF)?**
+→ Nivel 2 mínimo. Reportar.
+
+**5. ¿El cambio afecta marca, identidad, dependencias, o configuración del producto?**
+→ Nivel 3 (consulta previa).
+
+**6. Si nada de lo anterior aplica → Nivel 1**
+
+Ejemplos válidos de Nivel 1:
+- Renombrar variable interna por claridad
+- Reordenar imports
+- Mejorar comentario de código
+- Extraer función helper usada en múltiples lugares
+- Eliminar código muerto evidente (sin riesgo de uso futuro)
+- Limpiar artefactos accidentales del refactor (variables `void` no usadas)
+
+### Argumentos que NO son justificación válida para Nivel 1
+
+El agente puede invocar argumentos que parecen razonables pero violan los criterios de arriba:
+
+- **"Es mejora de legibilidad"** → si afecta contenido visible, es Nivel 2 mínimo
+- **"Es consistencia con etapa anterior"** → verificar si la etapa anterior fue autorizada o si también es adelanto silencioso (ver AP.8)
+- **"Es trivial de revertir"** → la reversibilidad NO es criterio de clasificación. Cambios reversibles también pueden ser Nivel 3.
+- **"Resuelve un bug menor"** → si el bug está documentado en TECH_DEBT.md, es Nivel 3
+- **"Es lo que el usuario esperaría"** → eso es asumir. La política existe para no asumir.
+
+### Casos reales documentados (Sprint 1.5 InQ ROI)
+
+**Caso 1 (Etapa 5):** compactación de páginas reportada como Nivel 1.
+- Realidad: Nivel 2 mínimo (modificó paginación visible)
+- Resultado: nota metodológica truncada, descubierto en validación visual
+- Lección: paginación es estructura de salida, criterio 3 aplica
+
+**Caso 2 (Etapa 7-8):** reescritura de fórmulas Σ → "SUM" reportada inicialmente sin clasificación, después como Nivel 1.
+- Realidad: Nivel 3 (resolvía ítem de TECH_DEBT.md sobre Unicode roto)
+- Resultado: aceptado retroactivamente porque resultó ser solución correcta para el dominio, pero el patrón quedó como anti-patrón AP.8
+- Lección: ítem en TECH_DEBT.md activa criterio 1 directo, sin importar el tamaño
+
+### Implicancia para CLAUDE.md del proyecto
+
+En el `CLAUDE.md` de cada proyecto, agregar a la sección "Política de iniciativa proactiva":
+
+```
+Antes de aplicar un cambio fuera del scope explícito del prompt actual:
+
+1. Verificá si el cambio está listado en TECH_DEBT.md, BACKLOG.md, o 
+   archivos de planificación equivalentes. Si está, es Nivel 3 — consultá.
+
+2. Verificá si el cambio choca con una restricción explícita del prompt
+   ("NO entra", "NO tocar", "está agendado para Etapa X"). Si choca, 
+   es Nivel 3 — consultá.
+
+3. Verificá si el cambio modifica paginación, layout, estructura de 
+   salida, contenido visible. Si lo hace, es Nivel 2 mínimo — reportá.
+
+4. Solo si nada de lo anterior aplica, ejecutá como Nivel 1.
+
+Argumentos NO válidos para evitar la consulta:
+- "Es mejora de legibilidad"
+- "Es consistencia con etapa anterior" (verificar si esa etapa fue 
+  autorizada o también fue adelanto silencioso)
+- "Es trivial de revertir"
+- "Resuelve un bug menor"
+```
+
 ---
 
 ## Categoría D — Estructura del repo