# Bolão

App de bolão de futebol: os amigos palpitam os placares da rodada, o sistema
apura contra o resultado oficial e mantém o ranking — sem planilha e sem alguém
tendo que anotar tudo à mão.

Três partes, um repositório:

| Pasta | O que é | Como rodar |
| ----- | ------- | ---------- |
| [`bolao-backend/`](bolao-backend) | API NestJS 11 + Prisma 7 + PostgreSQL | [README](bolao-backend/README.md) |
| [`bolao-mobile/`](bolao-mobile) | App Flutter (Android e iOS) | [README](bolao-mobile/README.md) |
| [`docs/`](docs) | PRDs, stories, planos de teste e controle de execução | [CONTROLE.md](docs/CONTROLE.md) |

## As regras que não se negocia

Estas não são preferências de implementação — quebrar qualquer uma corrompe a
competição, e por isso cada uma tem teste travando:

- **O prazo é o relógio do servidor.** O palpite fecha no apito inicial de cada
  jogo, decidido pelo servidor. Adiantar o relógio do celular não muda nada.
- **Palpite alheio é segredo até o jogo terminar** — para todos, inclusive o
  administrador. Libera no fim, não no apito.
- **Empate não tem faixa de saldo.** Todo empate tem saldo zero, então acertar
  "foi empate" com o placar errado vale a faixa mais baixa. Palpitar `1x1` num
  jogo que termina `4x4` dá 3 pontos, não 5.
- **O campeão é derivado na leitura, nunca congelado.** Correção de placar depois
  do encerramento muda a pontuação e pode trocar o campeão. Parece bug e é o
  contrário: é o que permite consertar um placar errado sem apagar o histórico.
- **Sair do bolão é definitivo**, e quem criou é administrador permanente — não
  sai, não é rebaixado, não é removido.
- **Todo jogo não realizado é adiado.** Não existe cancelado nem W.O.

## Estado

**35 de 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.

As 6 tasks abertas não dependem de código: 5 esperam credencial do FCM (lembrete
de prazo por push) e 1 espera hospedagem que não hiberne o processo de
sincronização. `docs/CONTROLE.md` é a fonte única de progresso, e
`docs/validar.sh` verifica que ele bate com as stories.

## Como o projeto foi construído

Cada mudança nasce de uma story com critérios de aceite, tem plano de casos de
teste escrito **a partir da story** (não do código) e execução registrada em
`docs/testes/`. Mudança de tela só fecha depois de rodar em device — e boa parte
dos defeitos encontrados aqui só apareceu assim, não no teste automatizado.

Os defeitos achados e o que cada um ensinou estão nos arquivos de execução; vale
ler `docs/testes/README.md` para navegar.
