Replica Nao Contratado

Skill — replica-nao-contratado

Orquestra a produção de réplica à contestação em ações declaratórias de inexistência de relação jurídica (fraude absoluta — cliente nega contratação), usando o catálogo de 60+ pilotos modulares do vault Obsidian em Modelos/ReplicasNaoContratado/.

Quando sou invocada

1. Usuário diz "faz a réplica desse processo de não contratado", "gera réplica do empréstimo fraudulento", "réplica bancária de fraude".
2. Usuário envia pasta de processo onde a tese é "não contratei" (não vício de consentimento).
3. Usuário diz /replica-nao-contratado <pasta>.

Quando NÃO usar

1. Caso de RMC/RCC com vício de consentimento (cliente assinou achando que era empréstimo) → usar outras skills de RMC.
2. Caso de cumprimento, apelação ou inicial — esta skill só faz réplica.
3. Caso onde o cliente reconhece ter contratado mas alega abusividade → não é "não contratado".
4. Réplica à contestação do INSS — esta skill é EXCLUSIVA para banco. Réplica ao INSS é peça AUTÔNOMA, com template próprio em Modelos/ReplicasNaoContratado/pecas-autonomas/replica-INSS-template.md. Mesmo que o INSS esteja no polo passivo, NÃO rebater a contestação dele nesta réplica.

Entrada obrigatória

Caminho para pasta contendo o PDF do processo (consolidado, baixado do PJe/eproc/TJ). Geralmente o nome do PDF tem o número CNJ.

Sistema de 3 camadas dos pilotos

Cada piloto no vault Modelos/ReplicasNaoContratado/teses-modulares/<categoria>/<nome>.md tem:

• Camada 1 — Núcleo doutrinário fixo (~70-95% do texto): copy-paste LITERAL, NÃO mexer NUNCA
• Camada 2 — Slots variáveis ({{CHAVES}}): preencher com dados do caso
• Camada 3 — Zonas de adaptação ([ZONA DE ADAPTAÇÃO]): decisão estratégica caso a caso

[!danger] PROIBIDO redigir argumentos próprios em substituição aos pilotos Para CADA tese a usar, é OBRIGATÓRIO abrir o piloto correspondente e transcrever o texto Camada 1 LITERALMENTE (incluindo citações jurisprudenciais), substituindo apenas slots e zonas. Reescrever do zero, ainda que pareça melhorar a redação, é violação grave da skill: perde-se a doutrina decantada do escritório e introduzem-se variações textuais não validadas. Erro detectado em caso anterior — reincidência inadmissível.

[!danger] PROIBIDO cortar pilotos por decisão própria A skill insere todos os pilotos aplicáveis ao caso. A decisão de cortar/integrar pilotos redundantes é EDITORIAL HUMANA, feita pelo usuário no Word após a entrega. A skill nunca decide o que é "supérfluo".

Fluxo autônomo — NÃO pedir confirmação ao usuário

/replica-nao-contratado <pasta>
      │
      ├─ (1) Localizar PDF na pasta
      │
      ├─ (1.5) FATIAR o PDF consolidado em fatias por arquivo (Arq:)
      │        - Usa `references/fatiar_pje_tjam.py` (PJe TJAM por padrão)
      │        - Cria pasta `_fatias/` ao lado do PDF
      │        - Cada fatia nomeada `NNN-movXXX-YY-tipo.pdf`
      │        - Permite ler peças isoladas (inicial, contestação, CCB, HISCRE, TED)
      │          sem carregar o PDF inteiro a cada extração
      │        - Para eproc/TRF4/TJSC ou PJe TJBA, chamar a skill `fatiar-processo`
      │          (que detecta o sistema automaticamente) antes de prosseguir
      │
      ├─ (1.6) [SE houver contratos DIGITAIS] EXECUTAR PERÍCIA DIGITAL
      │        - Importar `references/pipeline_pericia_digital.py`
      │        - Verificar cache em `_pericia/_pericia.json` (se existe, reusar)
      │        - Senão, executar `executar_pericia(...)` com:
      │            * lista de contratos digitais identificados
      │            * textos de CCB, trilha de auditoria, comprovante TED por contrato
      │            * caminho dos PDFs de cada CCB (para hash + metadados)
      │            * HISCRE por competência (banco do INSS na época do TED)
      │        - Salvar resultado em `_pericia/_pericia.json`
      │        - As 12 verificações A–L são executadas conforme
      │          `references/tabela-mestre-achado-piloto.md`
      │        - Verificações que exigem leitura visual (B validador ITI,
      │          H comparação de selfies) ficam como `risco: manual` no JSON
      │
      ├─ (2) Ler INICIAL e identificar:
      │        - Autor (nome, CPF, RG, idade, profissão, endereço, NB INSS)
      │        - Banco réu (nome, CNPJ, procurador)
      │        - Comarca, processo, juízo
      │        - >>> Procurador da autora (NOME COMPLETO + OAB) — capturar do rodapé da inicial
      │            para usar na ASSINATURA da réplica. NÃO usar lista fixa de 3 advogados.
      │        - Filial do escritório que atende (cidade) — usar na cidade da assinatura final
      │        - Notificação extrajudicial (AR digital/AR-Email) — capturar DATAS específicas
      │            (envio + entrega) se juntada
      │
      ├─ (3) Ler CONTESTAÇÃO (palavra "CONTESTAÇÃO" como cabeçalho de página
      │        ou "CONTES1" como tipo de evento) e extrair TODAS as teses arguidas
      │        pelo banco (literais — não parafrasear)
      │
      ├─ (4) Identificar contratos impugnados na inicial:
      │        - Número, valor, data, parcelas
      │        - Conta de depósito alegada
      │        - Cadeia de refinanciamentos (se houver)
      │        >>> Comparar com contratos JUNTADOS pelo banco na contestação:
      │            - Se algum contrato impugnado NÃO foi juntado pelo banco → tese da
      │              presunção art. 400 CPC + pedido individual de julgamento antecipado
      │
      ├─ (5) VERIFICAÇÕES CRUZADAS AUTOMÁTICAS (todas obrigatórias):
      │
      │   FÍSICAS:
      │   ────────
      │   a) Anotação "IMPOSSIBILIDADE DE ASSINAR" no RG × data dos contratos
      │      - Se RG anterior aos contratos: argumento devastador
      │
      │   b) Tipo de assinatura por contrato físico (via leitura visual):
      │      - CURSIVA + autor analfabeto/impossibilitado = nulidade DE PLANO
      │      - CURSIVA + caixa "A Rogo" NÃO marcada em pessoa que não pode assinar = nulidade
      │      - DIGITAL + caixa "A Rogo" marcada + duas testemunhas = perícia papiloscópica
      │      - DIGITAL sem rogo regular = pedido de nulidade
      │
      │   c) Declaração de residência (ou outras) em branco com assinatura solta
      │
      │   d) Cronologia anômala dos documentos físicos:
      │      - Comprovante de TED, CPF ou outros documentos emitidos APÓS data da CCB
      │      - Verificação cadastral feita após o contrato = sinal de fraude
      │
      │   e) Campo 14 da CCB vazio em contrato classificado como REFIN
      │      - Banco diz refin mas não declara qual contrato anterior
      │
      │   f) Campos cadastrais da CCB × documentos do autor:
      │      - Estado civil divergente
      │      - Endereço divergente
      │      - E-mail vazio em operação supostamente eletrônica
      │
      │   DIGITAIS:
      │   ─────────
      │   g) CCB × HISCON (impossibilidade temporal):
      │      - Se HISCON registra averbação ANTES da data de assinatura da CCB =
      │        impossibilidade material (não se averba contrato inexistente)
      │
      │   h) Hash idêntico entre contratos digitais:
      │      - Mesmo hash SHA-256 em arquivos de contratos distintos = mesmo PDF reutilizado
      │      - Comum em "Termo de Cadastro" / "Aviso de Privacidade" entre dois contratos
      │
      │   i) Reutilização de selfie entre contratos digitais (via leitura visual):
      │      - Comparar visualmente as selfies extraídas de cada contrato digital
      │      - Mesma roupa, mesmo fundo, mesma expressão = reutilização (não há prova de vida real por contrato)
      │
      │   j) Trilha de auditoria com status "Incompleto" em todos os passos
      │      (incluindo a etapa final "Proposta Paga")
      │
      │   k) SMS de formalização para telefone com DDD diferente da residência do autor
      │
      │   l) Identificação eletrônica (Certisign) por e-mail do próprio banco
      │      (ex.: safra@safra.com.br) — não por e-mail pessoal do consumidor
      │
      │   m) Originador/correspondente bancário em cidade distante da residência
      │
      │   FINANCEIRAS:
      │   ────────────
      │   n) TED para conta divergente (REGRA CRÍTICA HISCRE):
      │      - Capturar o comprovante de TED (DEMTRANSF, COMPTRANS) — se imagem, ler visualmente
      │      - Cruzar banco/agência/conta de DESTINO da TED com o banco do INSS
      │        registrado no HISCRE (Histórico de Créditos do INSS) na competência da TED
      │      - Se a conta da TED for DIFERENTE do banco onde o autor recebia o INSS:
      │          - Confirma fraude (TED para conta de terceiro)
      │          - Argumento devastador
      │      - Se HISCRE não disponível: ALERTAR explicitamente o usuário antes do protocolo
      │
      │   o) Divergência interna na contestação × documentos juntados pelo banco:
      │      - Comparar valores e número de parcelas afirmados no TEXTO da contestação
      │        com os mesmos campos no extrato financeiro / CCB juntada
      │      - Se contraditório: tese específica com tabela comparativa
      │
      │   p) Cessão de crédito não notificada (parcelas marcadas como "Cedida"
      │      no extrato financeiro do banco)
      │      - Tese art. 290 CC (cessão sem notificação ao devedor)
      │
      │   q) Contratos paralelos não impugnados com depósitos em contas divergentes
      │      - Mencionar como possível padrão de fraude maior, a apurar
      │
      ├─ (6) Mapear cada tese arguida pelo banco contra os pilotos do vault
      │        (ver tabela de mapeamento abaixo)
      │        Para teses sem piloto: marcar como "[TESE A SER DESENVOLVIDA]" em amarelo
      │
      ├─ (7) Calcular dano material — somente dos contratos com TED COMPROVADO
      │        (com fls./Num. específicos) pelo banco. Não incluir contratos sem TED na tabela:
      │        - Total descontado até a data
      │        - Total a ser descontado (parcelas restantes × valor)
      │        - Lucro do banco (total - liberado)
      │        - Percentual de lucro sobre o liberado
      │        - VALOR DO TED tirado do COMPROVANTE (não da contestação — banco pode escrever errado)
      │
      ├─ (8) Gerar DOCX combinando os pilotos LITERAIS:
      │        - Substitui slots {{CHAVES}} com dados reais
      │        - Resolve zonas [ZONA DE ADAPTAÇÃO] conforme contexto
      │        - GRIFA EM AMARELO tudo que foi modificado (Camadas 2 e 3)
      │        - Mantém SEM destaque o núcleo doutrinário (Camada 1)
      │        - Estrutura do mérito por contrato:
      │             - Sub-bloco DO CONTRATO FÍSICO (quando houver)
      │             - Sub-bloco DOS CONTRATOS DIGITAIS (quando houver)
      │             - Sub-sub-blocos individuais por contrato digital quando ≥2
      │        - Mapa visual da cadeia contratual quando houver refin/portabilidade/migração
      │        - Tabela inventário hashes SHA-256 quando ≥2 contratos digitais
      │        - Tabela lucro % real só dos contratos com TED comprovado
      │        - Pedidos finais INDIVIDUALIZADOS por contrato (não em bloco):
      │             - Nulidade dos com cursiva fraudulenta
      │             - Julgamento antecipado dos AUSENTES (art. 355 I + 400 CPC)
      │             - Perícia papiloscópica dos a rogo
      │             - Perícia grafotécnica dos físicos com cursiva impugnada
      │             - Perícia digital dos digitais
      │        - Cambria 12pt, citações 11pt itálico recuo 4cm
      │        - Margens 3cm sup./esq., 2cm inf./dir.
      │        - Espaçamento 1,5 linhas, justificado
      │        - ZERO travessão (—) ou hífen (-) como aposto
      │        - Listas com a), b), c) ou i, ii, iii — NUNCA traços
      │
      └─ (9) Salvar como REPLICA_<BANCO>_<NOME-AUTOR>.docx
              na MESMA pasta do PDF

Estrutura padrão da réplica

[CABEÇALHO] — endereçamento simples (2 linhas centralizadas) + processo
[Apresentação enxuta — 1 frase]

>>> [INSERIR MANUALMENTE — Bloco padrão de fraude sistêmica do INSS, com tabela visual da reportagem Metrópoles
     "R$ 466 BILHÕES EM CONSIGNADOS" e investigações PF/CGU. NÃO entra automaticamente.]

SÍNTESE PROCESSUAL (bullets curtos, não parágrafo único)
└── Resumo das teses arguidas pelo banco

PRELIMINARES (na ordem em que o banco arguiu)
├── Pilotos LITERAIS aplicáveis
├── Pilotos novos disponíveis: perda-objeto-contrato-liquidado-refin · litigancia-ma-fe-banco-rebate

>>> [INSERIR MANUALMENTE — Bloco padrão de Lei 14.063/2020 (3 tipos de assinatura eletrônica)]
>>> [INSERIR MANUALMENTE — Bloco padrão de Selfie liveness (11 requisitos NT INSS)]
>>> [INSERIR MANUALMENTE — Bloco padrão de Assinatura inválida (validador ITI)]
>>> [INSERIR MANUALMENTE — Bloco padrão de Modus operandi "kit fraude"]

MÉRITO
├── Da irregularidade da contratação (abertura)
├── DO CONTRATO FÍSICO Nº {{XXX}} (quando houver)
│     - [PLACEHOLDER MANUAL — análise grafotécnica]
│     - Robôs para falsificar (piloto)
│     - Análises específicas detectadas
│
├── DOS CONTRATOS DIGITAIS (quando houver) — seção III.X estruturada
│     [Inserida via `helpers.injetar_pericia_digital(doc, pericia_json)`]
│     │
│     ├── III.X     Abertura: impugnação geral + tabela de identificação
│     │             (número, ADE, data, valor, evento/ID, status)
│     │
│     ├── III.X.1   Da moldura técnica geral [PILOTO FIXO MANUAL — amarelo]
│     │             Lei 14.063/2020 + MP 2.200-2/2001 + Res. CMN 5.057/2022
│     │
│     ├── III.X.2   Da régua biométrica [PILOTO FIXO MANUAL — amarelo,
│     │             apenas se banco invocou selfie/biometria]
│     │             11 requisitos liveness — IN INSS 138/2022, ISO 30107-3,
│     │             IEEE 2790-2020
│     │
│     ├── III.X.3   Da régua de assinatura digital [PILOTO FIXO MANUAL — amarelo,
│     │             apenas se há pretensa assinatura digital]
│     │             Validador ITI — MP 2.200-2 art. 10 §1º
│     │
│     ├── III.X.4   Das inconsistências individuais [SUB-BLOCO POR CONTRATO]
│     │             Para cada contrato digital, sub-bloco com:
│     │             - Tabela de achados aplicáveis (só A–K detectadas, risco
│     │               ALTO/MÉDIO/manual)
│     │             - Parágrafos por achado:
│     │                 * A → inconsistencias-dados-cadastrais
│     │                 * B → assinatura-invalida-validador-iti
│     │                 * C → ausencia-codigo-hash / codigo-hash / kit-fraude (C.3)
│     │                 * D → analise-metadados
│     │                 * E/F → ip-desconhecido / ip-correspondente-bancario
│     │                 * G → inconsistencias-trilha-auditoria /
│     │                       trilha-incompativel-comportamento-humano
│     │                 * H → selfie-liveness (+kit-fraude em H.2,
│     │                       +contratacao-digital-parte-analfabeta em H.4)
│     │                 * I → dados-correspondente-originador /
│     │                       correspondente-maues-manaus (caso AM)
│     │                 * J → inconsistencias-dados-cadastrais
│     │                 * K → ausencia-total-contrato-master
│     │                 * L → compensacao-valores-tese-nova (com calibração L.3 ética)
│     │
│     ├── III.X.5   Da matriz cruzada [APENAS SE ≥2 contratos digitais]
│     │             - Tabela comparativa: IP, sessão, selfie, correspondente,
│     │               horário aceite, hashes SHA-256
│     │             - Padrões sistêmicos detectados
│     │             - Aciona kit-fraude se ≥3 padrões;
│     │               cadeia-custodia-digital-inexistente se 1–2 padrões
│     │
│     ├── III.X.6   Da insuficiência probatória global
│     │             [piloto: insuficiencia-probatoria-prova-unilateral]
│     │             [+ piloto cadeia-custodia-digital-inexistente quando trilha
│     │              em arquivo separado da CCB sem hash de vínculo]
│     │             [+ piloto contratacao-digital-parte-analfabeta se autora
│     │              analfabeta]
│     │             [+ piloto merito-bradesco-logs específico Bradesco com logs]
│     │
│     └── III.X.7   Da utilização de robôs e do imperativo de perícia
│                   [piloto: robos-falsificar-assinatura]
│                   + pedido de perícia digital
│
├── Cadeia de refinanciamentos / migração (quando houver) — seção autônoma
│     [piloto: cadeia-refinanciamentos-fraude-autonoma]
│     [piloto: alegacao-refin-quando-nao-e — quando banco alega refin mas
│      HISCON mostra averbação nova]
├── Mapa visual da cadeia contratual (diagrama, quando houver)
├── Inversão do ônus / Tema 1.061 STJ
├── Compensação de valores (quando houver TED comprovado)
│     - Tabela do modus operandi (genérica)
│     - Tabela do lucro real do banco (só dos contratos com TED comprovado)
├── Ausência de dano material
├── Devolução em dobro
├── Ausência de defeito / Danos morais (QUASE OBRIGATÓRIA)
└── Juros moratórios

REQUERIMENTOS FINAIS — enxutos (5-6 itens, não 10+)
├── Rejeição dos argumentos do banco
├── Inversão do ônus da prova
├── Pedidos individualizados por contrato:
│     - Nulidade absoluta dos com cursiva fraudulenta
│     - Julgamento antecipado dos AUSENTES (art. 355 I + 400 CPC)
│     - Perícia papiloscópica dos a rogo
│     - Perícia grafotécnica dos físicos com cursiva
│     - Perícia digital dos digitais
├── Procedência dos pedidos da inicial (devolução em dobro + danos morais)
├── Eventual depoimento pessoal do preposto
└── Prequestionamento expresso

CIDADE/DATA — usar cidade da FILIAL do escritório que atende, não do juízo
ASSINATURA — apenas o advogado que assinou a INICIAL (NOME COMPLETO + OAB capturados da inicial)

Tabela mestre de mapeamento — teses do banco × pilotos

A skill DEVE consultar e seguir esta tabela.

Pipeline OCR híbrido (proposta C)

A skill usa estratégia híbrida para extrair conteúdo do PDF:

1. Texto principal via pymupdf (rápido) — funciona para PDFs com camada de texto
2. Para PEÇAS CRÍTICAS, leitura visual nativa — eu (Claude) leio a imagem PNG diretamente:
   • Comprovante de TED / DEMTRANSF / COMPTRANS — confirmar conta destino
   • Selfies dos contratos digitais — comparar reutilização
   • Trilha de auditoria — quando em formato de imagem
   • Páginas do contrato físico com assinatura — para classificar tipo
   • Declarações anexas (residência, hipossuficiência) — flagrar campos em branco
   • Prints da CCB — quando texto não extrai (PDF digitalizado)
3. Tesseract opcional — só se um caso específico precisar de OCR em massa de PDF totalmente digitalizado. Não faz parte do pipeline padrão.

Implementação no references/visual_pipeline.py.

Regras inegociáveis

Regra 1 — Grifo amarelo

Grifar em amarelo TUDO que foi modificado/adaptado ao caso:

• Dados específicos preenchidos nos slots Camada 2 (nomes, CPFs, datas, valores, cidades, números de contrato)
• Decisões resolvidas nas zonas Camada 3 (escolha de variantes, adaptações narrativas)
• Inserções factuais específicas do caso

NÃO grifar o núcleo doutrinário fixo da Camada 1 — texto que vem direto do piloto sem alteração.

Regra 2 — Teses sem piloto

Se uma tese arguida pelo banco NÃO tiver piloto correspondente no vault:

1. Criar título da seção com nome da tese arguida
2. Inserir parágrafo em AMARELO com texto: [TESE A SER DESENVOLVIDA — banco arguiu X mas não há piloto pronto. Desenvolver manualmente antes do protocolo.]
3. Deixar 3 linhas em branco para preenchimento manual

NUNCA pular ou fingir que o banco não arguiu.

Regra 3 — TED para conta divergente (HISCRE)

Quando o banco juntar comprovante de TED para conta diferente da declarada na inicial:

1. Antes de argumentar fraude, conferir HISCRE (Histórico de Créditos do INSS) na competência exata da TED.
2. Se a conta do TED coincide com banco de pagamento INSS na época → autora apenas mudou de conta. NÃO usar argumento de fraude.
3. Se NÃO coincide → fraude confirmada. Invocar HISCRE como prova documental.
4. Se HISCRE não disponível na pasta → ALERTAR explicitamente o usuário antes do protocolo.
5. VALOR DO DEPÓSITO sai do TED, não da contestação (banco pode errar na transcrição).
6. COMPENSAÇÃO só dos contratos com TED COMPROVADO (com fls./Num. específicos). Não incluir contratos sem comprovante.

Regra 4 — Padrão visual

• Fonte: Cambria 12pt para corpo
• Citações: Cambria 11pt itálico, recuo 4cm
• Margens: 3cm (sup./esq.), 2cm (inf./dir.)
• Espaçamento: 1,5 linhas, justificado
• Negrito para títulos e termos-chave
• ZERO travessão (—) ou hífen (-) como aposto. Use vírgula ou parênteses.
• Listas: a), b), c) ou i, ii, iii. NUNCA traços.
• Sem numeração contínua de parágrafos — escrever em prosa contínua, com parágrafos separados por linha em branco. NÃO numerar parágrafos como 1., 2., 3.
• Cabeçalho simples (2 linhas centralizadas: vara + processo)
• Apresentação em 1 frase
• Síntese em bullets curtos (sem explicações longas entre parênteses)
• Requerimentos finais com 5-6 itens (não 10+)

Regra 5 — Cidade e advogado da assinatura

• Cidade = cidade da FILIAL do escritório que atende a parte autora (capturar de "endereço onde recebem avisos e intimações" da inicial), não a cidade do juízo
• Advogado = nome completo + OAB do procurador que assinou a inicial. Não usar lista fixa de 3 advogados. Capturar do rodapé da inicial.

Regra 6 — Cuidado com juiz Anderson (Maués/AM)

Em comarcas onde o juiz Anderson atua:

• Evitar peças muito longas e padronizadas
• Variar narrativa factual (não copiar "foi à agência INSS" entre processos consecutivos)
• Encurtar blocos doutrinários quando possível

Regra 7 — Imagens

• Imagens devem ser embutidas no DOCX quando disponíveis (extraídas do PDF ou fornecidas pelo usuário)
• Para casos onde a imagem não pode ser embutida automaticamente, inserir placeholder textual em amarelo: [INSERIR — Imagem 1: Print do validador ITI mostrando assinatura inválida]

Regra 8 — Blocos manuais (NÃO inserir automaticamente)

Os seguintes blocos são padrão do escritório e o usuário insere MANUALMENTE depois:

• Bloco introdutório de fraude sistêmica do INSS (com tabela visual da Metrópoles "R$ 466 bilhões")
• Lei 14.063/2020 (3 tipos de assinatura eletrônica)
• Selfie liveness (11 requisitos NT INSS)
• Assinatura inválida (validador ITI)
• Modus operandi "kit fraude"

A skill apenas marca a posição com [INSERIR MANUALMENTE — bloco padrão X] em amarelo.

Regra 9 — Análise grafotécnica é manual

A análise grafotécnica conclusiva é decisão humana. A skill apenas insere placeholder em cada contrato físico:

[ANÁLISE GRAFOTÉCNICA — PREENCHER MANUALMENTE NO CHAT
Comparar visualmente:
- Assinatura na CCB do contrato {{NUMERO}} (Evento {{X}}, fl. {{Y}})
- Assinatura padrão na Procuração (Evento {{X}}, doc {{Y}})
- Assinatura padrão no RG/CNH (Evento {{X}}, doc {{Y}})
Apontar: traçado, fluidez, pressão, fragmentação, similitudes/divergências.
Indicar se há indício de decalque (preto-e-branco, ausência de variação de pressão).]

Regra 10 — Decisão editorial é humana

A skill insere TODOS os pilotos aplicáveis ao que o banco arguiu. A decisão de cortar/integrar pilotos redundantes é EDITORIAL HUMANA, feita pelo usuário no Word após a entrega. A skill nunca corta nem decide o que é "supérfluo".

Regra 12 — L.3 ético: TED para conta diversa da do INSS (CALIBRAÇÃO OBRIGATÓRIA)

Quando o pipeline de perícia detecta verificação L.3 (TED depositado em conta diversa daquela em que a autora recebia o INSS na época, conforme HISCRE), aplicar rigorosamente a tese calibrada:

PROIBIDO afirmar ou pedir, sob qualquer circunstância:

• ❌ "Conta de terceiro" / "fraude para terceiro"
• ❌ "A autora não recebeu os valores"
• ❌ Pedido de intimação da autora para esclarecer titularidade

Why: se o advogado afirma que a autora não recebeu os valores ou pede intimação dela, e a autora possuir efetivamente conta no banco destino (que ela mesma pode não ter declarado na inicial), o cliente pode levar má-fé processual. O risco recai sobre o cliente, não sobre o banco.

PERMITIDO (limite seguro — texto que entra na réplica):

1. Mencionar a divergência factual: "TED foi para conta <X>, conta diversa daquela em que a autora recebia INSS na época, conforme HISCRE em todas as competências relevantes"
2. (Opcional, no máximo) Acrescentar que a autora "não percebeu o referido depósito" dentre os múltiplos lançamentos do extrato
3. Acionar a tese da compensacao-valores-tese-nova: o depósito não é prova de contratação, mas elemento da própria fraude; em eventual procedência, autoriza-se a compensação dos valores efetivamente creditados para evitar enriquecimento ilícito

Pedido associado correto: procedência + compensação dos valores efetivamente creditados — NUNCA intimação da autora.

A função helpers.add_subbloco_contrato_digital() já injeta o texto calibrado quando o JSON traz variante: "L.3". O campo texto_calibrado_etico no JSON serve de lembrete reforçado para revisão.

Regra 11 — Petição apartada de litigância predatória do Banco PAN

Em alguns processos, o Banco PAN apresenta, ALÉM da contestação, uma petição apartada alegando litigância predatória (em geral subscrita pelo escritório Lima e Feigelson Advogados — pan.civel@limafeigelson.com.br). Essa petição costuma vir como movimentação separada e foca em ataques ao patrono/cliente (Recomendação 159 CNJ, fracionamento, contumácia, etc.).

A skill IGNORA essa petição apartada. Não rebater nesta réplica:

• A peça gerada pela skill responde EXCLUSIVAMENTE à contestação propriamente dita do PAN.
• A defesa contra a petição apartada de litigância predatória, se necessária, é peça AUTÔNOMA, redigida manualmente pelo usuário em momento próprio (geralmente em manifestação específica após o juízo abrir vista).
• Caso a contestação propriamente dita já invoque, dentro de seu próprio corpo, o argumento de litigância de má-fé contra a parte autora (art. 80 CPC), ESSE rebate vai na réplica usando o piloto litigancia-ma-fe-banco-rebate. A regra acima vale apenas para a peça APARTADA de "litigância predatória".

Regra 13 — Banco NÃO juntou contrato (cenário CCB-ausente, art. 400 + art. 434 CPC)

Quando o banco apresenta contestação SEM juntar o instrumento contratual impugnado (CCB, ficha cadastral, "laudo digital", trilha de auditoria), juntando apenas telas genéricas da plataforma de contratação, manuais de política de privacidade, normas técnicas (ISO 19794-5), prints de canais de atendimento etc., a skill DEVE acionar automaticamente o seguinte conjunto de teses:

Detecção (heurística obrigatória do analisador):

1. Contestação afirma "validade do contrato digital" / "biometria facial" / "assinatura eletrônica" / "selfie + IP + geolocalização" MAS;
2. Não há, anexada à contestação, CCB com dados do cliente (nome, CPF, valor, parcelas, conta) NEM trilha de auditoria com IDs de sessão/device/IP nominais ao caso concreto NEM imagem da selfie nominativa.
3. Os anexos do banco se resumem a: telas-padrão da plataforma + descrições genéricas + comprovante de TED (no máximo).

Quando detectar, inserir OBRIGATORIAMENTE:

• Em PRELIMINARES: [[processuais-especiais/preclusao-contrato-documentos]] (art. 434 CPC) — rebate antecipado a eventual juntada extemporânea.
• Em PRELIMINARES (se o banco arguiu interesse processual, tutela ou pacta sunt servanda): seções 1, 2 e 4 do [[processuais-especiais/ausencia-total-contrato-master]].
• Em MÉRITO — primeiro bloco "Da irregularidade da contratação": texto-padrão derivado do master (Seção 5 — presunção de veracidade do art. 400 CPC), com adaptação obrigatória listando, em letras a) b) c) d), os documentos que o banco efetivamente juntou, demonstrando a insuficiência de cada um. Padrão típico:
  • "(a) descrição genérica da plataforma de contratação digital do [BANCO], sem indicação de quaisquer documentos específicos;
  • (b) prints de telas de 'Política de Contratação por biometria facial' e 'Política de Privacidade';
  • (c) print do procedimento de captura de selfie segundo norma ISO 19794-5:2011;
  • (d) afirmações genéricas sobre 'laudo digital' que conteria nome do usuário, IP, ID da sessão e geolocalização — todavia, sem juntada do laudo em si nos autos;
  • (e) print de tela 'RESULTADO DE PESQUISA EM SISTEMA INTERNO';
  • (f) prints de canais de atendimento."

O que NÃO fazer neste cenário:

• ❌ NÃO injetar a seção III.X de perícia digital (não há contrato para periciar)
• ❌ NÃO acionar pilotos merito-probatorio-digital/* (selfie-liveness, hash, ITI, IP, metadados, etc.) — sem objeto de prova, esses pilotos perdem força
• ❌ NÃO listar verificações A–L como achados periciais (não há documentação para verificar)
• ❌ NÃO incluir tabela de identificação de contratos digitais (III.X)

O que pode permanecer:

• Tese de robos-falsificar-assinatura (genérica, não depende do contrato)
• inversao-onus-prova-tema-1061 (rebate específico)
• boa-fe-objetiva (rebate venire/supressio quando arguidos)
• Cálculo de lucro do banco (apenas se houver TED comprovado nos autos)

Caso paradigma: Domingos × PAN (Teste 6, 2026-05-04, 1ª Vara Federal de Lages/SC). O banco PAN contestou afirmando contratação digital regular mas não juntou nenhum contrato — apenas telas genéricas da plataforma. A versão protocolada pela equipe usou exatamente este conjunto: preclusão (art. 434), presunção (art. 400) com lista a)-(f) dos anexos genéricos, irregularidade da contratação focada na ausência de assinatura, sem qualquer seção de perícia digital. Estrutura final enxuta: 5 preliminares + 8 sub-blocos de mérito + 5 requerimentos.

Regra 14 — Glossário canônico dos slots de gênero (preenchimento dos DADOS_CASO)

A skill usa duas famílias de slots para gênero da parte autora, com significados distintos que NÃO podem ser confundidos. Erro de preenchimento gera frases gramaticalmente quebradas no DOCX final.

Slot de SUJEITO COMPLETO (substantivo + artigo, usado como sujeito da oração):

Slot de FLEXÃO ISOLADA (apenas o artigo ou letra de flexão, agregado a outro substantivo):

Slot de GENITIVO (do autor/da autora — apesar do nome enganoso ter "DATIVO"):

⚠️ Atenção: nomes enganosos. Os slots a seguir começam com _DATIVO mas são GENITIVOS nos pilotos do vault. A tabela abaixo dá o preenchimento que efetivamente funciona em todos os contextos atuais (validado contra os pilotos ausencia-defeito, compensacao-valores-tese-nova, litigancia-ma-fe-banco-rebate etc.).

Erro comum (já cometido em produção): preencher PARTE_AUTORA_GENERO com apenas "o" ou "a". Isso gera frases como:

• "Em síntese, é o réu quem se apresenta com prova frágil [...] não o." (faltou o substantivo)
• "O é pessoa de poucos recursos financeiros." (idem)
• "O afirma que jamais contratou." (idem)

Régua imediata de revisão: após gerar o DOCX, fazer Ctrl+F por " o.", " a.", " o,", " a," e verificar se há ocorrências em final de frase ou seguidas de pontuação. Se houver, slot foi mal preenchido.

Configuração canônica para autor MASCULINO:

DADOS_CASO = {
    # SUJEITOS COMPLETOS
    "PARTE_AUTORA": "parte autora",
    "PARTE_AUTORA_GENERO": "o autor",
    "PARTE_AUTORA_NOMINATIVO": "o autor",
    "PARTE_AUTORA_OBJETO": "o autor",
    "PARTE_AUTORA_GENERO_CONSUMIDOR": "o consumidor",
    "PARTE_AUTORA_GENERO_CONSUMIDORA": "o consumidor",
    "AUTOR_GENERO": "o autor",
    "AUTOR_GENERO_CONSUMIDORA": "o consumidor",
    # FLEXÕES ISOLADAS (artigo / sufixo)
    "PARTE_AUTORA_GENERO_MIN": "o",
    "PARTE_AUTORA_GENERO_O_A": "o",
    "GENERO_FLEXAO_O_A": "o",
    "GENERO_FLEXAO": "",            # vazio: "vencedor" sem 'a'
    "GENERO_FLEXAO_VAZIO_A": "",    # idem
    # GENITIVOS (apesar do nome conter "DATIVO")
    "PARTE_AUTORA_DATIVO": "do autor",
    "PARTE_AUTORA_DATIVO_AUTOR": "do autor",
    "PARTE_AUTORA_DATIVO_DEMANDANTE": "do demandante",
    "PARTE_AUTORA_AUTORIZACAO": "do autor",
    # DATIVOS DE VERDADE
    "PARTE_AUTORA_DATIVO_CONSUMIDOR": "ao consumidor",
}

Configuração canônica para autora FEMININA: trocar todos os "o autor" por "a autora", "ao" por "à", e "" por "a" nas flexões.

A documentação completa dos slots vive em regras-de-adaptacao.md no vault, seção "Slots universais → Gênero da parte autora".

Regra 15 — TODAS as strings literais que vão para o DOCX devem ter acentuação plena em português

Erro recorrente já cometido em produção (Teste 7, 8 e 10): ao escrever os textos literais nos scripts de redação (cabeçalho, síntese processual, blocos custom, requerimentos finais, parágrafos de bridge entre pilotos), tendi a digitar SEM acento por reflexo de digitação no terminal — gerando frases como "ja qualificada nos autos da acao em epigrafe", "a regular tramitacao do feito", "em razoes que nao se sustentam". Isso quebra a leitura técnica da peça e fica visualmente inaceitável no protocolo.

Regra obrigatória:

1. Toda string literal Python que será inserida no DOCX deve usar acentuação plena, incluindo:
   • cabeçalhos (EXCELENTÍSSIMO, não EXCELENTISSIMO)
   • apresentação (já qualificada nos autos da ação em epígrafe)
   • síntese processual em bullets
   • blocos custom de mérito e

…(truncated)