T-067 - Gravar o resultado e publicar na exchange fanout

[pedro-fs-garcia]

T-067 - Gravar o resultado e publicar na exchange fanout

• Componente: worker

• Estimativa: 3

• Depende de: T-021, T-066

• Data máxima: 2026-09-25 (sex)

Descrição

Gravar o resultado decomposto na tabela do worker e publicar simulacao-concluida na exchange fanout, com job_id, referência, status, veredito, totais e desfecho das asserções.

O ponto em que o resultado entra no sistema. O worker grava a linha no Postgres e publica simulacao-concluida numa exchange fanout, para que api e codegen consumam de forma independente, cada um pela sua fila.

Se o evento se perder, o resultado não se perde junto: a linha é consultável e reconciliável depois.

Escopo

Dentro do escopo

• INSERT do resultado decomposto na tabela do worker.
• Publicação de simulacao-concluida na exchange fanout, com job_id, referência da linha, status, veredito, totais e desfecho das asserções.
• Ordem garantida: gravar antes de publicar.
• Testes com um consumidor desligado e com os dois ligados.

Fora do escopo

• Consumo pela api (T-045) e pelo codegen (T-049).
• Cálculo do veredito (T-066).
• Limpeza do container (T-068).
• Reconciliação de resultado órfão, que é operação, não código desta sprint.

Requisitos

• O worker tem apenas INSERT nessa tabela; nenhuma outra operação, em nenhuma outra tabela.
• Grava antes de publicar: um evento que referencia linha inexistente é pior do que um evento perdido.
• A exchange é fanout, com uma fila por consumidor: derrubar um consumidor não impede o outro de receber.
• O evento carrega os totais e o veredito além da referência, para que os consumidores não precisem ler o banco só para reagir.

Contexto técnico

• Entradas: resultado com veredito (T-066); usuário de banco do worker (T-021); schema do evento (T-003).
• Saídas: linha de resultado gravada; evento publicado na fanout.
• Componentes afetados: worker/; RabbitMQ; tabela de resultado.
• Restrições: claim-check - o conteúdo fica no banco, o evento leva a referência mais os poucos agregados previstos na §6.3.
• Referências: ARCHITECTURE.md §3.4 (publicação do resultado), §6.1 e §6.3; ADR-001.

Critérios de aceitação

• O resultado decomposto é gravado na tabela do worker antes de o evento ser publicado.
• O evento valida contra contracts/events/simulacao-concluida.schema.json.
• api e codegen recebem o mesmo evento, cada um pela sua fila.
• Com o consumidor da api desligado, o codegen continua recebendo - e vice-versa.
• Uma tentativa de UPDATE na tabela de resultado falha por permissão.
• Perder o evento não impede que a linha seja consultada no banco.

Definição de concluído (DoD)

• Todos os critérios de aceitação foram atendidos.
• Testes automatizados foram adicionados ou atualizados quando aplicável.
• Os testes existentes passam.
• O código segue as convenções e padrões de qualidade do projeto.
• Documentação, migrações, contratos ou configurações exigidos foram atualizados.
• Nenhuma regressão conhecida ou problema não resolvido foi introduzido pela tarefa.
• As alterações foram confirmadas e estão prontas para revisão/mesclagem.
• A implementação foi verificada no ambiente apropriado.

Observações / Decisões

Único ponto do sistema com exchange fanout. Os outros cinco eventos têm consumidor único e usam fila simples. A fanout existe aqui porque api e codegen reagem ao mesmo fato por motivos independentes, e nenhum deve esperar pelo outro.

Efeito cascata: fecha a trilha do worker e é pré-requisito de T-045 e T-076.