🎯 Clinicafy — Auditoria cs-*

🧑‍💼 cs-engineering-lead — Engineering Lead & Team Coordination

Auditoria técnica e estratégica pela ótica cs-engineering-lead — Engineering Lead & Team Coordination. Achados classificados por severidade, plano de ação e matriz de decisão.

!

Veredito: HANDOFF.md exemplar como documentação de sessão, mas sem README útil, sem runbook de incidente e processo de desenvolvimento indefinido.

O projeto tem um HANDOFF.md atualizado (2026-07-15) com documentação técnica detalhada — qualidade rara. Porém o README não existe como documento de onboarding. Sem .github/workflows, sem branch protection, sem CONTRIBUTING.md. Processo de desenvolvimento é 'push para main e Vercel builda' — sem pull request review, sem staging environment.

2026-07-15
Último HANDOFF
SEM
README de onboarding
SEM
Branch protection rules
SEM
Staging environment
SEM
Runbook de incidente

Dimensões Analisadas

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

Documentação

60

HANDOFF.md muito bom. README ausente. Sem ADR de decisões técnicas.

2 achados

Processo de Desenvolvimento

20

Push direto em main. Sem PR, sem review, sem staging. Vercel auto-deploy quebrado.

2 achados 2 bloqueante(s)

Incident Management

10

Sem runbook. Sem on-call. Sem alert. Detecção de incidente depende de usuário reportar.

1 achados

Onboarding

30

Novo dev precisa ler 2911 linhas de server.ts para entender o sistema. Sem guia de setup local.

1 achados

🔎 Achados (5)

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

README ausente — onboarding de novo dev depende de HANDOFF.mdMédiaEsforço baixoEngineering Excellence / Documentation

O que é: O projeto não tem README.md útil (ou está ausente). O HANDOFF.md é excelente para retomar sessão, mas não é o documento de entrada de um novo colaborador. Sem 'Como rodar local', 'Variáveis de ambiente necessárias', 'Arquitetura resumida'.

Onde: raiz do repo (ausência de README.md)

Impacto: Tempo de onboarding de novo dev: horas → dias. Dependency de 1 pessoa (o criador) para qualquer entendimento.

✅ Correção: Criar README.md com: badges de status, quick start (clone+env+dev), variáveis de ambiente necessárias, diagrama de arquitetura (Mermaid), link para HANDOFF.md.
Push direto em main sem branch protectionAltaBloqueanteEsforço baixoGitFlow / Branch Strategy

O que é: Não há .github/branch-protection-rules configurado. Qualquer commit em main vai direto para produção via Vercel (quando o auto-deploy for corrigido). Sem PR review obrigatório.

Onde: github.com/cspgabriel/clinicafy (settings → branches — inferido)

Impacto: Um commit com bug crítico vai para produção instantaneamente. Sem janela de review. Rollback manual demorado.

✅ Correção: Configurar branch protection em main: require PR review (mínimo 1 aprovação), require status checks passing (CI), prevent force push.
Sem staging environment — testa direto em produçãoAltaBloqueanteEsforço medioDORA / Deployment Safety

O que é: HANDOFF.md não menciona staging. Todas as features são desenvolvidas e testadas diretamente no ambiente de produção (clinicafy.com.br). Banco MySQL compartilhado com NutriFoco aumenta o risco.

Onde: HANDOFF.md (ausência de staging) + banco compartilhado HANDOFF.md:26

Impacto: Bugs de feature afetam usuários reais. Dados de teste se misturam com dados de produção.

✅ Correção: Criar Vercel Preview Deployments (automático com PR). Configurar DATABASE_URL_STAGING apontando para schema separado no Hostinger.
Banco MySQL compartilhado com NutriFoco (outro produto)AltaEsforço altoIsolation / Multi-product Architecture

O que é: HANDOFF.md:26: 'tabelas prefixadas clinic_*, banco compartilhado com o NutriFoco'. Um bug de SQL sem WHERE clause correto pode afetar dados do NutriFoco e vice-versa. Sem isolamento de esquema.

Onde: HANDOFF.md:26

Impacto: Cross-product data corruption possível. Se NutriFoco cresce, compartilha conexões MySQL com Clinicafy gerando latência mútua.

✅ Correção: Migrar Clinicafy para schema próprio no mesmo servidor Hostinger. Longo prazo: banco dedicado quando tiver budget.
Sem runbook ou playbook de incidenteMédiaEsforço baixoSRE / Incident Response

O que é: Nenhum documento de 'O que fazer quando X quebra'. Sem RUNBOOK.md, sem alertas configurados, sem ponto de contato para incidente. Detecção depende do usuário reportar.

Onde: raiz do repo (ausência)

Impacto: MTTR alto. Incidente de API fora do ar pode levar horas para ser detectado e resolvido.

✅ Correção: Criar RUNBOOK.md com: 'API retorna 500' → verificar Vercel logs. 'Login falha' → verificar Firebase Auth console. 'DB timeout' → verificar Hostinger hPanel. Adicionar UptimeRobot (free) com alert por email/WhatsApp.

📋 Plano de Ação

Cronograma de implementação recomendado.

1

Branch protection em main (30min)

GitHub Settings → Branches → require PR + CI passing
processo
30min · CRÍTICO
2

UptimeRobot monitor (15min)

Monitor https://www.clinicafy.com.br/api/health a cada 5min. Alert por email.
sre
15min · CRÍTICO
3

README.md (2h)

Quick start + arquitetura Mermaid + env vars + link ao HANDOFF
docs
2h
4

RUNBOOK.md (1h)

Playbook para os 5 cenários de falha mais prováveis
docs
1h

Matriz de Decisão

CritérioFonteStatusBloqueante
Branch Safetycs-engineering-leadPush direto em mainSIM
Staging Environmentcs-engineering-leadInexistenteSIM
Documentação HANDOFFcs-engineering-leadExcelente qualidadenão
README / Onboardingcs-engineering-leadAusentenão
Incident Responsecs-engineering-leadSem runbook nem alertasnão