Diagnóstico Preliminar As-Is — Questionário de Mitigação de Lacunas, por Equipe¶

Projeto: DSB26201 — Assessment de Arquitetura e Integrações ADMS (Energisa) Versão: v0.3 · rascunho de trabalho Data-base: 14/08/2026 (v0.2 era 13/08/2026, v0.1 era 04/08/2026 — ver nota de revisão ao final) Fonte: Mapa de lacunas e evidências pendentes (v0.2), Matriz de achados e lacunas (v0.2) e Matriz de riscos consolidada (v0.2, hoje até R45) — mais os artefatos publicados entre 08/08 e 13/08/2026 que trazem lacunas próprias ainda não incorporadas linha a linha aos três documentos-fonte (ver nota de revisão ao final)

Este questionário converte em perguntas objetivas as lacunas já registradas nos documentos-fonte — evidências pendentes (E1–E7), achados classificados como "Hipótese a validar" ou "Risco potencial" (D1–D12) e riscos que dependem de confirmação (R01–R45). Cada pergunta traz entre colchetes a referência ao item de origem, para rastreabilidade na próxima consolidação. Perguntas sem referência foram inferidas diretamente do conteúdo das Atas ou artefatos de origem citados em cada bloco.

Como usar¶

Cada bloco é endereçado à equipe que, pela distribuição de participantes das Atas 01–14 e da sessão de DR, é a responsável natural pela resposta. Se a equipe correta for outra, o ajuste é simples — a referência entre colchetes aponta para o item original.
Respostas devem vir com evidência documental sempre que possível (print, export de configuração, documento formal, planilha) — não só declaração verbal. Isso segue a mesma regra de ouro do assessment: valores citados de memória permanecem como hipótese até confirmação.
Perguntas já respondidas nas Atas 13 e 14 (Rede/Telecom e Engenharia de Dados) não estão aqui — o que falta responder é justamente o que essas sessões não cobriram ou deixaram como encaminhamento em aberto.
O domínio E6 (pendências operacionais da consultoria — acesso a Citrix/DevOps, artefatos no SharePoint, transcrições) não gerou perguntas: são providências internas da consultoria e do Roberto, não lacunas técnicas de uma equipe.
Ordem dos blocos segue a criticidade já registrada na matriz de riscos (críticos primeiro).

1. Segurança e Continuidade / Disaster Recovery¶

[E5] Quais são o RTO e o RPO formalmente definidos, por sistema, para o ambiente corporativo e para o ADMS — não apenas o RTO agregado de 24h já mencionado na sessão de DR?
[E5, R33] Existe runbook documentado de chaveamento de site, com papéis, dependências e tempos medidos, cobrindo os sistemas corporativos (não só os testes em ambiente isolado, "bolha")?
[R33] Há plano para um teste de chaveamento integral — não isolado — que exercite resolução de nomes, rotas, autenticação, certificados e as integrações reais entre ADMS e sistemas corporativos?
Qual o motivo técnico pelo qual a Schneider orienta não executar o teste "site suíte local" em 2026? Existe posição formal por escrito, além dos e-mails já trocados?
Qual o estado atual da iniciativa, mencionada na Ata 13, de replicar os sistemas corporativos para João Pessoa? Ainda está ativa ou foi descontinuada?
Existe avaliação formal de replicar o serviço (como já ocorre para Redis e Mongo) em vez da VM inteira, para reduzir o RTO de 24h hoje declarado?
[R32] Qual o modo de proteção e o transporte (síncrono ou assíncrono) configurado hoje no Data Guard entre os sites? Existe leitura habilitada no ambiente secundário?

2. Plataforma e Barramento (OpenShift / Confluent Kafka)¶

[E1] Quais as versões exatas do OpenShift por ambiente e do operador/componentes Confluent, antes e depois da última atualização?
[E1] Quantos nodes, cores e memória são dedicados ao barramento por componente, e qual o total efetivo de cores licenciados?
[E1, R15] O número de aproximadamente 120 cores dedicados citado na Ata 10 está correto? Existe inventário formal que confirme?
[E1] Quantos clusters Kafka existem, qual a capacidade provisionada e a ocupação real? Quantos tópicos, esquemas, produtores e consumidores existem por domínio?
[E1] Qual a política de retenção configurada por tópico, e qual o volume diário/mensal de eventos?
[E1] Quais os parâmetros de StorageClass configurados? Existe medição de entrada/saída que confirme ou descarte a hipótese de esquema de paridade levantada na Ata 10?
[E1, R07] Existe lista atualizada das aplicações que acessam o Kafka por rota externa? Há endpoints fixos (hardcoded) em código?
[E1, R02] Quais ferramentas de backup do barramento já foram testadas com registro formal? Qual a capacidade real do object storage disponível para funcionar como Event Store?
[E1] O licenciamento atual do Confluent já contempla mecanismo de replicação entre clusters?
[R13, R18] Existe hoje algum inventário de tópicos duplicados ou eventos equivalentes? Há previsão de catálogo corporativo de eventos?
[R14] Qual o plano para reconexão automática e health checks funcionais dos consumidores após reinício ou atualização da plataforma?
[R27] Qual o cronograma formal — com janelas, testes e critérios de rollback — para atualização do operador e dos componentes Confluent?
[R28] Qual o plano de adoção completa do Schema Registry entre as empresas do grupo?
[R13, R14] O desenvolvedor responsável pelo eForce (WFM) sugeriu, em 12/08/2026, que a ausência de padrão de Dead Letter Queue deveria ter solução corporativa, reaproveitável entre domínios, em vez de cada squad resolver isoladamente. Existe patrocínio da arquitetura corporativa para essa iniciativa? Quem seria o responsável — arquitetura corporativa ou cada domínio individualmente? [ver 030-artefatos/integracao-wfm-eforce-ordem-servico.md]
A instância MongoDB usada pelo domínio WFM/eForce é a mesma do domínio Atendimento, ou um deployment separado? Hoje é uma pergunta em aberto, registrada como tal no blueprint de componentes para não presumir. [ver 030-artefatos/blueprint-componentes-adms.md, seção C.0]

Checklist de confirmação de licenciamento — por componente [E1]¶

A Ata 10 confirma o uso de cada componente abaixo, mas licenciamento formal (edição, SKU, cobertura de cores/features) só está explicitamente confirmado onde indicado. Checklist para a equipe de infraestrutura validar contra contrato/inventário, não contra memória:

Componente	Status observado em 20/07	Licenciamento confirmado?
OpenShift (plataforma)	Produção 4.20.24, não-produtivo 4.21	Não — SKU/edição e total de cores licenciados não confirmados (pergunta 2/3 acima)
CFK (Confluent for Kubernetes)	Em uso, evolução citada 2.9.3 → 3.2.3	Não confirmado nos manifestos
Kafka (brokers)	Em uso, 3 clusters ~2,5TB cada	Não — licenciamento por core/broker não detalhado
KRaft	Em uso, node dedicado	Não — presumido incluso no pacote Confluent, sem confirmação
Kafka Connect	Em uso, 5 nodes	Não — conectores individuais (ex.: Debezium) podem ter licenciamento próprio, não verificado
ksqlDB	Em uso, 587 estruturas reais em produção (02/09/2026)	Não — cobertura da licença para esse volume não confirmada; muda se migrar para Flink
Schema Registry	Em uso	Não confirmado
Control Center	Em uso	Não confirmado
Replicação entre clusters (Cluster Linking/MirrorMaker)	Não implementado — sem ferramenta	Pergunta 9 acima já cobre isso — reforçar pedido de confirmação por SKU explícito, não resposta verbal
OpenShift Data Foundation (object storage)	Capacidade mencionada como já existente, criada para apoiar tentativas de backup	Não confirmado se está licenciado para uso produtivo (ex.: como Event Store) ou só disponível para POC
MinIO (Paraíba)	Instalado, uso experimental/POC, fora do cluster	Comunidade (AGPLv3) — sem suporte comercial confirmado; repositório community está em modo somente-leitura desde abril/2026 (upstream arquivado), o que é motivo adicional para não tratar como produtivo sem avaliar MinIO AIStor (licença comercial) ou alternativa suportada
OpenShift Serverless (Knative)	Sem evidência de uso em nenhuma sessão	Não confirmado se está no catálogo de operators disponíveis/licenciados do cluster
OpenShift Pipelines (Tekton)	Sem evidência de uso	Não confirmado
OpenShift GitOps (ArgoCD)	Sem evidência de uso	Não confirmado

Os três operators sem evidência de uso (Knative, Pipelines, GitOps) estão no catálogo do OperatorHub habilitado para o cluster, mesmo que não instalados? Isso muda o custo de uma eventual adoção futura (arquitetura event-driven proposta neste assessment) de "nova licença" para "ativar operator já coberto".
O MinIO em uso experimental no datacenter da Paraíba tem algum plano de descontinuação ou upgrade, dado que o projeto community está em modo somente-leitura desde abril/2026? Existe avaliação de MinIO AIStor (edição comercial) ou de consolidar tudo no OpenShift Data Foundation em vez de manter as duas soluções de object storage em paralelo?
[E1] É possível disponibilizar (a) o schema Avro mais recente, por empresa, dos tópicos de origem oracle_source_xst_com_* das tabelas candidatas a um piloto de consolidação (ex. DESPACHO_OS), via export do Schema Registry, e (b) o texto completo — não truncado — das queries persistentes do ksqlDB relacionadas a essas mesmas tabelas, via SHOW QUERIES EXTENDED;? Objetivo: confirmar se as 9 empresas realmente compartilham o mesmo schema por tabela e se a consolidação hoje feita é UNION puro, antes de validar a proposta de roteamento via Debezium SMT [ver 030-artefatos/propostas-barramento-ksqldb/proposta-1-debezium-topic-routing.md]. Parte (b) resolvida em 02/09/2026: a Energisa entregou o script de extração sem truncamento (ksqldb_report_20260902_081400.json, 265 queries com statementText completo via SHOW QUERIES EXTENDED) — auditoria completa em evidencias-producao-confluent-kafka.md, Seção A.11, e incorporada em proposta-1-debezium-topic-routing.md. Confirmou-se que a consolidação não é UNION puro em todos os casos (30 das 265 queries fazem WHERE NOM_TABELA = ... sobre uma stream compartilhada). Parte (a) — schema Avro por empresa das tabelas candidatas ao piloto — resolvida em 03/09/2026. A Energisa entregou o export completo do Schema Registry (schema_registry_report_20260902_154604.json, 1.768 subjects) em 03/09/2026; sozinho não trazia o conteúdo do schema (só schema_id, versões, compatibilidade), e o schema_id distinto por empresa em DESPACHO_OS/OS_DIGITACAO inicialmente pareceu indício de divergência — leitura corrigida no mesmo dia ao cruzar com um arquivo já recebido em 02/09/2026 (ksqldb_report_20260902_081400.json), cujos 322 streams do ksqlDB trazem ddl_completo com a estrutura de coluna completa por tópico de origem. Comparando campo a campo: as 9 empresas têm exatamente a mesma estrutura de colunas em ambas as tabelas — schema_id diferente no Schema Registry não significa schema diferente, é peculiaridade deste ambiente (não reaproveita ID entre subjects mesmo com conteúdo idêntico). Confirmado: a consolidação hoje feita pelo ksqlDB para essas duas tabelas é, em termos de estrutura, um UNION de fato. Ver evidencias-producao-confluent-kafka.md, Seção A.12.

3. Banco de Dados — DBA Oracle e SQL Server / Captura de Dados (CDC)¶

[E2] Quais os nomes e esquemas das duas tabelas de maior volume, e como estão configuradas no barramento?
[E2] Existe o desenho de arquitetura do XStream elaborado na prova de conceito? Pode ser publicado no repositório compartilhado do assessment?
[E2] Quais comandos DDL e versões já interromperam a captura em produção? Existe lista consolidada?
[E2] É possível medir a vazão por etapa da cadeia — captura, transporte, materialização, consumo?
[E2] Existe inventário de consumidores das bases do ADMS, com finalidade, criticidade e prazo tolerável por consumidor?
[D9, R31] O conector de captura (Debezium) pode ser reposicionado mais próximo do banco de origem, dentro do ambiente operacional? Quais as restrições técnicas reais, considerando a ausência de orquestração de contêineres na OT?
[D12, R40] Qual a viabilidade contratual de usar extração incremental por marcador temporal como alternativa ao upgrade de licenciamento Oracle estimado em R$ 6 milhões? O contrato de licenciamento ilimitado permite esse uso em nuvem, inclusive após o encerramento do contrato atual?
[E5] Considerando o modo de proteção do Data Guard (pergunta 7 do bloco de Segurança e Continuidade), qual é o RPO efetivo da replicação do banco corporativo hoje?

4. Rede e Telecomunicações¶

[E5, R35] Já existem as séries históricas de 30 a 90 dias de ocupação dos enlaces (média, pico, percentis, perda, variação de atraso), por direção, como recomendado pela própria Ata 13?
[E5] Qual o SLA contratado e o histórico de indisponibilidade dos links entre Paraíba e Minas Gerais?
[R36] Qual o cronograma atualizado do projeto de interconexão de data centers e da migração da segmentação TI/OT, hoje apoiada em VLAN, para a nova solução?
Existe teste ponta a ponta agendado do OMS na Paraíba contra os sistemas corporativos em Minas Gerais, medindo tempo de resposta de API, vazão de eventos e taxa de erros?
Existe enlace dedicado ou VPN em avaliação para a conectividade com a nuvem de dados? Qual o status dessa avaliação?

5. Fornecedor Schneider (ADMS)¶

[D1, R06] Qual a posição formal da Schneider sobre o defeito de produto em aberto relacionado ao processamento single-thread do adaptador?
[D1] Após a melhoria já aplicada pela Schneider, qual o limite de crescimento e o comportamento esperado em picos e cenários de tempestade? Existe dimensionamento formal?
[D1, R04] A Schneider aceita formalizar um acordo de comunicação prévia de mudanças em views, tabelas e colunas antes de aplicar atualizações em produção?
[E4] Existe posição formal da Schneider sobre o defeito em aberto relacionado à capacidade e ao backlog de processamento do adaptador ADMS?
[R26] Existe alternativa às views proprietárias e bibliotecas do produto que reduza o acoplamento atual, ou algum contrato de dados formal está em avaliação com o fornecedor?
Reunião única e objetiva consolidando as dúvidas sobre upgrades, views, bibliotecas e site switch — pendente desde a Ata 12: quando pode ser agendada?
[R45 — direcionada à equipe técnica interna do ADMS, não à Schneider] Existe inventário de protocolo de campo (DNP3, IEC 104, IEC 101 ou Modbus — os únicos suportados pelo produto conforme o manual do fabricante), quantidade e localização de RTUs/IEDs, e confirmação do modelo de cutover (RTU de porta dupla, listen-only, ou integração ICCP) para os SCADAs legados por fornecedor/regional (Siemens — EPB/ESE/EMG; EFACEC — EMS) em relação ao SCADA do ADMS, já em operação no G1?
~~A correspondência sugerida entre o mecanismo de retorno da integração SGM/EAM e os adapters SMR (envio, ReceiveWorksService) / SMN (retorno, SendWorksService) do catálogo de adapters do fabricante está correta?~~ Resolvido em 27/08/2026: confirmado por Norberto da Silva Prado (Energisa), no preenchimento da planilha catalogo-adapters-schneider-adms.xlsx — mesma resposta confirmou também OSR/ONT (fluxo WSROT do CRM/IVR) e o uso de AVL (sem sistema Energisa específico ainda nomeado). [ver 030-artefatos/integracao-manutencao-dms-adms.md e 030-artefatos/catalogo-adapters-schneider-adms.md]
O código "SICCO", citado no slide de integrações do ADMS de 30/06 mas sem correspondência em nenhum dos 12 domínios do framework corporativo, corresponde a que sistema? Segue como lacuna sem pista nas fontes disponíveis até 13/08/2026. [ver 030-artefatos/framework-dominios-funcionais.md]
O sistema AMI (produto do domínio 5, Proteção à Receita) tem alguma integração com o ADMS via o adapter AMI do catálogo do fabricante, ou os dois nunca foram conectados? [ver 030-artefatos/catalogo-adapters-schneider-adms.md]
O produto NetClima (domínio 3.2, DSS) troca dados meteorológicos com o ADMS via o adapter WDI do catálogo do fabricante? Esta é hoje só uma coincidência de tema (ambos lidam com clima), sem qualquer leitura estrutural de fluxo que sustente a hipótese — precisa de confirmação direta, não de inferência. [ver 030-artefatos/catalogo-adapters-schneider-adms.md]
O adapter AVL (Automated Vehicle Location), confirmado em uso por Norberto da Silva Prado em 27/08/2026 (ver pergunta 8 acima), integra com qual sistema do lado Energisa? É o mesmo mecanismo de geolocalização/roteirização via APIs do Google Cloud já citado em 030-artefatos/blueprint-componentes-adms.md (seção B.7) — hoje descrito ali como usado pela mobilidade e pelo WFM, não pelo ADMS diretamente? Se for o mesmo, isso contradiz essa afirmação e precisa de reconciliação; se não for, qual é de fato o sistema consumidor? [ver 030-artefatos/catalogo-adapters-schneider-adms.md e 095-as-is/hld-as-is-adms.md, seção "Lacunas e pendências de evidência"]

6. Engenharia de Dados / Data Lake (Databricks)¶

[E7, D12] Qual a topologia exata (nós, distribuição), o failover e o SLA do componente de integração entre o ambiente próprio e a nuvem — hoje descrito como ponto único de falha da cadeia analítica e regulatória?
[E7, D12] Existe teste de failover documentado para esse componente? Qual o plano para adotar conectividade dedicada com o provedor de nuvem?
[R37] Existe avaliação para substituir a retenção uniforme de sete dias na área de aterrissagem por classes de retenção conforme criticidade?
[R38] Existe cronograma para implantar regras mínimas de qualidade de dados — completude, validade, consistência — com quarentena?
[R39] Existe plano para implementar idempotência nos consumidores e captura incremental de estado nos conectores do data lake?
[E7] Quem é hoje o responsável formal pelo serviço de gravação em Go que substitui o conector comercial? Existe documentação e plano de sustentação?
[E7] Qual o plano para reenviar dados corrigidos e notificar o consumidor quando um erro é descoberto após a publicação, especialmente nas APIs regulatórias?

7. GIS e Integração GIS-ADMS¶

Nota de revisão (31/08/2026): follow-up formal de 5 itens enviado à equipe do GIS a partir de uma tabela de tempos e de uma planilha de 30 extrações, respondido por escrito na mesma data — ver 030-artefatos/integracao-gis-adms.md, seção "Confirmações e achados novos (31/08/2026)".

[D2] ~~Os números de performance da integração, hoje divergentes entre fontes documentais, podem ser resolvidos e formalizados em uma fonte única?~~ Parcialmente resolvido (31/08/2026): confirmado que "2-3h" é uma média entre Unidades sem meta formal (dado real: EMR≈54min/EMS≈1h53/ESS≈1h29) e que a Etapa 3 (ChangeSets/sincronização) é manual, sem SLA, e infla o tempo total observado. Ainda não fechado: reconciliação com o "~8h" do screenshot operacional — pode descrever escopo/processo diferente, não confirmado.
[E4] Qual é, de fato, a janela de propagação do GIS ao ADMS, e qual o comportamento observado com equipamentos recém-instalados dentro dessa janela?
[D2] Existe hoje algum mecanismo de reconciliação para eventos tardios originados dessa janela de propagação?
~~O envio do extrato XML por circuito (GIS → pasta SFTP → ADMS Staging) usa o Adaptador de Monitor de Arquivo do catálogo do fabricante, ou é um mecanismo próprio da Energisa/Minsait que só coincide na forma (pasta monitorada)?~~ Resolvido em 03/09/2026: a equipe do GIS confirmou o nome do serviço — FileMonitoringService, o mesmo nome do Adaptador de Monitor de Arquivo do catálogo do fabricante (p. 894). É o adapter padrão Schneider, não uma implementação própria da Energisa/Minsait. [ver 030-artefatos/catalogo-adapters-schneider-adms.md, seção "Confirmação do adaptador de arquivo do fluxo GIS"]
[Novo, 31/08/2026] Existe meta de tempo máximo de permanência nos estados Pendente/Inválido/Rejeitado dos extratos GIS antes de o caso ser tratado como incidente? Respondido: não existe definição de tempo máximo hoje. Percentuais de Pendente no momento da extração de dados variam muito por Unidade (42% EMR, 23% EMS, 11% ESS) — atribuído pela equipe à qualidade de cadastro e ao volume diário de alterações de cada Unidade, não a uma causa técnica única.
[Novo, 31/08/2026] ~~Confirmar o significado da sigla GAT~~ — respondido: Gerência de Automação e Telecom, uma das áreas que decide o reenvio prioritário de um alimentador no mesmo dia (junto com operação e cadastro).

8. CRM, Atendimento e Incidentes (Érica)¶

[E4] Pode ser documentado o fluxo ponta a ponta de incidentes — geração, agrupamento, retorno ao CRM, fechamento, reabertura e conciliação de eventos tardios?
[D3] Existe plano para adotar o padrão Transactional Outbox e correlation ID ponta a ponta nos fluxos de incidentes?
[D3] O agrupamento de incidentes pelo ADMS já causou, na prática, reaberturas ou duplicidades perceptíveis? Há registro desses casos?
[R43] Existe inventário atualizado de quais distribuidoras ainda dependem do caminho legado RabbitMQ → MSGOT (parâmetro global 70 do SIATT ainda não migradas para o ADMS)? Existe processo formal de corte/descomissionamento alinhado ao cronograma de migração para o ADMS?

9. WFM (Especialista)¶

Nota de revisão (13/08/2026): a pergunta original "existe avaliação em curso para evoluir a sincronização para integração incremental por API?" foi removida — está respondida: o eForce é exatamente essa evolução (API/Kafka), já em migração e com arquitetura interna documentada em 030-artefatos/integracao-wfm-eforce-ordem-servico.md (sessão de 12/08/2026 com o desenvolvedor responsável). As perguntas 1 e 2 abaixo permanecem em aberto — a sessão de 12/08 cobriu a arquitetura interna do eForce, não a volumetria do motor IQOS nem o histórico de falhas do SIGOD legado, que seguem sem especialista dedicado. As perguntas 3–5 são novas, originadas diretamente dos achados da sessão de 12/08.

[D4] Qual a volumetria e as janelas de processamento do motor de cálculo IQOS e das integrações do WFM? Ainda sem resposta — não coberto pela sessão de 12/08 (ver "Pendências que esta sessão não resolveu" em integracao-wfm-eforce-ordem-servico.md).
[D4] A sincronização de equipes do SIGOD legado por carga full já causou falhas, timeouts ou ausência de confirmação de processamento identificáveis? Há registro desses casos?
O fluxo de cadastro de equipe via CDC (SIGOD → GoldenGate → Kafka Connect → tópico Kafka → midler → grava direto no MongoDB do eForce, sem passar pela API) é tratado hoje como dívida técnica assumida por prazo. Existe previsão para corrigi-lo, passando a escrever via API como os demais midlers?
Os midlers MsGodIncorpManut e MsGodIncorpProj (ordens de serviço de manutenção e de projeto) aparecem como desativados na wiki interna do eForce — o desligamento é definitivo, ou esses fluxos foram apenas temporariamente pausados? Se definitivo, como ordens desses tipos são tratadas hoje?
~~A "Base ETL do IQS" (motor de cálculo IQS, ver integracao-wfm-adms.md) é o mesmo banco Oracle IQOS já catalogado como um dos 5 bancos corporativos (IQOS, GIS, FAR, ATD, PDA — ver blueprint-componentes-adms.md, seção C.1), ou uma base separada apesar do nome parecido?~~ Resolvido (08/09/2026): sim — "IQS" era o nome incorreto usado nas atas e nos artefatos; o motor de cálculo é o produto Onesait IQOS da Minsait, confirmado por Castellani. Ver nota de revisão abaixo.

10. F5 e API Management (Sensedia)¶

[D7] Os monitores hoje verificam disponibilidade da aplicação — health endpoint, código e conteúdo de resposta, dependências — ou apenas do servidor?
[D7] Existe política de nomenclatura formal para VIPs em avaliação ou já aprovada?
[D8] Existem testes de contrato de API no CI/CD hoje, ou o mecanismo de detecção de quebras continua reativo — backend refeito ou fallback criado após incompatibilidade?
[D8] Qual o plano para bloqueio de breaking changes e versionamento obrigatório de APIs?
[Decorrente do achado AVL, Bloco 5 pergunta 12] Dois tópicos Kafka do domínio WFM (wfm_coordenada_veiculo, wfm_coordenada_equipe) são candidatos a alimentar o adapter AVL via Sensedia, mas não há evidência da rota nem do consumidor que fecham esse caminho. Aproveitando o pedido, seria possível exportar, para todas as APIs do ADMS no Sensedia: (a) Catálogo de APIs + Interceptors — interface/contrato (OpenAPI) e regras de transformação JSON↔XML de cada API; (b) General Trace / Analytics dos últimos 30–60 dias — por API, chamador (app/client ID), volume, latência e erros (nível de metadado, sem payload completo)? O mesmo pacote deve ajudar a confirmar de uma vez as perguntas 10 (AMI) e 11 (NetClima/WDI) do Bloco 5. [ver 030-artefatos/catalogo-adapters-schneider-adms.md e 095-as-is/hld-as-is-adms.md, seção "Lacunas e pendências de evidência"]

11. Observabilidade e Monitoração¶

[E3] Existe matriz consolidada de ferramentas de observabilidade, com fonte oficial por tipo de ativo, validada pelas equipes?
[E3] Qual a volumetria real do tópico único de telemetria? Existe mapeamento das 151 aplicações emissoras?
[E3, D10] O tráfego no trecho do Kafka de telemetria está com TLS configurado de ponta a ponta? O mascaramento de dados pessoais nos logs está implementado?
[E3] Existe plano de expansão da instrumentação do Datadog além das três unidades cobertas hoje?
[R20] Existe algum monitoramento previsto para Azure e Databricks? Qual o plano para consolidar a telemetria multicloud?

12. DevOps¶

Qual o estado da conversa sobre replicação via OpenShift para os sistemas corporativos, sinalizada como prioridade pela própria equipe na sessão de DR de 03/08?
Existe automação prevista para o chaveamento entre sites no F5, reduzindo a dependência de change multiequipe manual?
[R44] Existe previsão no cronograma da frente de IaC (Terraform) para cobrir também os objetos do ksqlDB, hoje criados manualmente no Confluent Control Center, fora do pipeline automatizado de CI/CD que cobre os demais componentes do barramento?

13. Arquitetura e Coordenação do Projeto (G1)¶

[R34] Quais critérios objetivos de aceite de integração serão exigidos antes da entrada em produção do OMS em 01/09?
Quem é o responsável formal por consolidar as respostas deste questionário e levar as duas propostas de elevação de severidade (R20 e R22, ver matriz de riscos) à rodada de validação?

Como as respostas serão usadas¶

Cada resposta recebida move o item correspondente de "Hipótese a validar" ou "Risco potencial" para "Achado confirmado" (ou o descarta, se a resposta contradizer a hipótese) na próxima revisão da matriz de achados e lacunas, fecha a linha correspondente no mapa de evidências, e permite reavaliar a severidade dos riscos dependentes na matriz de riscos consolidada — incluindo as propostas de elevação de R20 e R22, hoje pendentes de validação. Nenhuma resposta deve ser tratada como definitiva sem registro documental, conforme a regra de ouro já estabelecida no mapa de evidências.

Nota de revisão (13/08/2026): regeneração da v0.1 (04/08/2026) para incorporar tudo que mudou nas fontes desde então — os três documentos-fonte (mapa de evidências, matriz de achados, matriz de riscos) seguem formalmente na versão v0.2 (data-base 28/07), mas a matriz de riscos já acumula R43, R44 e R45 fora dessa consolidação formal, e uma sequência de artefatos publicados entre 08/08 e 13/08 (catálogo de adapters Schneider, achados da sessão de 12/08 com o desenvolvedor do eForce, revisão do blueprint de componentes, mapa do domínio funcional e framework de domínios funcionais) trouxe lacunas próprias que ainda não tinham pergunta correspondente aqui. Mudanças desta revisão:

Bloco 2 (Plataforma e Barramento): duas perguntas novas — padrão corporativo de DLQ (sugestão do dev do eForce) e identidade da instância MongoDB do domínio WFM/eForce.

Bloco 5 (Fornecedor Schneider): cinco perguntas novas — inventário de protocolo de campo/RTU/IED e modelo de cutover do SCADA (R45, endereçada à equipe técnica interna, não à Schneider), confirmação da correspondência SMR/SMN na integração SGM, o código SICCO sem correspondência no framework corporativo, e se AMI e NetClima/WDI de fato integram com o ADMS via os adapters homônimos do catálogo — os dois vindos do mapeamento Adapter→Sistema em 030-artefatos/catalogo-adapters-schneider-adms.md.

Bloco 7 (GIS): uma pergunta nova sobre se o fluxo de extrato XML por circuito usa literalmente o Adaptador de Monitor de Arquivo do catálogo do fabricante.

Bloco 8 (CRM/Atendimento): uma pergunta nova sobre o inventário de distribuidoras no caminho legado RabbitMQ/MSGOT (R43).

Bloco 9 (WFM): reescrito. A pergunta sobre evolução para integração via API foi removida — já respondida pelo achado do eForce. As duas perguntas sobre volumetria do IQOS e histórico de falhas do SIGOD legado permanecem em aberto, explicitamente não cobertas pela sessão de 12/08. Duas perguntas novas sobre achados dessa sessão: correção do bypass de API no CDC de cadastro, e status dos midlers desativados. Uma terceira pergunta cogitada nesta revisão — cronograma de outbox pattern com MongoDB Change Streams — foi descartada antes de entrar no documento: era um brainstorm do próprio Castellani durante a sessão de 12/08, não uma proposta da Energisa nem algo sob avaliação — não é uma lacuna real a perguntar. A mesma correção de atribuição foi feita em integracao-wfm-eforce-ordem-servico.md.

Bloco 12 (DevOps): uma pergunta nova sobre a cobertura do ksqlDB pela frente de IaC (R44).

Nenhuma pergunta de outros blocos foi revisada nesta rodada — permanece como trabalho pendente confirmar se achados de sessões mais antigas (Atas 01–14) também mudaram de status desde 28/07, fora do escopo desta atualização pontual.

Nota de revisão (13/08/2026, pontual): adicionada ao Bloco 9 (WFM) uma pergunta sobre se a "Base ETL do IQS" é o mesmo banco Oracle IQOS (um dos 5 bancos corporativos catalogados em blueprint-componentes-adms.md, C.1) ou uma base separada — os dois nomes são parecidos o suficiente para gerar confusão, mas nenhum artefato confirma que são a mesma coisa. Pendência já registrada em catalogo-adapters-schneider-adms.md, só sem pergunta correspondente aqui até agora.

Nota de revisão (08/09/2026): a pergunta 5 do Bloco 9 está resolvida — "IQS" era o nome incorreto usado nas atas e nos artefatos deste assessment; o motor de cálculo é de fato o produto Onesait IQOS da Minsait (mesmo banco Oracle IQOS catalogado em blueprint-componentes-adms.md, C.1), confirmado por Castellani (Syntropy Labs). Referências normalizadas para "IQOS" nos artefatos derivados (as atas/evidências originais mantêm o termo "IQS" como registrado na sessão).

Nota de revisão (14/08/2026, pontual): adicionado ao Bloco 2 (Plataforma e Barramento) um checklist de confirmação de licenciamento por componente, cruzando o inventário de uso confirmado na Ata 10 (010-evidencias/100-openshift-confluent-kafka.md) com o que segue sem confirmação formal de licenciamento — inclui os três componentes discutidos neste ciclo de brainstorming de arquitetura (OpenShift Serverless/Knative, Pipelines/Tekton, GitOps/ArgoCD) como itens sem evidência de uso nem de licenciamento em nenhuma sessão, e registra o achado sobre o MinIO community ter entrado em modo somente-leitura desde abril/2026 (upstream arquivado) como motivo adicional para não tratar a instância experimental da Paraíba como caminho produtivo sem revisão. Duas perguntas novas (16–17) sobre cobertura do OperatorHub e plano de descontinuação/upgrade do MinIO.

Nota de revisão (17/08/2026, pontual): adicionada ao Bloco 2 (Plataforma e Barramento) a pergunta 18, pedindo o schema Avro por empresa das tabelas candidatas a um piloto de consolidação e o texto completo (não truncado) das queries persistentes do ksqlDB — evidência necessária para validar a proposta de brainstorming 030-artefatos/propostas-barramento-ksqldb/proposta-1-debezium-topic-routing.md (PR #49), aberta neste mesmo ciclo. Correção de uma edição anterior no mesmo dia: a pergunta havia sido inserida por engano como um novo "16", antes do checklist de licenciamento — colidindo com as perguntas 16 e 17 já existentes (adicionadas em 14/08, acima) e já publicadas nas PDFs por bloco (Questionários/02-questionario-plataforma-e-barramento-openshift-confluent-kafka.pdf, gerada 14/08). Corrigido movendo a pergunta para o final do bloco, como item 18, sem renumerar as perguntas 1–17 já distribuídas.