Resultado da validação

Data: 13/10/2026 · Escopo: portal documental e modelagem de dados. Ambiente: Windows, Python 3.14, dependências fixadas, Playwright 1.56.0 com Microsoft Edge instalado.

Resultados

Verificação	Resultado
mkdocs build --strict	Aprovado, sem avisos de navegação/links
Navegação	53 páginas Markdown incluídas; 54 HTML contando a página 404
Links e assets locais	Todas as referências verificadas no HTML, sem destino ou âncora ausente
Acervo original	Sete textos e 16 imagens intactos; catálogo com três frases adequadas ao escopo backend e hash original registrado; hashes conferidos com LF normalizado
Fontes de código	444 links registrados; paths existentes nos commits Git locais indicados
Navegador real	Todas as 53 páginas abertas; navegação de dados, infraestrutura e arquitetura exercitada
Mermaid	47 diagramas em 23 páginas, incluindo 23 diagramas novos de dados; sem erro de sintaxe/runtime
Pesquisa	Consulta por TenantResolver retorna o BFF
Navegação interativa	Abas Arquitetura, Modelagem de dados e Infraestrutura; links de domínio Core, Templates e Scheduler
Links antigos	Dez âncoras do tutorial na raiz encaminham para a seção preservada
Visualização móvel	Largura 390 px sem overflow horizontal do documento; diagramas/tabelas possuem áreas próprias de rolagem
Assets externos	Nenhuma requisição externa necessária; validador bloqueia rede externa do navegador
Dependências Linux/Python 3.12	Resolução pip --dry-run aprovada na etapa anterior; dependências não alteradas nesta etapa
Docker / pipeline remoto	Não executados nesta tarefa documental

Revisão do escopo backend

Inventário limitado a 23 repositórios backend e dois de infraestrutura. Revisadas todas as páginas e os diagramas: consumidores permanecem externos; o cluster contém apenas backend e infraestrutura associada. Não restam seções de implementação de consumidores nem referências a seus repositórios. A navegação existente continua válida, sem páginas removidas. A regra permanente está na governança.

Separação de ambientes

A revisão distingue ambientes corporativos, ambiente local e estudos experimentais na navegação. A infraestrutura e os deployments corporativos são de responsabilidade do TOTVS Apps, com documentação oficial própria. O diagrama lógico não fixa o controller corporativo; a integração específica do ambiente local aparece na sua visão própria. Istio/Gateway API não aparecem nos diagramas principais como adoção oficial. Tutoriais e propostas históricas exibem avisos de escopo experimental/local sem alteração dos arquivos originais nesta revisão.

A validação de navegador também percorre as três categorias de infraestrutura e verifica os avisos do acervo experimental. Não houve execução de testes operacionais ou alteração de ambientes.

Diagramas validados

Página	Visões
Arquitetura lógica	Contexto, administração, políticas, execução, segurança, resolução e persistência (7)
Dependências	Outbox/publicação, invalidação e importação (3)
Ambiente local	Entrada e estado/eventos do Core (2)
Referência cloud	Relações propostas e tabela de recursos (1)
BFF	Transporte, tenant/limites, preparação e resultado HTTP (4)
Control Plane — integrações	Sete visões administrativas por domínio (7)
Dados — panorama e domínios	Visão geral (1), Core (2), Templates (2), nove outros domínios (9)
Dados — contratos transversais	Relações (1), versionamento (3), ownership (1), Redis (2), eventos (2)

Mermaid 11.12.0 permanece local e os diagramas editáveis em Markdown. Os estilos comuns são aplicados por hooks/diagrams.py, com configuração em hooks/mermaid.json e CSS em docs/assets/stylesheets/mermaid.css. A paleta segue o seletor claro/escuro do Material. A imagem do arquiteto foi preservada.

A validação visual cobre larguras desktop de 1280 e 1440 px nos dois temas: sem rolagem horizontal nas figuras, fontes de pelo menos 14 px, sem sobreposição de nós ou corte de rótulos e contraste textual de pelo menos 4,5:1. Capturas de cada figura ficam em validation-output/diagrams/, junto das medições em results.json. A inspeção visual complementa essas medidas, incluindo setas, agrupamentos e legibilidade.

Artefatos e limites

O procedimento salva validation-output/browser-results.json, inicio-desktop.png, bff-desktop.png e bff-mobile.png. Esses artefatos locais estão ignorados pelo Git para não versionar saídas geradas. As capturas foram inspecionadas nesta entrega.

URLs externas não foram autenticadas ou verificadas remotamente. Links de código requerem acesso corporativo e disponibilidade do commit no servidor; a validação comprova o objeto Git local. Testes de microserviços, deployment cloud e comportamento distribuído não foram executados. Os testes existentes foram consultados como evidência documental.

Veja o procedimento reproduzível. A modelagem dos bancos está disponível para revisão; fluxos E2E detalhados permanecem como próxima etapa.

Onboarding de desenvolvimento

Validação executada em 16/10/2026, no Windows/PowerShell, com JSON Handler no commit cc52b48774b14113fe5eae2bafc64ff398744b6e e Infra Local em 5ad5ccf44bde1eb8c189634bfabc3a52bbc1ba5e. O Primeiro deploy local contém a sequência reproduzível.

Procedimento executado	Resultado
Atualização Git dos repositórios consultados	pull --ff-only, sem novas alterações recebidas nesta execução
JSON Handler: mvnw.cmd verify, Java 21	Build aprovado; 131 testes Surefire, zero falhas/erros/ignorados; Failsafe desabilitado pelo POM
Dockerfile JVM e execução Docker	Imagem construída; readiness UP e geração de JSON Schema com campos string/integer
Carregamento no Kind totvs-gateway	Duas tags carregadas nos quatro nós do cluster existente
Chart JSON Handler, namespace exclusivo	Instalação e atualização concluídas com imagePullPolicy: Never; rollout aprovado
HTTP via Service/port-forward após cada rollout	Readiness UP e resposta funcional com tipos esperados
Helmfile NGINX / local-win list	Leitura da composição concluída; não executa instalação
Encerramento	Container, port-forwards, release e namespace do exercício removidos; clusters existentes preservados

A segunda tag utiliza o mesmo código: comprovou atualização do Pod template e da imagem selecionada, não uma mudança funcional. As imagens permanecem disponíveis localmente.

Limites da execução: não foram executados clone em máquina limpa, criação de um novo Kind, bootstrap integrado por Helmfile, builds nativos, execução Go ou sessões de debug. O build Maven utilizou o cache disponível. A tentativa de build Docker do Router foi bloqueada por permissão de download das imagens-base privadas. Os comandos desses caminhos foram conferidos nos arquivos indicados, sem atribuir-lhes validação funcional.

Correção na revisão de debug remoto: o BFF possui quarkus.http.non-application-root-path=/gateway/q. Portanto, sua raiz HTTP / não caracteriza divergência com as probes /gateway/q/health; o diagnóstico foi corrigido documentalmente.

Validação do portal nesta revisão: build mkdocs build --strict aprovado; 78 páginas HTML e 9.408 links/recursos locais verificados, 24 arquivos preservados e 462 referências de código verificadas nos objetos Git, sem erros. No Edge, 77 páginas abertas, 48 diagramas Mermaid renderizados, navegação, busca e 10 bookmarks antigos aprovados. Home e tutorial inspecionados em 1440 e 390 px, nos temas claro/escuro, sem overflow horizontal da página. O servidor temporário registrou conexões canceladas durante a navegação, sem erros HTTP/JavaScript no relatório do navegador.

Debug remoto Java no Kind

Validação em 16/10/2026. Infra Local 5ad5ccf44bde1eb8c189634bfabc3a52bbc1ba5e; BFF 4c0161acad09968433589f132dd640dcf624bec9. Os repositórios consultados foram atualizados com pull --ff-only, sem mudanças recebidas.

Verificação executada	Resultado
Renderização dos quatro charts com global.devMode=true/false	Oito renderizações aprovadas; porta 5005 e variáveis presentes em true e ausentes em false
Dependências e renderização do agregador	helm dependency build em cópia temporária dos charts; true habilitou os quatro containers, false nenhum. Arquivos originais preservados
Helmfile NGINX local-win, seletor name=totvs-gateway-server, list	Release declarada em default; Deployments em totvs-gateway
BFF já em execução no Kind	JAVA_DEBUG=true, porta 5005 e processo Java com -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
Entry point da imagem em execução	debug-options interpreta JAVA_DEBUG e JAVA_DEBUG_PORT; argumento observado coincide com o processo
Port-forward do Pod BFF	Bind local 127.0.0.1:15005 para 5005; handshake JDWP e comando VirtualMachine.Version aprovados
HTTP do mesmo Pod	/gateway/q/health/ready retornou 200; /q/health/ready retornou 404
Outros processos consultados	Core executa JVM com JDWP; Scheduler e Object Storage executam ./application native, apesar das variáveis declaradas

O deployment BFF já tinha debug habilitado e foi preservado. Não foram aplicados upgrades nem alternância true/false no cluster compartilhado; essa alternância foi validada na renderização. O port-forward de teste foi encerrado. Nenhuma imagem, Dockerfile, chart ou código de negócio foi modificado.

Os passos de IntelliJ IDEA e VS Code foram conferidos nas documentações oficiais, mas não executados nas IDEs. Não foi realizado teste de breakpoint/requisição autenticada nem comprovada correspondência entre o commit atual dos fontes e a imagem já implantada. A confirmação executada cobre agente JDWP, protocolo e conectividade; o tutorial orienta a validação de breakpoints com fontes e imagem correspondentes.

Portal: build estrito aprovado; verificação de 79 HTML, 9.630 links/recursos locais, 24 arquivos preservados e 472 referências Git, sem erros. Navegação para o tutorial, links cruzados e renderização em Edge conferidos em 1440/390 px e temas claro/escuro, sem overflow horizontal da página nem erros JavaScript. Capturas locais em validation-output/debug-java-*.png.

Instalação completa local — 17/10/2026

Consulte o registro das correções locais para renderizações, builds e testes do mock. Nenhuma alteração foi aplicada ao Kind; os cenários funcionais A/B permanecem pendentes.