Explicando o projeto

O problema

A Webjur busca os clientes nos jornais oficiais. Os termos de busca moram na tabela PalavrasBusca — mas espremidos e bagunçados: 5 colunas largas (PalavraBusca01..05), a MESMA pessoa espalhada em varias linhas, as vezes 2 termos diferentes na mesma linha, busca por OAB, por numero de processo... Resultado: ninguem responde rapido "quais sao os termos do cliente X?".

A solucao

Transforma esse balaio numa estrutura normalizada e curavel, num banco de estudo separado (a origem so e tocada com permissao):

• TermoBusca — cada entidade buscada (um advogado, uma empresa, um orgao), com um Tipo.
• Variacao — cada grafia/abreviacao daquela entidade (guarda a coordenada da celula de origem -> auditoria e zero-perda).
• LinhaOrigem — espelho fiel dos campos nao-busca da origem.
• Tipos: Advogado, Pessoa, Empresa, Publico, Busca de Numero, Indefinido.

Como ele monta isso (pipeline)

1. Camada 1 (deterministica): agrupa as celulas em entidades por OAB e por nucleo de nome (tolera abreviacao/typo, sem fundir empresas diferentes); separa numeros; classifica o tipo.
2. Dicionario de nomes: 77 mil tokens de nome de pessoa, aprendidos das empresas que so tem advogados. Com ele, "Classic Boulevard" e Empresa (nao e nome de gente) sem precisar de marcador.
3. Camada 2 (IA): julga so os pares ambiguos (dois termos do mesmo cliente que talvez sejam a mesma entidade) — junta typo/abreviacao, separa empresas distintas.
4. Auditoria: confere celula a celula contra a origem viva -> nada perdido, nada inventado.

As telas

• Buscar -> tela do cliente: editar nome/tipo/OAB, mover/adicionar/editar/remover variantes, novo termo, excluir (cascata, soft-delete), filtro e ordenacao.
• Revisao — fila do que precisa de gente (com filtros).
• Emitir — relatorio PDF (completo/resumido): ver na tela -> PDF -> email.
• Config, Logs, API, Manual.

Origem ↔ modelo — fluxo de mao dupla

• Operador edita na tela ANTIGA → grava na PalavrasBusca (origem) → eu replico na reestrutura (modelo normalizado) pelo job diario / incremental. (origem → modelo)
• Operador edita na tela NOVA → eu replico na origem antiga (PalavrasBusca) pelo writeback (Config "aplicar na origem" ligado, com snapshot + log). (modelo → origem)
• Ressalva: conteudo (texto/variantes) vai nos dois sentidos; agrupamento e tipo sao so do nosso modelo (a origem nao tem esse conceito).

API (terceiros)

Incluir / consultar / excluir termos de um cliente, auth por chave, tudo logado. Variantes opcionais (se faltarem, sao derivadas). Doc completa na aba API.

Status por empresa

• Empresa 1 (WebJur): completa.
• Empresa 42 (gigante, mista): so os PROPRIOS (363k linhas / 181k termos / 1,26M variacoes). Os clones diarios ("BR++") ficam de fora (vivem nas empresas-mae).
• Empresa 2 = "Excluidos" -> nunca processar.

Manutencao

O caro e a rodada inicial (acervo historico). Depois e incremental: so o que muda por dia, so os pares novos pra IA, e a curadoria humana acumula. Pendentes pra virar rotina: motor de replay e job diario.

Pendencias em aberto

• Motor de replay — edicoes manuais (criar/mover/apagar) sobreviverem ao loop diario.
• Job diario: ja existe o app de mesa CargaDiaria.exe (GUI clicavel) que VERIFICA o delta (origem x modelo) e JULGA os ambiguos pela Claude API. Falta o passo de APLICAR sozinho (incremental dos novos + merges) sem clique.
• FEITO — painel no ar na .177 (http://192.168.0.177:8092) E API publica no ar em http://cadastro.webjur.com.br/api (DNS registro.br → WAN ALGAR → NAT firewall). Falta: HTTPS (hoje a chave anda em texto puro) + a auth com escopo por cliente (logo abaixo) — agora urgente, pois esta exposto na internet.
• API: auth com ESCOPO por CLIENTES (futuro) — hoje e 1 chave global (X-API-Key em Config). Evoluir p/ credenciais onde cada chave/senha da acesso a um CONJUNTO de N clientes (escopo), guardado num campo da tabela Cliente ou numa tabela de credenciais ligada aos CdClis. Assim: identifica quem chama, limita cada terceiro aos seus N clientes, e revoga 1 sem afetar os outros. + rate-limit + HTTPS.

CdEmpresaCliPaga = quem paga (R$) o cliente — nao indica clone, exceto na empresa 42, onde clientes pagos por outra empresa sao os BR++ (copias diarias, ficam de fora). Nas demais empresas isso e so cobranca: cliente legitimo, fica.

Nao precisa carregar/curar as empresas-OAB (30/35/47/50/70/75) nem os BR++: la e tudo trivial — 1 cliente = 1 advogado, o nome do cliente JA e o termo (sem mundo misto, sem ambiguidade). Se um dia precisar do relatorio/API delas, e carga simples.

Ja feitos hoje: IA camada 2 da empresa 42 (235 agentes); residuos da 42; filtro por representante; pagina deste projeto.

Um pouco da historia da carga inicial

Numeros de 21/06/2026 — a "rodada inicial" (o passivo historico, feito uma vez):

• Empresa 1 (WebJur): camada 1 + IA + dicionario; auditoria zero-perda.
• Empresa 42 (so PROPRIOS, sem os clones "BR++"): 363.794 linhas de origem → 181.505 termos → 1.260.670 variacoes. Clones BR++ excluidos: 142.329 clientes.
• Dicionario de nomes (NomePessoa_Claude): 77.306 tokens de nome de pessoa, aprendidos de ~1,8M advogados das empresas-OAB (30/35/47/50/70/75).
• IA camada 2 (empresa 42): 35.143 pares ambiguos julgados por 235 subagentes Claude em paralelo (~7 min, ~9,3M tokens) → 14.092 juncoes e 21.051 separacoes.
• Fila de revisao (residuos): empresa 1 = 163; empresa 42 = 9.718.

Daqui pra frente e so o delta diario (incremental) — o pico foi hoje.

Desenvolvido por Getulio Menegatti em parceria com o Claude (Anthropic).