Etapa 1
SGVP Local
Front, Back e banco rodam dentro da Câmara. Predominantemente infraestrutura. Transcrição, biometria, assinatura e e-mail continuam saindo para a internet.
Premissa obrigatória
Com a internet fisicamente desconectada, todas as funções essenciais de uma sessão plenária continuam funcionando normalmente dentro da rede local.
Nenhuma parte necessária à sessão pode depender de CDN, API externa, AWS, Railway, Pusher, Google Fonts, bibliotecas carregadas pela internet ou validações remotas. A internet pode existir como recurso complementar — nunca como requisito.
link WANDESCONECTADO
servidor + terminaisreiniciados
sessão plenáriaOPERACIONAL
requisições obrigatórias à internet0
Local não é o mesmo que offline
O estudo mistura dois objetivos. Instalar o SGVP no prédio não garante, sozinho, operação sem internet — este backlog adota o segundo como requisito.
Etapa 2
SGVP 100% Offline
Além de rodar localmente, continua operando com queda total da internet. Exige mudanças de produto no Back-End e no Front-End, além da infraestrutura autônoma.
Três frentes, uma regra cada
Front e Back tornam o SGVP portável; DevOps transforma essa portabilidade em uma instalação repetível, segura e administrável.
Arquitetura homologada
Tudo dentro do retângulo continua funcionando mesmo que o cabo WAN do firewall seja retirado.
Funções essenciais da sessão
Precisam funcionar sem internet.
Decisões pendentes
Bloqueiam a definição final de alguns cards.
Quem faz o quê
Atividades compartilhadas mostram o papel de cada frente: o Back-End define a estrutura do banco, DevOps instala e executa.
| Atividade | Front-End | Back-End | DevOps / Infra |
|---|
| ID | Área | Épico | Tipo | Prioridade | Título | Apoio |
|---|
Casos de teste para o tester
Cada caso indica pré-condições, passos com resultado esperado e evidências a anexar. Registre o status e as observações; a execução fica salva neste navegador e pode ser exportada como relatório.
Cada dependência externa e seu tratamento sem internet
Mesmo com o servidor dentro da Câmara, estes serviços continuam saindo para a internet se nada for alterado.
| Serviço | Hoje | Estratégia | Alvo offline | Pendência | Cards |
|---|
Regra do navegador
O servidor estar na Câmara não basta: o navegador também precisa carregar 100% dos recursos pela LAN.
PODEservidor SGVP local · storage local · WebSocket local
NÃO PODEqualquer destino na internet, inclusive os chamados por bibliotecas
Domínios proibidos na aba Network
Destinos esperados
sgvp.localapi.sgvp.localstorage.sgvp.local192.168.50.10
Dependências transitivas
Baixar a biblioteca não resolve se ela, ao executar, buscar algo fora.
Aplicação SGVP
↓
Biblioteca A — em /vendor (local)
↓ carrega em runtime
Biblioteca B, worker, config, idioma ou fonte
↓
CDN externa → reprova o requisito
Card relacionado:
Bibliotecas a auditar
Marque conforme cada uma for localizada e tiver as chamadas em runtime verificadas. O progresso fica salvo neste navegador.
Onde procurar no código
Não basta procurar <script> e <link>: inclua @import, url(), chamadas dinâmicas e o conteúdo das próprias libs.
Validação no DevTools
Roteiro de homologação isolada
A WAN precisa ser retirada de fato — bloquear URLs específicas não comprova nada.
Critério de aprovação
0 requisições obrigatórias para a internet, com todos os 16 passos concluídos.
Caso de teste: · Cards:
Captura de tráfego em paralelo
Execute no servidor durante todo o roteiro. Ajuste a sub-rede à da Câmara.
Hardware de referência
Base nas medições do ambiente atual; o recomendado considera crescimento de logs, backups e serviços locais.
| Item | Mínimo | Recomendado |
|---|
Nomes locais
Resolvidos pelo DNS local, com certificados da SGVP Root CA.
Membros da VLAN SGVP
Pacote de instalação
Imagens carregadas com docker load antes do docker compose up -d — nada vem do Docker Hub.
Pacote de release
O pipeline externo produz o artefato completo; a Câmara não executa npm install nem composer install.