Contribuicao
Fluxo de Trabalho
Git branching, PRs e o portão que o CI cobra
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 |
A promoção para produção é um PR develop → main, no ritual de sexta ou sábado à noite.
Branching
Toda branch carrega o ID da issue:
feat/<ISSUE-ID>-descricao-curta— funcionalidade novafix/<ISSUE-ID>-descricao-curta— correção de bugrefactor/<ISSUE-ID>-descricao-curta— refatoração
Uma issue = uma branch = um PR.
Workflow
Crie a branch, no trilho certo
git checkout develop && git pull # construção
git checkout -b feat/CRM-123-minha-featureDesenvolva
Commits no formato tipo: descrição curta (ISSUE-ID):
feat: add deal filters (CRM-123)
fix: kanban drag-drop perdia a etapa (CRM-124)Prove
bun run validate:strict # lint + check-types + build + testes, em série, --force
bun run gates # knip + deno check das edges⚠️ bun run validate puro pode devolver FULL TURBO reusando cache — verde que não provou nada. Ele serve para o loop de trabalho; a prova antes do PR é o validate:strict.
E verifique no navegador: portão verde não significa que a feature funciona.
Abra um PR
Para main (hotfix) ou develop (construção), com Ref CRM-XX no corpo — nunca Closes.
CI
| Job | O que roda |
|---|---|
quality | lint (zero warnings) + check-types + testes (vitest) + knip |
edges | deno check em todas as edge functions |
drift | migration nova registrada e aplicada no Dev |
verdades | invariantes de negócio conferidos no banco de dev |
promocao | só em PR develop → main: exige changelog público + etiqueta release:* |
Há framework de testes: vitest, em apps/app. O CI bloqueia merge com teste vermelho. Não adicione runner em outro app sem combinar antes.