🤖 Action de review + cron de security

Pocock describe una "agent review action": una GitHub Action que "se ejecuta en un PR, hace checkout, verifica los tipos, ejecuta el agente de revisión (un prompt local) y responde 'looks good'." El secreto de toda Action está en su estructura: tiene un disparador (o on: — lo que conecta con la cadena), uno o más jobs (lo que se ejecuta), y dentro de cada job una secuencia de steps (los pasos). Este esquema siempre es el mismo — solo cambia lo que va dentro.

¿Por qué esto lo desbloquea tanto? Porque «run agents on GitHub Actions» es unreasonably effective" — puedes paralelizar todo lo que quieras sin preocuparte por los recursos de la máquina local. La cadena se ejecuta en la nube de GitHub: tu laptop puede estar apagada. El prompt local (un archivo de instrucciones de revisión que vive en el propio repo) es el cerebro del inspector: versionado junto con el código, igual que una skill. Error común: creer que necesitas un servidor propio funcionando las 24 horas. No: la Action solo se activa con el disparador, hace el trabajo y se apaga; pagas solo por los minutos usados.

Abajo está el YAML real de la review action — la primera de las dos piezas copiables de este módulo. Guárdala como .github/workflows/review.yml. Observa el esqueleto: on: (disparador), jobs:, y los steps: en el orden correcto. Copia y ajusta solo el comando de tu type check:

name: agent-review
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - name: Checkout PR
        uses: actions/checkout@v4

      - name: Type check
        run: npx tsc --noEmit        # guard rail barato e determinístico

      - name: Review agent
        run: npx claude -p "$(cat .github/review-prompt.md)" --output review.md
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

      - name: Comment on PR
        run: gh pr comment "$PR" --body-file review.md
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR: ${{ github.event.pull_request.number }}

Estos tres steps son la columna vertebral de la review action, en el orden que Pocock menciona: "haz checkout, type check, ejecuta el agente de revisión». El orden importa por economía: primero descargas el código y después ejecutas la revisión determinista y barata (el type check detecta errores obvios en segundos), y solo entonces gastamos tokens con el agente. Si el type check falla, muchas veces ni siquiera vale la pena despertar al agente — ya sabes que el PR está roto.

Esto es pura "economía de tokens" (módulo 1-5): el agente es el paso más caro, así que rodéalo de guard rails baratos. Otro motivo para seguir ese orden: el agente revisa mejor cuando el código ya compila. Error común: echarle todo al agente de una vez («revisa y corrige los tipos y ejecuta las pruebas»). No: separa los pasos. Lo determinista (type check, lint, pruebas) hace lo determinista; el agente hace lo que requiere criterio. Cada cual en lo suyo, y lo costoso al final.

El paso final de la review action es comentar en el propio PR — Pocock dice que el agente «responde “looks good”» ahí mismo. ¿Por qué comentar en el PR y no en un correo o un chat? Porque el PR es donde se toma la decisión: el comentario queda junto al diff, al lado de la discusión, y GitHub ya avisa a quienes lo siguen. Es el resultado natural del AFK en la nube: el agente trabaja solo y deja el dictamen visible, cómo hace el bot github-actions que publica un "Triage" con TL;DR y dificultad (viste esto en el módulo 4-4, Loops × Filas).

Aquí está el segundo valor del review (módulo 4-6): el comentario no sirve solo para gate ("esto es peligroso, detente"): te da observabilidad. Lees lo que encontró el agente y ves tu propio sistema de conexiones. Error común: dejar que el agente apruebe o rechace en silencio. Si el dictamen no aparece en el PR, pierdes la oportunidad de mejorar el harness con el tiempo — y caes en la trampa de «¿quién revisa a la IA que dice que todo está bien?». El comentario visible es lo que te mantiene al mando.

La segunda automatización es la joya del módulo. Pocock cuenta que el modelo Fable encontró bugs profundos y fallas de seguridad que otros no vieron, pero recalca: no es magia del modelo. "Descubrirías estos bugs con modelos más baratos si buscaras en los lugares correctos y usaras el prompt/harness adecuado." La receta: un cron diario de revisión de seguridad que "cada día revisa una parte nueva del repo con un modelo relativamente sencillo". El cron es el programador; lo «rotativo» es el truco: no revisas todo el repo cada día (es caro y lento), revisas una sección por día, recorriendo el repositorio.

¿Por qué funciona tan bien la rotación? Porque distribuye el costo en el tiempo y, tarde o temprano, lo cubre todo. ¿Un repo con 30 carpetas? Una carpeta al día → cobertura total en 30 días, con un modelo barato. Y el beneficio real no es solo encontrar el bug: es la lección. «¿Qué aprendiste? Que hay problemas de seguridad en tu código; deberías tener algo que se ejecute y revise si hay más en el futuro». Ese es el corazón de los sistemas que se mejoran a sí mismos (módulo 4-5): no revisas solo el código, revisas el sistema que produce el código. Error común: ejecutar la revisión de seguridad en todo el repo de una vez — sale caro, tarda y al final terminas desactivándola. La rotación es lo que hace que el hábito sea sostenible.

La línea de crontab es el corazón técnico de esto y la segunda pieza del módulo que puedes copiar. Son cinco campos: minuto, hora, día del mes, mes y día de la semana; y el * significa "todo". La línea de abajo es la real que pegas en el schedule: de una GitHub Action para ejecutarla todos los días a las 9h UTC. Copia:

# campos do cron:  minuto  hora  dia-do-mês  mês  dia-da-semana
# "0 9 * * *"  =  todo dia às 09:00 UTC
on:
  schedule:
    - cron: "0 9 * * *"   # security review diário, fatia rotativa do repo

Pocock describe el flujo completo de explora: «error de telemetría (Sentry) → crea un issue → etiqueta explore → el agente devuelve dato estructurado (¿se puede corregir ya o hace falta una persona?) → implementa → revisa → etiqueta auto-merge o le avisa a una persona." El punto clave es el structured output: en lugar de que el agente devuelva un texto larguísimo, devuelve campos fijos: gravedad, si se puede corregir automáticamente y confianza. ¿Por qué? Porque un campo «se puede corregir automáticamente: sí/no» es algo que otro programa puede leerlo y usarlo para decidir el siguiente paso por su cuenta. Texto suelto, no.

Es lo que conecta toda la cola (módulo 4-4): la issue recibe labels (agent:explore → agent:in-progress), el agente hace la clasificación AFK y devuelve el dato estructurado, y ese dato decide el enrutamiento: corregirlo de inmediato o enviar el punto de control human-in-the-loop más adelante. «Push human-in-the-loop checkpoints further toward the final output.» Error común: dejar que el agente responda en prosa e intentar adivinar con una regex si aprobó. Frágil. Pide JSON con campos definidos — así la automatización encadena acciones sin ambigüedad.

{
  "issue": 795,
  "severity": "high",
  "auto_fixable": true,
  "confidence": 0.9,
  "root_cause": "input não validado em /login",
  "suggested_label": "agent:implement",
  "needs_human": false
}

Al final del flujo, el agente «tag auto-merge o le avisa a una persona". El auto-merge es el máximo nivel de AFK: el PR entra en el código principal sin que nadie haga clic. Pero también es el lugar más peligroso; por eso el nombre del tema incluye «con cautela». Pocock insiste en el objetivo correcto: «push human-in-the-loop checkpoints further toward the final output" — empuja el punto de aprobación hacia adelante, eliminando puntos de control donde se pueda, con cuidado. No se trata de sacar a las personas de todo, sino de apartarlas de donde no aportan valor.

¿Dónde se puede hacer auto-merge con tranquilidad? Cuando «el PR solo refactoriza internamente, no cambia el comportamiento; la IA dice “no hace falta revisarlo”». Pero entonces llega la pregunta de oro de Pocock: "¿quién revisa a la IA que dice que todo está bien?" (¿quién revisa a la IA que dice que todo está bien?). La respuesta: necesitas muestrear algunos PR que el agente aprobó por su cuenta, para calibrar la confianza con el tiempo. «We're reviewing not just the code, but the SYSTEM that produces the code.» Error común: activar auto-merge en todo el día 1. Empieza con poco (solo los campos auto_fixable: true + confidence ≥ 0.9 + comprobación de tipos en verde), audita durante unos días y solo entonces amplía. La cautela es lo que mantiene confiable el sistema.