Fluxo de Desenvolvimento
Os dois trilhos, do cartão do board ao deploy
Os dois trilhos — escolha ANTES de criar a branch
| Hotfix (produção) | Construção (dev) | |
|---|---|---|
| Quando | bug de cliente, correção urgente | módulo novo, feature grande |
| Sai de | main | develop |
| PR alvo | main | develop |
| Deploy no merge | app.vendee.com.br | dev.vendee.com.br |
| Supabase | projeto de produção | projeto de dev |
Depois de todo hotfix cair na main, reflita main → develop para o dev espelhar produção mais o que está em construção.
A promoção para produção é um PR develop → main, feito no ritual de sexta ou sábado à noite.
O ciclo
Ler a issue inteira no vStack. Se os critérios de aceite estiverem vagos, pergunte antes de codar.
Mover o cartão para In Progress — ao pegar, não ao terminar.
Criar a branch no trilho certo: feat|fix|refactor/<ISSUE-ID>-descricao-curta.
Codar, com commits no formato tipo: descrição curta (ISSUE-ID).
Provar. bun run validate:strict (lint + check-types + build + testes, em série, sem cache) e bun run gates (knip + deno check das edges — o que o turbo não cobre e o CI cobra).
Verificar no navegador. Portão verde não significa que a feature funciona: rode, clique, veja.
Abrir o PR com Ref CRM-XX no corpo e mover o cartão para In Review.
Merge na develop → o cartão vai para Done Dev e a mudança está no ar em dev.vendee.com.br.
Promoção develop → main → o cartão vai para Done e a mudança está em produção.
⚠️ bun run validate puro pode devolver FULL TURBO em ~100ms reusando cache — verde que não provou nada. Ele serve para o loop de trabalho; a prova antes do PR é o validate:strict, que roda com --force e em série de propósito.
Deploy
Deploy é GitHub Actions → Hetzner, automático no merge. Não há Vercel em lugar nenhum do projeto.
| Merge em | Vai para |
|---|---|
develop | dev.vendee.com.br |
main | app.vendee.com.br |