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

**Plano:** `CC-2-plano.md` · **Data:** 07/08/2026
**Ambiente:** backend local (`test/regras.e2e-spec.ts`,
`test/cc2-tabela-customizada.e2e-spec.ts` — criada nesta execução,
`src/scoring/pr-1-plano.spec.ts`), Flutter em teste de widget
(`test/criar_bolao_test.dart`, `test/regras_edicao_test.dart`).

**Resultado: 11/11 ✅** — 1 defeito de UI corrigido, e o risco escondido da story
finalmente **verificado de ponta a ponta**.

| ID | Resultado | Onde |
| -- | --------- | ---- |
| CC-2-01 | ✅ **novo** | widget "CC-2-01 a etapa de regras vem recolhida" |
| CC-2-02 | ✅ **corrigido** | widget "CC-2-02 o aviso de travamento não mostra asterisco" |
| CC-2-03 | ✅ **novo** | widget "CC-2-03 criar sem mexer nas regras manda o padrão" |
| CC-2-04 | ✅ **novo** | widget "CC-2-04 tabela inconsistente é barrada antes da API" |
| CC-2-05 | ✅ | e2e "criação aceita regras diferentes do padrão" |
| CC-2-06 | ✅ **novo** | e2e "CC-2-06 o cálculo usa a tabela do bolão, não 10/5/3" + "CC-2-06b" |
| CC-2-07 | ✅ **novo** | e2e "CC-2-07 com empate em pontos, a ordem do bolão decide e é explicada" |
| CC-2-08 | ✅ | e2e "admin altera as regras enquanto não há palpite" |
| CC-2-09 | ✅ | e2e "regras travadas recusam alteração, apontando o caminho" |
| CC-2-10 | ✅ | e2e "participante comum não altera as regras" |
| CC-2-11 | ✅ | e2e "recusa valores inválidos e critério de desempate desconhecido" |

## `BE-3` verificado — a configuração não é decorativa

O risco estava escrito na story desde o começo: *"se PR-1 e PR-5 usarem valores
fixos no código, a configuração por bolão é decorativa"*. Metade dele já tinha
cobrado seu preço em `PR-5` (`tiebreakOrder` era persistido, editável, herdado na
recriação — e nunca lido).

A suíte nova monta um bolão **20/10/5 com `WINNERS` na frente** e verifica o
caminho inteiro: criação → palpite → apuração → ranking → extrato.

- Pontos: 35 e 30. Com 10/5/3 seriam 18 e 15 — o teste distingue os dois.
- Extrato: 20 no placar exato, 10 no vencedor-e-saldo, 5 no só-vencedor. Se o
  extrato explicasse o ponto com um número diferente do ranking, ele deixaria de
  servir como árbitro.
- Desempate: caso **discriminante**, montado para dar campeão diferente conforme
  a ordem — empate em 20 pontos, Ana com 4 acertos de vencedor e 0 exatos, Bruno
  com 1 exato e 1 acerto. Ordem do bolão (`WINNERS`) → Ana; ordem padrão
  (`EXACT_SCORES`) → Bruno. Um teste que só usasse a ordem padrão passaria mesmo
  com o defeito de volta.

## Defeito corrigido — markdown cru na tela

Três textos usavam `**assim**` dentro de um `Text`, que **não interpreta
markdown**: os asteriscos apareciam literalmente na tela. E não em lugar
qualquer — nos avisos que mais precisam ser levados a sério:

- criação: "**As regras travam no primeiro palpite**";
- tela de regras: "**travam no primeiro palpite**";
- diálogo de saída: "A saída é **definitiva**".

Corrigido com `Text.rich` e negrito de verdade nos dois primeiros; no terceiro,
o corpo do diálogo é `String`, então a frase foi reescrita sem asterisco. O caso
`CC-2-02` agora falha se `**` reaparecer em qualquer texto da tela de criação.

## Observações

- A etapa de regras **recolhida** é decisão de produto, não economia de tela:
  obrigar o admin casual a configurar pontos é o que o faz voltar para a
  planilha. O teste garante que o padrão fica dito em texto mesmo recolhido.
- **O app manda 10/5/3 explicitamente** mesmo quando o admin não abre a etapa de
  regras, enquanto o comentário do repositório fala em omitir o que não foi
  mexido. Sem efeito hoje (os valores são iguais ao default do servidor), mas
  registrado: se o default do servidor mudar, bolão novo criado pelo app não
  acompanha.
