PM-001 — Proposta apresentada antes de enviada
Conflito entre documentos
Aberto a partir da Análise PRDs × v0.3, depois da decisão de adotar os PRDs como fonte de construção (DEC-008 Adoção dos PRDs por incremento). Precisa de decisão das sócias antes da construção do incremento afetado.
O que precisa mudar?
O v0.3 exige que a proposta tenha estados próprios e que exista o estado apresentada antes de enviada. O PRD do Incremento 6 só trata de proposta validada (Gate 11) e apresentação validada (Gate 12), sem registrar envio.
Por quê?
A regra do v0.3 protege o vendedor: a proposta não vai para o e-mail do cliente antes de ser apresentada e explicada. Sem esse estado, o sistema não consegue nem medir quantas propostas foram enviadas sem apresentação.
Exemplo
O vendedor valida a proposta na sexta, manda por e-mail no sábado e a reunião só acontece na terça. Hoje, para o sistema, isso é indistinguível de uma proposta apresentada pessoalmente.
Preenchido por Julio:
Análise
- Requisitos e decisões afetados: ver a propriedade
afetaacima. - Impacto: decide o conteúdo do incremento correspondente. Quanto mais tarde for decidido, maior o retrabalho.
- Respeita as regras do produto (IA sugere, humano valida; ética; gates)? Sim nas duas versões; a diferença é o grau de controle.
Recomendação
Adotar a regra do v0.3: acrescentar ao PRD do Incremento 6 os estados da proposta (validada, apresentada, enviada) e a autorização de envio, mantendo o Gate 12 como está.
Decisão
- Resultado: aprovado — motivo: confirmado pelo Conflito 1 da Reconciliação Final v0.3 × PRDs. A Proposal é validada, apresentada humanamente e só depois enviada;
SEND_AUTHORIZEDentra como Operational Control (Send Authorization), não como Gate 14 numerado. - Decidido por: Julio — data: 2026-09-20
Aplicação pendente
A decisão está registrada. A edição do PRD do Incremento 6 v2 para incluir os estados validada/apresentada/enviada e o Send Authorization acontece quando esse incremento entrar em construção.
O que foi alterado
| Arquivo | Mudança |
|---|