T-309 - Definir o contrato das fontes de dados da simulação

• Componente: contracts/, sujeito a autorização.
• Depende de: T-304 no develop, porque a resposta da consulta de auditoria ganha o campo.
• Data máxima: 09/11/2026
• Estimativa: 2 pontos (Fibonacci)

Entregável

• Schema contracts/domain/resultado-fontes.schema.json, com exemplo registrado no manifesto.
• Campo opcional fontes nos resultados da resposta de GET /auditoria/jobs/{id}.

Descrição

A US04 exige que o registro de auditoria contenha a origem de cada dado processado e a vincule ao id da simulação, ao horário e à versão da regra. Hoje nada registra quais bases de dados uma execução usou. O worker já confere os arquivos de base contra o sha256 registrado no manifesto dos baselines, mas não grava isso. Esta tarefa define o formato desse registro, que o worker grava em resultados_simulacao.fontes (T-311) e a API expõe (T-310).

Contexto e decisões tomadas

• O manifesto (worker/sandbox/data/domrock/baselines/manifesto.json) registra versao, congelamento, o sha256 de cada arquivo de base em fontes_sha256 e, por competência, o arquivo e o sha256 do baseline em baselines.
• O worker lê e confere cinco arquivos (rh.jsonl, vendas.jsonl, comissoes.jsonl, eventos_rh.jsonl e regras_competencia.jsonl, em ARQUIVOS de worker/app/execucao/bases.py).
• O registro fica no resultado, e não na trilha. O resultado já se liga ao código, à versão da regra, à simulação e ao horário, então as fontes ficam vinculadas a tudo isso pela mesma linha, que é imutável.
• O registro é referência e identificação das bases, sem conteúdo de dados.

Escopo

Dentro do escopo

• O schema de domínio, o exemplo, o registro no manifesto de exemplos e o campo na resposta da consulta de auditoria em contracts/http/openapi.yaml.

Fora do escopo

• Migration, gravação pelo worker e leitura pela API.
• Os eventos executar-codigo e simulacao-concluida, que continuam sem as fontes.

Requisitos

1. Antes de editar, pedir autorização conforme contract-change (.agents/skills/contract-change/SKILL.md), informando o schema novo, o produtor (worker), o consumidor (API), a compatibilidade (campo novo e opcional) e as validações.
2. Criar resultado-fontes.schema.json, um objeto com manifesto (versao e congelamento), competencias (formato AAAA-MM, como em comum.schema.json), arquivos (lista de nome e sha256) e baselines (lista de competencia, arquivo e sha256). Todos obrigatórios, sem additionalProperties: false. O sha256 tem 64 caracteres hexadecimais minúsculos.
3. A descrição do schema diz que o registro identifica as bases que o worker conferiu contra o manifesto antes de executar, e que as imagens do worker e do sandbox copiam os dados do mesmo diretório do repositório.
4. Criar contracts/examples/domain/resultado-fontes.json com os valores do manifesto atual para duas competências e registrá-lo em contracts/examples/manifesto.json.
5. Na resposta de GET /auditoria/jobs/{id}, acrescentar aos resultados o campo opcional fontes, referenciando o schema novo, ausente nos resultados gravados antes do campo e nos de erro_infra.

Contexto técnico

• Entradas: o manifesto dos baselines.
• Saídas: schema e exemplo das fontes, e o campo na resposta de auditoria.
• Componentes afetados: contracts/.
• Restrições: evolução aditiva; nenhum dado de base no registro.
• Referências: worker/app/execucao/bases.py, manifesto dos baselines (worker/sandbox/data/domrock/baselines/manifesto.json), contracts/domain/comum.schema.json, contract-change (.agents/skills/contract-change/SKILL.md).

Critérios de aceitação

• python contracts/validar-exemplos.py passa com o exemplo novo.
• Um registro com sha256 em maiúsculas ou com competência fora do formato é rejeitado.

Definição de concluído (DoD)

• Autorização registrada antes da edição.
• python contracts/validar-exemplos.py e git diff --check sem falha, e gate dos quatro componentes verde.