Evidências de Produção — Barramento Confluent Kafka e Ambiente Best2Bee

Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa Fonte: Três relatórios técnicos exportados do Confluent Control Center / Kafka Connect em produção, gerados em 09/07/2026 — topicos_detalhado_latest.md, conectores_detalhado_latest.md, ksqldb_prd_latest.md — e um diagrama de arquitetura, ambientes-barramento-integracao-confluent.png, anexos fornecidos diretamente pelo cliente. Atualizado em 28/08/2026 com uma nova extração de tópicos gerada pela própria Energisa em 25/08/2026 rodando o script de extração fornecido pela consultoria — relatorio_prd_20260825_165932.csv (835 tópicos, mesmo formato) — ver Seção A.8 · Atualizado novamente em 02/09/2026 com nova extração de conectores — kafka_connect_report_20260902_081508.json (102 conectores) — e com as queries ksqlDB em texto completo, sem truncamento — ksqldb_report_20260902_081400.json (265 queries) — ambos fornecidos pela Energisa. Ver Seção A.11 · Atualizado novamente em 03/09/2026 com o export completo do Schema Registry — schema_registry_report_20260902_154604.json (1.768 subjects, gerado pela Energisa em 02/09/2026, entregue em 03/09/2026). Ver Seção A.12 Status: Rascunho para consolidação — primeira leitura auditável de dados reais de produção do barramento, cruzada com achados já registrados nas Atas 04, 09, 10 e 12 Elaborado por: Syntropy Labs

Por que este artefato existe

Até aqui, boa parte dos números sobre o barramento (cores, tópicos, conectores, cobertura de schema) vinha citada de memória em sessão, com hedge explícito de "a confirmar por inventário" (Ata 10, Anexo B). Os quatro anexos analisados aqui são a primeira evidência documental real — extração direta do Confluent Control Center e do Kafka Connect em produção, não relato verbal. Isso permite fechar parte das evidências pendentes [E1] e [E2], quantificar achados que hoje só existiam como observação qualitativa (D5, D9), e levanta achados novos que nenhuma sessão havia registrado.

Regra de leitura: os relatórios e o diagrama já estão versionados neste repositório (ver links acima, commitados em PR separado para não sobrecarregar a revisão deste artefato com ~290KB de dados brutos). Os números abaixo continuam citados a partir da leitura desses arquivos.

---

A. Achados do inventário real de produção (Kafka Connect + Confluent Control Center)

A.1 · Cobertura de Schema Registry por domínio — quantifica R28/D5

Visão geral: 732 de 930 tópicos (78,7%) têm schema associado. Mas a distribuição por domínio é desigual, e a lacuna não está espalhada — está concentrada:

Domínio	Tópicos	Com schema	Sem schema
WFM (wfm_*)	40	0 (0%)	40 (100%)
CRM (crm_*)	14	3 (21%)*	11 (79%)
CDC Stream / Oracle Stream / JDBC Stream	22+31+25	maioria	minoria

*Os 3 tópicos CRM com schema são derivados internos do ksqlDB (*_pab_key_v1), não os tópicos de origem publicados pela aplicação.

Atualização (28/08/2026, ver Seção A.8): na extração de 25/08/2026, cobertura geral sobe para 82,9% (692/835). WFM permanece em 0%. CRM cai de 21% (3/14) para 0% (0/10) — os 3 tópicos com schema que existiam em 09/07 não aparecem mais no inventário de 25/08. Não presumir que é regressão de qualidade: os candidatos mais prováveis são exclusão/expiração dos 4 tópicos CRM que saíram do inventário (14→10) ou reclassificação de domínio — nenhum dos dois confirmado. Tratar como pergunta a levantar com a equipe de barramento, não como piora silenciosamente aceita.

Atualização (03/09/2026, ver Seção A.12): o export completo do Schema Registry (1.768 subjects) mostra schema_id distinto por empresa nas duas tabelas piloto DESPACHO_OS e OS_DIGITACAO — a essa altura, um resultado que parece confirmar "divergência de esquemas entre empresas do grupo" (a própria redação de R28). Não confirma. Comparando o conteúdo real das colunas (via ddl_completo do ksqlDB, Seção A.11/A.12), as 9 empresas têm exatamente a mesma estrutura em ambas as tabelas — schema_id diferente aqui não quer dizer schema diferente, é uma peculiaridade deste Schema Registry (não reaproveita ID entre subjects mesmo com conteúdo idêntico). Para estas duas tabelas, R28 não se confirma; a divergência de schema entre empresas continua sendo um achado qualitativo geral (Ata 04), não quantificado por este export. Detalhe completo na Seção A.12.

Isso dá número concreto ao achado qualitativo de R28 ("Schema Registry com adoção parcial e divergência de esquemas entre empresas do grupo") e mostra que a exceção não é pontual: é o domínio inteiro de WFM e a quase totalidade de CRM — exatamente os dois domínios que originam o fluxo de atendimento/incidente discutido na Ata 09 (D3).

A.2 · Explosão multiempresa quantificada — reforça achado da Ata 04/topologia-confluent-kafka-multiempresa

A categoria "Outros" do relatório de tópicos soma 791 tópicos (85% do total de 930) — quase todos a mesma dúzia de tabelas (ORDEM_SERVICO, EQUIPE, DESPACHO_OS, CLIENTE etc.) replicadas por sufixo de empresa via XStream (com_spr, com_toc, com_ron, com_ser, sgm_mts, sgm_mtn, sgm_ron, sgm_pab, sgm_mgr, sgm_spr, sgm_ser, sgm_toc, sgm_acr, igs_*, sgd_*, itg_crp). Isso torna visível, em escala real, o padrão já discutido na Ata 04 sobre consolidação multiempresa via ksqlDB — e dá um número concreto para a comparação KSQLDB vs. Flink vs. microsserviço vs. pré-consolidação no banco que a própria Ata 04 pede como ação de 30–90 dias.

Atualização (28/08/2026, ver Seção A.8): a extração de 25/08/2026 separa esta categoria de forma mais limpa — o equivalente direto (domínio "Oracle XStream", tópicos oracle_source_xst_*) cai para 652 tópicos, e uma nova categoria residual "Outros" (79 tópicos: connect-configs, connect-offsets, connect-status, audit log e alguns *.CONTROLE_CONECTOR_BARIT) aparece separada — algo que o relatório de 09/07 não distinguia explicitamente. Olhando só pelo padrão de nome regional (oracle_source_xst_<sistema>_<região>.<tabela>), o fan-out cai de 621/930 (~67%) para 587/835 (~70,3%) — proporção estável, contagem absoluta menor.

A.3 · Concentração de captura em task única — achado novo, relevante para R05/D9

Os 75 conectores detalhados no relatório (38 JDBC + 34 Debezium/XStream + 3 SQL Server) rodam, sem exceção, com Tasks: 1. O caso mais extremo observado é oracle-source-xst-com-mgr, que captura 47 tabelas por uma única task; há pelo menos 3 outros conectores com 45–47 tabelas na mesma condição.

Isso é evidência de infraestrutura para dois achados já registrados na Ata 12/D9, até agora sem explicação de causa raiz: - "Leitura sequencial por número de mudança faz tabelas analíticas reterem o avanço de tabelas críticas" — se a tabela lenta e a tabela crítica dividem a mesma task de um conector, uma bloqueia a outra por construção, não por acidente. - O atraso de 10–30 minutos em tabelas de alto volume (R05) — task única por conector é um teto arquitetural de paralelismo que limita vazão, independente de tuning.

Recomenda-se levar isso para [E2] como resposta parcial de causa raiz (a medição de vazão por etapa que a evidência pede continua pendente, mas a arquitetura que explica o gargalo já está confirmada).

Atualizado em 02/09/2026 (ver Seção A.11): a re-extração de conectores confirma e amplia este achado — agora são 102 conectores (os 75 originais mais 24 sinks JDBC e 3 SQL Server novos, não capturados no relatório de 09/07/2026), todos, sem exceção, ainda com Tasks: 1.

A.4 · Tópicos com réplica única — achado novo, severidade mista

O relatório aponta 16 tópicos com apenas 1 réplica em produção (contra o mínimo de 3 recomendado pela própria nota de boas práticas do relatório). A maioria é de baixa criticidade — derivados ksqlDB (*_pab_key_v1, TB_*_PAB_V1) e tópicos WFM de baixo volume (coordenadas, escalas). Um deles, porém, é _confluent-ksql-barramento-confluent.ksqldb__command_topic — o tópico interno de comando do próprio cluster ksqlDB, que guarda o estado das 263 queries persistentes em produção. Réplica única nesse tópico específico é ponto único de falha para a recuperação de todo o processamento ksqlDB — risco distinto de R02 (que cobre o barramento de eventos de negócio, não a própria plataforma de streaming).

A.5 · Inconsistência no próprio relatório — nota metodológica

O resumo executivo do relatório de conectores declara 81 conectores, mas a soma das três categorias detalhadas (JDBC 38 + Debezium 34 + SQL Server 3) fecha em 75, e a soma de tabelas por conector individual bate exatamente com o "543" do resumo. Ou seja, o total de tabelas reconcilia, mas o total de conectores no cabeçalho, não — uma divergência de 6 conectores não explicada pelo detalhamento disponível. Registrar como pendência de esclarecimento antes de citar "81 conectores" em qualquer entregável ao cliente.

Superada pela re-extração de 02/09/2026 (Seção A.11). O novo relatório (kafka_connect_report_20260902_081508.json) declara total_conectores_api: 102 e total_processado: 102, com divergencia_detectada: false — sem a inconsistência de cabeçalho observada em 09/07/2026. Isso não confirma qual das duas contagens antigas (81 ou 75) estava correta: o ambiente mudou entre as duas extrações (24 sinks novos, SQL Server dobrou de 3 para 6 — ver A.11), então os números de 09/07 e 02/09 não são diretamente comparáveis. A divergência original fica registrada como nota histórica; para qualquer entregável ao cliente a partir de agora, usar 102 (02/09/2026).

A.6 · Saúde operacional — dado novo, sem achado de risco associado

74 conectores RUNNING, 1 PAUSED (oracle-source-jdbc-itg-mts.igdems), 0 FAILED. Não constitui achado, mas é linha de base que não existia antes e serve de referência para contrastar com qualquer instabilidade relatada em sessão futura.

Atualizado em 02/09/2026: 101 RUNNING, 1 PAUSED (o mesmo conector, oracle-source-jdbc-itg-mts.igdems — pausado nas duas extrações, com quase 8 semanas de intervalo entre elas), 0 FAILED, agora sobre uma base de 102 conectores (ver A.11).

A.7 · Arquitetura ksqlDB é 100% stream, sem tables materializadas

O relatório ksqlDB mostra 322 streams, 0 tables ("Nenhuma table encontrada"), 263 queries persistentes, todas RUNNING, 98% delas em formato AVRO. É um dado relevante para a decisão pendente ksqlDB→Flink da Ata 04: migrar um pipeline 100% stream (sem estado materializado acumulado) tende a ser tecnicamente mais simples que migrar com state stores — reduz um dos riscos da comparação que a própria Ata pede.

Atualizado em 02/09/2026: nova extração (ksqldb_report_20260902_081400.json) confirma 322 streams e 0 tables (sem mudança) e sobe para 265 queries persistentes (+2 em relação a 09/07/2026). Pela primeira vez o relatório traz o texto completo (não truncado) de cada query — ver análise em Seção A.11.

A.8 · Reconciliação com nova extração de tópicos (25/08/2026) — confiável, mesma metodologia; conectores continuam não cobertos

A Energisa rodou o script de extração de tópicos fornecido pela consultoria em 25/08/2026 (relatorio_prd_20260825_165932.csv, mesmo ambiente PRD, mesmas colunas de configuração/schema/consumer group). Por ser o mesmo script, tratamos este relatório como fonte confiável e comparável ao de 09/07/2026 — não uma segunda opinião a arbitrar, mas uma atualização do inventário.

Métrica	09/07/2026	25/08/2026	Variação
Total de tópicos (PRD)	930	835	−95 (−10,2%)
Cobertura de schema	78,7% (732/930)	82,9% (692/835)	+4,2 p.p.
WFM com schema	0% (0/40)	0% (0/40)	sem mudança
CRM com schema	21% (3/14)	0% (0/10)	−21 p.p., ver A.1
Fan-out regional XStream (oracle_source_xst_*)	621 (~67%)	587 (~70,3%)	−34 tópicos
Total de partições	4.401	3.631	−770
Tópicos com réplica única	16 (ver A.4)	7	−9
DLQ (sufixo -dlq)	4	4	sem mudança

O que isso não cobre: este é um relatório de tópicos e schemas, não de conectores — não traz dado novo sobre a divergência de contagem de conectores (81 vs. 75, A.5) nem sobre o estado operacional deles (A.6). Essas pendências continuam abertas e precisam de uma extração específica de conectores para fechar, não desta.

Achados que precisam de confirmação com a Energisa antes de virar afirmação em qualquer entregável: 1. Queda de 930 para 835 tópicos (−95). Pode ser limpeza/decomissionamento real no período (~7 semanas entre as duas extrações) ou diferença de escopo entre as duas rodadas do script. Nenhuma Ata ou sessão deste assessment registra uma atividade de limpeza de tópicos nesse intervalo — não presumir a causa. 2. CRM perde os 3 tópicos com schema (21%→0%, ver A.1). Mesma cautela: sem confirmação de que é decomissionamento dos tópicos específicos ou reclassificação de domínio no script. 3. Os números do Diagrama 1 do HLD (hld-as-is-adms.md → hld-as-is-barramento.md), do blueprint de componentes e da matriz de achados e lacunas foram atualizados para refletir 25/08/2026, com nota apontando para esta seção — a contagem de conectores nesses documentos permanece a de 09/07/2026 (75, com a divergência de A.5 ainda aberta).

A.9 · Agrupamento por empresa identificável pelo nome do tópico — pergunta de Castellani (29/08/2026)

Os tópicos da família Oracle XStream seguem o padrão oracle_source_xst_<família>_<código>, com 5 famílias de prefixo (com, sgm, sgd, igs, itg) e 9 códigos de 3 letras que se repetem em todas — batendo exatamente com as "9 distribuidoras" já registradas no business-model-canvas.md. Recomputando a extração de 25/08/2026 (835 tópicos), 7 dos 9 códigos foram confirmados por evidência textual direta — os nomes de tabela/schema dentro do tópico embutem a sigla do estado (ex.: oracle_source_xst_com_mts.ATDEMS... → MS):

Código (Kafka)	Empresa (razão social)	ID empresa	Código legado (tabelas)	Tópicos (25/08/2026)	Confiança
mgr	Energisa Minas Rio-Distrib. Energia SA + Energisa Nova Friburgo-Distr. Energia S.A (um único código para duas razões sociais)	1 / 10	EMG, ENF	73	Alta — confirmado pela Energisa (31/08/2026)
ron	Energisa Rondônia - Distribuidora de Energia S.A.	229	ERO	70	Alta
ser	Energisa Sergipe-Distrib.Energia SA	20	ESE	70	Alta — confirmado pela Energisa (31/08/2026)
acr	Energisa Acre - Distribuidora de Energia S.A.	226	EAC	69	Alta
mts	Energisa Mato Grosso do Sul - Distribuidora de Energia S/A	193	EMS	69	Alta
pab	Energisa Paraíba Distribuidora de Energia AS	27	EPB	68	Alta — confirmado pela Energisa (31/08/2026)
spr	Energisa Sul-Sudeste - Distribuidora de Energia S.A.	218	ESS	63	Alta
mtn	Energisa Mato Grosso - Distribuidora de Energia S.A.	191	EMT	60	Alta
toc	Energisa Tocantins - Distribuidora de Energia S/A	190	ETO	59	Alta

Tabela substituída em 31/08/2026: a Energisa confirmou por escrito o ID interno, a razão social completa e o código legado (o de 4 letras embutido nos nomes de tabela legados, como ATDEMS/ATDESS/ATDERO) de todas as 9 distribuidoras, fechando os dois códigos que antes só tinham confiança média por eliminação (mgr, pab) e confirmando os sete que já tinham evidência textual direta. Achado à parte: existem duas gerações de código de empresa convivendo no ambiente — o código legado de 4 letras (EMS, ESS, EMG/ENF, EPB, ESE, ETO, EMT, EAC, ERO), embutido em nomes de tabela mais antigos, e o código de 3 letras usado nos nomes de tópico Kafka hoje (mts, spr, mgr, pab, ser, toc, mtn, acr, ron) — não são o mesmo padrão nem uma simples abreviação um do outro (ex.: ESS → spr, não ess), o que já explica por que a leitura por eliminação (Seção original desta tabela) não encontrava a sigla do código novo diretamente nos nomes de tabela.

Total atribuível a uma das 9 empresas: 601 tópicos. Além disso:

• itg_crp (20 tópicos) não é uma 10ª empresa — é um conector/schema corporativo compartilhado; as próprias tabelas que grava (IGDEMT, IGDESS, IGDETO) pertencem a três empresas diferentes (MT, Sul-Sudeste, TO) ao mesmo tempo. Tratado como infraestrutura cross-empresa, não como grupo de empresa.
• 31 tópicos com prefixo oracle_stream.* (ex.: oracle_stream.EQUIPE, o mesmo tópico multi-tenant citado na resposta ao Bloco 9 sobre o fluxo WFM/eForce — ver integracao-wfm-eforce-ordem-servico.md) são o tópico único pós-consolidação via ksqlDB — já sem segmentação por empresa, exatamente o mecanismo do Diagrama 3 de topologia-confluent-kafka-multiempresa.md.

601 + 20 + 31 = 652, batendo exatamente com o total do domínio "Oracle XStream" da extração de 25/08/2026 (ver A.8).

~~Confirmar com a Energisa os dois códigos de confiança média~~ — resolvido em 31/08/2026, ver tabela acima. Confirmado também, na mesma troca: a base itg_crp é compartilhada entre empresas, consistente com a leitura já registrada acima de que não é uma 10ª empresa, e sim infraestrutura cross-empresa.

A.10 · Consumidor não documentado dos tópicos brutos por empresa — energisa-kafka-dls-sink-prd (29/08/2026)

Investigando a viabilidade de eliminar tópicos por empresa como parte da Proposta 1 de roteamento via Debezium, cruzamos os 235 tópicos de origem por empresa que alimentam as 33 tabelas hoje consolidadas pelo ksqlDB com as colunas Qtd_ConsumerGroups/ConsumerGroups já presentes na extração de 25/08/2026 (relatorio_prd_20260825_165932.csv) — dado que já existia no relatório, mas não havia sido cruzado com o inventário de queries do ksqlDB até agora.

Situação (por tópico)	Qtd. tópicos	Leitura
1 único consumer group, sempre no padrão _confluent-ksql-barramento-confluent.ksqldb_query_INSERTQUERY_<id>	202	Só o ksqlDB lê — sem dependência externa conhecida
Zero consumer groups (nem o próprio ksqlDB aparece consumindo hoje)	15	Achado à parte — possível stream órfã, query parada ou dessincronia da extração; não presumir nenhuma das duas hipóteses sem checar
Consumer group do ksqlDB + um segundo grupo	18	Ver abaixo

Os 18 tópicos do terceiro grupo são exatamente os 9 tópicos de DESPACHO_OS e os 9 de OS_DIGITACAO (um por empresa). O segundo consumer group, em todos os 18, é energisa-kafka-dls-sink-prd — nome que não aparece em nenhum conector do conectores_detalhado_latest.md (relatório de 09/07/2026), nem em nenhuma Ata ou artefato lido até agora.

Verificando o alcance completo desse consumer group na extração de 25/08/2026 (não só nos 18 tópicos acima, mas em toda a base de 835 tópicos): ele consome 209 tópicos em produção — 199 do domínio "Oracle XStream" e 10 de "Outros", 100% deles tópicos brutos oracle_source_xst_*/oracle_source_jdbc_* por empresa, e nenhum dos tópicos já consolidados pelo ksqlDB (oracle_stream.*, jdbc_stream.*). 80 dos 209 tópicos têm Lag_Total diferente de zero — indício de consumo ativo, não de um grupo órfão parado.

Hipótese de trabalho, não confirmada: o nome (dls sugere "data lake sink") e o padrão de consumo (só tópicos brutos por empresa, nunca os consolidados) são consistentes com um sink que replica o CDC bruto para um data lake ou warehouse, em paralelo e independente do pipeline de consolidação multiempresa via ksqlDB. Não confirmamos isso com a Energisa nem identificamos o conector/aplicação por trás do consumer group.

Por que isso importa para a Proposta 1: para as 26 tabelas do padrão "limpo" que não aparecem na lista acima, a eliminação dos tópicos por empresa não tem, pelos dados de hoje, nenhum consumidor conhecido além do ksqlDB. Para DESPACHO_OS e OS_DIGITACAO especificamente, existe um consumidor confirmado e ativo lendo os tópicos por empresa diretamente — eliminá-los sem migrar ou reapontar esse consumidor quebraria esse fluxo. Ver a seção "Validação parcial" da proposta para o detalhamento tabela a tabela.

A.11 · Re-extração de conectores e queries ksqlDB sem truncamento (02/09/2026)

A Energisa entregou, em 02/09/2026, os dois scripts que havia sinalizado no item 7 da seção "Próximo passo" (conectores desatualizados em relação à extração de tópicos de 25/08) e no pedido de queries ksqlDB sem truncamento (ver "Validação parcial" em proposta-1-debezium-topic-routing.md): kafka_connect_report_20260902_081508.json e ksqldb_report_20260902_081400.json, ambos já versionados neste repositório.

Conectores — 102 no total, sem a inconsistência de cabeçalho da Seção A.5.

Categoria	Conectores (02/09/2026)	Conectores (09/07/2026)
JDBC	38	38
Debezium/XStream	34	34
SQL Server	6	3
Outro (sink JDBC)	24	não capturado
Total	102	75 (ou 81, conforme A.5)

total_conectores_api e total_processado batem exatamente em 102, com divergencia_detectada: false. Por tipo: 78 source, 24 sink. Por estado: 101 RUNNING, 1 PAUSED, 0 FAILED, 0 erros. Todos os 102, sem exceção, continuam com Tasks: 1 — confirma e amplia o achado da Seção A.3 para a nova safra de conectores sink.

• SQL Server dobrou de 3 para 6 — confirma de forma independente o banco "Copy". São dois conjuntos paralelos de três conectores, sqlserver-source-* e sqlsrv-g1-source-*, cada um cobrindo os schemas adms-cpy, cust-dbo e oper-dbo. O schema adms-cpy é evidência independente do banco intermediário "Copy" descrito por Norberto (ver dba-cdc-materializacao-views-adms.md) — dois conectores distintos capturando o mesmo schema Copy, não um só; motivo da duplicação (redundância, ambientes/destinos distintos) não confirmado.
• 24 conectores sink novos, não documentados em nenhum artefato ou Ata deste assessment. Todos JdbcSinkConnector, em dois conjuntos paralelos de 12 (jdbc-sink-g1-* e jdbc-sink-ora-*), cobrindo os mesmos 12 domínios: crew, crew-stat, device, incident, o-i-c-sdp, o-i-i-g, o-incid, o-serv, outage, pc-event, sdp, sdp-resto. O mesmo padrão de duplicação g1/ora visto nos conectores SQL Server se repete aqui — hipótese de trabalho, não confirmada: redundância ativo-ativo, dois destinos distintos, ou migração em andamento entre duas plataformas de destino. Pendência nova de esclarecimento com a Energisa.

Cautela sobre qtd_tabelas: o novo relatório traz esse campo por conector, mas ele retorna 1 para todos os 102 conectores, incluindo oracle-source-xst-com-mgr — que a Seção A.3 (relatório de 09/07/2026, ainda a fonte válida) documenta capturando 47 tabelas por uma única task. Tratamos este campo como não confiável nesta extração; não o usamos para revisar nenhuma contagem de tabela já publicada.

ksqlDB — 265 queries, texto completo corrige um achado que a versão truncada não permitia ver. 322 streams e 0 tables, sem mudança; 265 queries persistentes (+2 em relação a 09/07/2026). Nenhuma query permanece truncada em ~62-63 caracteres — a maior chega a 12.624 caracteres. Varredura por padrão nas 265 queries com texto completo:

Padrão	Ocorrências	Leitura
JOIN / GROUP BY / WINDOW, TUMBLING, HOPPING / HAVING	0	Confirma, agora sobre texto completo, que não há join nem agregação com janela — a arquitetura é mesmo fan-in sem estado
PARTITION BY	261 de 265	Corrige o achado anterior. A análise sobre texto truncado (Proposta 1, seção "Validação parcial") relatava zero ocorrências por não alcançar além de ~62-63 caracteres; o texto completo mostra que é prática quase universal
COD_EMPRESA (literal injetado, ex. 226 AS COD_EMPRESA)	260 de 265	Mecanismo de consolidação: cada query injeta o código da empresa de origem como literal antes do PARTITION BY
WHERE	32 de 265	Ver detalhamento abaixo — parte é filtro trivial, parte não
STRUCT(...)	12 de 265	Mesma contagem já identificada na análise truncada (Proposta 1) — confirmado, não é achado novo

Das 32 queries com WHERE: 2 são as já conhecidas wfm_ordem_servico (lógica de negócio real, fora do padrão XST — uma filtra por uma janela de 8 horas antes do vencimento de SLA, UNIX_TIMESTAMP(...) < UNIX_TIMESTAMP() + 28800000; a outra por um campo de alerta de vencimento do serviço). As outras 30 seguem um padrão novo, não documentado antes: partindo de uma stream de origem compartilhada por empresa (controle_conector_barit_<código> — mesma família de tabela de controle/auditoria do conector itg_crp citado na Seção A.9), cada query filtra WHERE NOM_TABELA = '<tabela-alvo>' e faz PARTITION BY pela chave de registro, produzindo 4 tabelas-alvo consolidadas: ATENDIMENTO_OCORRENCIA_ENCRD (4 queries), PROJETO (8), SGD_SIGOD (9) e ORDEM_SERVICO (9). Ou seja, para essas 4 tabelas o fan-in multiempresa não é um UNION puro por tabela dedicada — é um filtro por nome de tabela sobre uma stream de controle compartilhada, uma empresa por query. Continua sem ser um JOIN entre streams, mas é lógica além do passthrough puro que a Proposta 1 original assumia — ver atualização em proposta-1-debezium-topic-routing.md.

Cruzamento adicional: os 8 valores distintos de COD_EMPRESA encontrados no texto completo (226, 218, 1, 190, 20, 191, 27, 229, entre 21 e 22 queries cada) batem exatamente com 8 dos 9 IDs de empresa confirmados pela Energisa em 31/08/2026 (Seção A.9) — falta o ID 193 (Mato Grosso do Sul, mts) na injeção literal; as queries desse código aparentam usar o COD_EMPRESA já vindo da coluna de origem em vez de um literal fixo. Não investigado a fundo — registrar como observação, não como achado fechado.

---

A.12 · Export completo do Schema Registry (03/09/2026) — resolve o item 18(a): schema idêntico entre empresas nas tabelas piloto

A Energisa entregou, em 03/09/2026, o export completo do Schema Registry gerado em 02/09/2026 — schema_registry_report_20260902_154604.json, já versionado neste repositório. É mais amplo do que o pedido original do item 18 do Bloco 2 (questionario-mitigacao-lacunas.md), que pedia só o subconjunto multiempresa das tabelas candidatas ao piloto — mas, em compensação, não traz o conteúdo do schema em si, só metadados por subject (subject, tipo, schema_id, versões, compatibilidade). Sozinho, não fechava o pedido original. Mas o pedido acaba fechado nesta seção mesmo assim — cruzando com um arquivo que já estava no repositório desde 02/09/2026 (ksqldb_report_20260902_081400.json, Seção A.11), que tem o conteúdo real das colunas. Ver "Achado principal" abaixo.

Visão geral: 1.768 subjects, 100% AVRO, 100% compatibilidade BACKWARD (igual à compatibilidade global do registro), modo global READWRITE. total_subjects e total_processado batem em 1.768, com divergencia_detectada: false — esse campo confirma só que nenhum subject diverge da compatibilidade global (100% BACKWARD), não que os schemas sejam iguais entre empresas; não confundir as duas coisas.

Cruzamento com a extração de tópicos (25/08/2026, Seção A.8): dos 692 tópicos "com schema" da extração de 25/08, os 1.336 subjects citados (SchemaKey_Subject/SchemaValue_Subject) aparecem 100% no export do Schema Registry — nenhuma divergência nessa direção, as duas fontes são consistentes.

Na direção oposta, o Schema Registry tem 432 subjects que não correspondem a nenhum tópico do inventário de 25/08:

• 138 são __debezium-heartbeat.<conector> — tópicos de heartbeat internos do Debezium, esperados e sem tabela associada; não é achado, é infraestrutura normal que a extração de tópicos provavelmente já filtra por padrão de nome.
• 294 não têm explicação óbvia, espalhados por dezenas de prefixos (oracle_source_igs_*, oracle_source_itg_*, oracle_source_sgd_*, oracle_source_sgm_*, entre outros — cada um com um subject de nível conector, <prefixo>-key/-value, mais subjects por tabela) e um punhado de nomes fora do padrão (TB_..._V<N>, crm_..._v<N>, oracle-source-igs-<sigla> com hífen em vez de underscore). Hipótese mais provável, não confirmada: são schemas de outro cluster/ambiente Kafka fora do escopo da extração de tópicos de 25/08, ou de conectores desativados — mas não descartar a possibilidade de o inventário de tópicos estar incompleto. Registrado como pendência (item 17, "Próximo passo").

Achado específico, direcionado ao item 18(a): dentro desses 294, chama atenção a família oracle_source_com_mtn.* (44 subjects — 22 tabelas × key/value, todas só para a empresa mtn) — sem nenhum conector correspondente no relatório de 102 conectores de 02/09/2026 (Seção A.11): existe oracle-source-xst-com-mtn (ativo, topic_prefix: oracle_source_xst_com_mtn), mas nenhum oracle-source-com-mtn sem o xst. Os schema_id dessa família são muito mais baixos (ex. DESPACHO_OS-value = 26) que os da família ativa (DESPACHO_OS-value via xst = 192) — consistente com registro bem mais antigo. Leitura mais provável, não confirmada com a Energisa: resquício de uma convenção de nome anterior à introdução do _xst_ no prefixo do conector, sem limpeza no Schema Registry após a renomeação. Relevante porque as duas tabelas do piloto, DESPACHO_OS e OS_DIGITACAO, estão nessa lista legada — ver item 16, "Próximo passo".

schema_id por empresa nas duas tabelas do piloto (DESPACHO_OS, OS_DIGITACAO): as 9 empresas têm subject próprio (família ativa oracle_source_xst_com_<código>.*), com schema_id distinto em toda linha, nunca compartilhado — ver por que isso não significa schema diferente logo abaixo da tabela:

Empresa (código Kafka)	DESPACHO_OS key	DESPACHO_OS value	OS_DIGITACAO key	OS_DIGITACAO value
mgr	458	736 (3 versões)	744	1333 (3 versões)
ron	349	350	353	1337 (3 versões)
ser	373	768 (2 versões)	375	1338 (5 versões)
acr	333	334	327	1332 (3 versões)
mts	139	140	137	1335 (3 versões)
pab	418	785 (2 versões)	748	1336 (5 versões)
spr	217	218	223	1339 (3 versões)
mtn	191	192	189	1334 (3 versões)
toc	255	256	249	1340 (3 versões)

Ao ler só esses IDs, a leitura mais fácil é "9 IDs distintos = 9 schemas diferentes" — comportamento padrão do Schema Registry é reaproveitar o mesmo schema_id global quando o schema canonizado é idêntico, não importa o subject. Essa leitura, checada logo abaixo com o conteúdo real do schema, se mostra errada — não a estamos deixando como conclusão.

Correção no mesmo dia (03/09/2026): a versão anterior desta seção parou nessa leitura e tratava o schema_id distinto como "indício de divergência", pedindo o schema real via GET /schemas/ids/{id} como próximo passo (ver item 15 riscado em "Próximo passo"). Achamos esse conteúdo antes de pedir — já estava no repositório, no relatório de queries ksqlDB de 02/09/2026 (ksqldb_report_20260902_081400.json, Seção A.11), que traz não só as 265 queries persistentes mas também os 322 streams do ksqlDB com ddl_completo — a definição de coluna completa (CREATE STREAM ... (BEFORE STRUCT<...>, AFTER STRUCT<...>, ...)), incluindo um stream por tópico de origem por empresa, com nome <TABELA>_<CÓDIGO_LEGADO>_XST.

Comparando o ddl_completo das 9 empresas, campo a campo, para as duas tabelas: a parte de colunas do DDL (tudo entre o nome do stream e o WITH (...), que é onde entra o tópico/subject específico de cada empresa) é byte a byte idêntica nas 9 empresas, tanto para DESPACHO_OS quanto para OS_DIGITACAO — uma única variante de coluna em cada tabela, não 9. Isso é comparação de conteúdo real, não inferência a partir de metadado — e contradiz a leitura do parágrafo anterior. O schema_id distinto no Schema Registry não significa schema diferente: neste ambiente, o Schema Registry aparentemente não reaproveita o ID global entre subjects diferentes mesmo com conteúdo idêntico (comportamento que difere do "default" mais comumente documentado do Confluent Schema Registry — não investigado o porquê, registrar como característica observada deste ambiente, não como fato genérico sobre Schema Registry).

Isso resolve o item 18(a) do questionário — as 9 empresas realmente compartilham o mesmo schema por tabela, ao menos para as duas tabelas piloto DESPACHO_OS e OS_DIGITACAO: a consolidação hoje feita pelo ksqlDB para essas duas é, em termos de estrutura de dado, um UNION de fato — o mesmo achado qualitativo da Ata 04 (schema de uma empresa assumido como padrão para todas) não se repete aqui, ao menos nestas duas tabelas. Ver também a correção na Seção A.1 (R28) e em proposta-1-debezium-topic-routing.md.

Generalizando para as 27 tabelas replicadas por empresa (não só as duas do piloto): o mesmo ddl_completo do ksqlDB permite repetir essa comparação para toda a família oracle_source_xst_com_* — 27 tabelas com stream por empresa no relatório de 02/09/2026 (as outras 3 tabelas com stream neste relatório, ORDEM_SERVICO/sgm, SGD_SIGOD/itg, PROJETO/igs, são infraestrutura cross-empresa de fato, não replicadas por empresa — ver Seção A.9 — e ficam fora desta comparação). Resultado: 23 das 27 têm estrutura de coluna idêntica em todas as empresas presentes (a maioria com as 9, MEDIDOR com 7, ANOMALIA_PDA com 3). Só 4 divergem — mas, olhando campo a campo, a divergência não é campo faltando, sobrando ou de tipo diferente: é ordem de coluna diferente entre um subconjunto pequeno de empresas, mesmo conjunto de campos e tipos:

Tabela	Empresas	Variantes de ordem	Empresa(s) fora do padrão
DESPACHANTE	9	2	pab (3 campos deslocados)
PDA	9	2	mtn, mgr (9 campos deslocados)
RETORNO_OS_TEC	9	2	mgr (11 campos deslocados)
SERVICO	9	3	pab (16 campos) e mgr (3 campos), cada uma numa ordem própria

Essas 4 tabelas são exatamente as mesmas 4 já registradas na seção "Validação completa" de proposta-1-debezium-topic-routing.md como usando STRUCT(...) para remontar campos em vez do passthrough direto (PDA_XST 8/9, SERVICO_XST 2/9, DESPACHANTE_XST 1/9, RETORNO_OS_TEC_XST 1/6 — a contagem lá é sobre queries persistentes, não sobre os streams de origem comparados aqui, por isso os denominadores não batem exatamente). Antes não havia explicação de causa para por que só essas 4 precisavam de STRUCT(); agora há: é para normalizar a ordem de coluna, que diverge fisicamente na tabela Oracle de origem em algumas empresas (hipótese mais provável, não confirmada com a Energisa: ALTER TABLE ADD COLUMN aplicado em momentos diferentes por base).

Leitura para a Proposta 1: das 27 tabelas replicadas por empresa, 85% (23) têm schema uniforme sem ressalva nenhuma; as 4 exceções são um problema já conhecido, já contornado no ksqlDB hoje e de causa identificada (ordem de coluna, não estrutura). Isso não elimina o cuidado de checar schema por tabela antes de migrar cada uma — mas muda o tamanho do problema: de "risco desconhecido, catálogo por levantar" para "catálogo levantado, 4 exceções conhecidas, mitigação já em uso". Ver atualização na Proposta 1.

---

---

B. Achados do diagrama de arquitetura

B.1 · Novo ator não documentado: equipe "Best2Bee"

O diagrama identifica explicitamente uma equipe terceirizada — "Equipe Best2Bee que irá atuar na implantação, gestão e suporte na plataforma de Confluent Kafka e Debezium" — com acesso via Citrix (browser, para ELK/Grafana) e via Citrix VDA (máquina de trabalho com VSCode, Git, Postman, CLI OpenShift/Kafka, Azure DevOps). Esse ator não aparece em nenhuma Ata, transcrição ou artefato lido até agora. Recomenda-se confirmar com a Energisa quem é a Best2Bee e desde quando atua — isso é relevante para os achados de propriedade formal já registrados (R21, R41: componentes customizados sem dono formal).

B.2 · Resolvido: SQL Server aparece rotulado como 2019 porque o diagrama reflete a concepção original — instância real é 2022

O container na zona "ADMS [DMZ ADMS]" está identificado como [Container: SQL Server 2019]. Isso divergia da versão informada por Norberto (2022), registrada como "conflito não resolvido entre duas fontes do próprio cliente" até esta atualização. Resolvido por Norberto (Energisa), em resposta direta e por escrito, 31/08/2026: o projeto foi concebido originalmente em SQL Server 2019; na implantação, a instância já foi migrada para 2022 (Enterprise). As duas fontes não se contradizem — o diagrama documenta a concepção, não o estado implantado. Confirmado também, na mesma troca: topologia Always-On (Availability Group), e o banco intermediário "Copy" (schema à parte, mesma instância, 79 tabelas em homologação) que recebe a materialização de views antes da captura CDC nativa — ver dba-cdc-materializacao-views-adms.md. Blueprint de componentes (blueprint-componentes-adms.md, seção C.0) já atualizado com esta resolução.

B.3 · Azure DevOps é instância própria on-premises, não o serviço SaaS — com versão e topologia exatas

"Azure DevOps Server 2020 Update 1.1 (Version: 18.181.31527.1)", rodando em 3 VMs de aplicação (MGDVPSEAPLP1 Tier1/Windows Server 2016, MGDVPSEAPLP2 e MGDVPA2APLP1 Tier2-3/Windows Server 2019) mais uma VM de Search (MGDVPSESCHP1), URLs devops.energisa.com.br e hmgdevops.energisa.corp. Isso substitui a entrada genérica de "Azure DevOps" hoje registrada no blueprint (seção E) — a distinção on-prem vs. SaaS muda a leitura de responsabilidade sobre patch, disponibilidade e atualização de versão.

B.4 · Três clusters OpenShift confirmados por hostname — não dois

A lista de URLs do diagrama confirma três ambientes distintos, cada um como cluster OpenShift próprio (não namespace compartilhado):

Sufixo	Ambiente provável	Evidência
ocpd1	DEV	Único com o stack Confluent detalhado no diagrama (Kafka, KSQLdb, Connect, Schema Registry, Control Center, todos em *.apps.ocpd1.energisa.corp)
ocph1	HML	Só rotas genéricas de console/oauth/grafana no diagrama
ocpp1	PRD	Idem; reconciliado com o cabeçalho dos 3 relatórios de produção analisados na Seção A, que declaram URL: https://ksqldb.apps.ocpp1.energisa.corp e Ambiente: PRODUCAO

Isso é relevante para o achado da Ata 04 sobre "homologação não representativa" (baixa volumetria e dados desatualizados): agora se sabe que HML é fisicamente outro cluster, não apenas outro namespace do mesmo cluster de PRD — o que muda a leitura de por que a paridade de ambiente é difícil de manter.

---

C. Cruzamento com os payloads de evento fornecidos pelo Castellani

Cinco payloads reais de produção foram fornecidos para os tópicos crm_chamada_ocorrencia_tecnica, crm_registra_ocorrencia_sistema_tecnico, crm_retorno_ocorrencia_sistema_tecnico, crm_comunicacao e crm_clientes_afetados_desligamento_emergencial. Todos os cinco batem com o status "Sem Schema" confirmado no inventário da Seção A.1.

Confirma, com payload real, a incerteza registrada na Ata 09. Nenhum dos cinco payloads tem event_id, event_type, correlation_id, causation_id ou schema_version. A correlação entre eventos hoje acontece por reaproveitamento de chave de negócio — Protocolo propagado de crm_chamada_ocorrencia_tecnica para crm_registra_ocorrencia_sistema_tecnico, depois NumComunicacao/NumeroComunicacao propagado até crm_retorno_ocorrencia_sistema_tecnico — e não por um identificador de correlação dedicado. É a confirmação literal, em produção, do que a Ata 09 registrou como incerteza ("não foi possível confirmar se existe identificador único de evento no envelope") e exatamente a lacuna que a recomendação de envelope canônico (Castellani, Ata 09, item 1.10.5.7/1.10.18; ver também 030-artefatos/integracao-sustentacao-adms.md, Diagrama 3) propõe corrigir.

Achado novo, candidato a risco: dado pessoal em texto puro em tópico sem schema. crm_chamada_ocorrencia_tecnica carrega CPF (CpfCnpjAlfanumerico) e celular (CelularSolicitante) sem máscara, num tópico sem contrato formal nem Schema Registry. Os riscos de dados pessoais hoje documentados (R19) cobrem só o pipeline de telemetria/ELK (D10) — este é um vetor diferente (barramento operacional de CRM, D3), sem risco correspondente na matriz atual. Proposta de novo risco:

# (proposto)	Risco	Domínio	Impacto principal	Origem
R42 (proposto)	Dados pessoais (CPF, telefone) trafegando em texto puro em tópicos operacionais de CRM sem Schema Registry nem contrato formal, sem mascaramento nem controle de acesso por schema.	CRM / LGPD (D3)	Exposição de dado pessoal sem trilha de governança; qualquer consumidor do tópico recebe o dado sem filtro.	Achado desta análise, a partir de payload real de crm_chamada_ocorrencia_tecnica

---

D. Nota de nomenclatura — Sigode/SIGOD

Este artefato não resolve a ambiguidade já registrada em 030-artefatos/fluxos-atendimento-adms.md (seção "Achado de nomenclatura: 'Sigode' vs. MsAttFiltroIncidentes") — os tópicos WFM analisados na Seção A.1 (wfm_ordem_servico_*) são consistentes com a atribuição da wiki técnica (produto SIGOD/WFM como origem), mas isso não fecha a dúvida sobre quem de fato filtra e republica os 7 tópicos por status. Mantido como pendência de confirmação com Izabooh ou Lucas, como já registrado no artefato de origem.

---

E. Evidências pendentes atualizadas

Item	Situação antes	Situação após esta análise
[E1] Número de tópicos, esquemas, produtores/consumidores por domínio	Pendente, números citados de memória	Parcialmente fechado — 835 tópicos, 3.631 partições (extração de 25/08/2026, Seção A.8), cobertura de schema por domínio quantificada (Seção A.1)
[E1] Versões exatas do OpenShift/Confluent por ambiente	Pendente	Parcialmente fechado — hostnames reais confirmados para os 3 clusters (Seção B.4); versões de componente Confluent ainda não confirmadas
[E2] Medição de vazão por etapa da cadeia de captura	Pendente	Não fechado, mas causa raiz arquitetural identificada (Seção A.3 — task única por conector)
[E2] Inventário de consumidores das bases do ADMS	Pendente	Não avançado por este anexo

---

F. Versões de componentes e recursos dedicados — resposta ao Bloco 2 (29/08/2026)

F.1 · Versões por ambiente — resposta a [E1]

A Energisa respondeu à Pergunta 1 do Bloco 2 com a tabela abaixo (operador CFK e componentes Confluent Platform, por ambiente):

Componente	DEV	HML	PRD
CFK (Operator)	3.2.3	3.2.3	3.2.3
Kafka	8.2.2	8.2.2	7.9.8
KRaft	8.2.2	8.2.2	7.9.8
Schema Registry	8.2.2	8.2.2	7.9.8
Connect	8.2.2	8.2.2	7.9.8
ksqlDB	8.2.2	8.2.2	7.9.8
Control Center	—	—	7.9.8
Control Center NG	2.6.0	2.6.0	2.6.0

Tabela corrigida em 02/09/2026 a partir de planilha enviada pela Energisa — a versão anterior desta tabela (lida por transcrição de texto livre) tinha trocado os valores de DEV/HML entre as duas linhas de Control Center; a leitura correta é a acima (Control Center legado só aparece em PRD; Control Center NG aparece nos três ambientes). Não muda a leitura já registrada no blockquote "Resolvido em 31/08/2026" abaixo — só corrige os valores de célula.

Confirmado por texto: o operador CFK foi atualizado de 2.9.3 para 3.2.3 em todos os ambientes. Em DEV/HML, os componentes Confluent Platform foram atualizados de 7.7.1 para 8.2.2, incluindo os plugins Kafka Connect:

Plugin	Antes (DEV/HML)	Depois (DEV/HML)	PRD (atual)
Debezium Oracle (XStream)	3.1.1.Final	3.5.2.Final	3.1.1.Final
Debezium SQL Server	3.1.2.Final	3.5.2.Final	3.1.2.Final
Confluent JDBC	10.7.4	10.9.0	10.7.4
ojdbc11	21.15.0.0	21.18	21.15.0.0

Inconsistência a esclarecer — PRD "7.7.1 para 8.2.2" (texto) vs. 7.9.8 (tabela). O texto da resposta afirma que "em PRD os componentes confluent saiu de 7.7.1 para 8.2.2" — mas a própria tabela registra PRD em 7.9.8 para todos os componentes CP, e as versões de plugin listadas para PRD são idênticas aos valores "antes" citados para DEV/HML (plugins ainda não atualizados). Os dois sinais — tabela consistente internamente e plugins de PRD iguais ao pré-upgrade — apontam para erro de cópia no parágrafo de PRD, não erro na tabela. Tratamos essa como a leitura mais provável, não como fato fechado, até confirmação formal da Energisa. Adotado neste artefato: PRD permanece em 7.9.8, sem atualização de componentes CP (só o operador CFK foi atualizado em PRD).

Resolvido em 31/08/2026 — não era duplicação de preenchimento. Confirmado por escrito pela Energisa: DEV e HML rodam somente o Control Center Next-Gen (a linha "Control Center" de 2.6.0 nesses dois ambientes já é o Next-Gen, não o legado — daí o valor coincidir ou se repetir entre as duas linhas da tabela). Em PRD rodam os dois hoje (legado em 7.9.8 como principal, Next-Gen em 2.6.0 marcado "(temp)" — consistente com a leitura original desta seção), e a Energisa confirmou que assim que PRD for atualizado para a versão 8.2 dos componentes Confluent Platform, vai passar a rodar somente o Next-Gen, como DEV/HML — ou seja, o estado atual de PRD é transitório, não a configuração-alvo. Confirmado também, na mesma troca: PRD não está na versão 8.2.2 hoje — permanece na versão anterior (7.9.8, já registrada nesta tabela), fechando a inconsistência "7.7.1 para 8.2.2" (texto) vs. 7.9.8 (tabela) discutida acima a favor da leitura "PRD permanece em 7.9.8".

F.2 · Recursos dedicados por ambiente (limits por pod) — resposta a [E1, R15]

A Energisa respondeu à Pergunta 2 do Bloco 2 com uma tabela de recursos por componente e ambiente. Confirmado por recomputação: os valores de CPU, Memória e Armazenamento são limits por pod, não agregados — multiplicando cada valor pelo número de pods (réplicas) da linha e somando, o resultado bate exatamente com o "Totalizador" declarado pela própria Energisa nos três ambientes:

Ambiente	Pods (soma)	CPU recalculado	CPU declarado	Memória recalculada (GB)	Memória declarada (GB)	Armazenamento recalculado (GB)	Armazenamento declarado (GB)
DEV	9	11,024	11,024	36	36	1099	1099
HML	10	16,536	16,536	93	93	1099	1099
PRD (sem Control Center NG)	17	52	52	330	330	7.633,5	7.633,5

Em PRD, o "Control Center NG (temp)" (1 pod, 1,8 CPU, 10,5 GB memória, 48,5 GB armazenamento) fica fora do Totalizador declarado — confirmado porque incluí-lo quebra a reconciliação (18 pods / 53,8 CPU / 340,5 GB / 7.682 GB, nenhum dos quatro bate com o Totalizador). Tratamos isso como o componente temporário sendo deliberadamente excluído do total oficial, consistente com a marcação "(temp)" da própria Energisa.

Dois pontos de corroboração forte com dados já publicados neste assessment:

• Armazenamento do Kafka em PRD: 2.500 GB por pod × 3 pods = 2,5 TB por broker — bate exatamente com o "~2,5TB cada" já registrado no blueprint de componentes (B.2).
• Contagem de pods em PRD: Kafka (3), KRaft (3), Schema Registry (2), Kafka Connect (5), Control Center (1) — todos batem com os números já publicados no blueprint de componentes (B.2).

Licenciamento por pod (novo, confirmado por texto): cobrança por pod, com preço cheio em PRD, metade em HML e gratuito em DEV — modelo distinto de "por core", relevante para qualquer modelagem de custo futura baseada nas contagens de pod acima.

[E1, R15] "~120 cores dedicados" (Ata 10) — indício de que a cifra pode estar superestimada, não confirmação nem refutação. Somando os Totalizadores de CPU dos três ambientes (excluindo o Control Center NG temporário): 52 (PRD) + 16,536 (HML) + 11,024 (DEV) = ~79,6 cores. Incluindo o componente temporário: ~81,4 cores. Isso é bem abaixo dos "~120 cores dedicados" citados verbalmente na Ata 10. Mas limits de pod (o teto que o OpenShift deixa cada pod consumir) não é necessariamente a mesma medida que "cores dedicados" a nível de node — reserva física via Machine Config Pool, overhead da plataforma e eventual co-alocação com outros workloads podem justificar um número maior de cores efetivamente reservados. Tratamos este achado como dado forte a favor de revisar a cifra de "~120 cores" para baixo, não como confirmação ou refutação definitiva.

---

Próximo passo

1. Confirmar com a Energisa a identidade e o escopo de atuação da equipe Best2Bee (B.1). ~~Divergência de versão do SQL Server 2019 vs. 2022 (B.2)~~ — resolvida por Norberto em 31/08/2026 (ver B.2).
2. Levar a proposta de risco R42 (dados pessoais em crm_chamada_ocorrencia_tecnica) à próxima rodada de validação da matriz de riscos consolidada, junto com as propostas de elevação de R20/R22 já pendentes.
3. ~~Versionar os 3 relatórios brutos e o diagrama~~ — feito, ver links na seção "Fonte" acima (010-evidencias/relatorios-producao-confluent/ e 050-drawio/ambientes-barramento-integracao-confluent.png).
4. ~~Esclarecer a divergência de contagem de conectores no relatório (81 vs. 75, Seção A.5)~~ — superada em 02/09/2026 pela re-extração de conectores (Seção A.11, 102 conectores, sem divergência de cabeçalho). Não usar mais 81 nem 75 em entregável ao cliente; usar 102.
5. Consolidar os achados A.1–A.8 e B.1–B.4 na próxima Ata de Kafka/OpenShift ou como addendum à Ata 10, seguindo o mesmo padrão já usado para a sessão de 24/07 (ver 030-artefatos/fluxos-atendimento-adms.md).
6. Confirmar com a Energisa a causa da queda de 930 para 835 tópicos e da perda de schema nos 3 tópicos CRM (Seção A.8, itens 1–2) antes de tratar qualquer um dos dois como fato fechado em entregável ao cliente.
7. ~~Pedir à Energisa uma extração de conectores equivalente~~ — recebido e incorporado em 02/09/2026 (Seção A.11): 102 conectores, sem divergência de cabeçalho. A divergência 81 vs. 75 (A.5) está superada; o estado operacional (A.6) está atualizado.
8. ~~Confirmar formalmente se PRD permanece em 7.9.8~~ — resolvido em 31/08/2026 (ver F.1): confirmado que PRD não está em 8.2.2.
9. ~~Esclarecer a duplicação de valor entre as linhas "Control Center" e "Control Center NG"~~ — resolvido em 31/08/2026 (ver F.1): DEV/HML rodam só o Next-Gen; PRD roda os dois hoje, transitoriamente, até a atualização para 8.2.
10. Confirmar junto à Energisa se a cifra de "~120 cores dedicados" da Ata 10 (R15/D6) se refere à mesma medida da soma de limits de CPU por pod calculada na Seção F.2 (~79,6 a ~81,4 cores) — se sim, a cifra de 120 deveria ser revisada para baixo; se a Ata 10 se refere a reserva de core a nível de node (Machine Config Pool), os dois números não são diretamente comparáveis e a pergunta precisa ser refeita nesses termos.
11. ~~Confirmar com a Energisa os dois códigos de empresa deduzidos por eliminação na Seção A.9~~ — resolvido em 31/08/2026 (ver A.9): todas as 9 distribuidoras confirmadas com ID interno, razão social e código legado.
12. Identificar o consumer group energisa-kafka-dls-sink-prd (Seção A.10) — não aparece em conectores_detalhado_latest.md nem em nenhum artefato/Ata deste assessment. A pergunta formal sobre migrá-lo ou não foi registrada na Proposta 1 de roteamento via Debezium como item de segunda fase; aqui o pendente é só identificar o que é (conector de Kafka Connect não coberto pela extração, aplicação própria, processo de outro time).
13. Investigar os 15 tópicos por empresa (Seção A.10) sem nenhum consumer group ativo na extração de 25/08/2026, incluindo os que a tabela de queries do ksqlDB indica como consolidados — pode ser stream órfã, query parada ou dessincronia da extração; não presumir nenhuma das duas antes de checar.
14. Pendente desde 31/08/2026, ainda não recebido em 02/09/2026: o questionário formal com as divergências identificadas pela Energisa entre os relatórios originais e a extração de tópicos de 25/08/2026 — mencionado pela própria Energisa como anexo, chegaram só os dois scripts (conectores e ksqlDB, incorporados na Seção A.11); o questionário em si continua pendente de reenvio.
15. ~~Pedir à Energisa o conteúdo real (não só o schema_id) dos schemas Avro de DESPACHO_OS e OS_DIGITACAO nas 9 empresas — via GET /schemas/ids/{id} no Schema Registry~~ — desnecessário, resolvido no mesmo dia (03/09/2026) sem precisar pedir nada: o conteúdo real já estava no repositório desde 02/09/2026, nos streams do ksqldb_report_20260902_081400.json (Seção A.11/A.12). Comparação campo a campo confirma schema idêntico nas 9 empresas para as duas tabelas — fecha o item 18(a).
16. Perguntar à Energisa sobre a família de subjects oracle_source_com_mtn.* no Schema Registry (Seção A.12, 44 subjects, incluindo DESPACHO_OS e OS_DIGITACAO) — sem conector correspondente no relatório de 102 conectores; confirmar se é resquício de uma convenção de nome anterior (segura para ignorar) ou se precisa de alguma limpeza/migração.
17. Investigar os 294 subjects do Schema Registry (Seção A.12) sem tópico correspondente na extração de 25/08/2026 — famílias igs/itg/sgd/sgm, entre outras — provavelmente outro cluster/ambiente ou conectores desativados, mas não confirmado; não tratar o CSV de tópicos como inventário 100% completo sem essa confirmação.