# Correção: valor já coletado pode ser corrigido durante COLLECTING_PARAMETERS

## Problema

Uma transação podia estar em `COLLECTING_PARAMETERS` com um campo obrigatório já preenchido em turno anterior (por exemplo `valor=19.99`) e outro ainda pendente (`subject`). Se o cliente corrigisse o valor no mesmo turno em que identificava o item — por exemplo `desculpa, é a de quatorze e noventa e nove` — o runtime enviava ao extrator LLM apenas os parâmetros ainda ausentes. Assim, `valor` ficava fora do contrato editável do turno e permanecia congelado em `19.99`.

Isso gerava estados inconsistentes como `resolved_value=14.99` e `valor=19.99`, fazendo a contestação executar com o valor antigo.

## Regra corrigida

Enquanto a transação estiver em `COLLECTING_PARAMETERS`, o extrator transacional recebe o conjunto completo de `policy.requires` como campos editáveis do turno. A LLM continua autorizada a devolver somente valores realmente presentes/inequívocos na fala atual. O merge mantém os valores antigos para campos não citados e sobrescreve apenas as chaves efetivamente extraídas.

Precedência resultante:

1. fala atual explicitamente corrige/preenche required field;
2. valor previamente coletado é preservado apenas se a fala atual não o alterar;
3. parâmetros ainda ausentes continuam sendo coletados;
4. somente depois disso é avaliada mudança de intenção.

## Caso de regressão coberto

Estado anterior:

- `valor=19.99`
- `subject` pendente

Mensagem atual:

- `desculpa, é a de quatorze e noventa e nove`

Router/contexto resolve:

- `subject=Tamboro Mensal`

Extrator do runtime corrige:

- `valor=14.99`

Resultado esperado antes da confirmação:

- `subject=Tamboro Mensal`
- `valor=14.99`

## Testes

Foram executados:

- 46 testes de runtime/roteamento/parâmetros transacionais;
- 27 testes de migração ligados a contestação/CVAL/paridade.

Todos passaram.
