bolao-firebase/ com firebase-tools 15.26.0 pinado como devDependency — global
não é reprodutível para quem clona. Firestore, Auth e Functions em emulador,
portas fixas, e 4 testes de security rule provando que as rules começam
fechadas.

Duas travas de propósito
- Projeto `demo-bolao`: o Firebase trata prefixo `demo-` como demonstração e o
  SDK nunca fala com serviço real. Apontar para projeto de verdade exige
  PERMITIR_PROJETO_REAL=true.
- Rules `if false` na largada. Participação entra em MG-2, sigilo e prazo em
  MG-3. Abrir primeiro e fechar depois é como vazamento chega em produção.

Dois defeitos encontrados no próprio script, os dois no caminho de erro
- `command -v java` mente no macOS: existe um stub em /usr/bin/java que satisfaz
  a checagem e falha ao executar. O teste passou a ser rodar `java -version` —
  presença de binário não é funcionamento.
- Sem JDK algum, o script morria com "unbound variable" (array vazio sob set -u)
  em vez de mostrar a instrução. Foi para poder testar esse caminho que a lista
  de candidatos virou JDK_CANDIDATOS sobrescrevível.

Confirmado: nada aqui exigiu plano Blaze. O cartão só entra no deploy.

MG-1 fechada, 8/8 tasks, plano e execução em docs/testes/MG-1-*.md.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Decisão do dono em 07/08: Firestore + Cloud Functions, migrando antes de
desligar — as duas implementações coexistem até os 234 casos e2e passarem na
nova.

Spike de arquitetura (docs/spikes/backend-firebase.md)
- Dimensiona o que sai: 38 rotas, 17 services, 12 tabelas, 3 jobs, 5.139 linhas.
  O caro não é o código, são os 234 e2e que provam que prazo, sigilo e apuração
  valem.
- Resolve o problema central: security rules não filtram resultado de query,
  então o sigilo do palpite passa a ser flag desnormalizada virada por Function
  no fim do jogo. O risco muda de "a consulta vaza" para "a Function não rodou".
- Descoberta que muda o sequenciamento: o Emulator Suite roda local sem cartão,
  então MG-1 a MG-8 não dependem de decisão financeira. Blaze só para publicar.
- Mapa das 12 tabelas para coleções, com o ranking materializado — somar pontos
  na leitura estouraria o free tier.

PRD e 9 stories (73 tasks), na ordem do risco e não da facilidade: emuladores,
modelo e rules, sigilo e prazo, Auth com recuperação de senha, apuração,
jobs no Scheduler, app, paridade verificada, e só então o corte do NestJS.

Efeitos colaterais registrados: MG-4 faz AC-4 voltar do cancelamento (o Auth dá
recuperação de senha de graça) e MG-6 fecha PP-10 OPS-1 e as 4 tasks de PP-8
presas ao FCM.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

O arquivo era o template do GitLab explicando como subir arquivos. Trocado por
uma porta de entrada real: as três partes do monorepo, as seis regras de domínio
que quebram a competição se forem violadas (prazo pelo servidor, sigilo até o fim
do jogo, empate sem faixa de saldo, campeão nunca congelado, saída definitiva,
tudo adiado) e onde ler o processo.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Produto completo de bolão de futebol, construído do PRD ao device: 35 das 38
stories fechadas, 312 de 318 tasks, três PRDs concluídos (Identificação e
acesso, Criação e convite, Ciclo de vida do bolão).

Backend (NestJS 11 + Prisma 7 + Postgres)
- Palpite com prazo decidido pelo relógio do servidor, sigilo até o fim do jogo,
  apuração 10/5/3 lida da configuração do bolão, ranking com desempate por
  critério configurável, extrato explicando cada ponto.
- Ciclo de vida: encerramento normal e antecipado, campeão derivado na leitura
  (nunca congelado), arquivamento reversível, recriação de temporada herdando
  regras e galera.
- Fonte oficial de calendário e placar via porta `FonteDeDados`: adaptador falso
  para desenvolvimento e `FootballDataAdapter` (football-data.org v4) para
  produção. O limite de 10 req/min desenhou o adaptador — uma requisição por
  temporada, cache de 5 min, cota recusada antes de ser gas...