> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Integração com o Lerian Consignado — Dataprev

> Como o gateway se integra — os dois comandos que consome do motor de crédito, os cinco fatos de negócio que emite, sua entrega por outbox agnóstica ao destino, a ausência de acoplamento direto com o ledger e com webhooks, e sua semântica de transporte e idempotência.

O Lerian Consignado — Dataprev é **event-first** na sua borda com a plataforma. Ele consome comandos do motor de crédito e emite fatos de negócio; não faz chamadas diretas ao ledger nem hospeda consumidores de webhook. Seu contrato autoritativo é o fluxo de eventos, não a sua superfície REST.

## Comandos que consome

***

O gateway consome **dois comandos** do motor de crédito, transportados como eventos pelo backbone de streaming da plataforma:

* uma **solicitação de margem**, que pede a margem de folha disponível de um trabalhador;
* uma **solicitação de averbação**, que pede o registro de um contrato assinado na Dataprev.

Um comando que decodifica mas **está sem a sua chave identificadora** — por exemplo o CPF do trabalhador — é terminal: ele vai para a fila de mensagens mortas em vez de ser repassado à Dataprev.

## Fatos que emite

***

O gateway emite **cinco fatos de negócio**:

* a **margem** obtida de um trabalhador;
* um resultado de **averbação confirmada**;
* um resultado de **averbação rejeitada**;
* um sinal de **proposta aceita**, que diz ao sistema de empréstimos a jusante para originar;
* um registro de **conciliação** — um por registro de escrituração ou de liquidação.

Cada fato carrega uma única versão de esquema para todo o pacote, estampada de forma idêntica nos cinco em vez de versionada por evento.

## Entrega agnóstica ao destino

***

O gateway escreve cada fato em um **outbox transacional** e repassa a partir dali. Ele **não possui roteamento por destino**: um hub de streaming a jusante decide qual sistema recebe cada fato. O mesmo fato pode ser distribuído a um ledger, a um armazenamento de conciliação ou a um sistema de empréstimos sem que o gateway saiba ou se importe com quem o consome.

## Sem acoplamento direto com o ledger ou com webhooks

***

O gateway **não faz chamadas diretas ao Midaz** e **não hospeda consumidores de webhook**. O contato com o tomador fora da plataforma está fora de escopo: o fato de **proposta aceita** é o limite de repasse, após o qual o sistema de empréstimos a jusante é dono da originação e de qualquer comunicação com o tomador.

## No transporte

***

* **Dinheiro e taxas cruzam como strings decimais**, nunca como ponto flutuante, para não perder precisão no caminho.
* **Os carimbos de tempo são UTC, RFC 3339.**
* **Nenhum CPF cruza o fato de conciliação.** Isso é garantido por construção: os tipos de registro de conciliação não têm campo de CPF, o CPF presente na fonte de escrituração é descartado no normalizador, e os testes verificam que o payload serializado não contém nenhum CPF. O **número de contrato é a chave de correspondência**, então nenhum identificador pessoal é necessário a jusante. (Os fatos de margem e de proposta aceita *carregam* um CPF, porque cada um é associado a um trabalhador ou a uma proposta específicos.)
* O **repasse** da CEF liquida **por movimento diário, não por contrato**, então a conciliação do lado bancário se baseia no identificador da transferência e não no número de contrato.

## Semântica de entrega

***

* **Idempotente por sujeito imutável.** Cada registro e cada liquidação carrega um identificador imutável; reprocessá-lo é um no-op a jusante.
* **Ao menos uma vez.** Os eventos são entregues ao menos uma vez; a reentrega e os reinícios se deduplicam a um no-op.
* **Pernas independentes.** Na conciliação, as pernas de escrituração e de repasse são processadas de forma independente — uma que falhe nunca bloqueia a outra.