Etapas para aprovação

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

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

   bloqueada: sem chave multimodal e sem vídeos reais

   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

Feito até agora

1. 22/10/2026

   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).
2. 22/10/2026

   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.
3. 22/10/2026

   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.
4. 21/10/2026

   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).
5. 21/10/2026

   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).
6. 21/10/2026

   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).
7. 21/10/2026

   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 22/10/2026.

Próximos passos

• Quando o arquivo aparecer: itens 1, 3, 6 e 7 do PROMPT_DEMO_ONLINE.md (preparar o servidor, gerar .env, publicar, testar ponta a ponta no endereço público, apontar a etapa E1 para a demo).
• Wellington aprova (ou pede ajustes) a etapa E1.
• Dono cria as contas da prova técnica: Google AI Studio (B1), Anthropic Console (B9), Supabase (B2); e envia 2 vídeos reais (B4).

Histórico de alterações

1. 918fa0a22/10/2026docs(log): bloco 7 — demonstração pronta para publicar, aguardando o VPS
2. d0a6f9f22/10/2026ci(demo): checagem correta de que o serviço de análise não publica porta
3. cef548022/10/2026ci(security): deploy da demo só após CI de push na main deste repositório e commit que pertence à main
4. 7e4f24b22/10/2026docs(demo): ambiente de demonstração na doc e na página de acompanhamento
5. 8bf8f3522/10/2026ci(demo): validar imagens e Compose no CI; deploy por SSH após CI verde; publicação manual
6. e2a4ccf22/10/2026feat(deploy): ambiente demo em Docker Compose (postgres, analysis, web, caddy) e scripts do servidor
7. 4af17c122/10/2026feat(web): build standalone, faixa 'Ambiente de demonstração' e redirecionamentos com o endereço público atrás do proxy
8. d406c5622/10/2026chore: ignorar .secrets/ e versionar prompts da demonstração
9. 51b4ff522/10/2026ci(security): fixar ações de terceiros por commit (wrangler-action recebe o token da Cloudflare)
10. 70c9b9f22/10/2026docs(log): bloco 6 — CI, arquivo fora do repositório e decisões do dono
11. 7c7769022/10/2026docs: decisões de ferramentas e serviços do dono (D14–D29), variáveis previstas e bloqueio B9
12. 974391922/10/2026ci: FFmpeg por binário pronto e limite de 20 min por job
13. 54119bc22/10/2026test(analysis): não exigir FFmpeg 8 exato (CI Linux usa a versão do apt)
14. 370256f22/10/2026fix(web): versionar apps/web/src/server/storage (estava ignorado por regra 'storage/' solta no .gitignore)
15. 249926922/10/2026docs: acompanhamento no ar, deploy, log dos blocos 4 e 5
16. 7009c7c22/10/2026ci: typecheck, build e testes (Node 24) + pytest, ruff e mypy (Python 3.12 + FFmpeg) em Linux
17. 346ae8e22/10/2026ci(acompanhamento): publicar no Cloudflare Pages a cada push na main
18. 6ebbcc122/10/2026feat(acompanhamento): gerador da página estática de acompanhamento e etapas para aprovação
19. 0ea403521/10/2026fix(security): teto de tamanho por parte no upload, login sem revelar bloqueio, /api/health público só com ok, erros internos não chegam ao usuário
20. 688455c21/10/2026fix(auth): não emitir nem logar token de redefinição fora de desenvolvimento (sem provedor de e-mail)
21. 34322da21/10/2026feat(web): aplicação Next.js da Fase 1 — auth, nova análise, upload retomável, fila e ingestão ponta a ponta
22. 0786b8f21/10/2026feat(db,contracts): banco (migrations, PGlite dev, repositórios), fila pg-boss e tipos TS dos contratos
23. 3c0037921/10/2026fix(analysis): endurecer entrada do ffmpeg (protocolo/contêiner permitidos, teto de decodificação, timeouts)
24. 3fa50b021/10/2026chore: ignorar egg-info
25. e57d9a221/10/2026feat(analysis): serviço Python com contratos, taxonomia EA FC, ingestão FFmpeg e matching contextual
26. 5c34a3921/10/2026chore: fundação do repositório, documentação base e kit de marca