Papéis e vereditos

Cada card ligado a uma task tem um papel. São dois, e a diferença não é burocrática: é o que separa “eu fiz” de “alguém conferiu”.

Implementer

O card que faz o trabalho. Ele é a participação principal da task. Seu relatório pode trazer um veredito, mas é uma autoavaliação — enquanto há revisor ligado à task, ela não propõe nada.

Reviewer

O card que julga o trabalho. Só um revisor pode concluir uma task que exigiu revisão. O revisor reporta com um veredito formal, e é esse veredito — não a prosa — que propõe a conclusão.

review: want

Declarar review: "wanted" no contrato torna a revisão obrigatória. Isso vence a assinatura delegada do orquestrador: nem implementer, nem outsider, nem o orquestrador gravam done/failed — só um card com papel reviewer. A delegação existe para destravar fluxo, não para dispensar o revisor que a task pediu. O humano pela interface continua livre.

O app não cria o revisor sozinho. Escolher quem julga é decisão do orquestrador; o app só ensina a saída (ligar um card como reviewer, ou pedir o status ao humano).

Como ler um relatório sem ser enganado

• Relatório de outro agente não é fato. Se a afirmação tem consequência, verifique você mesmo.
• Um ok: true com gates vazios não é entrega. Peça a evidência: qual comando, qual saída, qual linha.
• Suíte rodada em árvore compartilhada mente. Uma falha suspeita se refaz em worktree isolado no HEAD.
• Progresso não é entrega. “Commite mais tarde” é outra coisa.

Veredito como histórico

Os julgamentos são append-only, uma linha por rodada. Ver Dependências e sprints para o que acontece depois de um veredito.