T-079 - Implementar POST /jobs/id/reprocessar

[eduardo-Rib]

Resumo

Implementa a T-079, adicionando o endpoint POST /jobs/{id}/reprocessar para criar um novo job a partir de um job arquivado.

O reprocessamento preserva o job original e sua trilha, cria uma nova versão independente da regra e direciona o novo job para a etapa de confirmação de parâmetros.

Implementação

• adiciona POST /jobs/{id}/reprocessar;
• aceita somente jobs em estado arquivado;
• cria um novo job em aguardando_confirmacao_parametros;
• mantém o job original inalterado;
• copia o usuario_id do job de origem;
• relaciona os jobs através de job_origem_id;
• seleciona a versão mais recente da regra do job arquivado;
• cria uma nova regra com:
  • versao = 1;
  • origem = reprocessamento;
  • regra_origem_id apontando para a versão original;
• preserva integralmente nucleo, especificacoes e hash;
• mantém especificações extensíveis sem perda de campos desconhecidos;
• herda competências e orçamento quando não informados;
• permite substituir competências e orçamento no reprocessamento;
• registra a criação pela máquina de estados;
• publica regra-submetida pelo outbox com origem reprocessamento.

Representação da regra

As especificações da regra passaram a ser tratadas de forma extensível, preservando integralmente estruturas JSON existentes.

Isso garante a representação completa em todo o fluxo:

job arquivado
→ POST /jobs/{id}/reprocessar
→ GET /jobs/{id}
→ confirmação de parâmetros
→ nova versão da regra

Ao confirmar alterações no núcleo, orçamento ou competências, as especificações já existentes continuam preservadas.

A versão semeada permanece imutável e novas alterações geram uma nova versão ligada através de regra_origem_id.

Consulta e confirmação

GET /jobs/{id} e POST /jobs/{id}/parameters foram ajustados para suportar jobs originados de reprocessamento.

Para esses jobs:

• origem = reprocessamento;
• job_origem_id identifica o job arquivado;
• submissao_id não é retornado;
• a representação completa da regra permanece disponível;
• a confirmação continua seguindo o fluxo normal de versionamento.

Evento

O novo job publica regra-submetida na mesma transação da criação do job, regra e transição inicial.

Exemplo:

{
  "job_id": "<novo_job_id>",
  "origem": "reprocessamento",
  "competencias": ["2025-07", "2025-09", "2025-12"],
  "regra_id": "<nova_regra_id>"
}

[pedro-fs-garcia]

• No fluxo de reprocessamento, a confirmação ainda não permite
editar a representação completa. Quando o job arquivado tem
especificacoes não vazias, enviar a regra retornada por GET /
jobs/{id} para POST /jobs/{id}/parameters resulta em 400
(ConfirmarParametrosRequisicao.validarEspecificacoes). Enviar
especificacoes: [] permite confirmar, mas o serviço reutiliza as
especificações anteriores, ignorando qualquer edição. Ajustar a
confirmação para aceitar a representação completa e gravar uma
nova versão quando as especificações mudarem, preservando a
versão semeada e a do job original.