[databug] br_me_cnpj.socios: coluna documento truncada para 8 dígitos no snapshot 2026-08-09

### Tabela afetada

`br_me_cnpj.socios`

### Descrição do problema nos dados

No snapshot **`2026-08-09`**, a coluna `documento` dos **sócios pessoa jurídica** (`tipo = 1`) passou a conter apenas os **8 primeiros dígitos** do CNPJ (a raiz), em vez do CNPJ completo de 14 dígitos. Nos 54 snapshots anteriores (`2021-11-23` a `2026-07-12`) o valor sempre teve 14 dígitos — a mudança é abrupta e atinge 100% das linhas PJ de uma vez.

- **Período afetado:** apenas o snapshot `2026-08-09` (o mais recente).
- **Linhas afetadas:** **725.455** — todas as linhas de sócio PJ do snapshot, contra 717.651 com 14 dígitos no snapshot anterior. Nenhuma linha ficou com 14 dígitos no snapshot novo.
- **Valor esperado:** `05888349000125` (14 dígitos) — **observado:** `05888349` (8 dígitos).
- Sócios pessoa física **não** foram afetados: seguem no formato mascarado `***XXXXXX**`.

A mudança também contraria a descrição da própria coluna no schema publicado, que diz *"Documento (CPF mascarado ou CNPJ)"* — e não "raiz do CNPJ".

**Confirmamos que a origem não é a Receita Federal.** Baixamos o arquivo bruto do release `2026-07` da RFB (que alimenta esse snapshot): em uma amostra de **1.014.423 linhas**, as **15.249** linhas de sócio PJ têm `CNPJ_CPF_DO_SOCIO` com **14 dígitos** — 100%, zero exceções. O layout é idêntico ao do release `2026-06`: mesmas 11 colunas, mesma ordem. A truncagem parece ter sido introduzida no processamento.

#### Por que isso quebra usos legítimos da tabela

1. **Join com `empresas` / `estabelecimentos` pelo CNPJ completo** deixa de funcionar para sócios PJ — e falha em silêncio, retornando zero linhas em vez de erro.
2. **Séries temporais perdem a identidade do sócio.** Quem compara snapshots consecutivos para reconstruir histórico societário vê uma "saída" em massa de sócios PJ em `2026-08-09` seguida de uma "entrada" em massa dos mesmos sócios — eventos que nunca aconteceram.

O segundo caso é o nosso: trabalhamos com dados de processos trabalhistas, e a data de saída de um sócio define a janela de responsabilidade do sócio retirante (art. 10-A da CLT). No nosso recorte de ~5.500 CNPJs, a truncagem gerou **1.068 saídas falsas em 212 empresas**. Sem conferir a origem, teríamos afirmado que pessoas e empresas identificadas deixaram sociedades das quais nunca saíram.

Vale registrar que **validação por contagem de linhas não pega isso**: no nosso recorte o total ficou praticamente igual (10.182 → 10.174) enquanto ~10% das identidades mudaram.

### Evidência

```sql
-- 1) histograma do tamanho de `documento` para sócios PJ nos dois últimos snapshots
SELECT data, LENGTH(documento) AS tamanho, COUNT(*) AS linhas
FROM `basedosdados.br_me_cnpj.socios`
WHERE data IN (DATE '2026-07-12', DATE '2026-08-09')
AND REGEXP_CONTAINS(documento, r'^[0-9]')
GROUP BY 1, 2
ORDER BY 1, 2;
```

Resultado:

| data | tamanho | linhas |
|---|---:|---:|
| 2026-07-12 | 14 | 717.651 |
| **2026-08-09** | **8** | **725.455** |

```sql
-- 2) caso concreto: mesmos sócios, mesma empresa, dois snapshots
SELECT data, nome, documento
FROM `basedosdados.br_me_cnpj.socios`
WHERE cnpj_basico = '43351097'
AND data IN (DATE '2026-07-12', DATE '2026-08-09')
ORDER BY data, nome;
```

Resultado:

| data | nome | documento |
|---|---|---|
| 2026-07-12 | LEVI STRAUSS INTERNATIONAL | `05888349000125` |
| **2026-08-09** | LEVI STRAUSS INTERNATIONAL | **`05888349`** |
| 2026-07-12 | LEVI STRAUSS & CO. | `05721184000100` |
| **2026-08-09** | LEVI STRAUSS & CO. | **`05721184`** |

Comparação com a fonte original (release `2026-07` da RFB, arquivo `Socios1.zip`, entrada `K3241.K03200Y1.D60711.SOCIOCSV`):

| origem | linhas PJ | `documento` com 14 dígitos | com 8 dígitos |
|---|---:|---:|---:|
| RFB `2026-07` (bruto, amostra de 1.014.423 linhas) | 15.249 | **15.249 (100%)** | 0 |
| RFB `2026-06` (bruto, amostra de 1.013.849 linhas) | 14.995 | **14.995 (100%)** | 0 |
| BD `2026-07-12` (tabela inteira) | 717.651 | **717.651 (100%)** | 0 |
| BD `2026-08-09` (tabela inteira) | 725.455 | **0** | **725.455 (100%)** |

Ou seja: o release da RFB que alimenta o snapshot `2026-08-09` tem CNPJ completo em 100% das linhas conferidas, e o snapshot publicado tem 0%.

### Referências

- Fonte original: https://arquivos.receitafederal.gov.br/index.php/s/YggdBLfdninEJX9 → `2026-07/Socios1.zip`
- Layout oficial: https://www.gov.br/receitafederal/dados/cnpj-metadados.pdf
- Descrição da coluna no schema publicado: `documento` — *"Documento (CPF mascarado ou CNPJ)"*

### Sugestões

1. **Reprocessar o snapshot `2026-08-09`** a partir do release `2026-07` da RFB, restaurando o CNPJ completo em `documento`.
2. Se a truncagem foi **intencional** (por exemplo, para padronizar com `cnpj_basico`), que seja documentada e entregue em uma **coluna nova** — mudar o conteúdo de uma coluna existente sem aviso quebra silenciosamente quem já depende dela.
3. Teste de regressão no pipeline: assertar o formato de `documento` por snapshot (`^\*{3}\d{6}\*{2}$` para PF, `^\d{14}$` para PJ). Teria pego isso antes da publicação.

Ficamos à disposição para validar a correção — temos o recorte e as consultas prontas. Obrigado pelo trabalho de vocês; o `br_me_cnpj` é peça central da nossa infraestrutura.

Start by tracing the pipeline entry point that produces br_me_cnpj.socios from the RFB 2026-07 Socios1.zip release, then compare processing for snapshots 2026-07-12 and 2026-08-09. Reprocess the affected snapshot with complete PJ documents and add the suggested format regression checks for PF and PJ rows.

Written by the indexing model from the issue text.