docs(inquiries): a inquiry-0037 versiona o laudo do Multipag Pix e o arquivo que o banco aprovou

[lekadecastro]

Formaliza no repositório a evidência primária da frente Pix. Só documentação e anexos — nenhum byte de código.

O problema que resolve

Até hoje o .REM aprovado e o relatório do Validador existiam só na pasta de Downloads da P.O. As issues #923, #945, #948 e #980 os citavam pelo nome e nada os guardava. Perder aquela pasta apagaria a base de diff do Pix e a prova dos falsos positivos.

O que entra

arquivo	o que é
assets/0037/TESTE_PIX_BLOQUEADO_CNAB240_REV2.REM	o arquivo que o Bradesco validou em 05/09/2026. Primeira base de diff que existe para Pix, no papel que o PAG-GOLDEN_TESTE_AJUSTADO.REM cumpre para as outras formas (inquiry-0033). Dados fictícios, conferidos.
assets/0037/validador-universal-relatorio-02092026.pdf	vale como prova dos 17 falsos positivos, não como laudo.
0037-laudo-multipag-pix-e-validador-cego.md	a inquiry, no molde da 0033

O registro substantivo

Os 6 pontos confirmados (45 · 009 · G100=04 · ISPB 00000000 · movimento 0 + instrução 09 · bloco bancário zerado) e a descoberta que vale mais que eles:

O Validador Universal não aplica o layout Pix. O portal do Bradesco lista Pix como layout separado de Multipag, e o resumo do lote imprime 45-Modalidade não localizada. 17 dos 21 achados são falsos positivos, refutados um a um — a triagem está tabelada na inquiry.

Isso inverte a hierarquia da skill cnab240-bradesco para a modalidade: em launchForm 45 o validador é fonte inválida (#980). O risco não é hipotético — a nota de CLEARING_PIX já existia porque o 009 "parece errado" para quem lê o manual.

Ficam registrados também:

• o enquadramento das duas etapas do pré-voo — TED/transferência/boleto validados em produção pelo cliente, Pix em construção e em remessa separada —, com a regra de trabalho que a P.O. fixou: mudança da frente Pix não altera o arquivo das outras três, e byte-identidade para dado numérico se demonstra, não se presume;
• a premissa de negócio: a chave Pix tem de corresponder à inscrição do título, cobrada pelo banco via PF/PG — que hoje voltam como unknown ([financial] a régua de rejeição do retorno ignora 28 códigos do G059 — Pix recusado volta como desfecho desconhecido #984);
• os 4 achados que NÃO são falsos positivos (DVs do cedente) marcados como não validados, dado fictício, para que ninguém os cite como evidência a favor ou contra [financial] dígito verificador da conta do cedente nunca é conferido — o banco recusa toda remessa daquela conta #816/[financial] header CNAB: 3 campos do cedente seguem hardcoded (documentType, agencyDigit, accountAgencyDigit) — bankName já saiu #856.

Detalhes de gate

⚠️ Os assets vão em assets/0037/, não em 0037-assets/: handbook-numbering.test.ts lê o prefixo ^\d{4}- no topo do diretório, e uma pasta 0037-assets colidiria com a própria inquiry. INDEX.md e PERGUNTAS-EM-ABERTO.md foram regenerados por scripts/handbook/inquiry-index.ts — são derivados e inquiry-hygiene.test.ts os cobra.

Feito em worktree separado, a partir de origin/dev, para não interferir na árvore de trabalho compartilhada onde a frente Pix está em andamento.

Gate: 11672 testes, 0 falhas.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NJKkFN7sQDoBS8AvteK1kZ