workflow /monitor — a quarentena da fila

Este workflow é um comando, não um .js. /monitor sem parâmetro pega a lista da coluna Monitoring e vira um workflow dinâmico: spawna um subagente por card, em paralelo, e cada um atualiza o próprio card no fim. Com um card (/monitor DEV-123), roda um só — mesma lógica, lote de 1.

Trabalha a quarentena pós-merge: o card já está em produção e fica em observação até o soak fechar.

Clique no diagrama para a versão interativa (monitor.html): tema claro/escuro, pan/zoom, busca, três views guiadas e export PNG/SVG. A fonte é o JSON (docs/agents/monitor.architecture.json), nunca o .svg.

O conteúdo do card decide a skill

O comando não tem "uma skill". Ele lê o card e escolhe a da cesta do agente-monitor que aquele card pede:

Situação	Veredito
14 dias limpos, com evidência de uso	move pra Done
soak em curso	comenta o que foi procurado e o dia do soak
erro atribuível à entrega	diagnostica, comenta, classifica (triage) e sugere P/esforço
regressão feia	comenta e move pra Blocked
sem sinal de uso	diz isso: não é aprovação, é ausência de dado

Silêncio não é evidência. Card sem erro no Sentry pode significar "está de pé" ou "ninguém usou". Por isso a busca é dirigida àquela entrega — telemetria daquela feature, erro naquela área — nunca varredura genérica.

As outras skills entram por situação: prod-guardian no merge recente (wiki, grafo, PostHog annotation, ledger), impeccable nas lentes de monitoração (critique/audit) se tocou UI, testsprite-e2e apenas pra ler o check, release-manager no fim de sprint.

pr-guardian não é deste comando — é pré-merge e dirigido por evento de PR. E o monitor não abre issue: achado novo vai pra skill triagem, a única porta de issue.

O grafo de agentes

O desenho acima é o sistema; este é o grafo de agentes — quantas chamadas rodam e a que custo.

O degrau de modelo sai do card, não do comando (régua skill-modelo-effort): risco sobe (crítico · P0/P1 · L/XL) → Opus; trabalho mecânico e volumoso → Haiku; o meio é o dia a dia → Sonnet.

Fan-out sem barreira: nenhum card espera o outro, porque nenhum depende do resultado do outro. E não existe consolidador de estado — o board é o estado, e quem atualiza o card é o subagente que o trabalhou. O relato do fim é leitura, não decisão.

Dois destinos, sempre

Desfecho	Vai pra
fechou	Done
não fechou	fica em Blocked, com o motivo escrito no card

Resultado parcial declarado vale mais que conclusão inventada — e é o que permite alguém desbloquear em vez de refazer o trabalho do zero.

Regras que valem no run inteiro

• Produção é READ-ONLY. Ler Sentry/PostHog/Railway/Supabase e o código, sim; mutar env, fila, banco, deploy ou prompt, nunca.
• Nunca chamar API de parceiro pra testar — em débito, uma chamada de teste pode gerar cobrança real. Nunca mandar mensagem pela Ju ou pelo Abel — chega no WhatsApp de cliente real.
• A skill é a autoridade. Onde o comando e o SKILL.md discordarem, manda o SKILL.md — senão o comando vira uma segunda verdade sobre o método.

Todo workflow tem os dois desenhos — o do sistema (quais peças existem e quem é dona de quê) e o do grafo de agentes (quantas chamadas rodam, em que padrão, a que custo). É a regra da skill to-wiki.