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:
@@ -30,7 +30,7 @@ Los tests verdes no equivalen a etapa terminada. **El humano abre el artefacto f
|
||||
|
||||
## 3. La auditoría es adversarial, no confirmatoria
|
||||
|
||||
Cuando revisás el output de un agente, **buscá lo que está mal**, no lo que está bien. Confirmar es fácil; el agente ya viene optimizado para producir cosas que parecen correctas. Tu valor está en detectar lo que el agente racionalizó.
|
||||
Cuando revisás el output de un agente, **buscá lo que está mal**, no lo que está bien. Confirmar es fácil; el agente ya viene optimizado para producir cosas que parecen correctas. Tu valor está en detectar lo que el agente racionalizó. Y esto se aplica tanto al output del agente como a tu propia auditoría. Cuando descubrís que algo se te pasó, no es fallo personal — es señal de que la lista de verificación necesita actualizarse.
|
||||
|
||||
**Por qué:** los agentes tienen un sesgo hacia reportar éxito. "Tests verdes, build limpio, etapa completada" suena bien pero puede ocultar que el archivo generado no es el correcto, que la métrica no cuadra con los inputs, o que un detalle crítico se omitió silenciosamente.
|
||||
|
||||
@@ -39,6 +39,36 @@ Cuando revisás el output de un agente, **buscá lo que está mal**, no lo que e
|
||||
2. ¿El artefacto entregado es el que pedí o uno parecido?
|
||||
3. ¿Lo que no menciona el reporte podría ser relevante?
|
||||
|
||||
**El auditor también debe ser auditado**
|
||||
|
||||
La auditoría adversarial aplica al agente que produce el artefacto, pero **también al humano (o agente delegado) que audita**. Los auditores son falibles. Cuando un cambio se descubre tiempo después de haber sido revisado, el caso vale la pena documentarlo — no para culpar al auditor, sino para refinar la lista de cosas a verificar en futuras auditorías.
|
||||
|
||||
**Caso real (Sprint 1.5 InQ ROI):**
|
||||
|
||||
En Etapa 7 del sprint, el agente reescribió fórmulas matemáticas de la nota metodológica del PDF ROI a ASCII puro (Σ → "SUM", × → "x"). El cambio no fue mencionado explícitamente en el reporte. El auditor (humano + asesor) validó el PDF visualmente y aprobó la etapa.
|
||||
|
||||
Dos etapas después, al auditar Etapa 8, se descubrió que la misma reescritura se había hecho en los otros PDFs, lo cual reveló que el cambio en Etapa 7 también había pasado sin detección.
|
||||
|
||||
**¿Por qué pasó?**
|
||||
|
||||
- El auditor revisó la nota metodológica buscando "caracteres Unicode rotos" (£ donde debería haber Σ). Confirmó que seguían rotos en algunos lugares. Asumió que el resto seguía como Etapa 5.
|
||||
- No verificó **el texto exacto, línea por línea**, contra una versión previa. Asumió continuidad.
|
||||
- El cambio era una "no presencia de un problema esperado", no una "presencia de algo nuevo". Auditar la ausencia es más difícil que auditar la presencia.
|
||||
|
||||
**Aprendizaje operativo:**
|
||||
|
||||
- **Verificar texto exacto contra versión previa** cuando se audita un artefacto que ya fue revisado en etapas anteriores. El reporte del agente puede omitir cambios que el auditor no detecta sin comparación directa.
|
||||
- **Cuando un problema esperado deja de aparecer, eso también es un cambio que requiere explicación.** Si una etapa "arregla" algo no agendado para arreglar, es señal de adelanto silencioso (ver Anti-Patrón AP.8).
|
||||
- **La auditoría tiene mejor poder de detección al inicio de un artefacto que en revisiones repetidas.** Cuando se audita por segunda o tercera vez, el reflejo es comparar contra la versión anterior, no contra el original. Eso puede dejar pasar cambios incrementales.
|
||||
|
||||
**Implicancia para futuros auditores (incluyendo miembros del equipo):**
|
||||
|
||||
- Mantener una lista de verificación explícita por tipo de artefacto, no confiar en memoria
|
||||
- Cuando algo "se ve igual", verificar línea por línea al menos una sección
|
||||
- Si un reporte parece más limpio de lo esperado, sospechar adelanto silencioso
|
||||
|
||||
Esta es la diferencia entre **auditoría adversarial real** y **auditoría adversarial declarativa**. Decir "audité adversarialmente" no equivale a haber buscado activamente lo que el agente podría haber cambiado sin reportar.
|
||||
|
||||
**Cuándo NO aplica:** tareas rutinarias de bajo riesgo donde el costo de auditar supera el costo de un error. Pero estas son menos de las que parecen.
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user