Diagnóstico Preliminar As-Is — Matriz de Achados e Lacunas por Domínio¶
Projeto: DSB26201 — Assessment de Arquitetura e Integrações ADMS (Energisa) Equipe: Vlad e Castellani Versão: v0.2 · rascunho de trabalho (migrado do HTML original para markdown em 03/08/2026; revisado em 04/08/2026 e 05/08/2026 — ver notas de revisão ao final) Data-base: 28/07/2026 Base de evidências: Consolidado v1.10 (Atas 01 a 12)
Consolidação dos achados, riscos e lacunas do Assessment, para validação com Norberto e Rômulo e posterior rodada técnica com as áreas. Este documento destila as doze sessões de levantamento em três entregáveis: esta matriz de achados e lacunas por domínio, a matriz de riscos consolidada e o mapa de evidências pendentes. É um rascunho de trabalho: cada item carrega a classificação de maturidade da evidência e nada aqui deve ser lido como conclusão definitiva antes da rodada de validação.
Nota da migração (04/08/2026): esta matriz reflete o estado do assessment em 28/07 (base v1.10, Atas 01–12). As sessões de Rede/Telecom (Ata 13, 29/07), Engenharia de Dados (Ata 14, 31/07) e DR (03/08, sem Ata formal) trouxeram achados adicionais ainda não incorporados linha a linha aos domínios D1–D11 abaixo. A Engenharia de Dados foi a que produziu o maior volume de achados novos, com itens de prioridade P0 no próprio plano de ação da Ata 14 — por isso foi aberto o domínio D12 com o que já pode ser tratado como achado a partir dessa sessão, em vez de deixar a lacuna implícita como no restante do documento. Ver
030-artefatos/rede-telecom-adms.md,030-artefatos/engenharia-dados-adms.mde030-artefatos/dr-adms-sistemas-corporativos.md.
Números de referência¶
- 12 atas consolidadas na base de evidências (v1.10)
- 11 domínios cobertos na matriz de achados original (v1.10) — mais o domínio D12, aberto em 04/08/2026 a partir da Ata 14, fora da base v1.10
- 7 riscos classificados como críticos
- 5 convergências transversais entre sessões
Critérios de classificação¶
| Classificação | Critério |
|---|---|
| Achado confirmado | Evidência técnica suficiente e entendimento validado com a área responsável. |
| Hipótese a validar | Indícios relevantes, mas falta validação técnica ou documental. |
| Risco potencial | Cenário com impacto possível, dependente de confirmação de volume, criticidade ou frequência. |
| Recomendação preliminar | Direção de melhoria, sujeita a validação de viabilidade e prioridade. |
Síntese executiva¶
Leitura de conjunto. O ambiente é funcional e sustenta a operação, mas cresceu por acúmulo de decisões locais tomadas sob pressão de implantação. O padrão se repete em camadas diferentes: componentes que funcionam individualmente, conectados por soluções customizadas sem propriedade formal, sem SLA definido, sem observabilidade ponta a ponta e com dependência relevante de intervenção manual. Os problemas mais graves não são de ferramenta, e sim de arquitetura e governança: desenho de rede, continuidade do barramento e da captura de dados, contratos entre produtores e consumidores, e ausência de requisitos formalizados por trás dos termos "tempo real".
Os dois eixos críticos frente ao go-live G1 (01/09). Continuidade: nem o barramento de eventos nem a cadeia de captura de dados possuem hoje estratégia de recuperação que acompanhe uma troca de site — a replicação para os consumidores corporativos considera apenas o ambiente primário, e não existe backup ou replay consolidado dos eventos. Topologia: o G1 opera com ADMS ativo na Paraíba e sistemas corporativos em Minas, uma dependência WAN de produção sem precedente nas implantações anteriores, cuja resiliência ainda não foi evidenciada por testes.
Convergências transversais¶
Cinco padrões atravessam sessões diferentes e devem ser tratados como problemas únicos, não como itens isolados por área:
- CV1 · Failover incompleto da cadeia de dados. O failover via F5 resolve o redirecionamento de endpoint, mas não a continuidade do job de captura, a integridade de LSN e offsets, nem o reapontamento da replicação para o site secundário. Atas 05 e 12.
- CV2 · Cargas massivas sem classe de serviço. Carga full de equipes no WFM, tabelas de alta volumetria retendo a fila do CDC e cargas de BI encaminhadas ao barramento: o mesmo padrão de volume sem segregação por criticidade. Atas 08, 10 e 12.
- CV3 · Dependência de intervenção manual. Chaveamento do F5 por change multiequipe, reinício manual de pods consumidores e recuperação manual da captura: a contingência depende de pessoas, não de automação. Atas 05, 10 e 12.
- CV4 · "Tempo real" sem requisito formalizado. Intervalos de 5 e 10 minutos definidos pela duração dos jobs e não por necessidade de negócio; dashboards chamados de real-time sem SLA de processo. Conversa 11/07, Atas 11 e 12.
- CV5 · Governança e propriedade formal ausentes. VIPs sem padrão, tópicos duplicados, telemetria de 151 aplicações em um único tópico e procedimentos customizados sem responsável: ativos críticos sem dono identificável. Atas 05, 10, 11 e 12.
Postura e atribuições. O diagnóstico registra decisões históricas com respeito ao contexto em que foram tomadas: várias soluções customizadas resolveram problemas reais sob prazo de implantação. As dores relatadas pelas equipes internas constam como achados por decisão conjunta registrada na Ata 12. Iniciativas em curso da própria Energisa (reestruturação do ELK, atualização do operador Confluent, homologação da instrumentação do Kafka no Datadog, seis relatórios essenciais do COp) são da equipe do Norberto e estão indicadas como tal.
Matriz de achados e lacunas por domínio¶
Onze domínios da consolidação original (v1.10, Atas 01–12), cada um com seus achados classificados por maturidade de evidência, a origem nas atas e a recomendação preliminar — mais o domínio D12, aberto na revisão de 04/08/2026 a partir da Ata 14 e sinalizado como fora da base v1.10.
D1 · ADMS / OMS — núcleo e adaptadores¶
| Achado | Classificação | Origem | Recomendação preliminar |
|---|---|---|---|
| Processamento single-thread do adaptador Schneider, defeito de produto em aberto; fila única cria contenção e o problema é de priorização, não apenas de vazão. | Achado confirmado | Atas 01, 08 | Camada de proteção e priorização na frente do ADMS; engajamento formal da Schneider; medição de capacidade e backlog. |
| Melhoria aplicada pela Schneider reduziu o tempo de processamento, mas o limite de crescimento e o comportamento em picos não foram dimensionados. | Hipótese a validar | Ata 08, conv. 11/07 | Levantar capacidade, backlog e projeção de volume com Schneider e equipe ADMS. |
| Views proprietárias do ADMS invocam funções e bibliotecas do produto e buscam informação em memória, exigindo camada de materialização em tabelas para viabilizar a captura. | Achado confirmado | Ata 12 | Rever a solução de materialização, formalizar propriedade e avaliar contrato de dados com o fornecedor. |
| Atualizações do fornecedor alteram views, tabelas e colunas sem comunicação prévia nem documentação, quebrando materialização e captura em produção. | Achado confirmado | Ata 12 | Acordo formal de mudanças com a Schneider, detecção de desvio de esquema e automação da recriação. |
D2 · GIS e integração GIS-ADMS¶
| Achado | Classificação | Origem | Recomendação preliminar |
|---|---|---|---|
| Composição multivendor (GIS e adapter GE, ADMS Schneider) exige camada de transformação e enriquecimento entre modelos. | Achado confirmado | Ata 06 | Tratar como questão arquitetural, sem conclusão antecipada; documentar a camada de transformação. |
| Janela de até aproximadamente 12 horas para propagação do GIS ao ADMS pode gerar eventos tardios, duplicidades e incidentes com granularidade insuficiente. | Risco potencial | Ata 06, conv. 11/07 | Mapear o fluxo ponta a ponta, definir mecanismo de reconciliação e tratamento de eventos tardios. |
| Números de performance da integração divergem entre fontes documentais. | Hipótese a validar | Atas 01, 06 | Resolver a divergência como questão de validação no retorno com GIS/ADMS, sem arbitrar silenciosamente. |
D3 · CRM, incidentes e canais de atendimento¶
| Achado | Classificação | Origem | Recomendação preliminar |
|---|---|---|---|
| Dual write sem padrão Transactional Outbox nos fluxos de incidentes, com risco de divergência entre banco e evento publicado. | Achado confirmado | Ata 09 | Adotar Outbox nos serviços críticos; idempotência e dedupliçação nos consumidores. |
| Ausência de correlation ID ponta a ponta impede rastrear um incidente do canal de origem ao ADMS e de volta ao CRM. | Achado confirmado | Ata 09 | Definir e propagar identificador de correlação em todos os fluxos críticos. |
| Agrupamento de incidentes pelo ADMS e retorno ao CRM podem produzir inconsistência processual (reaberturas, duplicidades, estados divergentes), sobretudo combinados com eventos tardios da janela GIS. | Risco potencial | Ata 09, conv. 11/07 | Documentar e validar com Érica o fluxo ponta a ponta: geração, agrupamento, fechamento, reabertura e conciliação. |
D4 · WFM e sincronização de equipes¶
| Achado | Classificação | Origem | Recomendação preliminar |
|---|---|---|---|
| Sincronização de equipes por carga full, com pontos de falha, timeouts e ausência de confirmação de processamento. | Achado confirmado | Ata 08 | Evoluir para integração incremental por API em estratégia híbrida, conforme critérios discutidos na Ata 08. |
| Motor de cálculo IQS e integrações do WFM pressionam o barramento em janelas concentradas. | Hipótese a validar | Ata 08 | Confirmar volumetria e janelas com o especialista do WFM (sessão pendente, pós-férias). |
D5 · Barramento Kafka — eventos e governança¶
Quantificação por evidência real (05/08/2026): a análise de inventário real de produção (ver
030-artefatos/evidencias-producao-confluent-kafka.md, seção A.1) confirma e quantifica o achado de adoção parcial do Schema Registry abaixo: 78,7% dos 930 tópicos de produção têm schema (732/930), mas a cobertura é desigual — 0% no domínio WFM (0/40 tópicos) e 21% no domínio CRM (3/14, sendo os 3 apenas derivados internos do ksqlDB, não os tópicos de origem).
| Achado | Classificação | Origem | Recomendação preliminar |
|---|---|---|---|
| Ausência de estratégia consolidada de backup, replay e recuperação de desastre dos eventos e do barramento. | Achado confirmado | Ata 10 | Event Store com replay controlado; DR definida por RTO e RPO com testes periódicos de failover e failback. |
| Multiplicação de tópicos e eventos equivalentes eleva tráfego e processamento sem catálogo ou governança. | Achado confirmado | Ata 10 | Catálogo corporativo de eventos, esquema canônico por domínio e revisão dos tópicos fragmentados. |
| Schema Registry com adoção parcial e divergência de esquemas entre empresas do grupo. | Achado confirmado | Atas 04, 09 | Contrato versionado obrigatório e regras de compatibilidade na esteira. |
| Consumidores lentos para restabelecer o consumo após reinícios e atualizações, exigindo intervenção manual em pods; operação passou a postergar atualizações da plataforma. | Achado confirmado | Atas 04, 10 | Reconexão automática, espera progressiva, health checks funcionais e escalonamento para drenagem de backlog. |
| Cargas de CDC, BI e grandes tabelas encaminhadas ao barramento sem avaliação suficiente de alternativas batch ou nativas. | Hipótese a validar | Atas 10, 12 | Matriz de decisão entre streaming, CDC, API, batch e arquivo, condicionando a aprovação de novos fluxos. |
D6 · OpenShift — plataforma, rede e capacidade¶
| Achado | Classificação | Origem | Recomendação preliminar |
|---|---|---|---|
| Consumidores internos acessam o Kafka por rota externa, atravessando F5, firewall e API Gateway antes de retornar ao próprio cluster. | Achado confirmado | Ata 10 | Substituir rotas por Services e DNS do cluster, centralizar endpoints em configuração governada e aplicar Network Policies. Maior retorno imediato apontado pela Ata 10. |
| Ecossistema do barramento ocupa nodes dedicados da ordem de 120 cores, com pressão sobre licenciamento OpenShift e Confluent, virtualização e storage. | Hipótese a validar | Ata 10 | Confirmar por inventário; planejamento formal de capacidade e estudo de segregação do barramento por requisitos e custo total. |
| Kafka intensificou gravações em disco no mesmo ambiente de virtualização usado por outros workloads. | Hipótese a validar | Ata 10 | Medir entrada e saída, validar StorageClass e hipótese de esquema de paridade. |
| Operador e componentes Confluent permaneceram desatualizados por período relevante; atualização em curso pela Energisa, sem processo institucionalizado. | Achado confirmado | Ata 10 | Institucionalizar o ciclo de atualização com janelas, testes e critérios de rollback. |
D7 · F5 — balanceamento e chaveamento¶
| Achado | Classificação | Origem | Recomendação preliminar |
|---|---|---|---|
| Monitores verificam disponibilidade do servidor, não do serviço: nó pode receber tráfego com a aplicação parada. | Achado confirmado | Ata 05, conv. 11/07 | Monitores ativos de aplicação: health endpoint, código e conteúdo de resposta, dependências e prontidão real. |
| Chaveamento entre sites exige change, mobilização multiequipe e procedimentos manuais. | Achado confirmado | Ata 05 | Automatizar o chaveamento com health checks conscientes de papel (role-aware) e runbooks testados. |
| Quantidade elevada de VIPs sem padrão de nomenclatura, dificultando descoberta, auditoria e manutenção. | Achado confirmado | Ata 05, conv. 11/07 | Política corporativa de nomenclatura e metadados; higienização do inventário. |
D8 · APIs e Sensedia¶
| Achado | Classificação | Origem | Recomendação preliminar |
|---|---|---|---|
| Ciclo de vida de APIs sem controles automatizados de compatibilidade: quebras de contrato são percebidas após a publicação e tratadas como manutenção normal. | Achado confirmado | Ata 05, conv. 11/07 | Testes de contrato no CI/CD, bloqueio de breaking changes, versionamento obrigatório e validação de consumidores críticos. |
| Mecanismo atual é reativo: backend refeito ou fallback criado após alterações incompatíveis. | Hipótese a validar | Conv. 11/07 | Aprofundar com desenvolvimento, API Management e DevOps no retorno de F5/Sensedia. |
D9 · Captura de dados (CDC) — Oracle e SQL Server¶
Pendência pós-migração (04/08/2026): a Ata 13 (Rede/Telecom, 29/07) confirmou, com número concreto, um fator adicional para o atraso de captura já registrado nesta tabela: o conector de captura (Debezium) roda no OpenShift corporativo, distante do banco de origem no ambiente operacional, com latência interdatacenter medida em 60–70ms. Achado ainda não formalizado como linha desta tabela — ver
010-evidencias/130-rede-telecom.md, seção 1.14.8.Causa raiz confirmada (05/08/2026): a análise de relatórios reais de produção do Kafka Connect (ver
030-artefatos/evidencias-producao-confluent-kafka.md, seção A.3) confirma que os 75 conectores de captura em produção rodam, sem exceção, com uma única task — inclusive conectores que capturam até 47 tabelas simultaneamente pela mesma task. Isso é evidência de infraestrutura para a causa raiz do achado "leitura sequencial... reterem tabelas críticas" logo abaixo: quando uma tabela lenta e uma crítica compartilham a mesma task de um conector, uma bloqueia a outra por construção arquitetural, não por configuração pontual. Achado ainda não formalizado como linha desta tabela.
| Achado | Classificação | Origem | Recomendação preliminar |
|---|---|---|---|
| Duas tabelas de alta volumetria acumulam atraso de 10 a 20 minutos na captura do Oracle, chegando a cerca de 30 minutos em picos (10h às 11h30). | Achado confirmado | Ata 12 | Medir vazão por etapa, revisar particionamento e paralelismo, isolar as tabelas ofensoras. |
| Leitura sequencial por número de mudança faz tabelas analíticas reterem o avanço de tabelas críticas. | Achado confirmado | Ata 12 | Separar conectores e workloads por criticidade, com classes de serviço distintas. |
| Comandos DDL não interpretados pelo conector já interromperam a captura em operação rotineira de banco. | Achado confirmado | Ata 12 | Levantar comandos e versões envolvidos; submeter alterações de banco a procedimento controlado. |
| Failover do CDC no SQL Server exige solução em três camadas: redirecionamento de endpoint, continuidade do job e integridade de LSN e offsets. O F5 sozinho resolve apenas a primeira. | Achado confirmado | Ata 05 | Health checks conscientes de papel ou AG Listener, mais procedimento de retomada do job com validação de offsets. |
| Intervalos de atualização de 5 e 10 minutos definidos pela duração dos jobs, sem requisito de negócio formalizado. | Achado confirmado | Ata 12 | Matriz de consumidor, finalidade, criticidade e SLA, substituindo o termo "tempo real" por requisito mensurável. |
| Várias ferramentas leem as mesmas bases do ADMS para consumidores distintos, com leitura redundante sobre a fonte. | Achado confirmado | Ata 12 | Consolidar em solução única de integração, publicando produtos de dados reutilizáveis. |
D10 · Observabilidade e monitoração¶
| Achado | Classificação | Origem | Recomendação preliminar |
|---|---|---|---|
| Datadog não viabilizado no ambiente de tecnologia operacional onde o ADMS foi implantado; cobertura dividida entre ferramentas sem correlação entre domínios. | Achado confirmado | Ata 11 | Arquitetura de coleta segura na OT com correlação junto ao APM e à telemetria corporativa. |
| Instrumentação do Datadog cobre três das nove unidades, com cerca de 85% das APIs instrumentadas nessas três. | Achado confirmado | Ata 11 | Roadmap de cobertura por criticidade e aceite de instrumentação como requisito de projeto. |
| Ambiente ELK anterior ao OpenShift, com consumo excessivo e storage compartilhado; rebalanceamentos e backups já afetaram outros serviços. Reestruturação em curso pela Energisa. | Achado confirmado | Ata 11 | Storage e recursos dedicados, planejamento de capacidade e arquitetura resiliente na reestruturação. |
| Um único tópico de telemetria recebe registros de 151 aplicações, sem gestão de volumetria, propriedade ou impacto. | Achado confirmado | Ata 11 | Contrato de logging, tópico por aplicação, quotas e rateio de custo. |
| Mascaramento preventivo de dados pessoais no fluxo de logs não confirmado; criptografia em trânsito no trecho do Kafka de telemetria citada como lacuna em tratamento. | Risco potencial | Ata 11 | Mascaramento e detecção de segredos antes da indexação; TLS fim a fim com gestão de certificados. |
| Azure e Databricks sem ferramenta de monitoramento prevista no projeto; telemetria multicloud não consolidada. | Achado confirmado | Ata 11 | Incluir observabilidade como requisito de arquitetura e de aceite; consolidar a visão multifonte. |
| Resposta a incidentes predominantemente manual, com automação de remediação incipiente e retenção de logs de quinze dias em produção. | Achado confirmado | Ata 11 | Automação de remediação para cenários recorrentes e retenção por classe de log. |
D11 · Infraestrutura, telecom e continuidade¶
Domínio parcialmente coberto quando este diagnóstico foi escrito (28/07): as sessões dedicadas de infraestrutura/contingência e rede/telecom ainda não tinham ocorrido. Os achados abaixo vinham de sessões adjacentes. Atualização pós-migração (04/08/2026): as sessões de Rede/Telecom (Ata 13) e DR (sem Ata formal ainda) já ocorreram — ver
010-evidencias/130-rede-telecom.mde010-evidencias/150-dr-sistemas-corporativos.md. Esta matriz ainda não foi atualizada com esses achados — fica como próximo passo de revisão, não como lacuna real do assessment. Atenção: a atualização pendente não é só deste domínio — a Ata 13 também trouxe um achado específico de captura de dados que pertence a D9 (posicionamento do conector e latência interdatacenter medida), não a D11; ver nota equivalente lá. A Ata 14 (Engenharia de Dados), por sua vez, não se encaixa em nenhum domínio existente — ver D12.
| Achado | Classificação | Origem | Recomendação preliminar |
|---|---|---|---|
| Topologia G1 com ADMS ativo na Paraíba e corporativo em Minas cria dependência WAN de produção sem precedente nas implantações anteriores. | Achado confirmado | Atas 01, 03, 05 | Evidenciar por testes a resiliência da WAN e o comportamento das integrações síncronas em degradação. |
| A replicação para os consumidores corporativos considera o ambiente primário e não acompanha a troca para o secundário: em site switch, o ADMS segue operando enquanto BI e dependentes ficam sem atualização. | Achado confirmado | Ata 12 | Desenhar o failover ponta a ponta, incluindo reapontamento das integrações, com teste periódico. |
| RTO, RPO, runbooks e resultados de testes de DR por sistema ainda não evidenciados. | Hipótese a validar | Pendente | Sessão dedicada de infraestrutura e contingência, com a continuidade do barramento incorporada à pauta. |
D12 · Engenharia de dados e Data Lake (achados da Ata 14, fora da base v1.10)¶
Domínio aberto na revisão de 04/08/2026. Diferente do domínio D11 (que hoje mistura achados da base v1.10 com uma sessão de DR ainda sem Ata formal, só transcrição), esta seção é construída sobre a Ata 14, que já é uma Ata consolidada a partir de relatório técnico e transcrição — mesmo padrão de fidelidade das Atas 01–13. A ressalva aqui é outra: nenhum destes achados foi confrontado com uma segunda sessão independente, e nenhum passou pela rodada de validação com as áreas.
| Achado | Classificação | Origem | Recomendação preliminar |
|---|---|---|---|
| Resiliência da integração entre o ambiente próprio e a nuvem depende de um único componente intermediário (cluster de duas a três máquinas, contingência não detalhada), com tráfego por internet pública; falha nesse elo interrompe ingestão, processamento e disponibilização simultaneamente — ponto único de falha para toda a cadeia analítica e regulatória, na própria formulação da equipe. | Achado confirmado | Ata 14 | Documentar e testar o caminho completo com failover e retomada automática; avaliar conectividade dedicada com o provedor de nuvem. |
| Retenção uniforme de sete dias na área de aterrissagem, sem diferenciação por criticidade; caso concreto de perda de dados já ocorrido por reprocessamento solicitado fora da janela. | Achado confirmado | Ata 14 | Substituir por classes de retenção conforme criticidade, obrigação regulatória e custo de reconstrução. |
| Ausência de framework formal de qualidade de dados (completude, validade, consistência, quarentena, reconciliação); hoje existem apenas harmonização e conversão de tipos. | Achado confirmado | Ata 14 | Implantar regras mínimas com quarentena, indicadores e fluxo de decisão sobre registros retidos. |
| Conectores do barramento ativos apenas para o fluxo corrente, sem mecanismo de reconstrução de estado anterior; idempotência dos consumidores não implementada — segunda ocorrência independente do mesmo achado já registrado na Ata 09. | Achado confirmado | Atas 09 e 14 | Estabelecer contrato arquitetural obrigatório para reprocessamento, dedupliçação, chave de idempotência e captura incremental de estado. |
| Alterações de esquema na origem (mudança de tipo, remoção de campo, alteração de regra de negócio) quebram pipelines; detecção hoje é majoritariamente reativa, após reclamação do consumidor — mesma classe de problema já registrada na Ata 12 para a materialização de views do ADMS (D1), agora do lado do lake. | Achado confirmado | Atas 12 e 14 | Contratos de dados versionados, validação automatizada na esteira e alerta preventivo para mudanças incompatíveis. |
| Upgrade do licenciamento Oracle para a modalidade de replicação de grande volume estimado em cerca de R$ 6 milhões, considerado inviável para um único projeto; alternativa de extração incremental por marcador temporal em estudo, com viabilidade contratual de uso em nuvem ainda não confirmada. | Hipótese a validar | Ata 14 | Validar viabilidade técnica e contratual com administração de banco de dados e área de licenciamento antes de ampliar a dependência do mecanismo. |
| Serviço de gravação em Go, desenvolvido internamente sob pressão de prazo regulatório para substituir o conector comercial não adquirido a tempo, mantido em produção sem propriedade formal — mesmo padrão de risco já registrado para a materialização de views do ADMS (D1, Ata 12). | Achado confirmado | Ata 14 | Formalizar propriedade, documentação e sustentação; tratar como política transversal, não caso a caso (mesma recomendação cabível ao achado análogo de D1). |
Ver também: Matriz de riscos consolidada e Mapa de lacunas e evidências pendentes.
Nota de revisão (04/08/2026): esta revisão fez três alterações sobre o v0.1. Primeiro, adicionou a nota de migração no nível do documento (ausente antes, ao contrário dos dois documentos irmãos) para que a existência da Ata 13, da Ata 14 e da sessão de DR não dependa de o leitor chegar ao bloco de D11. Segundo, apontou que a atualização pendente da Ata 13 não é exclusiva de D11 — D9 também precisa de uma linha nova sobre o posicionamento do conector de captura. Terceiro, abriu o domínio D12 com os achados da Ata 14, que antes não tinham correspondência em nenhum dos onze domínios originais. Nenhuma linha de D1–D11 foi alterada nesta revisão — a atualização achado a achado desses domínios a partir das Atas 13 e 14 continua como trabalho pendente.
Nota de revisão (05/08/2026): duas anotações a partir da análise de evidências reais de produção do Confluent Kafka (ver
030-artefatos/evidencias-producao-confluent-kafka.md): D9 ganhou nota de causa-raiz confirmada (task única em todos os 75 conectores de captura) para o achado de leitura sequencial; D5 ganhou a quantificação real da cobertura do Schema Registry (78,7% geral, 0% WFM, 21% CRM). Nenhuma classificação de maturidade foi alterada — os achados já confirmados permanecem confirmados, agora com evidência quantitativa adicional.