Por que o brief precisa da sua aprovação

Deixar um agente “só implementar” é barato no curto prazo e caro no médio. Sem um PRD fechado, o worker inventa escopo, escolhe a stack errada ou acopla CMS onde o brief pedia HTML estático.

Brief é contrato, não rascunho

No Manager, o agente de briefing escreve o PRD na issue: objetivo, premissas, escopo, fora de escopo, critérios de aceite e riscos. Você lê na UI e aprova — ou devolve com pergunta objetiva via bloqueio.

Só depois disso o estágio IMPLEMENT sobe. Workers não negociam premissa em silêncio; se algo estiver ambíguo, o caminho certo é manager issue block, não um PR surpresa.

O que o gate evita

• CMS/Neon onde o produto pediu arquivos no repo.
• Landing reescrita quando o pedido era blog.
• Deploy direto sem preview revisável.

Premissas explícitas no brief são o antídoto contra “o agente assumiu CMS”. Se a origem do conteúdo muda, o desenho inteiro muda — e isso precisa do seu aval antes do primeiro commit.

Como aprovar bem

1. Confira premissas (estático? sem banco? identidade visual?).
2. Olhe os critérios de aceite: eles viram o checklist do QA.
3. Corte o que estiver fora de escopo em vez de “deixar para depois”.

Aprovou? O time é enfileirado. Recusou? O brief volta. Em ambos os casos, o Manager registra a decisão na thread de negócio — sem transcript de ferramenta poluindo o comentário.