Seis casos, cada um com uma pergunta de negócio.

Cenário de exemplo: uma empresa recebe repasses com taxas e prazos definidos em contrato. O projeto confere cada transação contra o contrato, agrupa as divergências pelo padrão do erro e prepara a contestação para uma pessoa aprovar. A saída é um relatório em Excel.

O que mostra. Na demonstração, com 248 transações, apareceram 80 divergências em 5 grupos.

Limite. Nos testes em modo demonstração, mede-se o código, não a IA.

• Python
• Relatório em Excel
• Conciliação

Detalhes técnicos, testes e limites completos

Contexto

Cenário fictício: um seller de e-commerce que recebe repasses de um payment gateway, com descontos de MDR, antecipação, estornos e prazos de pagamento.

Problema

Conferir linha a linha contra o contrato é manual e lento. Cobrança indevida vira perda silenciosa, e a divergência a favor passa despercebida até o parceiro cobrar de volta.

Abordagem

Um agente de IA lê o contrato em PDF e uma pessoa confere as regras extraídas. A conciliação em si é código determinístico, com dinheiro em Decimal. As divergências são agrupadas pelo padrão do erro, e cada grupo recebe uma análise (causa provável, cláusula, minuta de contestação) que uma pessoa aprova. A IA não escreve valores: uma checagem acusa qualquer número monetário que não veio do motor. A saída é um relatório em Excel.

Stack

• Python
• pydantic
• Streamlit
• pytest
• ruff
• mypy
• GitHub Actions
• Gemini (opcional, há modo demo)

Resultado verificável

Na demonstração, com 248 transações fictícias: 80 divergências em 5 grupos, e 5 chamadas de IA em vez de 80. O eval com divergências plantadas (20 cenários, modo demo) achou todas as plantadas, sem alarme falso. 66 testes automatizados, com lint e tipos checados no CI.
conferido

Contagem de testes e último CI na branch principal conferidos no repositório em 02/10/2026. Contei as funções de teste e vi o CI passar; não reexecutei a suíte.

Limites

O eval em modo demo mede o código (motor, agrupador, checagens), não a IA; a medição com o Gemini é um próximo passo do README. Um parceiro e um formato de CSV; sem chargeback.

Cenário hipotético: uma área financeira com 8 contas em bancos diferentes, cada extrato num formato. O projeto junta tudo num banco SQL, impede lançamento duplicado e aponta duplicidade, valor fora do padrão e lançamento acima do teto de alçada, com um painel com filtros.

O que mostra. Processar de novo o mesmo lote de 216 transações não duplicou nenhuma: as 216 foram ignoradas.

Limite. Roda em modo demonstração, com banco local.

• Python
• SQL
• Power Query
• Painel HTML

Detalhes técnicos, testes e limites completos

Contexto

Cenário hipotético: uma área financeira com 8 contas em bancos diferentes, cada extrato num formato e num horário. Os bancos e os dados são sintéticos; não há integração com nenhuma instituição real.

Problema

Extratos em formatos distintos, cargas repetidas que duplicam lançamentos e divergências que só aparecem no fechamento.

Abordagem

Esteira de ponta a ponta: extração (retentativa com backoff e circuit breaker por banco), ETL em Power Query, persistência em SQL com chave idempotente (SHA-256 e UNIQUE), regras de divergência (duplicata, outlier e teto de alçada), trilha de auditoria e painel HTML com filtros.

Stack

• Python
• pandas
• SQL (T-SQL e SQLite)
• Power Query (M)
• Chart.js
• GitHub Actions

Resultado verificável

30 testes automatizados, rodando no CI em Python 3.12 e 3.13. Reprocessar o lote de referência (216 transações sintéticas) não duplica nada: as já gravadas são ignoradas. O projeto não afirma ganho financeiro nem de tempo.
conferido

Contagem de testes e último CI na branch principal conferidos no repositório em 02/10/2026. Contei as funções de teste e vi o CI passar; não reexecutei a suíte.

Limites

Roda em modo demo (SQLite; o T-SQL é o modelo-alvo). A chave idempotente é por conteúdo: duas compras idênticas no mesmo segundo seriam tratadas como uma. A extração é sequencial.

Quem vende o mesmo produto em vários marketplaces precisa saber por quanto anunciar em cada um, e a taxa muda conforme a faixa de preço. O painel calcula o preço certo por canal e avisa quando a margem desejada é inatingível. Roda no navegador, sem login.

O que mostra. Exemplo do README: a fórmula simples dá prejuízo em cada venda; o preço certo fica numa faixa acima.

Limite. As taxas padrão vêm de fontes secundárias e precisam ser conferidas no painel do vendedor.

• JavaScript
• Painel web
• Regras de negócio

Detalhes técnicos, testes e limites completos

Contexto

Quem vende o mesmo produto em vários marketplaces (Shopee, Mercado Livre, TikTok Shop e Shein) precisa saber por quanto anunciar em cada canal. É a reescrita, com testes, de uma ferramenta que fiz antes para consultorias. Roda no navegador, sem login.

Problema

A taxa muda conforme a faixa de preço, e o preço depende da taxa. Na planilha, o erro comum é usar a taxa da faixa errada. Exemplo do README: a fórmula simples usa a taxa da faixa errada e, nesse preço, o marketplace cobra mais, então cada venda dá prejuízo; o preço certo fica numa faixa acima.

Abordagem

Um motor de cálculo puro (sem DOM) resolve o preço em cada faixa de taxa e fica com o menor preço consistente; se nenhuma faixa serve, responde “margem inatingível” em vez de um número absurdo. A importação de catálogo (CSV ou Google Sheets) relata cada linha ignorada e o motivo. As taxas são editáveis, com vigência e fonte.

Stack

• JavaScript (JSDoc e TypeScript strict)
• Node.js
• ESLint
• Prettier
• GitHub Actions

Resultado verificável

32 testes de unidade e 13 de ponta a ponta no Chrome (números do README; não os reexecutei). Cinco bugs da versão anterior estão cobertos por teste. A demonstração pública respondeu normalmente em 02/10/2026.

Limites

As taxas padrão vêm de fontes secundárias (consultadas em 10/2026) e precisam ser conferidas no painel do vendedor. A comissão por categoria não está modelada.