CECAPE Engineering Ecosystem

Estruturação completa do ecossistema de engenharia da CECAPE Tech — 17 repositórios organizados com propósito claro, cobrindo templates, configurações centralizadas, handbook, ambiente local e design system. O objetivo era eliminar inconsistência entre projetos e reduzir o tempo de onboarding de novos desenvolvedores.

• Padronizar arquitetura frontend e backend com boilerplates oficiais

• Eliminar o problema 'na minha máquina funciona' com ambiente local orquestrado

• Documentar decisões técnicas para que o time não repita os mesmos erros

• Centralizar configurações de ESLint, Prettier e TSConfig para consistência entre projetos

• Criar um design system compartilhado entre todas as aplicações da organização

Cada novo projeto da CECAPE começava do zero — sem padrão arquitetural, sem ambiente local padronizado, sem guia de contribuição. O custo de onboarding era alto e as decisões técnicas eram refeitas a cada projeto, gerando inconsistência e retrabalho.

Estudei como organizações como Vercel, Shopify e times de engenharia de scale-ups estruturam seus ecossistemas internos. A conclusão foi clara: a diferença entre times que escalam bem e os que não escalam está na documentação de decisões e na padronização de ferramental — não na tecnologia escolhida.

• nextjs-template com FSD, Server Actions, Zod e Zustand como boilerplate oficial frontend

• express-template com DDD, Prisma, JWT e Zod como boilerplate oficial backend

• local-development-kit com Docker Compose profiles (backend, frontend, fullstack), Traefik com HTTPS local e Mockoon para mocks

• engineering-handbook documentando arquitetura, Git flow, commits e padrões de PR

• architecture-proposals como repositório de ADRs e RFCs — registro de decisões técnicas com contexto e trade-offs

• js-configs centralizando ESLint, Prettier e TSConfig para consumo via npm

• Nomear os templates por framework (express-template) em vez de por domínio (backend-template) — evita ambiguidade quando surgir um django-template

• Separar o engineering-handbook (como fazer) do architecture-proposals (por que decidimos assim) — conceitos distintos que muitos times misturam

• Configurar o local-development-kit com profiles Docker para que frontend possa rodar sem backend via Mockoon

• Renomear a layer pages/ para views/ no nextjs-template — pages/ conflita com o Pages Router do Next.js

17 repositórios organizados com propósito claro e documentação completa. Novos projetos partem de uma base arquitetural sólida sem custo de setup. A decisão mais importante foi separar ADRs do handbook — o handbook diz como, o ADR diz por quê. Sem essa separação, a documentação vira ruído.