# Plano de testes — `CC-2` Definir tabela de pontos e desempate na criação

**Story:** `docs/stories/CC-2-definir-regras-na-criacao.md`

O risco escondido está escrito na própria story: se o cálculo usar constantes
fixas, a configuração por bolão é **decorativa**. Foi exatamente o que aconteceu
com `tiebreakOrder` (achado em `PR-5`). Por isso o eixo principal aqui é
"configurou → o cálculo obedeceu", não "salvou sem erro".

| ID | Título | Tipo | Prioridade |
| -- | ------ | ---- | ---------- |
| CC-2-01 | Etapa de regras recolhida, com o padrão do PRD | UI | alta |
| CC-2-02 | Aviso de travamento legível, sem markdown cru | UI | média |
| CC-2-03 | Criar sem mexer nas regras usa o padrão | caminho feliz | alta |
| CC-2-04 | Tabela inconsistente é barrada antes da API | validação | alta |
| CC-2-05 | Criação aceita tabela diferente do padrão | caminho feliz | alta |
| CC-2-06 | O cálculo lê a tabela do bolão | regra de negócio | alta |
| CC-2-07 | O desempate lê a ordem do bolão | regra de negócio | alta |
| CC-2-08 | Admin altera as regras antes do primeiro palpite | caminho feliz | alta |
| CC-2-09 | Depois do primeiro palpite, alteração é recusada | regra de negócio | alta |
| CC-2-10 | Participante comum não altera as regras | autorização | alta |
| CC-2-11 | Valores inválidos e critério desconhecido são recusados | validação | alta |

---

### CC-2-01 — Etapa de regras recolhida, com o padrão do PRD
**Tipo:** UI · **Prioridade:** alta
**Resultado esperado:** a criação mostra a pontuação padrão em texto e a
configuração fica **atrás de um toque**. Obrigar o admin casual a configurar
pontos é o que faz ele desistir e voltar para a planilha.

### CC-2-02 — Aviso de travamento legível, sem markdown cru
**Tipo:** UI · **Prioridade:** média
**Resultado esperado:** "As regras travam no primeiro palpite" em negrito de
verdade, sem `**` na tela. Asterisco visível no aviso mais importante da tela faz
o app parecer quebrado justamente onde ele precisa ser levado a sério.

### CC-2-03 — Criar sem mexer nas regras usa o padrão
**Tipo:** caminho feliz · **Prioridade:** alta
**Resultado esperado:** o bolão nasce 10/5/3 com a ordem padrão de desempate.

### CC-2-04 — Tabela inconsistente é barrada antes da API
**Tipo:** validação · **Prioridade:** alta
**Passos:** exato = 2, vencedor-e-saldo = 5.
**Resultado esperado:** recusado no app, sem chamar o servidor — que aceita cada
campo isoladamente (0 a 100). Bolão em que acertar mais vale menos só apareceria
na apuração, quando a regra já está travada.

### CC-2-05 — Criação aceita tabela diferente do padrão
**Tipo:** caminho feliz · **Prioridade:** alta
**Resultado esperado:** os valores enviados ficam persistidos no bolão.

### CC-2-06 — O cálculo lê a tabela do bolão
**Tipo:** regra de negócio · **Prioridade:** alta
**Passos:** bolão com 20/10/5; apurar um placar exato.
**Resultado esperado:** 20 pontos, não 10. É o `BE-3`: sem isso a configuração é
decorativa.

### CC-2-07 — O desempate lê a ordem do bolão
**Tipo:** regra de negócio · **Prioridade:** alta
**Resultado esperado:** com `WINNERS` primeiro, o ranking classifica **e
explica** por acertos de vencedor. Defeito real encontrado em `PR-5`:
`tiebreakOrder` era persistido, editável, herdado na recriação… e nunca lido.

### CC-2-08 — Admin altera as regras antes do primeiro palpite
**Tipo:** caminho feliz · **Prioridade:** alta
**Resultado esperado:** alteração aceita e visível a todos.

### CC-2-09 — Depois do primeiro palpite, alteração é recusada
**Tipo:** regra de negócio · **Prioridade:** alta
**Resultado esperado:** 409 apontando o caminho de saída (encerrar e abrir
outro). Mudar a pontuação com palpite registrado é reescrever o passado.

### CC-2-10 — Participante comum não altera as regras
**Tipo:** autorização · **Prioridade:** alta
**Resultado esperado:** 403, mesmo com a UI escondendo a ação.

### CC-2-11 — Valores inválidos e critério desconhecido são recusados
**Tipo:** validação · **Prioridade:** alta
**Resultado esperado:** 400 para ponto negativo, acima do teto e para critério de
desempate que não existe.
