Fluxos de aprovação
Uma aprovação só vale alguma coisa se a coisa aprovada for a coisa que sai.
Isto descreve um design, não um serviço em funcionamento
O problema
Aprovações geralmente vivem fora da ferramenta que publica. Uma captura de tela vai para um cliente, o cliente responde que sim, e então o texto muda. A aprovação agora se refere a um rascunho que ninguém tem, e a ferramenta não sabe disso, então publica o que foi entregue por último.
Como o produto foi projetado
- Uma aprovação é vinculada exatamente ao conteúdo que foi revisado. Editar um rascunho aprovado invalida a aprovação e diz qual campo mudou, em vez de simplesmente carregar a decisão antiga adiante.
- Um revisor pode aprovar, pedir mudanças ou rejeitar, e um comentário é obrigatório para qualquer coisa além de aprovar, então o autor nunca fica sem saber o que corrigir.
- A regra vive na camada de aplicação compartilhada, então o app web, a API REST, o servidor MCP, a CLI e os webhooks todos a seguem. Nenhuma superfície tem um atalho para contornar a revisão.
O que já está construído de fato
Os estados de aprovação, a superfície de revisão, as regras de reaprovação e os eventos de auditoria por trás deles estão construídos. O que não está construído é a última etapa, porque nenhum conector concluiu sua definição de pronto, então um post aprovado ainda não tem para onde ir.
Encontrei algo errado nesta página
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.