feat(arquitetura): adrs do data lakehouse e skill de verificação

[LuizaMaluf]

Descrição

Registra a arquitetura de dados de produção do MinC, aprovada em outubro de 2026, em três níveis: a narrativa no README, a decisão em dois ADRs e uma skill que verifica se o código segue a decisão.

README. Nova seção Arquitetura de dados com os dois desenhos aprovados (docs/arquitetura/), componentes, fluxo, camadas, nomenclatura e pontos em aberto. O ambiente local continua em PostgreSQL, e a seção avisa isso no início.

ADR 0009 fixa a arquitetura de produção: Airflow só extrai e grava no raw do MinIO, o raw é imutável, Trino carrega a Bronze e executa o dbt, todo consumo passa pelo Trino, e o Ranger anonimiza na consulta. Registra o que foi descartado (DW no Postgres, lake só de arquivos, anonimização em repouso, acesso direto ao MinIO, staging) e a consequência maior para o código de hoje: as DAGs de API gravam direto no Postgres e, em produção, precisam gravar no raw.

ADR 0010 fixa as cinco camadas (Raw, Bronze, Silver, Intermediate, Gold) com o que cada uma faz e não faz, e a organização do projeto dbt: uma pasta por fonte com arquivos planos bronze_<entidade>.sql e silver_<entidade>.sql, pasta intermediate/ para o cruzamento entre fontes, e uma pasta por produto de dados para a Gold, sem prefixo e com convenção de nome do próprio produto. O arquivo tem o nome da tabela; a fonte fica na pasta e no schema, sem alias. Substitui o "medalhão por domínio" de cotas_dbt e agentes_dbt e traz a tabela do que cada pasta de hoje vira. Nenhum dos 712 modelos atuais segue a nomenclatura; a migração é incremental e a regra é que o número de modelos fora do padrão não sobe.

Skill arquitetura-lakehouse-minc (.claude/skills/, versionada como as demais). Dois modos: verificar, que roda scripts/verificar.py e narra só o que o script apurou (princípio do ADR 0004); e codar ou migrar, com a tabela de decisão de camada pelo que o modelo faz e a receita de migração com os cinco leitores da convenção de pastas que ficam para trás em silêncio (governança do SALIC, coletor do site, recipes do OpenMetadata, geradores, macro de schema). O script é offline, sem banco nem dbt run, e por padrão confere só os arquivos mudados em relação à main; com --tudo dá o inventário e um destino sugerido por arquivo. CLAUDE.md e o guia de skills passam a apontar para o ADR 0010 e para a skill.

Issue relacionada

Sem issue.

Tipo de mudança

• Ingestão — cliente de API, DAG, carga
• Modelo dbt — transformação, camada, teste
• Correção de bug ou de inconsistência de dados
• Infra / CI
• Documentação
• Outro: skill versionada com script de verificação

Impacto em dados

Nenhum. O PR não toca DAG nem modelo dbt; só documentação, ADRs e a skill. O inventário do verificar.py --tudo sobre a main de hoje é a linha de base da migração que os ADRs abrem:

Regra	Violações
R1 pasta e nome	712 de 712 modelos
R3 silver lendo source()	59 (mapas_dbt/silver, sem modelo bronze)
R7 +schema diferente da pasta	4 (agentes_dbt, cotas_dbt, mapas_dbt, salic_dbt)

Como testar

# inventário inteiro (esperado: 775 violações, 0 avisos, saída 1)
python3 .claude/skills/arquitetura-lakehouse-minc/scripts/verificar.py --tudo

# só o que mudou em relação à main local (neste PR: nenhum .sql, saída 0)
python3 .claude/skills/arquitetura-lakehouse-minc/scripts/verificar.py

# um recorte
python3 .claude/skills/arquitetura-lakehouse-minc/scripts/verificar.py dbt/minc/models/mapas_dbt

[Arthrok]

lgtm