Comitê de agentes (scouts + Gate)¶

O que é¶

O catálogo, agente por agente, do comitê que alimenta a Entrada 1 da engenharia-regenerativa. Diferente do loop de novos projetos, o comitê não é um pipeline — é um grupo de agentes autônomos independentes, cada um vigiando uma fonte diferente, que convergem num único filtro (attention-gate) antes de chegar no humano.

backlog-scout ───────┐
ci-scout ─────────────┤
ux-scout ─────────────┼──► gate-inbox.jsonl ──► attention-gate ──► digest (P0-P4) + issues no Linear
tech-debt-scout ──────┤
triagem-grupos-tech ──┘

release-scout ──► canal próprio, entrega direta (não passa pelo Gate)
prod-guardian ──► age no merge (doc + grafo + ledger de prod), não passa pelo Gate

Todos são agents (.claude/agents/*.md), não skills — sempre topo da pilha, disparados por rotina agendada ou pedido direto, nunca chamados de dentro de outra skill.

Os scouts¶

Agente	Vigia	Cadência	Cria issue?
`backlog-scout`	Backlog do Linear (tickets sem responsável/projeto, baixo risco, `estimate` XS/S/M)	1x/dia, teto 5/dia	Não — abre PR draft
`ci-scout`	Saúde de produção (Sentry + Railway); agente padrão de qualquer investigação em prod	21h BRT ou sob demanda	Não — diagnostica/aprende
`ux-scout`	PostHog — erro de comportamento sem exceção (rage/dead clicks)	Piggyback no ci-scout	Não — só reporta
`release-scout`	Commits/PRs desde a última tag	Ao criar tag, ou fim de sprint	Não — fala direto, não passa pelo Gate
`tech-debt-scout`	Código modificado recentemente (função grande, `any`, sem teste)	Diário + semanal	Não — só relata
`deep-search`	Issues em `To deep` — deep research, gera PRD+sub-issues	Rotina de grooming, teto 5/rodada	Cria sub-issues
`triagem-grupos-tech` (global)	Grupos de WhatsApp de tech/dev/suporte	Rotina agendada	Não — reporta ao Gate

O Gate (`attention-gate`)¶

O único que fala diretamente com o humano sobre o que chega na fila — hub aberto, não lista fechada. Qualquer agente novo pode reportar (append em gate-inbox.jsonl). Ele:

Lê a fila compartilhada.
Reclassifica cada item em P0–P4 via a régua priorize (impacto × urgência + esforço da estimate) — não confia na severidade sugerida por quem reportou.
Decide o canal por situação: push, Slack #attention-gate (sempre), e-mail draft (quando merece registro), issue no Linear (rastreio/ação).
Entrega um digest único filtrado (P0/P1 na hora, P2 no daily, P3 no weekly, P4 nunca).
É o único que cria issue no Linear, direto (sem aprovação humana), com dedup rígido (atualiza issue existente em vez de duplicar). Decide a coluna consultando a skill linear: Deep Search se já analisado, To deep se tem info suficiente, Backlog se vago demais.

Cadência: sem rotina própria — encadeia depois do ci-scout (21h BRT), consolidando um digest diário. Trade-off aceito: o Gate fica acoplado ao ci-scout estar ativo; alerta em tempo real fica por conta do Sentry nativo. Exceção: pr-guardian encadeia o Gate na hora ao escalar risco pós-merge.

Só o Gate notifica. As notificações nativas de todos os scouts estão desligadas — quem notifica é sempre o attention-gate.

Por que `release-scout` pula o Gate¶

Tem canal de entrega próprio (#releases + e-mail) que já resolve o alert-fatigue — entrega briefing de negócio, não é "alerta". triagem-grupos-tech não pula o Gate, reporta normal via gate-inbox.jsonl.

Manutenção de doc — não é mais um agente dedicado¶

Existia um docs-agent que mantinha grafo/wiki/READMEs. Foi aposentado (2026-07-10): no fluxo de PR, quem mantém as três superfícies é o prod-guardian (pós-merge); fora de um PR, cada superfície tem entrada própria — o wiki-agent pro wiki, a skill to-readme pro README, a skill graphify pro grafo.

Os dois Guardians¶

Quebrado em dois agentes (2026-07-10) porque revisar o diff (antes do merge) e mapear o que subiu (depois do merge) são trabalhos diferentes, com gatilho, foco e modelo diferentes. Juntos substituem o antigo claude-code-review.yml (removido por redundância).

`pr-guardian` — o revisor (dispara: PR aberto/sincronizado)¶

Pergunta "isso é seguro pra mergear, e entrega o que o PRD pediu?":

Segurança de merge — usa graphify (ver codebase-grafo) pra achar o blast radius (só lê, não atualiza); revisa qualidade/bug/segurança como dev sênior; se toca UI, também faz revisão de design (impeccable critique/audit, ver impeccable); checa Sentry, spec vs. Linear/PRD, lê o check do TestSprite (ver testsprite), e faz governança de telemetria/dados. Entrega veredito ✅/🚫.
Rollback de migration — PR com migration nova sempre ganha o script de rollback companheiro.

Se o PR já mergeou antes do veredito e é risco: escala (issue + Gate + encadeia attention-gate na hora). Roda em model: opus (effort: xhigh) — papel de revisor/juiz. Nunca corrige código sozinho, nunca aprova/mergeia; não mexe no wiki/grafo.

`prod-guardian` — o cartógrafo (dispara: PR mergeado)¶

Age depois que o código entrou na main:

Guardião da doc — reconcilia o wiki (via to-wiki, marcando antes/depois) e atualiza o grafo (graphify).
Ledger de lançamento — cria PostHog annotation com timestamp do merge, formato [release] PR #N — título | task | kind | area.
Rede de segurança pós-deploy — só risco alto: scaffold de feature flag (kill-switch).
Log de auditoria em .claude/agents/memory/prod-guardian.jsonl.

Também dono do README (to-readme) e — quando mexe em UI — mantém o DESIGN.md honesto (ver impeccable). Não re-revisa segurança nem código. Roda em model: sonnet (effort: high) — cartógrafo/escriba com algum julgamento.

Memória de cada scout + mem0¶

Cada scout mantém memória própria (.claude/agents/memory/<nome>.jsonl) para dedup factual ("já vi este achado?"). O mem0 é a camada semântica entre sessões ("o que já foi decidido sobre isto?") — os hooks carregam contexto automaticamente. Muda o comportamento em: attention-gate (lembra o que o humano desprioriza), pr-guardian (decisão por área, "módulo que já queimou"), deep-search (causa-raiz/PRD já pesquisada), tech-debt-scout (dívida conscientemente aceita).

Relacionado¶

engenharia-regenerativa · loop-engineering · skills · testsprite · impeccable · codebase-grafo · mem0 · visao-geral