# Execução — `PP-3` Contagem de tempo restante por jogo

**Plano:** `PP-3-plano.md` · **Data:** 07/08/2026
**Ambiente:** backend local (`test/palpite.e2e-spec.ts`), Flutter em teste de
unidade e widget (`test/prazo_test.dart`, `test/prazo_na_rodada_test.dart`,
`test/pp5_plano_test.dart`) e **verificação em device** (emulador `bolao`, relógio
do aparelho alterado).

**Resultado: 11/11 ✅** — nenhum defeito. O caso que a story pedia em `QA-2`
(relógio do aparelho alterado) foi executado **em device de verdade**, nos dois
sentidos.

| ID | Resultado | Onde |
| -- | --------- | ---- |
| PP-3-01 | ✅ | e2e "a resposta traz o horário do servidor" |
| PP-3-02 | ✅ | e2e "rodada futura vem com prazo aberto; rodada passada, fechado" |
| PP-3-03 | ✅ **device** | relógio +3 h → contagem inalterada |
| PP-3-04 | ✅ **device** | relógio −3 h → contagem inalterada |
| PP-3-05 | ✅ | unidade "sem desvio, servidor e device coincidem" |
| PP-3-06 | ✅ | widget "jogo já iniciado aparece fechado, com campo desabilitado" |
| PP-3-07 | ✅ | unidade "formata dias, horas e minutos" |
| PP-3-08 | ✅ | unidade "menos de um minuto tem texto próprio" |
| PP-3-09 | ✅ | widget "PP-5-10 a contagem virando fecha o cartão sem recarregar" |
| PP-3-10 | ✅ | widget "mostra o horário local do jogo, não só a contagem" |
| PP-3-11 | ✅ **device** | ver abaixo |

## `PP-3-11` — verificação em device, com o relógio adulterado

Cenário: bolão na rodada 30, primeiro jogo em `02/10 21:00Z`. Horário do servidor
no momento do teste: `11:48Z`. Faltavam, de verdade, **56d 9h**.

| Relógio do aparelho | O que a tela mostrou | O que mostraria se usasse o device |
| ------------------- | -------------------- | --------------------------------- |
| +3 h (11:47 local, real 08:47) | `fecha em 56d 9h` | `fecha em 56d 6h` |
| −3 h (05:52 local, real 08:52) | `fecha em 56d 9h` | `fecha em 56d 12h` |

Nos dois sentidos a contagem ficou **idêntica** — o app aplica o desvio entre o
`serverTime` da resposta e o relógio local. E o horário do jogo continuou exibido
no fuso do aparelho com o fuso escrito (`02/10 às 18:00 UTC-03`), que é a outra
metade do problema: a hora **é** local, o prazo **não**.

Por que isso vale a verificação manual: o teste de unidade **injeta** o desvio, o
device o **produz**. Se o cálculo do offset estivesse invertido ou zerado, o teste
de unidade continuaria passando com um offset fabricado — e quem tem o celular
adiantado perderia a rodada sem entender por quê, que é o defeito com maior
potencial de acusação de trapaça no produto inteiro.

**Limite conhecido:** o desvio é medido **na carga da tela**. Mudar o relógio com
a tela aberta desloca a contagem até a próxima recarga. Não corrigi: é cenário
exótico (ninguém mexe no relógio durante um palpite), o servidor continua sendo
quem decide aceitar ou recusar, e recalcular offset a cada tick custaria uma
chamada de rede por segundo. Fica registrado como escolha, não como esquecimento.

## Observações

- O relógio do emulador foi restaurado (`auto_time 1`) e os dados de teste foram
  removidos do banco no fim da execução.
