Mega-Sena Analyzer

Análise estatística avançada da Mega-Sena com gerador inteligente de apostas baseado em ciência de dados.

Hospedagem e atualização diária

A versão 1.19.2 mantém frontend, API e banco SQLite em Workers/Durable Objects, com atualização diária da CAIXA em produção, e apresenta o site como um anuário estatístico: cada sorteio aparece no volante completo de 60 dezenas com as seis sorteadas marcadas, e números, prêmios e frequências viram tabelas com fio fino e linha de fonte da CAIXA. Produção e staging usam ambientes separados; staging bloqueia indexação e não agenda trabalho autônomo. A origem anterior foi arquivada após aceite público e reconciliação final dos dados. Veja os requisitos em docs/DEPLOY.md. Contas, inventários e evidências de implantação ficam fora deste repositório público. As instruções Bun/Docker abaixo descrevem o caminho local e de recuperação.

• cloudflare/worker.ts atende páginas App Router via vinext/Vite e encaminha /api/* ao Durable Object SQLite MegaSenaData pelo binding privado DATA.
• lib/api/handler.ts contém o contrato compartilhado da API; server.ts é o adaptador Bun. Contextos de banco e log isolam operações concorrentes.
• cloudflare.config.ts define staging/produção, o segredo IP_HASH_SECRET e habilita o agendador persistente somente em produção. O Durable Object agenda a atualização diária às 06:00 UTC (03:00 Brasília), sem depender de visitas ao site. Staging cancela alarmes existentes e permite refresh manual por RPC privado, sem retries autônomos.
• O cache de borda usa versão do aplicativo e revisão dos sorteios para imagens sociais, índices e páginas canônicas de concurso, número e ano sem query string. Cada HTML servido do cache recebe um nonce CSP novo em headers e corpo; o navegador continua recebendo no-store. Queries, cookies, autenticação, variantes de navegação e respostas comprimidas não entram no cache HTML.
• O seed público até o concurso 3065 inicializa somente um banco vazio. Isso não comprova atualização recente da CAIXA.
• A ingestão consulta a CAIXA antes da transação, valida concursos e acrescenta sorteios/caches atomicamente, com idempotência e até três novas tentativas por alarmes persistidos.
• A próxima tentativa é persistida antes da chamada de rede. Sucesso ou esgotamento das três tentativas preservam o próximo ciclo diário; reinícios mantêm o horário e o orçamento. Falhas de armazenamento permanecem visíveis à plataforma. A retenção é configurável por ambiente, preservando os prazos da origem e os padrões 400/30 dias. Decisões e alternativas estão no guia de deploy.

Use bun run dev:vinext para desenvolvimento Worker; bun run build:cloudflare para staging, bun run build:cloudflare:production para o artefato de produção e bun run test:cloudflare para a verificação local do runtime SQLite Durable Object. bun run build:vinext é o build Vite direto. Esses checks acrescentam evidência aos gates existentes de cobertura, SQLite Bun e build standalone. Argent Chromium deve verificar o candidato; não usar Playwright nesta migração. Deploy, backup, DNS e desativação do VPS seguem docs/DEPLOY.md.

Funcionalidades

• Arquivo Público de Resultados: Uma página por concurso (/concurso/{número}), por ano (/resultados/{ano}) e por número de 1 a 60 (/numeros/{número}), com análise própria de cada sorteio e links entre concursos, anos e números
• Mega da Virada: Todas as edições desde 2009 em /mega-da-virada, com prêmios, recordes, frequência das dezenas na Virada e as regras oficiais da CAIXA
• SEO Técnico: Sitemap gerado a partir do banco com lastmod fiel, canonical e Open Graph por página, JSON-LD encadeado (Organization, WebSite, WebPage, BreadcrumbList, Dataset), imagem social por concurso, llms.txt e respostas 404/308 reais para URLs inválidas ou com zeros à esquerda
• Análise Estatística Completa: Frequências, padrões e tendências históricas
• Referência de Atualização Visível: A página de estatísticas detalhadas informa claramente o concurso e a data-base exibidos
• Números Quentes e Frios: Identificação de números mais e menos sorteados
• Gerador Inteligente de Apostas: Múltiplas estratégias (aleatório, balanceado, Fibonacci, etc.)
• Orçamento em pt-BR: Valores como 50,50 e 1.200,50 preservam reais e centavos; erros esperados da geração permanecem legíveis em produção
• Dashboard Interativo: Visualização clara e moderna dos dados
• Banco de Dados Local: SQLite com dados históricos completos da CAIXA
• Integração com API: Conexão com a API oficial do Portal de Loterias da CAIXA
• Segurança Reforçada: CSP compatível com App Router/standalone, CORS estrito, rate limiting, validação Zod

Stack Tecnológica

• Frontend: App Router/React 19.2.8; Next.js 16.3.6 no caminho Bun e vinext/Vite no Worker
• Runtime: Worker com nodejs_compat em produção; Bun >=1.4.2 no caminho local/CI; imagem Docker de recuperação com digest imutável
• Banco de Dados: SQLite Durable Object em produção; bun:sqlite no caminho local e de recuperação
• Estilização: Tailwind CSS + componentes shadcn/ui
• TypeScript: Tipagem completa
• Analytics: Motor estatístico customizado

Primeiros Passos

Pré-requisitos

• Bun >=1.4.2 (runtime obrigatório para SQLite nativo)
• pnpm >=11 (gerenciador de dependências; ative com corepack enable)

Instalação

1. Instalar dependências:

pnpm install

2. Executar migrações do banco de dados:

bun run db:migrate

3. Baixar dados de sorteios (opcional - baixa os últimos 100 sorteios):

bun run db:pull -- --limit 100

Ou baixar todo o histórico (pode levar vários minutos):

bun run db:pull

4. Iniciar servidor de desenvolvimento:

bun run dev

Acesse http://localhost:3000 para ver a aplicação.

Para validar o runtime de produção local:

bun run build
bun run start

O repositório usa bunfig.toml com run.noOrphans = true, disponível no baseline Bun 1.3.14, para encerrar processos Bun filhos quando o processo pai morre. bun run build delega somente a compilação do Next.js ao Node 22+, evitando um crash conhecido do Bun 1.3.14 no Linux; scripts, SQLite, API e runtime de produção continuam no Bun. Os scripts de supervisão também esperam process.exited após SIGTERM e escalam para SIGKILL depois do período de graça; não use proc.killed como prova de encerramento.

Comandos Disponíveis

• bun run dev - Iniciar servidor de desenvolvimento (API Bun + proxy Next.js)
• bun run build - Build para produção com o bundler padrão do Next.js 16
• bun run dist:standalone - Sincronizar dist/standalone a partir de .next/standalone para deploy self-hosted
• bun run deploy:verify - Validar que a produção pública em /api/health está saudável e na mesma versão de package.json
• bun run security:csp:edge - Validar que a borda pública não substitui a CSP nonce-based da aplicação e classificar o dono provável da sobrescrita; quando a CSP é compartilhada por home/API, imprime fingerprint curto, resumo de fontes e ações de remediação públicas; com ORIGIN_BASE_URL, compara uma origem direta sem imprimir a URL privada; com token read-only, diferencia zona inacessível de zona acessível sem regra candidata e pode executar Cloudflare Trace com simulação opt-in
• bun run start - Iniciar a stack de produção local (API Bun + Next standalone já buildado)
• bun run lint - Executar ESLint (falha em warnings)
• bun run lint:ast - Executar regras estruturais de supply chain com ast-grep
• bun run typecheck - Verificar os tipos TypeScript sem emitir arquivos
• bun run lint:fix - Corrigir problemas de lint automaticamente
• bun run format - Formatar código com Prettier
• bun run test - Executar testes com Vitest (usa fallback de banco em memória)
• bun run test:sqlite - Executar os testes de atraso no bun:sqlite em arquivo; limpa apenas a fixture descartável .tmp/e2e/delay-analysis-test.db
• bun run test:argent - Reproduzir a geração de 200 apostas e a página 4 em Chromium de 375 px, usando Argent
• O fluxo .argent/flows/qa-generator-ptbr-budget.yaml verifica 50,50 como R$ 50,50 e oito apostas, sem inflar o orçamento. Reproduza-o duas vezes com argent flow run qa-generator-ptbr-budget --platform chromium na mesma fixture de produção.
• bun run doctor - Executar o React Doctor instalado pelo lockfile
• bun run security:secrets - Escanear a árvore fonte limpa com Gitleaks via Docker
• bun run security:secrets:history - Escanear o histórico Git com relatório redigido em .tmp/ e resumo de alcance por branch/tag
• bun run db:migrate - Executar migrações do banco de dados

Scripts de Banco de Dados

O seed versionado inclui 3.064 concursos, até #3064 (29/09/2026). Para atualizar somente os concursos posteriores ao último armazenado, o entry point legado bun run scripts/fetch-missing.ts usa a mesma ingestão incremental, validação, DATABASE_PATH e transação de db:pull.

Opções de Download de Dados

# Baixar últimos N sorteios (substitui existentes)
bun run db:pull -- --limit 100

# Baixar últimos N sorteios (incremental - apenas novos)
bun run db:pull -- --limit 100 --incremental

# Baixar faixa específica
bun run db:pull -- --start 1 --end 500

# Baixar todos os sorteios (sem flags)
bun run db:pull

# Baixar todos incrementalmente (pula existentes)
bun run db:pull -- --incremental

# Aceitar explicitamente lacunas da CAIXA quando uma faixa parcial for aceitável
bun run db:pull -- --incremental --allow-partial

Reidratação de premiação

db:pull reescreve todas as colunas de todos os concursos em uma transação única e longa. Quando faltam apenas os dados de premiação — o caso de um banco carregado antes do tratamento atual de listaRateioPremio/faixa, que faz a seção "Prêmios" exibir R$ 0,00 — use o backfill dedicado, que altera só as colunas de prêmio, commita em lotes e é retomável:

As consultas HTTP e pausas acontecem fora da transação de escrita. Cada lote já recebido é aplicado numa transação curta, permitindo logs/auditoria de outra conexão durante a espera da CAIXA. Falhas de banco revertem o lote; falhas sustentadas de rede preservam o progresso já recebido para retomada.

# Somente concursos sem dados de premiação
bun run db:backfill-prizes

# Refazer todos os concursos armazenados
bun run db:backfill-prizes -- --all

# Limitar a quantidade e ajustar o espaçamento entre requisições
bun run db:backfill-prizes -- --limit 100 --delay 500

Modos:

• Padrão (Completo): Usa UPSERT com ON CONFLICT ... DO UPDATE - atualiza sorteios existentes preservando a linha
• Incremental (--incremental): Usa ON CONFLICT ... DO NOTHING - apenas adiciona novos sorteios, pula existentes
• Parcial explícito (--allow-partial): mantém sorteios baixados mesmo quando alguns concursos falham; sem essa flag, downloads de faixa falham fechados para evitar bases incompletas tratadas como sucesso

Quando usar modo incremental:

• Atualizações diárias/semanais para adicionar apenas novos sorteios
• Quando deseja preservar modificações manuais em sorteios existentes
• Para reduzir chamadas de API e tempo de processamento

Otimização do Banco de Dados

Após baixar grandes quantidades de dados, otimize o banco para recuperar espaço e melhorar performance:

# Otimizar banco de dados (recomendado após grandes ingestões)
bun scripts/optimize-db.ts

Este script executa:

• WAL Checkpoint: Mescla Write-Ahead Log de volta ao arquivo principal do banco
• VACUUM: Recupera espaço não utilizado e compacta o banco
• ANALYZE: Atualiza estatísticas do otimizador de queries para melhor performance

Quando executar:

• Após download inicial de dados (bun run db:pull)
• Após baixar 100+ novos sorteios
• Semanalmente em ambientes de produção (via cron)
• Quando experimentar problemas de performance

Build e Empacotamento

Verificação de UI com Argent

Nesta revisão, a instrução do responsável substitui o gate Playwright por Argent. O fluxo salvo cobre geração e paginação; as demais verificações de UI exigem interação e evidência pelo Argent. Não representa toda a cobertura legada de tests/app.

Com Argent e Google Chrome instalados no macOS, prepare uma fixture isolada e inicie a stack de produção local (o build usa a porta padrão da API, 3201):

bun run scripts/prepare-e2e-db.ts
bun run build
PORT=3117 DATABASE_PATH=.tmp/e2e/mega-sena.db \
  IP_HASH_SECRET=public-argent-test-only-secret-0123456789 \
  TRUST_PROXY_HEADERS=true bun run start

Em outro terminal, rode bun run test:argent duas vezes sem alterar o YAML. Cada execução abre um perfil novo em .tmp/ e produz um relatório por etapa. O fluxo confirma 200 apostas e a faixa 61–80; contraste, largura efetiva e screenshots devem ser inspecionados pelo Argent em desktop e celular. O reset de fixtures aceita somente arquivos .db regulares em .tmp/e2e via E2E_DATABASE_PATH e ignora DATABASE_PATH herdado. Nunca use o segredo público de teste em produção.

O build do caminho local/VPS usa o fluxo padrão do Next.js 16:

bun run build

Para preparar os artefatos usados no deploy self-hosted e no Dockerfile, gere dist/standalone a partir do output oficial do Next:

bun run dist:standalone

Esse comando copia .next/standalone e .next/static sem depender de glob de shell, preservando arquivos ocultos como BUILD_ID e manifests. O build exclui bancos SQLite, WAL/SHM, backups e artefatos .bak do output tracing do Next.js e falha se .next/standalone ainda contiver esses arquivos. O script também remove qualquer diretório db/ remanescente de dist/standalone, mantendo o deploy fail-closed e dependente do volume/runtime reais.

Staging segue o mesmo artefato self-hosted documentado em docs/DEPLOY.md, mas exige alvo remoto explícito. Não considere staging publicado quando houver apenas tarball, imagem local ou CI verde; é preciso health check no domínio/base URL de staging real.

Estrutura do Projeto

├── app/                    # App Router Next.js
│   ├── (home)/            # Página inicial e seu estado de carregamento
│   ├── dashboard/         # Páginas do dashboard
│   │   ├── page.tsx      # Dashboard principal
│   │   ├── statistics/   # Página de estatísticas
│   │   └── generator/    # Página do gerador de apostas
│   ├── resultados/        # Arquivo de resultados e páginas por ano
│   ├── concurso/[numero]/ # Página e imagem social de cada concurso
│   ├── numeros/           # Frequência e atraso de cada número de 1 a 60
│   ├── mega-da-virada/    # Todas as edições da Mega da Virada
│   ├── _lib/, _components/ # Carregadores e UI compartilhados do arquivo
│   ├── sitemap.xml/, robots.ts, llms.txt/  # Superfície para buscadores e IAs
│   └── layout.tsx        # Layout raiz
├── components/            # Componentes React
│   ├── ui/               # Componentes shadcn/ui
│   └── *.tsx             # Componentes customizados
├── lib/                   # Bibliotecas principais
│   ├── analytics/        # Estatísticas e geração de apostas
│   ├── api/              # Cliente da API CAIXA
│   ├── security/         # CSP e headers de segurança
│   ├── db.ts             # Utilitários do banco de dados
│   ├── constants.ts      # Constantes compartilhadas
│   └── utils.ts          # Funções auxiliares
├── db/                    # Banco de dados SQLite
│   ├── migrations/       # Migrações SQL
│   └── mega-sena.db      # Arquivo do banco (gerado)
├── docs/SECURITY.md       # Decisões de CSP e manutenção de overrides
├── next.config.js         # Rewrites e output standalone do Next.js
├── proxy.ts               # Proxy Next.js (CSP e headers de segurança)
├── server.ts              # Superfície `/api/*` executada em Bun
└── scripts/               # Scripts CLI
    ├── migrate.ts        # Executor de migrações
    ├── pull-draws.ts     # Ingestão de dados
    └── sync-standalone-dist.ts  # Prepara `dist/standalone` para deploy

Estratégias de Geração de Apostas

1. Aleatório (Random): Números completamente aleatórios
2. Números Quentes (Hot Numbers): Baseado nos números mais sorteados
3. Números Frios (Cold Numbers): Baseado nos números menos sorteados
4. Balanceado (Balanced): Mix inteligente de números quentes e frios
5. Fibonacci: Baseado na sequência matemática de Fibonacci

Schema do Banco de Dados

Tabela draws

Armazena histórico completo de sorteios com:

• Número do concurso, data e números sorteados (1-6)
• Informações de prêmios para Sena, Quina e Quadra
• Dados de acumulação
• Flags de sorteios especiais

Tabela number_frequency

Análise de frequência em cache para todos os números (1-60):

• Total de ocorrências
• Último concurso e data de sorteio

Tabela user_bets

Rastreamento opcional de apostas geradas para análise futura.

Configuração

Copie .env.example para .env.local e personalize:

# URL base usada pelas páginas do App Router para fetches server-side
NEXT_PUBLIC_BASE_URL=http://localhost:3000

# Porta exposta pelo servidor Bun (`server.ts`)
API_PORT=3201

# CORS: lista de origens permitidas (separadas por vírgula)
ALLOWED_ORIGINS=http://localhost:3000,http://localhost:3002

# Confie em headers de proxy apenas quando o peer for loopback ou estiver em TRUSTED_PROXY_IPS
TRUST_PROXY_HEADERS=false
# TRUSTED_PROXY_IPS=172.18.0.10

# Segredo opcional para chamadas server-side internas escaparem do rate limit público.
# Deve ter no mínimo 32 caracteres e nunca ser exposto ao navegador.
# INTERNAL_API_SECRET=

# LGPD: segredo HMAC para pseudonimização de IP (mínimo 32 caracteres).
# Obrigatório em produção (NODE_ENV=production). Gere com: openssl rand -hex 32
IP_HASH_SECRET=

# O E2E injeta um valor público de teste no próprio playwright.config.ts.
# Produção nunca gera esse segredo automaticamente.

Os testes executados via bun run test simulam o banco de dados usando um driver em memória quando a variável VITEST está definida, permitindo rodar a suite sem o bun:sqlite real.

Privacidade e LGPD

O projeto cumpre a Lei nº 13.709/2018 (LGPD):

• Política de privacidade pública em /privacy (fonte: docs/PRIVACY.md).
• Página dedicada de direitos do titular em /privacy/direitos com modelo de solicitação.
• Documento de governança em docs/LGPD-COMPLIANCE.md (RoPA, bases legais, retenção, segurança).
• Plano de resposta a incidente em docs/INCIDENT-RESPONSE.md (Art. 48).
• Banner não-bloqueante de transparência sobre localStorage.
• Pseudonimização de IP com HMAC-SHA256 e salt rotativo (lib/security/pseudonymize.ts).
• Canal de privacidade: [email protected].

Design System

A aplicação segue um design limpo e minimalista inspirado em Apple/Linear/Mercury com:

• Tipografia: Fonte Inter com espaçamento apertado
• Paleta de Cores: Base neutra + destaque cyan elétrico
• Componentes: Cards arredondados com sombras suaves
• Micro-interações: Transições suaves e estados de hover
• Responsivo: Abordagem mobile-first

Todos os design tokens estão definidos em app/globals.css e tailwind.config.cjs.

Endpoints da API

Arquivo de resultados (GET, somente leitura)

Usados pelas páginas /resultados, /concurso, /numeros e /mega-da-virada. Parâmetros inválidos, ambíguos ou fora do intervalo respondem 400; concurso ou ano inexistente, 404. Seguem o mesmo rate limit por visitante e a mesma auditoria das demais rotas.

• GET /api/draws — índice: total de concursos, últimos 10 sorteios e resumo por ano.
• GET /api/draws?year=2026 — todos os concursos do ano (1996–2100).
• GET /api/draws?contest=3060 — um concurso com premiação por faixa, concursos vizinhos, histórico de cada dezena até aquele sorteio e posição da soma.
• GET /api/draws?view=mega-da-virada — as edições da Mega da Virada, da mais recente para a mais antiga.
• GET /api/numbers — frequência, ranking e atraso dos 60 números.
• GET /api/numbers?n=10 — perfil de um número: aparições, intervalo médio, maior sequência sem sair e dezenas parceiras.
• GET /api/sitemap — lista mínima de concursos e anos para o sitemap.xml.

/api/generate-bets (POST)

Gera apostas baseadas em orçamento, estratégia e modo.

Modos aceitos: simple_only, multiple_only, mixed e optimized. O valor simple_only corresponde a Apenas Simples na interface.

Corpo da Requisição:

{
  "budget": 100,
  "strategy": "balanced",
  "mode": "optimized"
}

Resposta:

{
  "success": true,
  "data": {
    "bets": [
      {
        "id": "bet_1727711234567_n1m2o3p4q",
        "numbers": [5, 12, 23, 34, 45, 56],
        "cost": 6,
        "type": "simple",
        "numberCount": 6,
        "strategy": "balanced"
      }
    ],
    "totalCost": 6,
    "remainingBudget": 94,
    "budgetUtilization": 6,
    "totalNumbers": 6,
    "strategy": "balanced",
    "mode": "optimized",
    "summary": {
      "simpleBets": 1,
      "multipleBets": 0,
      "averageCost": 6
    }
  }
}

Segurança

A descoberta no ChatGPT Search, as políticas de crawlers e os limites de medição de citações/referrals estão documentados em CHATGPT-SEARCH.md. O site mantém telemetria operacional, sem analytics de aquisição.

Esta aplicação implementa medidas de segurança seguindo OWASP e melhores práticas atuais:

Content Security Policy (CSP)

• CSP compatível com App Router/standalone: política por origem, tipos de recurso e headers restritivos gerados no proxy.ts
• Nonce por request: scripts de produção usam nonce + strict-dynamic, sem unsafe-inline em script-src
• Estilos com nonce: produção remove unsafe-inline de style-src; Google Fonts continua permitido por origem. Não há exceção para atributos style: o HTML do servidor não usa style=.
• Renderização dinâmica: páginas protegidas por nonce são renderizadas por request, como esperado para CSP nonce-based no Next.js. A alternativa CSP estática/SRI preserva cache estático, mas não é compatível com a hidratação atual do App Router neste projeto.
• JSON-LD seguro: dados estruturados recebem nonce e escapam < antes da injeção no <script>
• Proteção de Frame: frame-src, frame-ancestors definidos como 'none'

Headers de Segurança

Header	Valor
Content-Security-Policy	Restritivo por origem e tipos de recurso
Cross-Origin-Embedder-Policy	require-corp
Cross-Origin-Opener-Policy	same-origin
Cross-Origin-Resource-Policy	same-origin
Strict-Transport-Security	Aplicado pela API Bun em HTTPS confiável e pelo reverse proxy nas páginas TLS
X-Content-Type-Options	nosniff
X-Frame-Options	DENY

Segurança da API

• Validação de Input: Schemas Zod em todos os endpoints
• Rate Limiting: 100 requisições/minuto por identificador de cliente derivado do IP em toda a superfície /api/*, incluindo /api/health e preflights CORS
• Métodos HTTP restritos: endpoints públicos rejeitam métodos não suportados com 405 e header Allow
• JSON estrito em POST: endpoints JSON rejeitam Content-Type ausente ou não JSON com 415, evitando requisições simples cross-site sem preflight em operações de custo computacional
• Headers defensivos próprios: a superfície /api/* em Bun também aplica CSP deny-by-default para JSON, nosniff, DENY em frame e no-referrer
• CORS mínimo: validação estrita de origem, sem wildcards em produção, preflight limitado a Content-Type e sujeito ao mesmo rate limit da API
• Proxy trust restrito: headers CF-Connecting-IP/X-Real-IP/X-Forwarded-For só influenciam IP, auditoria ou rate limit quando TRUST_PROXY_HEADERS=true, o peer de socket é loopback ou está em TRUSTED_PROXY_IPS, o valor recebido é válido e o proxy sobrescreve headers de IP vindos do cliente; proxy.ts não emite HSTS nem upgrade-insecure-requests, então HSTS de TLS terminado deve ser aplicado no reverse proxy
• Rate limit interno: chamadas server-side podem usar INTERNAL_API_SECRET para evitar consumir a cota pública, mas o bypass exige peer loopback e segredo forte compartilhado; um cliente público não deve conseguir ativá-lo apenas enviando headers.
• SQL Injection: Queries parametrizadas com bun:sqlite
• Limite real de payload: POST JSON é rejeitado acima do teto configurado mesmo sem Content-Length

Infraestrutura

• Docker: Imagem runtime-only executada com usuário não-root bun (UID/GID 1000)
• Publicação por digest: o CI escaneia com Trivy o mesmo digest canônico construído e só aplica tags após o gate HIGH/CRITICAL passar
• Shutdown supervisionado: scripts Bun de produção aguardam saída real dos filhos e fazem fallback para SIGKILL quando SIGTERM não encerra dentro do prazo
• Segredos: arquivos de ambiente fora do VCS; Gitleaks fixado por digest imutável escaneia a árvore atual no CI e o histórico sob demanda

Telemetria Operacional

• Logs estruturados: request ID, rota, status e contexto técnico mínimo
• Identificador pseudônimo de cliente: hash derivado do IP para rate limit/auditoria
• User-Agent sanitizado: armazenado com limite de tamanho para investigação operacional
• Redação recursiva: metadados de logs e auditoria redigem chaves sensíveis aninhadas e limitam profundidade, arrays e tamanho de strings

Deploy em Produção

Build para produção:

bun run build

A aplicação pode ser implantada via Docker. Veja docker-compose.yml para configuração.

O docker-compose.yml local publica as portas apenas em 127.0.0.1. Em produção, exponha somente o proxy reverso público e mantenha a porta da API Bun restrita à rede interna do Docker/proxy.

Contribuindo

1. Siga o formato Conventional Commits
2. Execute bun run lint:fix e bun run format antes de commitar
3. Garanta que todos os testes passam com bun run test -- --run
4. Atualize a documentação para novas funcionalidades

Antes de publicar uma release, execute bun run lint, bun run lint:ast, bun run typecheck, bun run test -- --run --coverage, bun run test:sqlite, bun run security:braces, pnpm audit e bun run build; verifique mudanças de UI com Argent conforme o fluxo acima. A exceção de audit do patch local é específica e exige a regressão anterior; veja SECURITY.md.

Depois do deploy, execute bun run deploy:verify; produção com versão antiga em /api/health deve ser tratada como release não concluída. Depois de mudanças em Cloudflare/Traefik, execute também bun run security:csp:edge; a borda não deve trocar a CSP nonce-based por uma política com unsafe-inline em script-src ou style-src. A aplicação não usa unsafe-inline em nenhuma diretiva de produção. Quando a mesma CSP ampla aparecer na home e em /api/health, o verificador deve apontar shared_response_headers como diagnóstico provável; investigue primeiro regras globais de response headers ou middleware do proxy. Se o lookup Cloudflare disser que a zona está inacessível ao token, não conclua que a zona não tem regras candidatas.

Licença

Apache 2.0

Aviso Legal

Esta aplicação é apenas para fins educacionais e de análise estatística. Não garante resultados vencedores. Jogos de loteria são jogos de azar. Jogue com responsabilidade.