Entre "pedi uma mudança" e "minha equipe está usando" existe um caminho com portões. Conhecê-lo ajuda a confiar no processo — e a entender o que está acontecendo quando a conversa mostra o progresso.
As etapas#
- Rascunho em Dev. Toda mudança nasce no ambiente Dev — a bancada. Nada do que acontece aqui afeta a sua operação.
- Compilação e builds. A fonte estruturada e os artefatos gerados passam pelos oráculos declarados. Erro, timeout ou ausência de evidência bloqueiam o candidato.
- Inicialização de verificação. O backend candidato sobe num ambiente real e o frontend candidato é associado à mesma identidade de entrega.
- Smokes declarados. As rotas escolhidas para aquele fluxo recebem chamadas reais. O receipt registra quais métodos e caminhos foram exercitados; não presume cobertura de áreas que não aparecem nele.
- Correção em rodadas. Falhou algo? A plataforma captura o erro observado, corrige e submete uma nova revisão. As rodadas têm limite: se o portão não fecha, o candidato permanece não entregue.
- Comprovante e promoção. Só o candidato com todos os checks obrigatórios daquela política recebe o comprovante de entrega. A promoção usa a identidade registrada para evitar trocar os bytes depois da verificação.
O que isso significa no dia a dia#
- "Verificado" tem denominador. Abra o comprovante e veja candidato, política e checks declarados; não trate o selo como garantia genérica.
- Mudança invalida evidência antiga. Fonte, configuração ou artefato relevante alterado exige um novo ciclo antes de outra entrega verificada.
- Falha é informação, não segredo. Se uma verificação não passa, você fica sabendo — preferimos um "ainda não" honesto a um "pronto" quebrado.
Limite do receipt: ele não prova ausência de bugs, adequação regulatória, correção de toda regra de negócio ou disponibilidade futura. É evidência assinada dos checks declarados para um candidato específico.