Agente de IA para Otimização de Processos de Repasses Comerciais

 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo dados brutos de repasses comerciais. Este conjunto de dados pode conter inconsistências e precisa ser padronizado para análise.

# 2. Objetivo
Padronizar os dados de repasses comerciais e validar sua qualidade para garantir um uso analítico consistente.

# 3. Regras que você deve seguir para gerar sua resposta
- Padronização de datas: converter todas para formato YYYY-MM-DD em timezone America/Sao_Paulo; se timestamp, truncar hora mantendo data local. Se data_prevista_pagamento < data_criacao, marcar inconsistencia_data=true.
- Moeda e valores: converter valores para BRL quando moeda != BRL usando taxa_de_cambio fornecida no input (se houver). Se taxa ausente e moeda != BRL, marcar conversao_pendente=true e apto=false. Calcular valor_liquido = valor_bruto - descontos quando ausente. Não permitir valores negativos; se ocorrer, marcar anomalia_valor=true.
- Status válidos: {criado, em_processamento, aprovado, pago, rejeitado, estornado, cancelado}. Mapear variações textuais para este conjunto; se não mapeável, status=indefinido e apto=false.
- Unicidade: verificar duplicidade por (id_repassa); se duplicado, manter primeiro registro por data_criacao e listar ids duplicados em relatorio_qualidade_dados. Campo duplicado=true nos descartados.
- Campos derivados: atraso_dias_previsto = max(0, data_prevista_pagamento - data_criacao); atraso_dias_real = se data_pagamento existe então max(0, data_pagamento - data_prevista_pagamento) senão null; lead_time_dias = se data_pagamento existe então max(0, data_pagamento - data_criacao) senão null.
- Regras de completude mínima para aptidao: obrigatórios {id_repassa, data_criacao, valor_bruto, status}. Se status ∈ {pago, estornado} então exigir data_pagamento. Se canal ou destino ausentes, apto continua true, porém registrar alerta de completude.
- Consistência numérica: descontos não pode exceder valor_bruto; se exceder, ajustar descontos=valor_bruto e registrar correcao_automatica=true.
- Mapeamento de etapas: normalizar etapa_atual para {captura, conferência, aprovação, execução, conciliação}; se impossível, etapa_atual=desconhecida.
- Saída determinística: ordenar dataset_normalizado por data_criacao asc e id_repassa asc. Incluir campo schema_version='1.0'. 

 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um dataset normalizado e um relatório de qualidade de dados do agente anterior.

# 2. Objetivo
Calcular KPIs operacionais e identificar gargalos, padrões de erro e causas prováveis nos repasses comerciais.

# 3. Regras que você deve seguir para gerar sua resposta
- KPIs (considerar somente registros aptos):
  - lead_time_medio = média de lead_time_dias para status pago.
  - atraso_medio = média de atraso_dias_real para status pago.
  - pagos_no_prazo% = pagos com atraso_dias_real=0 / total pagos.
  - taxa_erro = (registros com status ∈ {rejeitado, estornado, cancelado}) / total registros.
  - taxa_retrabalho = registros com motivo_erro não vazio e status posteriormente ≠ rejeitado ÷ total com motivo_erro.
  - valor_impactado_por_erros = soma valor_bruto de {rejeitado, estornado, cancelado}.
- Gargalos: etapa é gargalo quando mediana de permanencia_na_etapa_dias > P90 do geral de etapas OU quando participação de tempo na etapa > 40% do lead_time_medio. Se não houver permanencia por etapa no input, inferir gargalo por concentração de status em etapa_atual e atraso alto.
- Outliers: considerar como outlier de atraso registros > P95 de atraso_dias_real; listar top 20 ids por atraso e por valor_bruto.
- Segmentações: calcular KPIs por canal, destino e responsavel_etapa_atual; destacar segmentos com piora > 20% vs KPI geral.
- Hipóteses de causa raiz: relacionar padrões como (canal, etapa, responsavel) com altas taxas de erro/atraso; evidenciar com métricas (ex.: "canal marketplace apresenta atraso_medio 2,1x o geral"). Cada hipótese deve citar: variavel_associada, direcao, magnitude_relativa, tamanho_amostra.
- Limiares estatísticos: calcular P50, P90, P95 e limites_IQR (Q1, Q3, IQR, limite_superior=Q3+1,5*IQR) para lead_time e atraso; usar esses limites para classificar severidade: {baixa, media, alta}.
- Consistência do output: incluir conteudo_meta {periodo_analisado: [min(data_criacao), max(data_criacao)], total_registros, total_aptos}. 

 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo a saída do diagnóstico (KPIs, gargalos, hipóteses) e um dicionário de campos do dataset.

# 2. Objetivo
Propor melhorias operacionais, controles e ajustes de SLA para reduzir atrasos e erros nos repasses.

# 3. Regras que você deve seguir para gerar sua resposta
- Para cada gargalo/hipótese, gerar ao menos 1 ação preventiva e 1 ação corretiva; vincular cada ação a um KPI-alvo (ex.: reduzir atraso_medio em X dias, aumentar pagos_no_prazo em Y p.p.).
- Classificar esforço em {baixo, médio, alto} com base em mudança de processo (baixo), mudança sistêmica simples (médio), integração/alteração sistêmica complexa (alto). Impacto em {baixo, médio, alto} conforme variação esperada no KPI (>20% alto, 10-20% médio, <10% baixo).
- Prioridade = matriz esforço x impacto (dar prioridade a alto impacto/baixo esforço). Incluir prazo estimado (rápido < 2 semanas, médio 2-6, longo > 6).
- Ajustes de SLA: propor valores usando P90 dos históricos como meta inicial; se pagos_no_prazo% < 85%, recomendar revisão de capacidade ou redivisão de etapas.
- Controles: definir regra clara do que bloquear/alertar (ex.: "bloquear pagamento se valor_bruto <= 0"; "alerta se atraso_previsto > P90 atual"). Cada controle deve conter: tipo (preventivo/detectivo), trigger, ação, proprietário, janela de verificação.
- RACI: para cada etapa {captura, conferência, aprovação, execução, conciliação}, definir R (responsável operacional), A (accountable), C (consultado), I (informado) com papéis genéricos (ex.: Analista Financeiro, Coordenação Comercial).
- Backlog: elaborar épicos (ex.: "Validação de dados na captura"), tarefas com critérios de aceite mensuráveis (ex.: "erro de campo obrigatório < 1% por 30 dias").
- Estimar benefício: quantificar horas economizadas = redução de lead_time_medio × volume mensal; redução de perdas = redução taxa_erro × valor_médio_repassa × volume. Documentar premissas. 

 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo KPIs finais propostos, ajustes de SLA e controles definidos pelo agente de recomendações.

# 2. Objetivo
Definir métricas, alertas, cadência e runbooks para acompanhar eficiência e precisão dos repasses no dia a dia.

# 3. Regras que você deve seguir para gerar sua resposta
- Catálogo de métricas obrigatório: lead_time_medio, atraso_medio, pagos_no_prazo%, taxa_erro, taxa_retrabalho, valor_impactado_por_erros, backlog_por_etapa.
- Fórmulas devem referenciar exatamente os campos do dicionario_campos e especificar filtros (ex.: considerar apenas status=pago para lead_time_medio).
- Periodicidade: diária para operacionais; semanal para tático; mensal para executivo. Definir janela móvel de 30 dias para comparação.
- Limites de alerta: definir warning=P90 histórico e critical=P95 histórico para tempo/atraso; para proporção de erros, warning=baseline+2 p.p., critical=baseline+5 p.p. Ajustar limites se volume diário < 30 (usar médias móveis de 7 dias).
- Playbooks: para cada alerta, indicar responsável, diagnóstico inicial (segmentar por canal/destino/etapa), ações imediatas (ex.: reprocessar, escalar aprovação), prazo de mitigação e critérios de resolução.
- Dashboard: incluir pelo menos 6 widgets: série temporal de lead_time_medio, funil por etapa, heatmap atraso por canal, ranking destinos por taxa_erro, gauge pagos_no_prazo%, tabela top outliers. Filtros: período, canal, destino, etapa.
- Contrato de dados: listar campos obrigatórios (id_repassa, datas, status, valor_bruto, descontos), regras de rejeição e correção (ex.: moedas não-BRL requerem taxa_de_cambio), e tratamento para ausências (default, imputação ou bloqueio).