Prontidão: não está pronto; restam seis decisões impeditivas e várias lacunas médias.
B1 — conflito de agente. AC-4 diz “o responsável seleciona”, D2 diz o solicitante e C18 diz o coordenador, enquanto o contexto aprovado permite o solicitante ou o coordenador e restringe o responsável à visualização. Essas opções permitem testes incompatíveis de autorização e segurança. O responsável de Produto deve confirmar a regra aprovada em todos os artefatos; a evidência é o registro de decisões/contexto.
B2 — conflito de estado. Uma história cria Assigned, mas o modelo de estados aprovado não contém Assigned. As implementações poderiam acrescentar uma nova transição de fluxo de trabalho ou manter Ready com um indicador de campo, afetando persistência, análise, migração e testes. Produto é responsável pela decisão: atribuir um aceitante muda o estado do fluxo de trabalho ou apenas a apresentação do campo?
B3 — contradição de notificação. “Notificá-los de modo apropriado” permite e-mail, push, notificação no aplicativo ou nenhuma notificação; o registro de decisões diz que não haverá notificação nesta versão. Também deixa indefinidos o destinatário, o gatilho, o comportamento de repetição e a opção de cancelamento. Produto deve remover ou excluir explicitamente a notificação deste limite; ninguém deve inventar um comportamento.
B4 — elegibilidade e dados inválidos. “Pessoa certa” poderia significar qualquer usuário, membro ativo, membro qualificado para o papel ou pessoa sugerida. O limite aprovado é membro ativo do espaço de trabalho, mas o critério de aceitação não trata do envio de um usuário inativo/não membro nem de desativação simultânea. Produto/Engenharia devem definir rejeição e recuperação observáveis; Design será responsável pelo texto posteriormente.
B5 — comportamento sem atribuição. “Ofereça suporte a casos não atribuídos e etc.” não define se o campo pode ficar vazio na criação, se pode ser limpo depois, quem pode limpá-lo, como será exibido nem se Ready pode prosseguir. Produto é responsável por essas decisões; “etc.” não é testável.
B6 — salvamento/erro/concorrência. “Salva” poderia significar exibição local otimista ou persistência confirmada no servidor. Faltam: carregamento, falha, nova tentativa, envio repetido, dois editores, visualização desatualizada, comportamento de auditoria e reversão. Engenharia propõe as opções; Produto aprova a regra visível para o usuário.
Lacunas médias: “fácil”, “rapidamente” e “em tempo real” não têm medidas; o texto exato e os nomes analíticos estão explicitamente pendentes; ordem do teclado, rótulo programático, foco após erro e indicador que não dependa de cor precisam de critérios. “Todos os usuários” entra em conflito com permissões de edição específicas por papel e deve diferenciar visualização de edição.
Ordem das decisões: agente/estado/notificação → ausência de atribuição e elegibilidade → salvamento/concorrência/erro → interação acessível/texto → análise/desempenho. A prontidão para testes só será alcançada depois que os itens B se tornarem critérios observáveis.