kit-juridico

name kit-juridico description Organização automatizada de kits documentais jurídicos para escritórios de advocacia, com detecção de múltiplos benefícios INSS, parser de extrato HISCON, detecção de cadeias de fraude (refinanciamento, portabilidade, consolidação, fracionamento), grifo colorido por cadeia e geração de ESTUDO de cadeia em DOCX. Recebe pasta com documentos brutos (PDFs, imagens, Word) de um ou mais clientes e organiza em estrutura BENEFÍCIO/BANCO/ com numeração canônica, validação documental e Pendências.xlsx. Suporta processamento em lote. SEMPRE use esta skill quando o usuário mencionar: kit jurídico, organizar documentos de cliente, separar kit, montar pasta de ação, organizar pasta AL/AM/SC, RMC, RCC, empréstimo consignado, empréstimo não contratado, organizar procurações, organizar Bradesco, kit processual, montar kit de processo, processar kits em lote, cadeia de empréstimos, refinanciamento sucessivo. Kit Jurídico — Organização Documental Automatizada com Detecção de Cadeias Esta skill recebe uma pasta com documentos brutos de cliente(s) e produz uma estrutura organizada, validada, com extratos grifados por cadeia e ESTUDO em DOCX por banco. O objetivo é uma ação por cliente, por banco, por benefício — agrupando bancos APENAS quando há cadeia inter-banco (portabilidade), conforme regras em references/regras-cadeias.md . Pré-requisitos pip install pymupdf python-docx Pillow img2pdf openpyxl opencv-python --break-system-packages Regra de Escopo — Trabalhar APENAS na pasta selecionada REGRA ABSOLUTA E INVIOLÁVEL: O processamento deve ser feito exclusivamente dentro da pasta que o usuário selecionou . Essa é a ÚNICA pasta com a qual você deve interagir. A pasta selecionada é o universo de trabalho. Tudo acontece dentro dela. NUNCA use find , ls , locate para buscar fora da pasta selecionada. NUNCA navegue para diretórios pai, irmãos ou qualquer caminho fora dela. NUNCA presuma que existem outros kits em outros locais do computador. Se a pasta não contém os documentos esperados, informe e peça que selecione a pasta correta — não saia procurando. Use SEMPRE caminhos relativos à pasta selecionada ao listar arquivos. Regra de Integridade — NUNCA excluir documentos REGRA ABSOLUTA E INVIOLÁVEL: Nenhum arquivo pode ser excluído, removido, apagado ou deletado da pasta de trabalho. As únicas operações permitidas são mover (dentro da mesma pasta de cliente) e copiar (replicar documentos comuns nas subpastas de banco). NUNCA use rm , del , unlink , shutil.remove , os.remove , Path.unlink() , etc. NUNCA exclua arquivos "temporários", "duplicados" ou "desnecessários". Documentos não classificados, modelos em branco, fotos de cautela, vídeos, senhas → tudo vai para 0. Kit/ , nunca é excluído. Imagens originais, após convertidas em PDF, são MOVIDAS para 0. Kit/ — nunca excluídas. Os scripts auxiliares também respeitam essa regra: nenhum script contém lógica de exclusão. Estrutura final esperada Cliente com UM benefício INSS [Cliente]/ ├── 0. Kit/ (sempre criada — auxiliares, modelos, mídia) ├── BANCO ITAÚ CONSIGNADO/ (1 banco = 1 ação) │ ├── 2. Procuração – Banco Itaú Consignado – Contrato N.pdf │ ├── 3. RG e CPF.pdf │ ├── 4. Declaração de hipossuficiência.pdf │ ├── 5. Comprovante de residência.pdf │ ├── 6. Histórico de empréstimo (grifado).pdf │ ├── 7. Histórico de créditos.pdf │ ├── ESTUDO DE CADEIA - BANCO ITAÚ CONSIGNADO.docx │ └── CALCULO_INDEBITO.xlsx (planilha gerada com INPC + juros 1% + dobro + dano moral) ├── BANCO BMG - RMC-RCC/ (cartão consignado — NÃO tem CALCULO_INDEBITO.xlsx) └── Pendências.xlsx CALCULO_INDEBITO.xlsx (gravado 13/05/2026): gerado automaticamente para cada pasta de ação CONSIGNADO (não para RMC/RCC). Usa skills/_common/calculadora_indebito.py com regime fixo: correção INPC, juros 1% a.m. simples, dobro art. 42 CDC, dano moral R$ 15k (1 contrato) ou R$ 5k×N (2+). A skill inicial-nao-contratado lê esse Excel para usar o TOTAL GERAL como valor da causa. Separadores (v2.2): ponto após o número ( 2. , 3. ), travessão – entre campos da procuração (Banco – Contrato), hífen comum - entre descritor e nome de subdocumento ( 3.1 - RG e CPF do rogado - NOME COMPLETO.pdf ). Regras completas em references/regras-nomenclatura.md . Cliente com DOIS ou mais benefícios INSS (v2.4, paradigma Guilherme 2026-05-14) Estrutura <CLIENTE>/<BENEFÍCIO>/<TESE>/<BANCO>/[Contrato XXX/] : [Cliente]/ ├── 0. Kit/ ├── APOSENTADORIA/ (NB principal — maiúsculas) │ ├── Não contratado/ │ │ ├── BANCO BRADESCO/ (1 contrato → docs direto, sem subpasta) │ │ │ ├── 2. Procuração – Bradesco – Contrato N.pdf │ │ │ ├── 3. RG e CPF.pdf │ │ │ ├── 4. Declaração de hipossuficiência.pdf │ │ │ ├── 5. Comprovante de residência.pdf │ │ │ ├── 6. Histórico de empréstimo - Extrato de Empréstimo - Aposentadoria.pdf │ │ │ ├── 7. Histórico de créditos.pdf │ │ │ └── notificacao/ │ │ └── BANCO DO BRASIL/ (3 contratos → subpastas Contrato XXX/) │ │ ├── Contrato 114180212/ │ │ ├── Contrato 159730415/ │ │ ├── Contrato 185401944/ │ │ └── notificacao/ │ ├── RMC/BANCO PAN/ (1 contrato → docs direto) │ └── RCC/BANCO PAN/ └── PENSÃO/ (segundo NB) └── Não contratado/ ├── BANCO DO BRASIL/ (185402234) └── BANCO ITAU/ Regras críticas para múltiplos benefícios: Cada contrato pertence a UM benefício, identificado pelo HISCON respectivo. Em _estado_cliente.json , o campo contratos[i].beneficio_pasta deve ser APOSENTADORIA ou PENSAO (sem til, para alinhar com o filtro da skill notificacao-extrajudicial ). HISCON por benefício : dentro de cada pasta-banco, deixe SÓ o HISCON do benefício correspondente (não duplicar os dois). Em APOSENTADORIA/.../BANCO X/ → só 6. Histórico de empréstimo - Extrato de Empréstimo - Aposentadoria.pdf . HISCRE vem único do INSS cobrindo ambos os NBs — replicar nas duas árvores. pastas_acao[i].path_relativo no formato BENEFÍCIO/TESE/BANCO (3 níveis). Colapso de Contrato XXX/ : aplicar SÓ se banco tem 2+ contratos no mesmo benefício; com 1 contrato, deixar docs direto na pasta do banco. EXCEÇÃO AM (gravada 2026-05-14, Gabriel): no Amazonas o entendimento atual é uma ação por contrato . Quando UF=AM e a pasta-de-ação Não contratado/BANCO X/ tiver 2+ contratos NC no mesmo banco/benefício, criar subpastas Contrato XXX/ (uma por contrato) com replicação completa dos documentos comuns + HISCON grifado SÓ daquele contrato + procuração específica + 1 inicial separada. A NOTIFICAÇÃO extrajudicial, ao contrário, agrega todos os contratos do banco em um só docx em Não contratado/BANCO X/notificacao/ (fora das subpastas Contrato XXX/). Entendimento AM-only; quando mudar, atualizar esta regra e inicial-nao-contratado/references/perfis_juridicos.py (flag uma_inicial_por_contrato ). Caso paradigma: MARIA AZEVEDO PARINTINS (Maurivã) 2026-05-14 — 2 contratos PAN NC. Pasta notificacao/ SEM subpasta de banco interna quando há 1 só banco em cada pasta-de-ação (regra escritório 2026-05-14). Cliente com UM benefício INSS (formato simplificado) Quando há apenas um benefício, omitir o nível BENEFÍCIO (estrutura plana TESE/BANCO): [Cliente]/ ├── 0. Kit/ ├── Não contratado/BANCO X/ ├── RMC/BANCO X/ └── RCC/BANCO X/ Cliente com cadeia inter-banco (portabilidade) Pasta combinada quando há cadeia atravessando bancos: APOSENTADORIA/ ├── BANCO ITAÚ CONSIGNADO + BANCO BMG/ (cadeia de portabilidade) │ └── ESTUDO DE CADEIA - BANCO ITAÚ CONSIGNADO + BANCO BMG.docx └── BANCO ITAÚ CONSIGNADO/ (contratos isolados sem cadeia inter-banco) Detecção de modo Antes de processar, identifique: Individual: pasta com documentos brutos de UM cliente. Lote: pasta-mãe com subpastas (cada uma é um cliente). Processe um por um. Organização Parcial: pasta já tem subpastas com numeração canônica. Analise antes de refazer; corrija apenas o que estiver errado. Como detectar: Liste o conteúdo da pasta indicada. Se contém subpastas que por sua vez contêm arquivos → modo lote. Se contém diretamente documentos → modo individual. Se contém subpastas como 0. Kit , [BENEFÍCIO]/ , BANCO X/ → modo organização parcial. Em caso de dúvida, pergunte ao usuário. Fluxo de Trabalho (12 fases) Execute estas fases em ordem. Use os scripts em scripts/ para tarefas determinísticas. Use sua leitura visual (Read tool) para tarefas que exigem interpretação (assinatura, texto rotacionado, classificação ambígua). Fase 1: Inventário e Detecção de Modo from scripts.pipeline import fase_a_inventario inv = fase_a_inventario( "/caminho/pasta-cliente" ) Lista todos os arquivos com extensão, tamanho, número de páginas e se tem text-layer. Decida o modo (Individual / Lote / Parcial). Fase 2: Identificação do KIT Assinado e Separação de Modelos Aplique a regra de assinatura (física ou digital). Detalhes em references/regras-validacao.md (seção 2). Documentos sem assinatura → MOVER para 0. Kit/ (nunca excluir). Documentos Word .doc/.docx → quase sempre são modelos editáveis → vão para 0. Kit/ . KIT compactado em PDF assinado → fonte da Fase 5 (separação por documento). Distinção KIT em branco × Processo escaneado (v2.3, paradigma Guilherme 2026-05-14): Quando há 2+ PDFs candidatos a "kit do cliente" em 0. Kit/ (típico: KIT <NOME>.pdf gerado em Word para impressão E Processo <NOME>.pdf escaneado com tudo assinado), USE scripts/pdf_utils.py:score_kit_assinado(path) para decidir qual é a fonte autoritativa: from scripts.pdf_utils import score_kit_assinado, escolher_kit_assinado # Cada candidato recebe score -100..+100 info = score_kit_assinado(path) # info['classificacao']: 'ASSINADO' | 'MODELO' | 'AMBIGUO' # Ou: passar lista de candidatos e receber o vencedor resultado = escolher_kit_assinado([kit_em_branco_path, processo_path]) # resultado['escolhido'] = caminho do kit assinado # resultado['descartados'] = outros (intactos, só não usados como fonte) Sinais que indicam kit ASSINADO : producer em {intsig.com pdf producer, Adobe Scan, CamScanner, ScannerPro, Office Lens} (apps de scanner) Text-layer vazio ou < 100 chars (PDF imagem puro) ≥ 1 imagem raster na primeira página Tamanho > 3 MB Nome começa com "Processo" Sinais que indicam kit MODELO (em branco para o cliente assinar): producer em {Microsoft® Word, LibreOffice, OpenOffice, WPS Writer} Text-layer abundante (> 500 chars) + zero imagens raster Tamanho < 1 MB Nome começa só com "KIT" sem "assinado"/"completo" Em pipeline.py:_sugerir_tipo_pdf , qualquer PDF com "kit" ou "processo" no nome passa por essa heurística antes do match por keyword. Em fase_b_classificar_pdfs , quando há múltiplos KIT_ASSINADO na mesma pasta, o de menor score é REBAIXADO a KIT_MODELO (intacto fisicamente, apenas não é fonte de extração). Sub-documentos a extrair do Processo escaneado (paradigma Guilherme): Procurações específicas por banco/contrato (uma por página) Declaração de hipossuficiência (uma única, replicada nas pastas-banco) Declaração LGPD / consentimento (única) RG/CPF do cliente, da rogada (se a rogo) e das testemunhas NUNCA pegar essas peças do KIT em branco — sairão sem assinatura e atrapalham o protocolo. Para verificar assinatura visual quando o score for ambíguo: Renderize cada página em imagem ( scripts/pdf_utils.py:render_page ). Use Read tool para análise visual procurando: traços manuscritos, rubricas, impressão digital, selos de certificado digital (ICP-Brasil, DocuSign, ClickSign, ZapSign, D4Sign, Adobe Sign). Se não tiver nenhum tipo de assinatura → modelo → MOVER para 0. Kit/ . Fase 3: Identificação dos Tipos de Ação A skill cobre múltiplos tipos: Empréstimo consignado não contratado RMC (Reserva de Margem Consignável) RCC (Reserva de Cartão Consignado) Refinanciamento Empréstimo consignado genérico Bradesco — Tarifas, Mora, Mora+Encargo, Aplic.Invest, PG ELETRON, Título de Capitalização A classificação parte SEMPRE da procuração — o documento-mestre. Detalhes em references/regras-validacao.md (seções 7 e 8). Validação do número do contrato (v2.4, paradigma Guilherme 2026-05-14): O número que vai como contrato no JSON precisa ser EXTRAÍDO DA PROCURAÇÃO ASSINADA específica, NUNCA presumido pelo RG, CPF ou outros identificadores. O kit-juridico antigo às vezes confundia o RG do cliente com número de contrato (caso paradigma: Guilherme PAN RMC ficou como "1897431-7" no JSON, que era o RG do cliente — o número real era "0229014603105"). Antes de gravar contratos[i].contrato no JSON: Conferir que o número aparece literalmente na procuração específica. Validar cruzando com HISCON ou HISCRE quando aplicável (cartões RMC/RCC podem não aparecer no HISCON tradicional, mas a procuração é fonte autoritativa). Em caso de ambiguidade, marcar contratos_impugnar_origem = "sugestao_automatica" para forçar revisão humana antes de gerar inicial. Heurísticas que NÃO devem ser fonte primária do número de contrato: RG do cliente (formato XXXXXXX-X) CPF do cliente NB do benefício (formato XXX.XXX.XXX-X) Identificadores internos do banco que aparecem em telas/extratos sem o rótulo "Contrato" Fase 4: Processamento de Imagens Para cada imagem (JPG, PNG, HEIC, etc.), aplique: Análise — Identifique TODOS os documentos/elementos (uma imagem pode conter múltiplos: RG + senha; RG + CPF; etc.). Detalhes em references/regras-imagens.md . Recorte e centralização — Use scripts/process_images.py para auto-detectar bordas via OpenCV. Ajuste manualmente quando o auto-detect falhar. Conversão para PDF — Cada documento vira um PDF separado. Dados sensíveis (senhas INSS, gov.br, banco) — separar e SALVAR em 0. Kit/ , nunca em pastas de ação. Fotos de cautela (cliente assinando) — não recortar, mantém no 0. Kit/ . from scripts.process_images import crop_and_save_as_pdf, process_batch process_batch( "pasta_imagens" , "pasta_pdfs_output" ) Fase 5: Separação do KIT (PDF compactado) em Documentos Individuais Se houver KIT compactado assinado (PDF único com vários documentos): Renderize cada página em imagem. Identifique visualmente onde um documento termina e outro começa. Use scripts/pdf_utils.py:extract_pages para fatiar. Nomeie conforme references/regras-nomenclatura.md . Fase 5.5: Preparar leitura de manuscritos (se aplicável) Antes de extrair banco/contrato de procurações manuscritas, carregue o módulo de aprendizado : Ler aprendizado/_index.md (entender a estrutura) Ler aprendizado/padroes-bancos.md (formato esperado por banco) Identificar o captador do kit (nome no PDF, contrato escritório, ou rótulo do usuário). Se houver ficha em aprendizado/captadores/<slug>.md , ler antes de extrair (descontar erros conhecidos da caligrafia daquele captador). Aplicar references/regras-manuscritos.md para o workflow completo (1ª tentativa → cross-check HISCON → retry → solicitar usuário). Fase 6: Extrair Banco/Tipo/Contrato das Procurações from scripts.pipeline import fase_c_preparar_procuracoes manifesto = fase_c_preparar_procuracoes( pdf_procuracoes= "caminho/2- Procurações N22.pdf" , pasta_trabalho= "pasta-cliente" ) # Gera crops_pag_NN.png em pasta-cliente/_proc_crops/ Para CADA crop, use Read tool para extrair: Banco (do parágrafo "PODERES ESPECIAIS: em face do BANCO X") Tipo (consignado vs RMC/RCC — verifique se há texto "em virtude do desconto de cartão de crédito RMC/RCC") Número do contrato Em caso de dúvida em algum dígito, use: from scripts.pipeline import fase_c_revalidar_pagina fase_c_revalidar_pagina(pdf_procuracoes, pag_num, pasta_trabalho) # Gera linha_pag_NN.png com super-zoom só da linha do contrato Fase 7: Parser de Extratos HISCON from scripts.pipeline import fase_d_parsear_extratos extratos = fase_d_parsear_extratos([ "caminho/EXTRATO PENSAO.pdf" , "caminho/EXTRATO APOSENTADORIA.pdf" , ]) Cada extrato é parseado em {beneficio: {...}, contratos: [...]} . Se o extrato for sem text-layer (raro), o parser retorna is_ocr_required=True — você precisará rodar OCR (visual via Claude ou easyocr) antes. Fase 8: Detecção de Múltiplos Benefícios Se há mais de um NB único nos extratos parseados, a estrutura final terá nível BENEFÍCIO. Detalhes em references/regras-beneficios.md . Fase 9: Cruzamento Procurações × Extratos Use fase_i_cruzar_procuracoes_hiscon para classificar cada procuração: from scripts.pipeline import fase_i_cruzar_procuracoes_hiscon resultado = fase_i_cruzar_procuracoes_hiscon(procuracoes, extratos) # resultado["exatos"]: match exato no HISCON → confiança 100% # resultado["aproximados"]: Lev ≤ 2 → SUGERIR e PEDIR confirmação ao usuário # resultado["nao_localizados"]: pendência crítica (ver regras-manuscritos.md) Para cada aproximado , mostrar ao usuário: Procuração pag 4 diz "31203991.43" — não bate exato com nenhum HISCON. Candidato mais próximo: 31103991143 (Lev=2, Bradesco, pensão). Confirmar ou corrigir? Para cada não localizado : Aplicar técnicas de retry (ver references/regras-manuscritos.md Fase 3) Se ainda não achar, marcar pendência crítica e pedir leitura ao usuário Quando usuário corrigir, registrar via : from scripts.pipeline import fase_j_registrar_correcao fase_j_registrar_correcao( cliente= "ALICE DA CONCEIÇÃO DOS SANTOS" , captador= "Marcio Teixeira" , pagina= 4 , banco= "Bradesco" , valor_lido= "31203991.43" , valor_correto= "311039911-43" , origem= "usuario" , observacao= "O '0' depois do '31' parecia bola, era '1' fechado." , ) Toda correção é registrada em aprendizado/correcoes.md . Se o padrão é recorrente no captador (≥3 correções similares), atualizar aprendizado/captadores/<slug>.md na seção "Padrões de erro". Fase 10: Detecção de Cadeias from scripts.pipeline import fase_e_detectar_cadeias cadeias = fase_e_detectar_cadeias(extratos)