processo.md

+| [Home](home) | [**Escopo**](escopo) | [Processo](processo) | [Design/Mockups](design_mockups) | [Configuração](configuracao) | [Arquitetura](arquitetura) | [Gerência](gerencia) | [Código](codigo) | [BD](Banco de Dados) | [Qualidade](qualidade) | [Frontend](frontend) | [Backend](backend) | [Analytics](analytics)
+| :----------: | :-------------------------------: | :------------------: | :--------------: | :--------------------------: | :--------------------: | :------------------------: | :--------------: | :---------------: | :--------------------: | :---------------: | :--------------------: | ------------: |
+
+# Processo do Time – WimBelemDon+
+
+Este documento descreve como o time organiza o trabalho, desde a definição de tarefas até a entrega em produção, garantindo consistência, colaboração e qualidade.
+
+## Sumário
+
+* [Planejamento](#planejamento)
+* [Branches e Commits](#branches-e-commits)
+* [Pull Requests](#pull-requests)
+* [Code Review](#code-review)
+* [Integração Contínua](#integração-contínua)
+* [Entrega](#entrega)
+* [Reuniões e Comunicação](#reuniões-e-comunicação)
+* [Boas Práticas](#boas-práticas)
+
+---
+
+## Planejamento
+
+* As tarefas são priorizadas no **board** (Scrum/Sprint) pela equipe.
+* Cada tarefa deve estar claramente descrita, com critérios de aceite e linkada a uma issue.
+* O time planeja entregas por **sprints quinzenais**, com daily check-ins curtos para acompanhamento.
+
+---
+
+## Branches e Commits
+
+* Usar **branch naming conventions** e **conventional commits** descritos abaixo.
+* Cada issue/task deve ter sua branch dedicada.
+* Branches são criadas a partir de `develop`.
+* Commits devem ser pequenos, claros e relacionados a uma única mudança.
+
+
+## Diretrizes para Mensagens de Commit
+
+Seguimos o padrão **Conventional Commits**:
+
+```
+<tipo>(<escopo>): <assunto> (#<id-da-tarefa>)
+```
+
+* **tipo**: `feat`, `fix`, `chore`, `test`, `docs`, `ci`, `perf`, `refactor`, `build`
+* **escopo**: opcional, ex.: módulo ou funcionalidade
+* **assunto**: descrição curta, em minúsculas, sem ponto final
+
+**Exemplos:**
+
+* feat(auth): adicionar login via Google OAuth
+* fix(ui): corrigir alinhamento do botão na página inicial
+* chore(deps): atualizar react para 19.0.1
+* test(auth): adicionar testes unitários para login
+* docs(readme): atualizar instruções de configuração
+* ci(pipeline): adicionar etapa de linting
+* perf(api): cachear respostas para reduzir tempo de carregamento
+* refactor(ui): simplificar renderização condicional
+* build(webpack): atualizar configuração para produção
+
+Use sempre o **imperativo** em vez do passado.
+
+Se houver, adicione o **id da tarefa** ao final do título do commit.
+Exemplo:
+
+```
+feat(auth): adicionar login via Google OAuth (#123)
+```
+
+## Convenções de Nomenclatura de Branches
+
+Usamos **kebab-case** para os nomes das branches. Prefixe as branches de acordo com o tipo de trabalho:
+
+| Tipo        | Prefixo     | Exemplo                     |
+| ----------- | ----------- | --------------------------- |
+| Feature     | `feature/`  | `feature/add-login-button`  |
+| Bugfix      | `fix/`      | `fix/fix-login-error`       |
+| Chore       | `chore/`    | `chore/update-dependencies` |
+| Teste       | `test/`     | `test/add-login-tests`      |
+| Docs        | `docs/`     | `docs/update-readme`        |
+| CI          | `ci/`       | `ci/setup-ci-pipeline`      |
+| Performance | `perf/`     | `perf/improve-load-time`    |
+| Refatoração | `refactor/` | `refactor/cleanup-code`     |
+| Build       | `build/`    | `build/update-packages`     |
+
+> Não use espaços ou caracteres especiais nos nomes das branches.
+
+---
+
+## Pull Requests
+
+* Todo desenvolvimento deve passar por PR.
+* PRs devem ser abertos contra `develop`.
+* O autor deve:
+
+  * Descrever claramente as alterações.
+  * Atribuir-se como responsável.
+  * Solicitar revisão de ao menos **1 integrante** do time.
+* PR só pode ser mergeado após aprovação e pipeline passando.
+
+---
+
+## Code Review
+
+* O objetivo é **garantir qualidade e aprendizado coletivo**, não apenas apontar erros.
+* Revisores devem checar:
+
+  * Clareza e legibilidade do código.
+  * Padrões de arquitetura e estilo.
+  * Testes e cobertura mínima.
+  * Segurança (nada de segredos hardcoded).
+* Feedback deve ser construtivo e registrado nos comentários do PR.
+
+---
+
+## Integração Contínua
+
+* O pipeline de CI roda automaticamente em cada PR.
+* Passos básicos:
+
+  * Lint e formatação.
+  * Testes unitários.
+  * Build.
+* Nenhum PR pode ser mergeado com falha no pipeline.
+
+---
+
+## Entrega
+
+* `develop` é a branch de integração.
+* `main` representa a versão estável em produção.
+* Releases seguem versionamento semântico (`vX.Y.Z`).
+* O deploy é feito somente a partir de `main`, após validação do PO/cliente.
+
+---
+
+## Reuniões e Comunicação
+
+* **Dailies**: acompanhamento rápido (15 min).
+* **Planning**: início da sprint para priorizar tarefas.
+* **Review/Demo**: apresentação das entregas ao cliente.
+* **Retrospectiva**: ajustes no processo do time.
+* Comunicação principal via **Slack/Teams/Discord** (definir).
+* Decisões importantes devem ser documentadas (no Notion/Confluence).
+
+---
+
+## Boas Práticas
+
+* Todo código, documentação e commits devem estar em **inglês**.
+* PR descriptions e comentários podem ser em português.
+* Evitar **big PRs** → dividir em entregas menores.
+* Tratar warnings e falhas de lint antes do merge.
+* Se encontrar um problema, **abrir uma issue** mesmo que não vá resolver no momento.
+
+
+