🤖 Action de review + cron de security

Pocock descreve uma "agent review action": uma GitHub Action que "roda num PR, faz checkout, type check, roda o review agent (um prompt local), e responde 'looks good'." O segredo de toda Action é o esqueleto: ela tem um gatilho (o on: — o que liga a esteira), um ou mais jobs (o que executa), e dentro de cada job uma sequência de steps (os passos). Esse esqueleto é sempre o mesmo — muda só o que vai dentro.

Por que isso destrava tanto? Porque "run agents on GitHub Actions é unreasonably effective" — você paraleliza quanto quiser sem se preocupar com recursos da máquina local. A esteira roda na nuvem do GitHub: seu notebook pode estar desligado. O prompt local (um arquivo de instruções de review que mora no próprio repo) é o cérebro do inspetor — versionado junto com o código, igual a uma skill. Erro comum: achar que precisa de um servidor próprio rodando 24h. Não: a Action só acorda no gatilho, faz o trabalho, e desliga — você paga só pelos minutos usados.

Abaixo está o YAML real da review action — a primeira das duas peças copiáveis deste módulo. Salve como .github/workflows/review.yml. Note o esqueleto: on: (gatilho), jobs:, e os steps: na ordem certa. Copie e ajuste só o comando do seu 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 }}

Esses três steps são a espinha da review action, na ordem que Pocock cita: "faz checkout, type check, roda o review agent". A ordem importa por economia: primeiro você baixa o código, depois roda a checagem determinística e barata (o type check pega erros óbvios em segundos), e só então gasta tokens com o agente. Se o type check falhar, muitas vezes nem vale acordar o agente — você já sabe que o PR está quebrado.

Isso é puro "economia de tokens" (módulo 1-5): o agente é o passo mais caro, então cerque-o de guard rails baratos. Outro motivo da ordem: o agente revisa melhor com o código já compilando. Erro comum: jogar tudo no agente de uma vez ("revise e arrume os tipos e rode os testes"). Não — separe os passos. O determinístico (type check, lint, testes) faz o que é determinístico; o agente faz o que exige julgamento. Cada um no seu quadrado, e o caro por último.

O passo final da review action é comentar no próprio PR — Pocock diz que o agente "responde 'looks good'" ali mesmo. Por que comentar no PR e não num e-mail ou num chat? Porque o PR é onde a decisão acontece: o comentário fica colado ao diff, ao lado da discussão, e o GitHub já avisa quem está acompanhando. É a saída natural do AFK na nuvem — o agente trabalha sozinho e deixa o parecer visível, como faz o bot github-actions que posta um "Triage" com TL;DR e dificuldade (você viu isso no módulo 4-4, Loops × Filas).

Aqui mora o segundo valor do review (módulo 4-6): o comentário não serve só de gate ("isto é perigoso, segura") — ele te dá observabilidade. Você lê o que o agente achou e enxerga seu próprio encanamento. Erro comum: deixar o agente aprovar/reprovar em silêncio. Se o parecer não aparece no PR, você perde a chance de melhorar o harness com o tempo — e cai naquela armadilha do "quem revisa a IA que diz que está tudo bem?". O comentário visível é o que mantém você no comando.

A segunda automação é a joia do módulo. Pocock conta que o modelo Fable achou bugs profundos e falhas de segurança que outros não viram — mas frisa: não é mágica do modelo. "Você descobriria esses bugs com modelos mais baratos se olhasse nos lugares certos e desse o prompt/harness certo." A receita: um cron diário de security review que "cada dia checa uma parte nova do repo, com um modelo relativamente simples". O cron é o agendador; o "rotativo" é o truque — você não revisa o repo inteiro todo dia (caro e lento), você revisa uma fatia por dia, girando pelo repositório.

Por que rotativo funciona tão bem? Porque dilui o custo no tempo e cobre tudo eventualmente. Repo com 30 pastas? Uma pasta por dia → cobertura total em 30 dias, com um modelo barato. E o ganho real não é só achar o bug: é a lição. "O que você aprendeu? Que há problemas de segurança no seu código — você deveria ter algo que roda e checa por mais no futuro." Isso é o coração dos sistemas auto-melhoráveis (módulo 4-5): você não revisa só o código, revisa o sistema que produz o código. Erro comum: rodar o security review no repo inteiro de uma vez — fica caro, demora, e você acaba desligando. A rotação é o que torna o hábito sustentável.

A linha de crontab é o coração técnico disso — e a segunda peça copiável do módulo. São cinco campos — minuto, hora, dia-do-mês, mês, dia-da-semana — e o * significa "todo". A linha abaixo é a real que você cola no schedule: de uma GitHub Action pra rodar todo dia às 9h UTC. Copie:

# 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 descreve o fluxo completo do explore: "bug de telemetria (Sentry) → cria issue → label explore → o agente retorna dado estruturado (dá pra corrigir já ou precisa de humano?) → implementa → revisa → tag auto-merge ou pinga o humano." O ponto-chave é o structured output: em vez de o agente devolver um textão, ele devolve campos fixos — gravidade, se é auto-corrigível, confiança. Por quê? Porque um campo "auto-corrigível: sim/não" é algo que outro programa consegue ler e usar pra decidir o próximo passo sozinho. Texto solto, não.

É o que liga a fila inteira (módulo 4-4): a issue ganha labels (agent:explore → agent:in-progress), o agente faz a triagem AFK e devolve o dado estruturado, e esse dado decide o roteamento — corrige já, ou empurra o human-in-the-loop checkpoint mais pra frente. "Push human-in-the-loop checkpoints further toward the final output." Erro comum: deixar o agente responder em prosa e tentar fazer um regex adivinhar se ele aprovou. Frágil. Peça JSON com campos definidos — assim a automação encadeia sem ambiguidade.

{
  "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
}

No fim do fluxo, o agente "tag auto-merge ou pinga o humano". Auto-merge é o ápice do AFK: o PR entra no código principal sem ninguém clicar. Mas é também o lugar mais perigoso — por isso o nome do tópico é "com cautela". Pocock insiste no objetivo certo: "push human-in-the-loop checkpoints further toward the final output" — empurre o ponto de aprovação pra frente, removendo checkpoints onde dá, com cuidado. Não é tirar o humano de tudo; é tirá-lo de onde ele não agrega.

Onde dá pra auto-mergear com tranquilidade? Quando "o PR é só refactor interno, não muda comportamento — a IA diz 'não precisa revisar'". Mas aí vem a pergunta de ouro de Pocock: "who reviews the AI that says it's fine?" (quem revisa a IA que diz que está tudo bem?). A resposta: você precisa amostrar alguns PRs que o agente aprovou sozinho, pra calibrar a confiança no tempo. "We're reviewing not just the code, but the SYSTEM that produces the code." Erro comum: ligar auto-merge em tudo no dia 1. Comece estreito (só os campos auto_fixable: true + confidence ≥ 0.9 + type check verde), audite uns dias, e só então amplie. Cautela aqui é o que mantém o sistema confiável.