---
name: scale-audit
description: Auditoria completa de prontidao para producao em escala. Avalia se o projeto aguenta 100k usuarios simultaneos analisando 80+ checks em 10 categorias - arquitetura, database, API, seguranca, frontend performance, infra, monitoramento, resiliencia, config e stress test. Gera relatorio com nota 0-100 e plano de acao priorizado.
---

# Scale Audit — Auditoria de Prontidao para 100k Usuarios

## Quando ativar
- Quando o usuario digitar `/scale-audit`
- Quando disser: "aguenta escala?", "ta pronto pra producao?", "100k usuarios", "stress test", "audit de performance", "pode subir?", "ta production-ready?", "vai aguentar?"

## Filosofia
Esta skill responde UMA pergunta: **"Se 100.000 usuarios usarem isso ao mesmo tempo, o que quebra?"**

Nao e sobre codigo bonito. E sobre sobrevivencia em producao sob carga real.

## EXECUCAO — 10 Categorias, 80+ Checks

### Passo 1: Identificar o projeto
```bash
# Detectar projeto pela pasta atual
cat package.json 2>/dev/null | head -5
cat CLAUDE.md 2>/dev/null | head -20
```
Anotar: nome, stack, portas, banco de dados, framework.

### Passo 2: Detectar stack automaticamente
```bash
# Detectar tudo que importa
cat package.json | grep -E "express|fastify|koa|nest|next|react|vue|svelte|better-sqlite3|pg|mysql|mongoose|redis|bull|socket.io|ws"
```

---

## CATEGORIA 1: ARQUITETURA & ESCALABILIDADE (10 pontos)

| # | Check | Peso | O que verificar | Comando |
|---|-------|------|----------------|---------|
| 1.1 | Stateless design | 2 | Sem sessao in-memory (MemoryStore, variavel global mutavel) | `grep -rn "MemoryStore\|global\.\|let sessions\|const sessions\|var sessions" src/ --include="*.ts"` |
| 1.2 | Sem estado em variavel global | 1 | Nenhum Map/Set/Array global que cresca com usuarios | `grep -rn "^const \|^let \|^var " src/ --include="*.ts" \| grep -i "map\|set\|array\|cache\|store\|queue"` |
| 1.3 | Cluster mode possivel | 1 | App funciona com multiplas instancias (sem port hardcoded, sem file locks exclusivos) | `grep -rn "cluster\|workers\|PM2\|\.listen(" src/ --include="*.ts"` |
| 1.4 | Separacao de concerns | 1 | Rotas, logica de negocio e acesso a dados separados | Verificar estrutura de pastas: routes/ services/ models/ ou equivalente |
| 1.5 | Graceful shutdown | 2 | Handler pra SIGTERM/SIGINT que fecha conexoes | `grep -rn "SIGTERM\|SIGINT\|graceful\|shutdown\|process\.on" src/ --include="*.ts"` |
| 1.6 | Health check endpoint | 1 | GET /health ou /healthz que retorna status | `grep -rn "health\|healthz\|readiness\|liveness" src/ --include="*.ts"` |
| 1.7 | Sem operacoes sincronas bloqueantes | 1 | Sem fs.readFileSync, crypto.pbkdf2Sync em hot path | `grep -rn "Sync(" src/ --include="*.ts" \| grep -v "node_modules\|test\|spec"` |
| 1.8 | Worker offload pra CPU-heavy | 1 | Operacoes pesadas (crypto, image, PDF) em worker thread ou fila | `grep -rn "worker_threads\|Bull\|BullMQ\|agenda\|bee-queue" src/ --include="*.ts"` |

**VEREDICTO:** Se score < 5: "Arquitetura NAO escala horizontalmente. Reescrever antes de pensar em 100k."

---

## CATEGORIA 2: DATABASE & PERSISTENCIA (10 pontos)

| # | Check | Peso | O que verificar | Comando |
|---|-------|------|----------------|---------|
| 2.1 | Connection pooling | 2 | Pool de conexoes (nao abre/fecha por request) | `grep -rn "pool\|createPool\|connectionLimit\|max:" src/ --include="*.ts"` |
| 2.2 | Indexes nas queries frequentes | 2 | CREATE INDEX nos campos usados em WHERE/ORDER BY | `grep -rn "CREATE INDEX\|CREATE UNIQUE INDEX" src/ --include="*.ts" --include="*.sql"` + cruzar com `grep "WHERE\|ORDER BY"` |
| 2.3 | N+1 queries | 1 | Nao faz query dentro de loop | Buscar padrao: `for.*{.*db\.\|forEach.*db\.\|map.*db\.` |
| 2.4 | WAL mode (SQLite) | 1 | PRAGMA journal_mode=WAL ativado | `grep -rn "journal_mode\|WAL\|wal" src/ --include="*.ts"` |
| 2.5 | Prepared statements | 1 | Usa .prepare() e nao concatena strings | `grep -rn "db\.\(prepare\|run\|get\|all\)" src/ --include="*.ts"` — verificar se tem `?` ou `$` |
| 2.6 | Limite de resultados | 1 | Toda query de listagem tem LIMIT | `grep -rn "SELECT.*FROM" src/ --include="*.ts" \| grep -v "LIMIT\|COUNT\|MAX\|MIN"` |
| 2.7 | Transacoes pra operacoes compostas | 1 | BEGIN/COMMIT pra writes multiplos | `grep -rn "transaction\|BEGIN\|COMMIT\|ROLLBACK" src/ --include="*.ts"` |
| 2.8 | Backup strategy | 1 | Script ou mecanismo de backup automatico | `grep -rn "backup\|dump\|export" . --include="*.sh" --include="*.ts"` |

**LIMITE SQLite:** Se o projeto usa better-sqlite3, avisar:
- SQLite aguenta ~50k leituras/s e ~5k escritas/s em WAL mode
- Pra 100k usuarios simultaneos com muita escrita: migrar pra PostgreSQL
- Pra 100k com leitura predominante: SQLite pode servir COM cache layer

---

## CATEGORIA 3: API & ENDPOINTS (10 pontos)

| # | Check | Peso | O que verificar | Comando |
|---|-------|------|----------------|---------|
| 3.1 | Rate limiting | 2 | Middleware de rate limit em rotas publicas | `grep -rn "rateLimit\|rate-limit\|throttle\|express-rate-limit\|@fastify/rate-limit" src/ --include="*.ts"` |
| 3.2 | Input validation | 1 | Zod, Joi, class-validator ou validacao manual em TODAS as rotas POST/PUT | `grep -rn "zod\|joi\|class-validator\|body\.\|req\.body" src/ --include="*.ts"` |
| 3.3 | Paginacao em listagens | 1 | Toda rota que retorna array tem limit/offset ou cursor | `grep -rn "page\|limit\|offset\|cursor\|skip\|take" src/ --include="*.ts"` |
| 3.4 | Response compression | 1 | gzip/brotli habilitado | `grep -rn "compression\|brotli\|gzip\|deflate" src/ --include="*.ts"` |
| 3.5 | Timeout nos handlers | 1 | Timeout configurado pra nao pendurar | `grep -rn "timeout\|setTimeout\|AbortController\|signal" src/ --include="*.ts"` |
| 3.6 | Payload size limit | 1 | Limite de body size (default Express = 100kb, mas precisa ser explicito) | `grep -rn "limit.*mb\|limit.*kb\|bodyLimit\|json({" src/ --include="*.ts"` |
| 3.7 | Respostas padronizadas | 1 | Formato consistente (data/error/message) | Verificar se respostas seguem padrao |
| 3.8 | Idempotencia | 1 | POST/PUT criticos sao idempotentes (retry-safe) | Verificar se existe idempotency key ou upsert |
| 3.9 | Versionamento de API | 0.5 | /api/v1/ ou header de versao | `grep -rn "/v1/\|/v2/\|api-version" src/ --include="*.ts"` |
| 3.10 | Documentacao de endpoints | 0.5 | Swagger, OpenAPI ou README com endpoints | `grep -rn "swagger\|openapi\|@Api" src/ --include="*.ts"` |

---

## CATEGORIA 4: SEGURANCA PRODUCAO (10 pontos)

| # | Check | Peso | O que verificar | Comando |
|---|-------|------|----------------|---------|
| 4.1 | HTTPS enforced | 1 | Redirect HTTP→HTTPS ou HSTS header | `grep -rn "hsts\|Strict-Transport\|redirect.*https\|forceSSL" src/ --include="*.ts"` |
| 4.2 | Security headers | 1 | Helmet ou headers manuais (X-Frame, CSP, etc) | `grep -rn "helmet\|X-Frame\|Content-Security-Policy\|X-Content-Type" src/ --include="*.ts"` |
| 4.3 | CORS restrito | 1 | origin nao e "*" em producao | `grep -rn "origin.*\*\|cors()\|cors({" src/ --include="*.ts"` |
| 4.4 | Auth token expiry | 1 | JWT com expiresIn configurado | `grep -rn "expiresIn\|exp:\|maxAge" src/ --include="*.ts"` |
| 4.5 | Password hashing | 1 | bcrypt/argon2/scrypt, NUNCA MD5/SHA1 | `grep -rn "bcrypt\|argon2\|scrypt\|pbkdf2\|md5\|sha1" src/ --include="*.ts"` |
| 4.6 | Brute force protection | 1 | Login com rate limit especifico ou lockout | `grep -rn "login.*limit\|lockout\|attempt\|maxAttempts\|loginRateLimit" src/ --include="*.ts"` |
| 4.7 | Sem secrets no frontend | 1 | Nenhuma API key, token ou secret em codigo frontend | `grep -rn "API_KEY\|SECRET\|TOKEN\|PRIVATE" src/ --include="*.tsx" --include="*.jsx"` |
| 4.8 | SQL injection protegido | 1 | Prepared statements em 100% das queries | Scanner check 5 |
| 4.9 | XSS protegido | 1 | Sem dangerouslySetInnerHTML ou sanitizacao | `grep -rn "dangerouslySetInnerHTML\|innerHTML\|v-html" src/ --include="*.tsx" --include="*.jsx"` |
| 4.10 | CSRF protegido | 1 | Token CSRF ou SameSite cookies | `grep -rn "csrf\|csurf\|SameSite\|sameSite" src/ --include="*.ts"` |

---

## CATEGORIA 5: FRONTEND PERFORMANCE (10 pontos)

| # | Check | Peso | O que verificar | Comando |
|---|-------|------|----------------|---------|
| 5.1 | Bundle size | 2 | Bundle < 500KB gzipped (ideal < 200KB) | `ls -la dist/assets/*.js 2>/dev/null \|\| ls -la build/static/js/*.js 2>/dev/null` |
| 5.2 | Code splitting | 1 | React.lazy/dynamic import pra rotas | `grep -rn "React\.lazy\|lazy(\|import(\|loadable\|Suspense" src/ --include="*.tsx"` |
| 5.3 | Image optimization | 1 | WebP/AVIF, lazy loading, srcset | `grep -rn "loading=\"lazy\"\|srcset\|webp\|avif\|next/image\|Image" src/ --include="*.tsx"` |
| 5.4 | CDN ready | 1 | Assets com hash no nome (Vite/Webpack faz por padrao) | `ls dist/assets/ 2>/dev/null` |
| 5.5 | Caching headers | 1 | Static assets com max-age longo | `grep -rn "max-age\|Cache-Control\|etag\|immutable" src/ --include="*.ts"` ou Nginx config |
| 5.6 | Debounce em inputs | 1 | Busca/filtro com debounce (nao dispara a cada tecla) | `grep -rn "debounce\|useDebounce\|setTimeout.*search\|throttle" src/ --include="*.tsx"` |
| 5.7 | Virtualizacao de listas | 1 | Listas longas usam react-window/react-virtualized | `grep -rn "react-window\|react-virtualized\|virtual\|FixedSizeList\|useVirtual" src/ --include="*.tsx"` |
| 5.8 | Memoization adequada | 1 | useMemo/React.memo em componentes pesados | `grep -rn "React\.memo\|useMemo\|useCallback" src/ --include="*.tsx" \| wc -l` |
| 5.9 | Error boundary | 0.5 | ErrorBoundary em nivel de app e rota | `grep -rn "ErrorBoundary\|componentDidCatch\|getDerivedStateFromError" src/ --include="*.tsx"` |
| 5.10 | Loading states | 0.5 | Skeleton/spinner em todas as chamadas async | `grep -rn "loading\|isLoading\|Skeleton\|Spinner\|Placeholder" src/ --include="*.tsx"` |

---

## CATEGORIA 6: INFRA & DEPLOY (10 pontos)

| # | Check | Peso | O que verificar | Comando |
|---|-------|------|----------------|---------|
| 6.1 | PM2 cluster mode | 2 | PM2 config com instances > 1 ou "max" | `cat ecosystem.config.* 2>/dev/null \|\| grep -rn "instances\|exec_mode.*cluster" . --include="*.config.*"` |
| 6.2 | Nginx otimizado | 2 | worker_connections >= 4096, keepalive, gzip | Verificar Nginx config se disponivel |
| 6.3 | Ulimit adequado | 1 | File descriptors >= 65536 | `ulimit -n` |
| 6.4 | Memory limits | 1 | Node --max-old-space-size ou PM2 max_memory_restart | `grep -rn "max-old-space-size\|max_memory_restart\|--max-heap" . --include="*.config.*" --include="*.json"` |
| 6.5 | Zero-downtime deploy | 1 | PM2 reload (nao restart), blue-green ou rolling | `grep -rn "reload\|gracefulReload\|rolling\|blue-green" . --include="*.sh" --include="*.yml"` |
| 6.6 | Environment separation | 1 | .env.production diferente de .env.development | `ls .env* 2>/dev/null` |
| 6.7 | Docker ready (opcional) | 0.5 | Dockerfile otimizado (multi-stage, non-root) | `cat Dockerfile 2>/dev/null` |
| 6.8 | CI/CD pipeline | 0.5 | GitHub Actions, GitLab CI ou equivalente | `ls .github/workflows/ .gitlab-ci.yml 2>/dev/null` |
| 6.9 | SSL auto-renew | 0.5 | Certbot com cron ou renewal hook | `crontab -l 2>/dev/null \| grep certbot` |
| 6.10 | Disk space strategy | 0.5 | Log rotation, temp cleanup | `grep -rn "logrotate\|maxSize\|maxFiles\|rotate" . --include="*.config.*"` |

---

## CATEGORIA 7: MONITORAMENTO & OBSERVABILIDADE (10 pontos)

| # | Check | Peso | O que verificar | Comando |
|---|-------|------|----------------|---------|
| 7.1 | Logging estruturado | 2 | Winston, Pino ou logger com levels (nao console.log) | `grep -rn "winston\|pino\|bunyan\|log4js\|createLogger" src/ --include="*.ts"` |
| 7.2 | Error tracking | 2 | Sentry, Bugsnag ou tracking de erros | `grep -rn "sentry\|Sentry\|bugsnag\|errorHandler\|captureException" src/ --include="*.ts"` |
| 7.3 | Health endpoint detalhado | 1 | /health retorna: uptime, memory, db status, version | `grep -rn "health\|uptime\|memoryUsage\|process\.uptime" src/ --include="*.ts"` |
| 7.4 | Request logging | 1 | Middleware logando method, path, status, duration | `grep -rn "morgan\|pinoHttp\|accessLog\|requestLogger" src/ --include="*.ts"` |
| 7.5 | Metrics endpoint | 1 | /metrics (Prometheus format) ou APM agent | `grep -rn "metrics\|prometheus\|prom-client\|newrelic\|datadog" src/ --include="*.ts"` |
| 7.6 | Alerting | 1 | Alerta configurado pra down/error spike | Verificar configs de alertas |
| 7.7 | Log levels configurados | 1 | LOG_LEVEL via env, default INFO em prod | `grep -rn "LOG_LEVEL\|logLevel\|level.*info\|level.*warn" src/ --include="*.ts"` |
| 7.8 | Audit trail | 1 | Acoes criticas logadas (login, delete, config change) | `grep -rn "audit\|auditLog\|activity.*log" src/ --include="*.ts"` |

---

## CATEGORIA 8: RESILIENCIA & FAULT TOLERANCE (10 pontos)

| # | Check | Peso | O que verificar | Comando |
|---|-------|------|----------------|---------|
| 8.1 | Error handling global | 2 | Middleware catch-all pra erros nao tratados | `grep -rn "unhandledRejection\|uncaughtException\|app\.use.*err" src/ --include="*.ts"` |
| 8.2 | Retry com backoff | 1 | Chamadas externas com retry exponencial | `grep -rn "retry\|backoff\|exponential\|attempts" src/ --include="*.ts"` |
| 8.3 | Circuit breaker | 1 | Protecao contra cascading failure | `grep -rn "circuit.*breaker\|opossum\|cockatiel\|half-open" src/ --include="*.ts"` |
| 8.4 | Queue pra operacoes pesadas | 2 | Email, PDF, notificacao via fila (nao inline) | `grep -rn "bull\|BullMQ\|bee-queue\|agenda\|queue\|enqueue" src/ --include="*.ts"` |
| 8.5 | Timeout em chamadas externas | 1 | fetch/axios com timeout configurado | `grep -rn "timeout.*[0-9]\|AbortSignal\.timeout\|signal.*abort" src/ --include="*.ts"` |
| 8.6 | Graceful degradation | 1 | App funciona (modo reduzido) se servico externo cai | Verificar fallbacks em integracao |
| 8.7 | Backpressure handling | 1 | WebSocket/streams com controle de pressao | `grep -rn "backpressure\|highWaterMark\|pause()\|drain" src/ --include="*.ts"` |
| 8.8 | Data consistency | 1 | Operacoes criticas sao atomicas | Verificar transacoes em writes compostos |

---

## CATEGORIA 9: WEBSOCKET & REAL-TIME (10 pontos)
*Se o projeto nao usa WebSocket/real-time, redistribuir pontos entre outras categorias.*

| # | Check | Peso | O que verificar | Comando |
|---|-------|------|----------------|---------|
| 9.1 | Adapter pra multi-instance | 2 | Redis adapter (nao memory) pra Socket.IO cluster | `grep -rn "redis.*adapter\|@socket.io/redis\|createAdapter" src/ --include="*.ts"` |
| 9.2 | Room management | 1 | Rooms com cleanup (nao acumula rooms vazias) | `grep -rn "join(\|leave(\|rooms\|room" src/ --include="*.ts"` |
| 9.3 | Reconnection handling | 1 | Cliente reconecta automaticamente | `grep -rn "reconnect\|reconnection\|autoConnect" src/ --include="*.ts" --include="*.tsx"` |
| 9.4 | Auth em WebSocket | 1 | Middleware de auth na conexao WS | `grep -rn "io\.use\|socket\.handshake\|auth.*socket\|middleware.*socket" src/ --include="*.ts"` |
| 9.5 | Broadcast eficiente | 1 | Broadcast pra room especifica, nao pra todos | `grep -rn "io\.emit\|broadcast\.emit\|to(\|in(" src/ --include="*.ts"` |
| 9.6 | Payload size control | 1 | maxPayload configurado | `grep -rn "maxHttpBufferSize\|maxPayload\|perMessageDeflate" src/ --include="*.ts"` |
| 9.7 | Heartbeat/ping | 1 | pingTimeout/pingInterval configurado | `grep -rn "pingTimeout\|pingInterval\|heartbeat" src/ --include="*.ts"` |
| 9.8 | Namespace separation | 1 | Namespaces pra funcionalidades diferentes | `grep -rn "io\.of(\|namespace" src/ --include="*.ts"` |
| 9.9 | Connection limit | 1 | Limite de conexoes por usuario/IP | `grep -rn "maxConnections\|connectionsPerIP\|connectionLimit" src/ --include="*.ts"` |

---

## CATEGORIA 10: CACHE & OTIMIZACAO (10 pontos)

| # | Check | Peso | O que verificar | Comando |
|---|-------|------|----------------|---------|
| 10.1 | Cache layer | 2 | Redis, node-cache ou in-memory cache com TTL | `grep -rn "redis\|node-cache\|lru-cache\|Map.*ttl\|cacheable\|ioredis" src/ --include="*.ts"` |
| 10.2 | Cache invalidation | 1 | Cache invalida quando dado muda | `grep -rn "invalidate\|delete.*cache\|cache\.del\|flush\|bust" src/ --include="*.ts"` |
| 10.3 | ETags | 1 | ETags habilitados pra respostas | `grep -rn "etag\|ETag\|conditional" src/ --include="*.ts"` |
| 10.4 | Database query cache | 1 | Queries frequentes cacheadas | Verificar se existe cache antes de query |
| 10.5 | Static file caching | 1 | Static middleware com maxAge | `grep -rn "static.*maxAge\|express\.static\|@fastify/static" src/ --include="*.ts"` |
| 10.6 | Lazy loading de dados | 1 | Dados carregados sob demanda | Verificar paginacao + scroll infinito |
| 10.7 | Connection reuse | 1 | HTTP keep-alive pra chamadas externas | `grep -rn "keepAlive\|keepAliveMsecs\|agent.*new" src/ --include="*.ts"` |
| 10.8 | Compression | 1 | Respostas comprimidas (gzip/brotli) | Ja coberto em 3.4, validar aqui tambem |
| 10.9 | Preload/prefetch | 0.5 | Frontend prefetch de dados criticos | `grep -rn "prefetch\|preload\|preconnect\|dns-prefetch" src/ --include="*.tsx" --include="*.html"` |
| 10.10 | CDN pra assets | 0.5 | Imagens/JS/CSS servidos via CDN | Verificar se assets apontam pra CDN ou local |

---

## EXECUCAO DA AUDITORIA

### Passo 3: Rodar TODOS os checks
Usar subagents em paralelo para acelerar:
- **Agent 1:** Categorias 1-3 (Arquitetura + Database + API)
- **Agent 2:** Categorias 4-6 (Seguranca + Frontend + Infra)
- **Agent 3:** Categorias 7-9 (Monitoramento + Resiliencia + WebSocket)
- **Agent 4:** Categoria 10 + Build analysis + Nginx config

Cada agent roda os greps/checks e retorna resultado estruturado.

### Passo 4: Calcular score

```
SCORE TOTAL = soma de todos os pontos obtidos / 100

Cada check: 0 (ausente), parcial (metade do peso), ou total (peso completo)
```

### Passo 5: Gerar relatorio

```
SCALE AUDIT — {Projeto}
========================
Data: {YYYY-MM-DD}
Stack: {detectada}
Usuarios-alvo: 100.000 simultaneos

  ██████████████░░░░░░  68/100  ESCALA COM RISCO

  CATEGORIA                    SCORE    STATUS
  ─────────────────────────────────────────────
  1. Arquitetura & Escala      7/10     OK
  2. Database & Persistencia   5/10     RISCO
  3. API & Endpoints           8/10     OK
  4. Seguranca Producao        6/10     ATENCAO
  5. Frontend Performance      7/10     OK
  6. Infra & Deploy            4/10     RISCO
  7. Monitoramento             3/10     CRITICO
  8. Resiliencia               5/10     RISCO
  9. WebSocket & Real-time     8/10     OK
  10. Cache & Otimizacao       5/10     RISCO

  ─────────────────────────────────────────────

  BLOQUEADORES DE ESCALA (resolve ANTES de ir pra producao):
  ──────────────────────────────────────────────────────────
  1. [CAT 7] Sem error tracking (Sentry/equivalente) — crash em producao = invisivel
  2. [CAT 6] PM2 em fork mode (1 instancia) — 1 CPU de N disponiveis
  3. [CAT 2] SQLite sem WAL mode — escritas concorrentes vao travar
  4. [CAT 7] Sem logging estruturado — debugging em producao impossivel

  RISCOS ALTOS (resolve em ate 1 semana):
  ───────────────────────────────────────
  5. [CAT 3] Sem rate limiting — DDoS derruba app em segundos
  6. [CAT 4] CORS com origin:"*" — qualquer site faz request
  7. [CAT 8] Sem retry em chamadas externas — 1 timeout = erro pro usuario
  8. [CAT 10] Sem cache layer — cada request bate no DB

  MELHORIAS (nice to have):
  ─────────────────────────
  9. [CAT 5] Bundle 780KB — ideal < 500KB (code split nas rotas)
  10. [CAT 9] WebSocket sem Redis adapter — nao escala multi-instance

  ─────────────────────────────────────────────

  ESTIMATIVA DE CAPACIDADE ATUAL:
  ──────────────────────────────
  Leituras/s estimadas:    ~2.000 (precisa: ~50.000)
  Escritas/s estimadas:    ~500   (precisa: ~5.000)
  Conexoes WS simultaneas: ~1.000 (precisa: ~50.000)
  Bottleneck principal:    Database (SQLite single-writer)

  ROADMAP PARA 100k:
  ──────────────────
  Fase 1 (BLOQUEADORES — fazer agora):
    □ Ativar WAL mode no SQLite
    □ Configurar PM2 cluster mode (instances: "max")
    □ Instalar e configurar Sentry
    □ Trocar console.log por Pino/Winston

  Fase 2 (RISCOS — 1 semana):
    □ Adicionar rate limiting (express-rate-limit)
    □ Restringir CORS para dominio especifico
    □ Adicionar Redis cache layer
    □ Implementar retry com backoff

  Fase 3 (OTIMIZACAO — 2 semanas):
    □ Code splitting no frontend
    □ Redis adapter pro Socket.IO
    □ Metrics endpoint (/metrics)
    □ Health check detalhado

  Fase 4 (SE PRECISAR DE MAIS):
    □ Migrar SQLite → PostgreSQL
    □ CDN pra assets estaticos
    □ Queue (BullMQ) pra operacoes pesadas
    □ Horizontal scaling (load balancer)
```

### Passo 6: Classificar resultado final

| Score | Status | Significado |
|-------|--------|-------------|
| 90-100 | PRONTO PRA GUERRA | Pode mandar 100k. Monitorar e escalar horizontal se precisar. |
| 75-89 | ESCALA COM CONFIANCA | Aguenta bem, mas tem pontos pra polir. |
| 60-74 | ESCALA COM RISCO | Funciona pra 10-50k, mas 100k vai ter problemas. |
| 40-59 | NAO ESCALA | Maximo ~5k usuarios. Precisa de trabalho serio. |
| 0-39 | PERIGO | App vai cair sob qualquer carga real. Repensar arquitetura. |

### Passo 7: Salvar relatorio

Salvar em `~/.claude/shield/reports/{projeto}-scale-{data}.json`:
```json
{
  "project": "nome",
  "date": "2026-04-04",
  "score": 68,
  "status": "ESCALA COM RISCO",
  "target_users": 100000,
  "categories": {
    "arquitetura": { "score": 7, "max": 10, "issues": [...] },
    "database": { "score": 5, "max": 10, "issues": [...] },
    ...
  },
  "blockers": [...],
  "risks": [...],
  "improvements": [...],
  "capacity_estimate": {
    "reads_per_second": 2000,
    "writes_per_second": 500,
    "ws_connections": 1000,
    "bottleneck": "database"
  },
  "roadmap": [...]
}
```

---

## REGRAS DE EXECUCAO

1. **NUNCA inventar resultado** — se nao conseguir verificar um check, marcar como "NAO VERIFICADO" (0 pontos)
2. **Ser brutalmente honesto** — melhor assustar agora do que cair em producao
3. **Considerar o CONTEXTO** — SQLite pra app de mentoradas (500 usuarios) e diferente de SaaS publico
4. **Dar o CAMINHO** — nao so apontar o problema, dar o comando/lib exata pra resolver
5. **Priorizar por IMPACTO** — o que derruba o app primeiro vem primeiro
6. **Comparar com benchmarks reais:**
   - Express single thread: ~15k req/s simples
   - Express + cluster (4 cores): ~50k req/s
   - SQLite WAL reads: ~50k/s | writes: ~5k/s
   - PostgreSQL: ~100k reads/s | ~20k writes/s
   - Socket.IO single instance: ~10k conexoes
   - Socket.IO + Redis: ~100k+ conexoes
   - Node.js memory: ~1.5GB default (--max-old-space-size)

## Integracao com Shield
- Rodar APOS /scanner (usa resultados do scanner como input)
- Alimenta o /health-score com dados de escala
- Respeita Guardian — NUNCA sugere deletar funcionalidade, sempre ADICIONAR
