DNAPLAY

Acompanhamento do projeto

Atualizado em (horário de Brasília)

Esta página é o acompanhamento. Para usar o sistema, abra o DNAPLAY.

Abrir o DNAPLAY dnaplay.200-141-24-170.sslip.io

O que já funciona

  • criar conta e entrar
  • começar uma nova análise: vídeo de referência por link do YouTube ou arquivo, e o seu vídeo por arquivo
  • enviar o vídeo (o envio é em partes e retoma se a conexão cair)
  • análise com IA de verdade: o Gemini assiste aos dois vídeos e o Claude compara, verifica e recomenda, com o custo de cada análise à vista
  • página de resultado: lances comparados com o minuto certo no YouTube e no seu vídeo, pontos fortes, o que mais custa e recomendações
  • minha conta, sessões ativas e assinatura (sem cobrança)
  • DNAPLAY Live: a página que explica o coach durante a partida e salva o modo e a voz preferidos

O que ainda não funciona

  • a qualidade da análise ainda não foi validada com partidas de verdade (etapa E3, aguardando os vídeos do Rotcha)
  • aula animada e vídeo final narrado: Fase 3
  • “esqueci minha senha” não envia e-mail (B8); se alguém perder a senha, o dono pede e a gente redefine
  • DNAPLAY Live durante a partida: entra na Fase 6 (B10); hoje só as preferências ficam salvas

Etapas para aprovação

Cada etapa passa por: implementar → corrigir falhas → testar → Wellington aprova.

E1 aguardando aprovação

Fundação: cadastro, login, nova análise, upload, fila

O que olhar
o sistema no ar: https://dnaplay.200-141-24-170.sslip.io (criar conta, nova análise, enviar vídeo, ver o processamento)
Entregue em
21/10/2026
Observações do Wellington
nenhuma ainda
E2 aguardando aprovação

Documento de alinhamento v2 + escopo do DNAPLAY Live

O que olhar
o PDF v2 (seção “Documentos” desta página: docs/DNAPLAY_Modelo_de_Negocio_v2.pdf) e, no sistema, o menu “DNAPLAY Live” (explicação, modos e preferências salvas). Responder também: antecipar o Live para logo após a Fase 2?
Entregue em
23/10/2026
Observações do Wellington
nenhuma ainda
E3 aguardando vídeos do rotcha

Primeira análise real com partidas de verdade

O que olhar
o Rotcha cria uma análise pelo próprio site: em "Referência", o link do YouTube de um pro; em "Sua gameplay", uma partida dele. Ao terminar, a página de resultado mostra os lances comparados (com o minuto certo), pontos fortes, o que mais custa, recomendações e o custo real. O terminal lê o resultado com olhar crítico e registra no log o que a IA acertou, errou e não enxergou
Entregue em
undefined/undefined/—
Observações do Wellington
nenhuma ainda

Documentos

Documentos de alinhamento do projeto. Abra para ler ou baixar.

Estado das fases

  1. 1 — Fundação

    em andamento

    repositório, arquitetura, banco, autenticação, design system, layout, dashboard, fluxo de nova análise, upload, armazenamento privado, fila

    Pronta quando: usuário cria conta, envia dois vídeos, análise fica enfileirada e ingestão real roda

  2. 2 — Prova técnica da IA

    em andamento: encanamento real pronto (em produção desde 2026-10-23), aguardando partidas reais (E3)

    eventos, timestamps, análise independente A/B, comparação contextual, evidências, relatórios estruturados

    Pronta quando: validado com partidas reais

  3. 3 — Animação e relatório audiovisual

    não iniciada

    campo 3D, cenas, roteiro, narração, legendas, MP4, player

    Pronta quando: vídeo íntegro e sincronizado

  4. 4 — Coaching e evolução

    não iniciada

    chat, histórico, biblioteca, comparação entre análises

    Pronta quando: coach responde com links para evidências

  5. 5 — Comercialização

    não iniciada

    planos, pagamentos, créditos, admin, limites, monitoramento, carga, produção

    Pronta quando: produção estável

  6. 6 — DNAPLAY Live

    não iniciada (página e preferências já no ar)

    coach de IA durante a partida: captura da tela (PC, placa de captura ou YouTube não listado), análise em janelas, dicas por voz e texto nos modos discreto/equilibrado/intensivo/silencioso, relatório pós-partida

    Pronta quando: jogador compartilha a tela, joga uma partida inteira, recebe orientações por voz no modo escolhido com atraso declarado e ao fim vê o relatório; validado por jogadores reais

Feito até agora

  1. Bloco 16: correções da auditoria externa nº 1 (Bloco A)

    0 itens
    • Bloco 15: API da Hostinger descartada

      4 itens
      • Removido scripts/reiniciar-producao.ps1.
      • .github/workflows/vigia-externo.yml: saiu o passo "Reiniciar pela API da Hostinger" (e a variável IP); o aviso por e-mail agora diz para reiniciar pelo painel.
      • Registrado em docs/SECURITY.md (decisão e motivo; não reintroduzir sem nova decisão) e docs/DEPLOYMENT.md (linha "Reinício do servidor": manual pelo painel); incidente de 23/10 atualizado.
      • Conferido: .secrets/hostinger-api.txt já não existia nesta máquina; gh secret list não tem HOSTINGER_API_TOKEN (nunca foi cadastrado). Busca no projeto por HOSTINGER_API, reiniciar-producao, hostinger-api, developers.hostinger: só restam as menções históricas neste log (blocos 13 e 14), mantidas como registro.
    • Bloco 14: blindagem do sistema aplicada, sudo do deploy e Gemini pago

      5 itens
      • blindar-host.sh ganhou o passo do sudo (/etc/sudoers.d/deploy, 0440, validado com visudo -c -f antes de instalar e visudo -c depois). Aplicado às 21:58 com docker run --rm -i --privileged --pid=host alpine:3 nsenter -t 1 -m -u -i -n -p -- bash -s.
      • Conferência no servidor: sudo -n true → ok; visudo -c → /etc/sudoers.d/deploy: parsed OK; swapon --show → /swapfile file 4G 0B; kernel.panic = 10, kernel.hung_task_panic = 1, kernel.softlockup_panic = 1, vm.swappiness = 10; RuntimeWatchdogUSec=1min, RebootWatchdogUSec=5min, softdog carregado, /dev/watchdog0; journald Storage=persistent (/var/log/journal/…).
      • /opt/dnaplay/.env: cópia .env.bak-202610232201 (0600) e troca para GEMINI_MODEL=gemini-4-argon, GEMINI_MODEL_FAST=gemini-3.8-flash; reservas sem mudança (padrão gemini-3.5-flash-lite,gemini-3.8-flash). Padrões do Compose e .env.example alinhados.
      • Preços: https://ai.google.dev/gemini-api/docs/pricing consultada em 2026-10-23 ("Last updated 2026-10-22 UTC"): gemini-4-argon US$ 2,00 / 10,00 (entrada/saída por 1 M tokens) até 30/11/2026, depois 4,00 / 20,00; gemini-3.8-flash e gemini-3.6-flash 0,75 / 3,75 até 31/12/2026, depois 1,50 / 7,50; gemini-3.5-flash-lite 0,30 / 2,50. Iguais aos já cadastrados; acrescentado o preço de cache (cache_read) em pricing.json.
      • Docs: B11 resolvido (KNOWN_LIMITATIONS.md), D37 (ARCHITECTURE.md), SECURITY.md (sudo e por que o risco não muda: o deploy já era do grupo docker), DEPLOYMENT.md, incidente (pendência do sistema resolvida).
    • Bloco 13: diagnóstico das quedas do servidor e blindagem

      0 itens
      • Bloco 12: Fase 2 — a IA de verdade (encanamento real em produção)

        5 itens
        • Serviço de análise: GeminiProvider real (URL do YouTube em fileData, arquivo pela Files API e apagado ao fim, triagem em resolução baixa, 2ª passada densa a 5 qps limitada por orçamento, 3 tentativas com espera crescente, modelos reserva), ClaudeProvider real (pares, diagnóstico, verificação, recomendações), regras determinísticas em stages.py, costs.py + config/pricing.json (fonte e data), prompts versionados em prompts/, gravação/reprodução (Cassette), endpoints /v1/stages/*.
        • Banco: migration aditiva 0006_resultados_ia (evidências por evento, índice de custo); custo por estágio somado (inclusive tentativas que falharam), gasto do dia por chamada (horário de Brasília), ResultsRepo.
        • Site: worker encadeia identificação de situações → análise A → análise B → comparação → diagnóstico → verificação → recomendações → finalização; aula animada e vídeo final aparecem "não incluída nesta versão"; guarda de orçamento antes de cada estágio pago (alerta em 80 %); Cancelar e Retomar de onde parou; página de resultado (resumo honesto, pares com minuto certo no YouTube e no vídeo do jogador, pontos fortes, o que mais custa, recomendações, tudo o que a IA registrou, custo real); /api/health com os dois provedores; vídeo do usuário servido com Range só para o dono. Aviso antigo "a análise com IA ainda não está ativa" removido do assistente (busca no projeto inteiro).
        • Problema encontrado e corrigido no caminho: na revisão de trecho recortado, o Gemini misturou na mesma resposta o relógio do trecho e o do vídeo (ex.: lance em 00:01 com o jogo começando em 00:20). Agora a 1ª passada sempre começa no início do vídeo e cada lance da revisão é conferido um a um (dentro do trecho = mantém; relativo = desloca; incoerente = descarta e anota).
        • Docs: ARCHITECTURE.md (D37), AI_PIPELINE.md (como cada estágio chama o modelo, regras, amostragem, falhas, limites), COST_MODEL.md (preços com fonte/data, guarda de orçamento), KNOWN_LIMITATIONS.md (B1 e B9 resolvidos, B4 continua, B11 novo, limites reais da API), ROADMAP.md (Fase 2 em andamento), APROVACOES.md (E3).
      • Bloco 11: documento de ferramentas v2 publicado

        1 item
        • PDF e HTML fonte de "Ferramentas, serviços e assinaturas v2" no repositório e na seção "Documentos" da página; revisões em docs/ARCHITECTURE.md (Vercel dispensada, Supabase e R2 adiados, Hetzner só como opção futura depois do upgrade da Hostinger, atendimento Crisp + WhatsApp Business → D36); B2 atualizado; histórico da página continua recolhido (título, data e quantidade de itens; detalhes em <details>).
      • Bloco 10: DNAPLAY Live (coach durante a partida) entra no projeto como Fase 6

        7 itens
        • Contratos Pydantic novos (services/analysis/dnaplay_analysis/contracts/live.py): LiveWindowAnalysis (janela de 15–30 s, eventos dentro da janela, evidências existentes), LiveTip (texto até 160 caracteres, categoria, gravidade, rótulo, confiança, evidência obrigatória, momento do lance e da decisão, modo, entrega falada/exibida/pos_partida; hipótese nunca falada; simulação proibida; silencioso só pós-partida) e LiveSessionSummary. JSON Schemas exportados para packages/contracts/schemas e tipos TS gerados (LiveMode, TipSeverity, TipDelivery, CaptureSource exportados).
        • Motor de decisão por modo (services/analysis/dnaplay_analysis/live/decision.py, LiveCoach): gravidade e confiança mínimas por modo, intervalo mínimo entre falas (120/60/25 s), cooldown por categoria (300/180/90 s), sem repetir a mesma dica, no máximo uma fala por janela, lance com mais de 40 s não é falado, candidata sem evidência na janela é descartada; resumo com categorias recorrentes. 14 testes novos em tests/test_live.py, com entradas simuladas marcadas como FIXTURE.
        • Banco: migration aditiva 0005_live.sql com coach_settings, live_sessions, live_windows e live_tips (RLS forçada; políticas por usuário no Supabase); LiveRepo com userId obrigatório; 2 testes novos (isolamento entre usuários, dica sem evidência recusada).
        • Sistema: item "DNAPLAY Live" no menu (/app/live): explicação em linguagem de jogador (exemplos do Wellington), aviso "Disponível na Fase 6. Hoje você já pode deixar suas preferências salvas.", atraso declarado de 10–30 s ("quase em tempo real"), captura por plataforma, custo por minuto sem valores. Formulário que salva o modo preferido, a voz e o volume em coach_settings, também em Minha conta. Sem botão de iniciar sessão.
        • Docs: PRD.md §11 (objetivo, jornada, modos com regra objetiva, captura, limites, métricas) e público; AI_PIPELINE.md (Módulo Live); ARCHITECTURE.md (D31–D35); DATABASE.md; COST_MODEL.md (Live por minuto com fator por modo, sem valores); KNOWN_LIMITATIONS.md (B10); ROADMAP.md (Fase 6, com a observação sobre antecipar para depois da Fase 2); APROVACOES.md (E2, aguardando aprovação).
        • Página de acompanhamento: seção "Documentos" com o PDF v2 (atual) e o v1 (histórico), copiados para dist/docs/; 6 fases; E2 com link para a seção; o Live nas listas "o que já funciona / o que ainda não funciona".
        • Observação: a taxonomia tem 38 categorias em taxonomy.py (o pedido citava 37); D35 registra o número real.
      • Bloco 9: o servidor Hostinger é PRODUÇÃO (sem avisos de demonstração) e backup diário

        7 itens
        • Interface: removida a faixa "Ambiente de demonstração" (environment-banner.tsx, NEXT_PUBLIC_ENVIRONMENT no código, Dockerfile, Compose, gerar-env.sh e .env.example).
        • Texto visível achado na busca: o plano de entrada se chamava "Gratuito / Demonstrativo" (semente da migration 0001). Migration aditiva 0004_plano_gratuito_nome renomeia para "Gratuito" (só se o nome ainda for o original); teste novo no pacote db.
        • Renomeações: deploy/demo/ → deploy/producao/; variável DEMO_HOST → APP_HOST (também no /opt/dnaplay/.env do servidor, com cópia de segurança apagada depois do deploy verde); workflow "Deploy demo (Hostinger)" → "Produção (Hostinger)" (.github/workflows/producao.yml); segredos DEMO_SSH_ → PROD_SSH_ (novos criados; antigos apagados depois do primeiro deploy verde); scripts/deploy-demo.ps1 → scripts/deploy-producao.ps1; .secrets/hostinger-demo.txt → .secrets/hostinger-producao.txt; nome do servidor dnaplay-demo → dnaplay; deploy key do GitHub dnaplay-demo → dnaplay-producao (mesma chave, só leitura); job do CI demo-compose → producao-compose, que agora garante que a página não tem a faixa. Chaves locais ~/.ssh/dnaplay_demo* mantidas (nome histórico, registrado em docs/DEPLOYMENT.md).
        • Página de acompanhamento: botão "Abrir o DNAPLAY", texto "Esta página é o acompanhamento. Para usar o sistema, abra o DNAPLAY."; o gerador lê "Endereço do sistema:" em docs/DEPLOYMENT.md. E1 em docs/APROVACOES.md aponta para "o sistema no ar".
        • Backup de produção: deploy/producao/backup.sh (pg_dump -Fc + uploads.tgz + SHA256SUMS, confere o dump, guarda 7 dias em /opt/dnaplay/backups); cron diário às 03:30 instalado por atualizar.sh, que também faz backup antes de cada atualização; deploy/producao/testar-restauracao.sh (restaura num banco temporário, compara contagens, apaga o temporário); scripts/backup-producao.ps1 copia o último backup para D:\backups\dnaplay\ e confere as somas (até existir o R2).
        • Docs: README.md, docs/DEPLOYMENT.md (seção Produção: regras, backup, restauração, operação), docs/ARCHITECTURE.md (D30), docs/KNOWN_LIMITATIONS.md e docs/PRD.md sem "demonstrativo".
        • Prints antigos com a faixa (14–19-demo-*) removidos da galeria; novos sem faixa: 14-producao-inicio.png, 15-producao-cadastro-celular.png, 16-producao-assinatura-celular.png.
      • Bloco 8: demonstração no ar (Hostinger São Paulo) e teste ponta a ponta

        6 itens
        • Servidor dnaplay-demo (Hostinger KVM 2, São Paulo, Ubuntu 24.04.5, IP 200.141.24.170). Acesso inicial pela chave ~/.ssh/dnaplay_demo cadastrada pelo dono no painel (sem senha root).
        • bootstrap.sh passou a ter duas etapas: preparo (nome dnaplay-demo, usuário deploy só com chave, Docker 29.9.2 + Compose v5.6.1, ufw 22/80/443, fail2ban, unattended-upgrades, fuso de SP, swap 2 GB) e travar (sem senha, sem root), executada só depois de confirmar que deploy entra por chave.
        • Deploy key só-leitura dnaplay-demo no GitHub; código em /opt/dnaplay/app; /opt/dnaplay/.env gerado no próprio servidor (permissão 600; segredos nunca saíram de lá).
        • Deploy automático: chave separada para o GitHub Actions (~/.ssh/dnaplay_demo_actions); segredos DEMO_SSH_HOST, DEMO_SSH_USER, DEMO_SSH_KEY, DEMO_SSH_KNOWN_HOSTS gravados (impressão digital conferida com a do servidor).
        • Correção encontrada no teste: aviso de hidratação do React (#418) na tela de processamento. O servidor (UTC no contêiner) e o navegador (Brasília) formatavam a data diferente. Criado lib/dates.ts com fuso fixo America/Sao_Paulo, usado nas 4 telas com data, mais teste.
        • Docs: endereço da demo e mapa de servidores em docs/DEPLOYMENT.md; E1 aponta para a demo em docs/APROVACOES.md; link no README.md; botão "Abrir demonstração" na página de acompanhamento.
      • Bloco 7: demonstração online pronta para publicar (aguardando o VPS)

        9 itens
        • .secrets/hostinger-demo.txt ainda não existe: feito tudo que independe do servidor (conforme PROMPT_DEMO_ONLINE.md). Pasta .secrets/ confirmada no .gitignore.
        • Web: output: "standalone" com rastreamento a partir da raiz do monorepo e as migrations SQL incluídas; faixa "Ambiente de demonstração" quando NEXT_PUBLIC_ENVIRONMENT=demo (embutida no build).
        • Correção encontrada no teste: atrás de proxy, os redirecionamentos do proxy.ts (ex.: /app → /login) apontavam para o endereço interno (http://127.0.0.1:3100/...). Agora usam X-Forwarded-Host/X-Forwarded-Proto (o web só é alcançável pelo Caddy). Cookie de sessão já é secure em produção.
        • Contêineres: apps/web/Dockerfile (Node 24, standalone, usuário node, healthcheck), services/analysis/Dockerfile (Python 3.12 slim + FFmpeg do apt, usuário sem privilégio, healthcheck), .dockerignores.
        • deploy/demo/: docker-compose.yml (postgres:16, analysis sem porta publicada, web, caddy; volumes pgdata, storage, analysis-work; limites de memória), Caddyfile (HTTPS automático, 16 MB por requisição: o upload é em partes de 8 MB), .env.example, gerar-env.sh (segredos gerados no próprio servidor), atualizar.sh (sobe e confere /api/health), bootstrap.sh (usuário deploy só com chave, Docker, ufw 22/80/443, fail2ban, unattended-upgrades, fuso de SP, swap 2 GB, SSH sem senha e sem root, deploy key só-leitura do GitHub).
        • .github/workflows/deploy-demo.yml: após CI verde de push na main deste repositório, publica por SSH (host conferido por known_hosts, commit precisa pertencer à main). Sem os segredos DEMO_* falha com mensagem clara e não publica. scripts/deploy-demo.ps1 para publicação manual.
        • CI ganhou o job demo-compose: monta as duas imagens e sobe postgres + analysis + web de verdade no Linux do GitHub (substitui o teste com Docker que esta máquina não tem).
        • Página de acompanhamento: bloco "o que dá para testar / o que ainda não funciona" e botão "Abrir demonstração", que aparece sozinho quando docs/DEPLOYMENT.md tiver o endereço real.
        • docs/DEPLOYMENT.md: seção do ambiente demo (mapa de servidores, primeira instalação passo a passo, publicar, logs, reiniciar, backup e restauração do pgdata e dos uploads, avisos).
      • Bloco 6: CI no ar, correção de arquivo fora do repositório e decisões de ferramentas do dono

        6 itens
        • O primeiro CI no Linux revelou que apps/web/src/server/storage/index.ts nunca tinha sido versionado: a regra storage/ do .gitignore ignorava também o código-fonte. Corrigido para /storage/ (só a raiz) e o arquivo entrou no repositório. Conferido com um clone limpo: npm ci + npm run build + typecheck + testes passam.
        • Teste test_versions_available exigia FFmpeg 8 exato (versão do Windows de dev); passou a exigir só versão detectável.
        • CI: FFmpeg instalado por binário pronto (FedericoCarboni/setup-ffmpeg@v3) porque o apt-get update do runner travou mais de 10 min; limite de 20 min por job.
        • DNAPLAY_Ferramentas_Servicos_Assinaturas.pdf (versão de 21/10 18h) movido para docs/referencias/ (tinha entrado por engano na raiz no commit 0ea4035).
        • Decisões do documento registradas em docs/ARCHITECTURE.md (D14–D29): Gemini (AI Studio → Vertex AI), Claude Sonnet 5.5 para diagnóstico/coach, RF-DETR + ByteTrack + OpenCV (sem YOLO por licença AGPL), Roboflow, ElevenLabs v3, Remotion + Three.js, Cloudflare R2, Hetzner CCX33, Vercel Pro, Stripe + eNotas, Resend, Sentry, Better Stack, PostHog, Turnstile, 1Password. Nenhuma vira código agora.
        • .env.example com as variáveis previstas (marcadas "ainda não usado pelo código"); docs/KNOWN_LIMITATIONS.md com fornecedores decididos em B3/B6/B8 e novo bloqueio B9 (chave da API do Claude); docs/DEPLOYMENT.md com Vercel Pro, Hetzner e R2 como alvo.
      • Bloco 5: página de acompanhamento no Cloudflare Pages e CI

        10 itens
        • docs/APROVACOES.md: ciclo implementar → corrigir → testar → Wellington aprova; etapa E1 (Fundação) entra como aguardando aprovação.
        • Gerador scripts/acompanhamento.mjs (Node puro, sem dependências): lê aprovações, roadmap, este log, bloqueios B1–B8, telas e git log; escreve apps/acompanhamento/dist/ (index.html, styles.css, logo.svg, screenshots/). Sem JavaScript no cliente. Página diz explicitamente que não é o aplicativo e que a demonstração ainda não está online.
        • Visual pelo design system (carvão/chumbo/branco-gelo, verde-limão só em destaques, Sora + Inter); emblema exportado como SVG estático de apps/web/src/components/brand/Emblem.tsx.
        • Scripts npm run acompanhamento:build e npm run acompanhamento:dev (gera e serve em http://127.0.0.1:4321 com servidor HTTP mínimo embutido, sem dependência nova).
        • Correção durante o teste: cards das fases vazavam 8 px na largura de celular (grade sem minmax(0, 1fr)); corrigido e conferido sem rolagem lateral em 390 px.
        • Cloudflare (conta da BANMO): projeto dnaplay-acompanhamento criado pela API REST (success=True, dnaplay-acompanhamento.pages.dev); primeira publicação manual com wrangler pages deploy → 16 arquivos enviados, "Deployment complete".
        • Segredos CLOUDFLARE_API_TOKEN (lido do arquivo, valor nunca exibido) e CLOUDFLARE_ACCOUNT_ID gravados no GitHub com gh secret set.
        • .github/workflows/acompanhamento.yml: a cada push na main gera e publica; falha com mensagem clara se faltar segredo ou se o index.html sair vazio.
        • .github/workflows/ci.yml: Ubuntu; Node 24 (npm ci, build, typecheck, testes, gerador) e Python 3.12 + FFmpeg (pytest, ruff, mypy).
        • docs/DEPLOYMENT.md e README.md com o endereço, a conta, onde fica o token (só o caminho) e o comando manual.
      • Bloco 4: correções de segurança após revisão

        3 itens
        • 688455c — redefinição de senha: fora de desenvolvimento nenhum token é emitido nem logado (sem provedor de e-mail, B8); o usuário recebe aviso para falar com o suporte. Em dev o link continua no console, marcado "SOMENTE DEV".
        • 0ea4035 — upload: teto de tamanho por parte (lê content-length e recusa parte acima do limite); login: conta bloqueada ou inativa recebe a mesma resposta genérica e a senha é processada mesmo assim (não revela estado da conta pelo tempo de resposta); /api/health público responde só { ok }, detalhes só para admin logado ou com o token interno (comparação em tempo constante); erros internos da fila viram mensagens neutras para o usuário e o detalhe fica só no log do servidor.
        • O mesmo commit 0ea4035 incluiu por engano o PDF DNAPLAY_Ferramentas_Servicos_Assinaturas.pdf na raiz (tratado no bloco seguinte).
      • Bloco 3: banco, fila, contratos TS e aplicação web (Fase 1)

        6 itens
        • packages/db: migrations 0001_init (31 tabelas, planos sem preço), 0002_rls_supabase (RLS + políticas auth.uid() só quando o schema auth existir), 0003_rls_lockdown (RLS em todas as tabelas restantes; sem política permissiva ⇒ só o papel de serviço acessa; leitura de catálogos para autenticados). Cliente único (pg em produção; PGlite em dev, marcado), migrate idempotente, repositórios com filtro obrigatório por user_id, pg-boss sobre adaptador (funciona no PGlite).
        • packages/contracts: tipos TS gerados dos JSON Schemas do Python (fonte única).
        • apps/web (Next.js 16, Cache Components, Tailwind 4): design system com os 7 tokens do kit, Sora/Inter, emblema e logotipo em SVG provisório; cadastro/login/recuperação de senha (Argon2id, sessão em banco, cookie httpOnly, bloqueio após 5 falhas); proxy.ts com verificação otimista; dashboard; histórico; nova análise em 5 passos (referência por link do YouTube via oEmbed público ou arquivo; upload retomável em partes de 8 MB com verificação de tipo real por magic bytes; objetivos; contexto; revisão); página de processamento com etapas reais (polling a cada 3 s); minha conta (perfil, sessões ativas); assinatura (planos sem preço, aviso de cobrança desligada); treinos (vazio honesto); /api/health.
        • Workers no processo do Next (instrumentation.ts): job de ingestão chama o serviço Python, grava video_metadata/video_segments, marca vídeo validated; quando as duas ingestões terminam, enfileira a análise, que para em blocked com motivo B1.
        • Correções durante o teste: connection() antes de ler sessão (erro de pré-renderização do Next 16); PGlite cria o diretório pai; adaptador do pg-boss devolve as linhas de todas as instruções; layout de "Minha conta"; status do vídeo atualizado pelo polling; dados locais movidos para ~/.dnaplay/ (dentro do repositório, cada escrita do PGlite disparava o watcher do Next e a página recarregava em loop).
        • Documento do dono DNAPLAY_Contas_Assinaturas_Custos.pdf (apareceu na pasta durante o bloco) movido para docs/referencias/ e resumido em docs/KNOWN_LIMITATIONS.md; nada nele contradiz a arquitetura (R2 = S3-compatível; Resend; Sentry; pagamento Stripe/MP/Asaas; preços são decisão do dono).
      • Bloco 2: serviço Python de análise (services/analysis)

        8 itens
        • Contratos Pydantic v2 dos 9 estágios (contracts/): IngestionResult, VideoAnalysis, MatchingResult, Diagnosis/VerifiedDiagnosis, RecommendationSet, LessonPlan, RenderedReport, ValidationReport. Validações de integridade: fato observado exige evidência; correspondência abaixo da similaridade mínima é rejeitada; recomendação sem evidência só pode ser hipótese; cena 3D exige dados estruturados; campos desconhecidos são erro.
        • Taxonomia própria de EA FC (taxonomy.py): 37 categorias em 4 grupos, cada uma com definição, exemplo, critério de evidência e se é observável diretamente.
        • Módulo A real (ingestion/): ffprobe (metadados), cortes de cena (select=gt(scene,…)), trechos estáticos (freezedetect), segmentação gameplay/estático/transição, amostragem base 1 fps e densa 8 fps em CPU, orçamento de quadros. Segurança: -protocol_whitelist file, contêiner validado contra lista, -t limita decodificação ao teto, timeouts viram erro de domínio.
        • Provedores: interface VideoAnalysisProvider; GeminiProvider bloqueia antes de qualquer chamada sem GEMINI_API_KEY (e falha explicitamente mesmo com chave: integração pendente de validação com vídeos reais); NullProvider só para testes.
        • Matching contextual puro (matching/context.py): similaridade por zona, posse, adversários, pressão, opções, espaço, fase; cobertura reduz confiança; nunca compara pelo minuto; nunca força par.
        • API FastAPI interna com token (/v1/health, /v1/ingest, /v1/analyze → 503 com código provider_not_configured).
        • Base de conhecimento EA FC 27 com esquema (fonte + data obrigatórios), vazia de propósito.
        • JSON Schemas exportados para packages/contracts/schemas (10 arquivos).
      • Bloco 1: confirmação do ambiente e fundação do repositório

        5 itens
        • Confirmação do ambiente (sem re-auditar o resto):
        • git init -b main em D:\workspace\DNAPLAY.
        • Kit de marca movido de DNAPLAY_Kit_Imagens_Separadas/ para design/brand-kit/ (31 arquivos). Inspeção visual de 01, 02, 03, 22, 23 para vetorização do logo.
        • .gitignore (segredos, node, python, mídia, PGlite) e .env.example documentado.
        • Documentação obrigatória criada: README, PRD, ARCHITECTURE (decisões D1–D10 + riscos), DATABASE, AI_PIPELINE, VIDEO_RENDERING, UX_GUIDELINES, DESIGN_SYSTEM, SECURITY, TESTING, DEPLOYMENT, COST_MODEL, ROADMAP, KNOWN_LIMITATIONS (B1–B7), este log.

      Telas atuais

      Capturas reais do sistema rodando. Toque numa tela para ver em tamanho grande.

      Aguardando o dono

      O que só o dono pode providenciar e o que acontece enquanto não chega.

      Lista atualizada em 23/10/2026.

      ~~B1~~

      ~~Chave do Gemini~~ resolvido em 2026-10-23 (chave em .secrets/gemini.txt, no .env local e no do servidor)

      Para que serve: assiste aos vídeos

      Enquanto não vem: —

      ~~B11~~

      ~~Ativar a cobrança da conta do Google~~ resolvido em 2026-10-23 (cobrança ativada pelo dono; produção com GEMINI_MODEL=gemini-4-argon e GEMINI_MODEL_FAST=gemini-3.8-flash, reservas mantidas)

      Para que serve: modelo principal, fila normal e vídeos fora do treino do Google

      Enquanto não vem: —

      B2

      Projeto Supabase (URL + chaves) e Cloudflare R2; adiados para quando houver volume de clientes (D21/D24 revistas em 2026-10-23)

      Para que serve: banco e armazenamento de vídeos gerenciados na nuvem

      Enquanto não vem: sem bloqueio hoje: a produção usa PostgreSQL e disco no próprio servidor (D30), com backup diário e cópia externa manual

      B3

      Conta Stripe (decidido; Asaas/Mercado Pago como plano B), que exige CNPJ e conta PJ

      Para que serve: cobrar assinaturas

      Enquanto não vem: assinatura só com plano gratuito; interface pronta, cobrança desligada

      B4

      Partidas reais: o Rotcha faz a primeira análise pelo site (link do YouTube de um pro em A, a própria gameplay em B) — etapa E3

      Para que serve: validar se a análise funciona de verdade

      Enquanto não vem: o encanamento está provado (vídeo público + vídeo sintético); a qualidade da análise não está validada e a Fase 2 não é declarada validada antes disso

      B5

      Logotipo original em SVG ou PNG alta com fundo transparente

      Para que serve: interface e vídeo final com a marca exata

      Enquanto não vem: usamos um SVG recriado a partir do kit, marcado como provisório

      B6

      Conta ElevenLabs (narração; decidido)

      Para que serve: narrar a aula

      Enquanto não vem: aula sairá com legendas e sem voz

      B7

      Preços dos planos

      Para que serve: cobrar

      Enquanto não vem: planos sem preço até aprovação

      B8

      Conta Resend (e-mail; decidido)

      Para que serve: enviar link de recuperação de senha e notificações

      Enquanto não vem: em dev o link de redefinição aparece no console do servidor; fora de dev a redefinição fica desligada (nenhum token é gerado) até existir provedor

      ~~B9~~

      ~~Chave da API do Claude~~ resolvido em 2026-10-23

      Para que serve: comparação, diagnóstico, verificação, recomendações

      Enquanto não vem: —

      B10

      DNAPLAY Live (Fase 6): validação com partidas reais (a chave do Gemini já existe)

      Para que serve: coach durante a partida

      Enquanto não vem: só a página e as preferências existem. Limites conhecidos: o jogador precisa de captura (PC, placa de captura ou transmissão "não listada" no YouTube); atraso de 10–30 s entre o lance e a dica; custo por minuto ainda não medido; API Live do Gemini ainda não validada; a voz provisória do navegador muda de um aparelho para outro

      Próximos passos

      O último registro (24/10/2026) não traz próximo passo.

      Histórico de alterações

      1. 40e29d224/10/2026docs(auditoria): resposta à auditoria externa nº 1, bloco 16 do log e prints da produção
      2. 1f41b0623/10/2026fix(web): tempo da etapa em andamento sem erro de hidratação; restauração cria volumes pelo Compose
      3. fea1e3d23/10/2026docs(auditoria): A-17 documentação separa 'implantado hoje' da arquitetura-alvo
      4. 693fe7f23/10/2026fix(auditoria): Q-02 estados do resultado inequívocos e motivo quando não há pares
      5. 2cfb07c23/10/2026fix(auditoria): A-13/A-15 cópia externa cifrada puxada pelo notebook e restauração completa
      6. 45a75ed23/10/2026fix(auditoria): A-03/A-04 orçamento de IA como reserva atômica e tentativas no custo
      7. 85af77f23/10/2026fix(auditoria): A-11 limites aplicados de forma atômica (revisão de segurança)
      8. a3c440223/10/2026fix(auditoria): A-11 limites de abuso no site e no serviço de análise
      9. ba6d14923/10/2026fix(auditoria): A-10 recusa do vídeo sem detalhe técnico na mensagem ao usuário
      10. 900ce6e23/10/2026fix(auditoria): A-16 recuperação da fila é pré-condição dos workers
      11. ce732c023/10/2026fix(auditoria): A-10 vídeo conferido (ffprobe e limites) na conclusão do upload
      12. 324b36523/10/2026fix(auditoria): A-07 conclusão do upload idempotente e sem corrida
      13. 1441cd223/10/2026fix(auditoria): A-06 erro transitório volta para a fila do pg-boss
      14. a1785a923/10/2026fix(auditoria): A-05 etapa pega de forma atômica e chave estável na fila
      15. 1237fb223/10/2026fix(auditoria): A-01 aplicação conecta como dnaplay_app (sem superusuário, BYPASSRLS explícito)
      16. 13a34f523/10/2026chore(producao): API da Hostinger descartada; reinício só pelo painel e vigia externo só avisa
      17. 546990523/10/2026docs: bloco 14 do log (blindagem do sistema aplicada, sudo do deploy, Gemini pago)
      18. 322c80723/10/2026feat(producao): blindagem do sistema aplicada, sudo do deploy e Gemini pago (gemini-4-argon + gemini-3.8-flash)
      19. 28c20ee23/10/2026docs: verificação do bloco 13 (deploy por imagens, retomada após queda, aguardando a vez) e prints
      20. 71275db23/10/2026docs: incidente das quedas de 23/10, proteções contra queda, entrega por imagens e bloco 13 do log
      21. 46d301223/10/2026fix(producao): retomada imediata após queda, upload que continua de onde parou, imagens prontas no ghcr.io e limites por contêiner
      22. f5d1e5d23/10/2026docs: log da segunda queda do servidor (16:00–17:47) e retomada automática da análise
      23. 2a84d9223/10/2026docs: bloco 12 do log (Fase 2: encanamento real em produção, guarda de orçamento testada, incidentes) e prints
      24. 5e9285b23/10/2026docs: Fase 2 — D37 (modelos), pipeline com IA real, preços e guarda de orçamento, B1/B9 resolvidos, B11, E3
      25. a5bdf4523/10/2026chore(deploy): modelos, chaves e orçamento de IA na produção (valores só no .env do servidor)
      26. 1ef718623/10/2026feat(web): pipeline de ponta a ponta com a IA real e página de resultado
      27. cb9850b23/10/2026feat(db): migration 0006 (aditiva), custo por estágio, gasto do dia e resultados da análise
      28. 43eabf823/10/2026test(analysis): respostas reais gravadas e anonimizadas, guarda de orçamento e regras de evidência
      29. 8f768a623/10/2026feat(analysis): Gemini e Claude reais nos estágios 1–6, custo por chamada e guarda de orçamento
      30. bb45e9d23/10/2026docs: print da seção Documentos com as ferramentas v2