# Plantilla: Auditor con Veto Items + Cap Enforcement

Plantilla reusable para revisores SWL que aplican el patrón "veto items + cap
enforcement". Ver `reglas/gobernanza.md` sección "Veto items y cap enforcement".

---

## Cuándo usar esta plantilla

Cuando crees o actualices un revisor (`revisor-*-swl.md`) que:

- Audita cumplimiento de reglas globales del sistema (`reglas/*.md`).
- Necesita comunicar al lector cuáles violaciones son **no negociables**.
- Debe evitar que un score promedio "redondeado" oculte un problema crítico.

---

## Estructura a copiar (insertar antes de "Formato de reporte obligatorio")

```markdown
## Veto items — cap enforcement a [LÍMITE]

Ciertos hallazgos son **no negociables**. Si encuentras CUALQUIERA de los
siguientes, el `score` del reporte queda **CAP a [LÍMITE] como máximo absoluto**,
independientemente de qué tan limpio esté el resto del código. Patrón adaptado
del modelo de auditor con veto items (ver `reglas/gobernanza.md`).

**Lista de veto items**:

1. **[Nombre del veto]**: [descripción específica + regla que viola].
2. ...
N. ...

**Reglas del cap**:

- Encontrar 1 veto item → `score ≤ [LÍMITE]`. Veredicto automático:
  `RECHAZADO` o `APROBADO CON CORRECCIONES` (nunca `APROBADO` limpio).
- Encontrar 2+ veto items → `score ≤ [LÍMITE_ESTRICTO]`. Bloqueo absoluto.
- El veto NO se puede negociar bajando severidad.
- El cap se levanta SOLO cuando se demuestra remediación (commit + test) y el
  revisor re-ejecuta la auditoría.

Reportar al inicio del reporte con bloque dedicado:

\`\`\`
### VETO ITEMS DETECTADOS
- [VI-1] <descripción>: \`archivo:linea\` — <evidencia>
- [VI-N] <descripción>: \`archivo:linea\` — <evidencia>
→ score CAP a [VALOR] ([N] veto items). Veredicto: [VEREDICTO].
\`\`\`

Si no se detecta ninguno: \`### VETO ITEMS DETECTADOS\n- Ninguno\`.
```

---

## Reglas para definir veto items

Antes de declarar un veto item, verifica:

1. **¿Existe una regla global que lo respalde?** Si no, no es veto. Crear o
   actualizar la regla primero (`reglas/<dominio>.md`).
2. **¿Es objetivamente detectable?** Un veto debe ser binario (presente o
   ausente). Criterios subjetivos como "código feo" no califican.
3. **¿Su presencia justifica bloquear el merge?** Si el equipo puede aprobar
   el código sin corregirlo, no es veto — es hallazgo regular.
4. **¿Es proporcional al dominio del revisor?** Un revisor de seguridad no
   declara vetos de estilo. Cada revisor solo veta lo de su dominio.
5. **¿Está la lista cerrada?** Una lista de 50 veto items es señal de mala
   curación. Lo razonable: 8-15 items por revisor.

---

## Escalas recomendadas

| Tipo de reporte | Cap con 1 veto | Cap con 2+ vetos |
|-----------------|---------------|-----------------|
| Score 0-100 (CVSSv3-like) | 60/100 | 30/100 |
| Score 0-10 promedio por dimensión | 6.0/10 | 3.0/10 |
| Score 0-1 (probabilístico) | 0.6 | 0.3 |

---

## Ejemplos en agentes existentes

- `agentes/revisor-seguridad-swl.md` — 10 veto items de OWASP Top 10 + secrets + CVEs
- `agentes/revisor-codigo-swl.md` — 10 veto items mapeando a `reglas/estilo-codigo.md`
  y `reglas/arquitectura.md`

---

## Cómo el ejecutor responde a un cap

Si recibes un reporte con veto items detectados:

1. **NO negocies la severidad**. El cap está justificado por regla global.
2. **Aplica las correcciones específicas** que el revisor indica con
   archivo:línea.
3. **Agrega un test que pruebe la corrección** (regression test). Sin test,
   el veto puede regresar.
4. **Solicita re-revisión** al mismo revisor. Si el veto desapareció, el cap
   se levanta y el score se recalcula sin penalización.
5. **Si NO puedes corregir** (limitación externa, blocker técnico): documenta
   en `.planning/AUDITORIA.md` y escala al humano. NUNCA marques el trabajo
   como completado con vetos abiertos.
