🔧 cs-cto-advisor — CTO Technical Leadership Advisor

Auditoria técnica e estratégica pela ótica cs-cto-advisor — CTO Technical Leadership Advisor. Achados classificados por severidade, plano de ação e matriz de decisão.

Veredito: Arquitetura inventiva mas acumulou dívida técnica estrutural: monólito de 2911 linhas, shim de Firestore não documentado e migração de banco bloqueada.

O stack Express+Prisma+MySQL é tecnicamente correto para o estágio, mas o server.ts monolítico com 2911 linhas representa débito estrutural severo. O alias Vite para mockFirestore.ts é uma gambiarra elegante porém perigosa: qualquer import de 'firebase/firestore' vira uma chamada HTTP sem o dev saber. DORA metrics: deploy bloqueado (auto-deploy quebrado + DATABASE_URL perdida), lead time desconhecido, MTTR potencialmente alto sem runbook.

2911

Linhas server.ts (monólito)

Testes E2E funcionando

127KB

Tamanho server.ts

bloqueado

Deploy automático

Firebase→MySQL

Shim alias Vite (risco)

Dimensões Analisadas

Pontuação por área de análise.

Arquitetura

Server.ts monolítico, sem separação de camadas, sem injeção de dependência. Crescimento vai escalar o problema.

2 achados

DORA Metrics

Deployment Frequency: manual. Lead Time: desconhecido. MTTR: sem runbook. Change Failure Rate: sem métricas.

2 achados 2 bloqueante(s)

Tech Debt

Alias Vite mockando Firestore é elegante mas invisível. TSC reporta erros pré-existentes (auth.ts).

2 achados

Observabilidade

Sem APM, sem alertas de erro, sem métricas de latência de DB. Logs apenas via console.log.

1 achados

🔎 Achados (5)

1 crítico(s) · 3 alto(s) · 1 bloqueante(s). Clique para expandir.

server.ts monolítico — 2911 linhas, zero separação de camadasAltaEsforço altoSOLID / Clean Architecture

O que é: server.ts tem 2911 linhas (127KB) misturando: init do Firebase Admin (L38-69), config MercadoPago (L71-74), constantes de negócio (L76-123), funções utilitárias (L199-342), todas as rotas de API, middleware e lógica de negócio. Zero separação de camadas.

Onde: server.ts:1-2911

Impacto: Impossível testar rotas isoladas. Bug em uma rota pode derrubar todas. Onboarding de novo dev leva dias.

✅ Correção: Extrair por domínio: routes/pacientes.ts, routes/agenda.ts, routes/billing.ts, services/auth.ts, services/mercadopago.ts. Migrar progressivamente usando Express Router.

Alias Vite mockFirestore invisível para devsAltaEsforço medioArchitecture Decision Record / Transparency

O que é: vite.config.ts:56 faz: 'firebase/firestore' → src/lib/mockFirestore.ts. Qualquer dev que importa getDocs/addDoc na crença de usar Firestore está na verdade chamando a API REST. Não há comentário, ADR ou ARCHITECTURE.md documentando isso.

Onde: vite.config.ts:56 + src/lib/mockFirestore.ts:1-409

Impacto: Risco de regressão silenciosa. Novo dev pode desativar o alias achando que é temporário, quebrando toda a persistência.

✅ Correção: Criar ARCHITECTURE.md com ADR-001 explicando o shim. Adicionar comentário em vite.config.ts:56 com link ao ADR. Considerar renomear importações para '@/lib/db' para tornar a abstração explícita.

Auto-deploy quebrado + DATABASE_URL perdida = DORA Deployment Frequency = 0CríticaBloqueanteEsforço baixoDORA Metrics / Four Keys

O que é: HANDOFF.md:4 repo renomeado → webhook Vercel apontando para nome antigo. HANDOFF.md:73 DATABASE_URL encrypted-only no Vercel. Código de Estoque, R2 Storage e Subscriptions pronto mas não deployável.

Onde: HANDOFF.md:4, HANDOFF.md:73-80

Impacto: Deploy Frequency próxima de zero. Features prontas ficam em dead code. Risco de divergência entre main e produção.

✅ Correção: 1) Reconectar repo no Vercel dashboard. 2) Recuperar DATABASE_URL no hPanel. 3) Usar Vercel CLI: 'vercel env pull .env.local' para ambiente local seguro.

Erros TypeScript pré-existentes ignorados (api/_lib/auth.ts)MédiaEsforço medioCode Quality / Type Safety

O que é: HANDOFF.md:65-66: 'Erros de tsc restantes são pré-existentes: api/_lib/auth.ts e patient-delete.ts:11'. O projeto tem 'check': 'tsc --noEmit' no package.json:11 mas o build passa com erros de tipo existentes — CI não está bloqueando.

Onde: HANDOFF.md:65-66 + package.json:11

Impacto: Erros de tipo acumulam silenciosamente. Risco de runtime errors não detectados em produção.

✅ Correção: Corrigir os erros pré-existentes em api/_lib/auth.ts e patient-delete.ts. Adicionar CI step que falha o build se 'tsc --noEmit' retornar erros.

Zero observabilidade em produçãoAltaEsforço medioSRE / Observability Three Pillars

O que é: server.ts usa apenas console.error/console.log para erros (ex: L66, L218). Sem Sentry, sem Datadog, sem Uptime monitoring. Sem métricas de latência de queries Prisma. Sem alertas de falha de webhook MercadoPago.

Onde: server.ts:66, server.ts:218, server.ts:339

Impacto: Incidentes em produção detectados apenas quando usuário reclama. MTTR alto por falta de contexto.

✅ Correção: Integrar Sentry (free tier suficiente): 3 linhas de init no server.ts. Adicionar Vercel Analytics para Core Web Vitals. Webhook monitor via Better Uptime ou UptimeRobot (free).

📋 Plano de Ação

Cronograma de implementação recomendado.

Destravar deploy (1 dia)

Reconectar repo Vercel + recuperar DATABASE_URL + rodar MIGRATION.sql

devops
1 dia · CRÍTICO

Observabilidade mínima (2 dias)

Sentry init + UptimeRobot + log estruturado de webhooks MP

sre
2 dias · CRÍTICO

ADR do shim mockFirestore

ARCHITECTURE.md + comentário em vite.config.ts + renomear imports para @/lib/db

docs
4h

Modularizar server.ts (sprint)

Extrair 5 routers por domínio. Não reescrever — split incremental.

refactor
2 semanas

Matriz de Decisão

Critério	Fonte	Status	Bloqueante
Deployment Frequency	cs-cto-advisor	Bloqueado (repo+DB)	SIM
Modularidade	cs-cto-advisor	Monólito 2911L	não
Documentação arquitetural	cs-cto-advisor	Sem ADR do shim	não
Type Safety	cs-cto-advisor	Erros TSC ignorados	não
Observabilidade	cs-cto-advisor	Apenas console.log	não