# Plano de testes — `PP-2` Editar palpite enquanto o prazo estiver aberto

**Story:** `docs/stories/PP-2-editar-palpite.md`

Editar é onde a disputa nasce: "eu tinha mudado", "salvou o antigo". Por isso as
duas garantias que importam são **qual versão valeu** e **o que a tela mostra
depois de uma recusa** — mostrar na tela um valor que o servidor não aceitou é o
jeito mais rápido de perder a confiança do participante.

| ID | Título | Tipo | Prioridade |
| -- | ------ | ---- | ---------- |
| PP-2-01 | Novo palpite substitui o anterior | caminho feliz | alta |
| PP-2-02 | Substituição mantém um registro só | regra de negócio | alta |
| PP-2-03 | Cada mudança de valor guarda revisão | regra de negócio | alta |
| PP-2-04 | Reenviar o mesmo valor não cria revisão | borda | alta |
| PP-2-05 | Vale a última versão antes do fechamento | regra de negócio | alta |
| PP-2-06 | Prazo fechando entre abrir e enviar | borda | alta |
| PP-2-07 | A tela mostra o palpite que valeu, não o digitado | UI | alta |
| PP-2-08 | Não há como editar palpite de outro | autorização | alta |
| PP-2-09 | Tela vem pré-preenchida com o palpite atual | UI | alta |

---

### PP-2-01 — Novo palpite substitui o anterior
**Tipo:** caminho feliz · **Prioridade:** alta
**Resultado esperado:** valor novo na leitura, com confirmação.

### PP-2-02 — Substituição mantém um registro só
**Tipo:** regra de negócio · **Prioridade:** alta
**Resultado esperado:** um `Prediction` por participante e jogo. Dois registros
tornariam ambíguo qual vale — exatamente a dúvida que o produto existe para
eliminar.

### PP-2-03 — Cada mudança de valor guarda revisão
**Tipo:** regra de negócio · **Prioridade:** alta
**Resultado esperado:** histórico com o valor anterior. É a auditoria de disputa
que a story pede em `BE-2`.

### PP-2-04 — Reenviar o mesmo valor não cria revisão
**Tipo:** borda · **Prioridade:** alta
**Resultado esperado:** nenhuma revisão nova. A fila offline de `PP-4` reenvia o
mesmo lote; sem isso o histórico enche de linhas idênticas e deixa de servir
para resolver disputa. Defeito real corrigido em 06/08.

### PP-2-05 — Vale a última versão antes do fechamento
**Tipo:** regra de negócio · **Prioridade:** alta
**Resultado esperado:** a apuração usa a última versão aceita antes do apito.

### PP-2-06 — Prazo fechando entre abrir e enviar
**Tipo:** borda · **Prioridade:** alta
**Resultado esperado:** recusa pelo relógio do servidor, com motivo de prazo.

### PP-2-07 — A tela mostra o palpite que valeu, não o digitado
**Tipo:** UI · **Prioridade:** alta
**Resultado esperado:** depois da recusa, o campo volta ao valor que está
gravado. Defeito real corrigido: o valor recusado ficava na tela, e o
participante ia embora acreditando que aquele era o palpite dele.

### PP-2-08 — Não há como editar palpite de outro
**Tipo:** autorização · **Prioridade:** alta
**Resultado esperado:** o endpoint só grava para o dono do token, e campo extra
no corpo (`userId`) é **recusado**, não ignorado. Ignorar em silêncio é o que faz
uma falha de autorização parecer funcionalidade.

### PP-2-09 — Tela vem pré-preenchida com o palpite atual
**Tipo:** UI · **Prioridade:** alta
**Resultado esperado:** editar é mudar um número, não digitar tudo de novo.
