Você divide uma tarefa grande em cinco cards de kanban, cinco agentes começam a trabalhar em paralelo e todos entregam no prazo. Então você mescla tudo e percebe o problema: dois workers inventaram respostas diferentes para a mesma questão de design, um arquivo foi embaralhado por três cards ao mesmo tempo e ninguém revisou nada — porque “revisão” nunca fez parte do fluxo. Essa é a parte mais dolorosa da colaboração multi-agente, e é exatamente o que um conjunto de PRs mesclados em 10 de agosto de 2026 (#83412, #83423, #83424, #83428) resolve: o kanban do Hermes agora tem um ciclo de revisão de primeira classe, além de três salvaguardas contra o caos. Aqui está o fluxo completo — do envio do trabalho para revisão até ele ser devolvido — e as convenções que mantêm os agentes paralelos honestos.

O ciclo de revisão: implementador → review lane → veredito

Os cards de kanban agora têm uma fase de revisão adequada. Quando um implementador termina, ele submete via kanban_request_review:

kanban_request_review(
  task_id="T-42",
  summary="Implemented the export feature; verified with 3 sample files",
  reviewer="code-reviewer"    # optional
)

summary é obrigatório — ela informa ao revisor o que foi construído e como foi verificado; reviewer é opcional; o conteúdo submetido é redigido automaticamente. O card vai para a review lane, onde um perfil de revisor o pega e a skill sdlc-review carrega automaticamente. O revisor dá um de três vereditos:

Veredito	Ação	Significado
Aprovar	kanban_complete	Critérios de aceitação atendidos, tarefa encerrada
Solicitar mudanças	kanban_comment + kanban_request_changes(reason=...)	Restam defeitos corrigíveis; o card volta para o implementador original
Escalonar	kanban_block	É necessária uma decisão humana ou um pré-requisito externo

A proveniência é preservada: se o implementador corrige o card e pede revisão novamente sem indicar um revisor, ele volta para o mesmo perfil de revisor — sem reatribuição aleatória, com continuidade de contexto de revisão.

Lentes de revisão rotativas: rodada 1 leitura a frio, rodada 2 execute, rodada 3 audite o contrato

A skill sdlc-review tem um design inteligente: cada rodada olha o trabalho por uma lente diferente em vez de repetir a mesma inspeção. O número da rodada é a contagem de tentativas anteriores de changes_requested mais um (rodada 1 = zero devoluções, rodada 2 = uma, e assim por diante):

• Rodada 1 — Artefato: leia o diff ou a entrega a frio, antes do resumo do implementador; forme um julgamento independente e depois compare-o com a narrativa de handoff, investigando cada divergência;
• Rodada 2 — Execução: faça checkout do trabalho e execute-o de fato via terminal — compile, teste e exercite o comportamento relatado você mesmo, em vez de reler o artefato;
• Rodada 3+ — Contrato: releia o corpo original da tarefa do card e os critérios de aceitação, audite a entrega estritamente contra eles e verifique se cada item de todas as rodadas anteriores de request_changes realmente foi implementado.

O mesmo princípio se aplica quando você distribui revisores paralelos ad hoc via delegate_task: dê a cada revisor um briefing diferente (um só com diff, outro com contexto completo, outro com checkout-e-execute) em vez de briefings idênticos. Briefings idênticos produzem vereditos correlacionados e achados duplicados; lentes variadas cobrem mais classes de defeitos pelo mesmo custo de revisão.

Salvaguarda 1: propriedade de decisões — um dono por questão

O modo clássico de falha multi-agente é o “split brain”: dois workers resolvem a mesma questão de design de forma independente com respostas diferentes. Um novo contrato de propriedade de decisões no KANBAN_GUIDANCE bloqueia esse caminho diretamente:

• Decisões de design pertencem ao orchestrator e são tomadas antes do fan-out;
• Nenhum par de cards subárvore pode decidir a mesma questão;
• Todo corpo de card filho deve carregar as decisões das quais depende — porque os workers não conseguem ver o contexto dos irmãos.

O exemplo da documentação diz perfeitamente: um card de exportador e um card de importador não podem “inventar” cada um o formato de arquivo. O orchestrator escolhe o formato primeiro e carimba os dois corpos de card, então os dois workers escrevem contra o mesmo contrato e nada colide na hora do merge.

Salvaguarda 2: pontos de colisão — sinalize, não acumule

Edições paralelas no mesmo arquivo vão colidir; a nova convenção lida com isso logo de cara. Quando um worker percebe que o arquivo que está prestes a tocar continua atraindo conflitos de cards irmãos, ele deixa um kanban_comment começando com hotspot: (ex.: hotspot: src/config.py — três cards estão editando este arquivo) e o expõe nos metadados de conclusão. Um orchestrator que vê 2+ sinalizações em um caminho cria um card de decomposição — separando aquele arquivo quente da fila antes de despachar mais trabalho que o toque. Para conflitos que já aconteceram, o merge-reconciler arbitra.

A conclusão

Juntas, essas mudanças transformam o kanban de “despachar trabalho, coletar resultados” em um ciclo de desenvolvimento completo: revisão, perspectivas rotativas, propriedade de decisões e alerta precoce de conflitos. O ponto ideal é óbvio — repositórios onde vários agentes trabalham em paralelo e a qualidade precisa de um portão; um único agente fazendo tarefas pequenas não precisa de um fluxo tão pesado. Para a superfície completa de comandos do kanban, veja a referência de comandos do hermes-kanban; para mais convenções em setups multi-agente, também escrevemos sobre a cadeia de diretórios do AGENTS.md.