Framework
Docs

02 — Convenções de Código

Idioma

ContextoIdioma
Código, testes, commitsInglês
UI, mensagens de produto, APIs públicasInglês
Docs em docs/, specs em specs/Português (pt-BR)
ComentáriosPT ou EN quando ajudar clareza

Monorepo

  • Package manager: pnpm (workspaces)
  • Rodar por app: pnpm --filter @framework/service …
  • Config Prettier na raiz; ESLint por app

Estrutura (service)

apps/service/src/modules/<domain>/
  ├── *.controller.ts
  ├── *.service.ts
  ├── *.module.ts
  └── dto/

Novos domínios seguem padrão existente em apps/service/src/modules/*.

Estrutura (app)

apps/app/src/features/<feature>/
  ├── components/
  ├── hooks/
  ├── api/
  └── routes/

Feature-based; rotas TanStack Router em routes/.

Commits e entrega

Fluxo sem Pull Requests — alterações vão em commit direto na branch de trabalho (main, develop ou feature branch com merge local).

  • Escopo mínimo alinhado à spec/task
  • Mensagem Conventional Commits (ver abaixo em framework-basics)
  • Sem secrets, .env, credenciais
  • Hooks pre-commit (husky) devem passar
  • Antes de push: lint + build nos apps afetados (ver 06-testing-quality)

Nomenclatura

  • Componentes React: PascalCase
  • Hooks: use* camelCase
  • API paths: kebab-case ou REST plural
  • Test IDs: inglês, estável (data-testid)

Identidade e tema (@framework/brand)

  • Nome, domínios, logos, cores, metadata e tokens de tema: sempre via @framework/brand — ver 10-brand-kit
  • Proibido hardcode de hex da paleta, domínios de produção e nome do produto fora do pacote (exceto docs de marketing e exemplos Swagger pós-rebrand via brand-data.json)

O que evitar

  • Refactor adjacente fora do escopo da task
  • Abstrações de uma linha
  • Lógica de negócio crítica só no client

Links relacionados