Pular para conteúdo

Guias Compartilhados — Atenvi ERP

Convenções aplicadas a todos os projetos (atenvi-ui, atenvi-web, atenvi-web-admin, atenvi-bff, atenvi-app).

Linguagem

  • TypeScript strict em todos os projetos
  • Sem any — use unknown + type guard se necessário
  • Sem @ts-ignore — corrija o tipo

Nomenclatura

Contexto Convenção Exemplo
Arquivos de componente PascalCase UserCard.tsx
Arquivos de hook camelCase com use useUserData.ts
Arquivos de util/service camelCase formatCurrency.ts
Arquivos de tipo camelCase com .types.ts user.types.ts
Constantes UPPER_SNAKE_CASE MAX_RETRY_COUNT
Variáveis/funções camelCase fetchUserById

Commits

Seguir Conventional Commits:

<type>(<scope>): <description>

types: feat | fix | refactor | test | docs | chore | style
scope: nome do projeto ou módulo (ex: web-admin, bff, ui, app)

Estrutura de PR

  • PR pequeno: 1 feature ou 1 fix por PR
  • Branch: <type>/<ID>-<description> → feat/ATE-23-fechamento-caixa (ID do Linear no nome, ver Fluxo Linear ↔ PR)
  • Requer: CI verde + /code-review sem findings bloqueantes — sem aprovação de terceiros (time solo por enquanto); /code-review é o substituto do review humano

Definition of Ready (Backlog → Todo)

Issue só entra em Todo se tiver:

  1. Título + descrição com contexto (por quê, não só o quê)
  2. Critério de aceite explícito, testável (checklist)
  3. Projeto alvo definido (atenvi-ui/atenvi-web/atenvi-web-admin/atenvi-bff/atenvi-app)
  4. Tela Figma referenciada (node ID) se envolve UI
  5. ADR linkada se envolve decisão arquitetural
  6. Dependências/bloqueios identificados
  7. Suposição de negócio não validada, marcada explicitamente como risco aceito (plano B: sem discovery formal antes do MVP)

Fluxo Linear ↔ PR

Sem app oficial Linear→GitHub instalado no org (só Cloudflare Pages, checado em 2026-07-03). Vínculo é manual via Linear MCP — quem opera (Claude Code) move o status da issue diretamente, sem depender de magic words/integração automática. Reavaliar instalar o app oficial (Settings → Integrations → GitHub) se o time crescer ou a automação manual pesar.

  1. Issue passa Definition of Ready → Todo
  2. Início do trabalho: branch <type>/<ID>-<description> → feat/ATE-23-fechamento-caixa (ID do Linear no nome, para rastreio). Issue → In Progress (via MCP)
  3. PR: título inclui o ID → feat(bff): fechamento de caixa (ATE-23); corpo linka a URL da issue no Linear
  4. Definition of Done roda (CI + /code-review)
  5. Merge → issue → Done (via MCP, não automático)

Definition of Done (PR → Done)

  1. Sensores computacionais verdes: tsc, lint, test (unit), build — CI
  2. /code-review passou (obrigatório em feature, opcional em chore/docs — ver sensors/inferential.md)
  3. Fidelidade Figma checada se envolveu UI (screenshot comparado)
  4. PR pequeno, 1 feature/fix, sem console.log/secret hardcoded
  5. Swagger/contrato atualizado se mudou API; ADR atualizada se mudou decisão arquitetural
  6. Testado manualmente no fluxo real (plano B: validação com tenant piloto, não só teste automatizado)
  7. Issue Linear movida pra Done, linkada ao PR

Imports

  • Imports absolutos via path alias @/ configurado em cada projeto
  • Sem imports relativos com ../../../

Proibido

  • console.log em código commitado
  • Secrets ou credenciais hardcoded
  • Lógica de negócio em componentes de UI