Carregando
Preparando o conteúdo
Aguarde enquanto os dados da página são carregados.
Aguarde enquanto os dados da página são carregados.
A V1.0E consolida a infraestrutura já validada: leitura remota com fallback, autenticação, escrita controlada, auditoria e critérios explícitos de recuperação e encerramento.
A rota /ods passa por uma camada de leitura que tenta o espelho Supabase, verifica paridade e usa a base remota somente quando os 17 registros coincidem integralmente com a linha de base.
Abrir mapa dos ODSA página de diagnóstico mostra modo configurado, contagens, fingerprints, divergências e latência sem expor chaves ou habilitar qualquer mutação.
Ver paridade do SupabaseO painel administrativo exige sessão válida e perfil ativo. Somente admin pode salvar ou cancelar rascunhos ODS; o catálogo canônico permanece sem mutação direta.
Abrir rascunhos dos ODSAbrir operação da V1.0A autenticação comprova quem acessa o painel; a autorização depende do perfil. Na V1.0D, a escrita ocorre somente por RPC autenticada e sempre gera auditoria.
Ver sequência da V1.0A V1.0 não substitui a base estática de uma vez. O Supabase entra primeiro como espelho isolado, depois como fonte de leitura paralela e somente após a paridade comprovada recebe fluxos administrativos de escrita.
Os arquivos TypeScript permanecem preservados até a estabilização final. Na V1.0B, ausência de configuração, erro remoto, timeout ou divergência de conteúdo fazem o repositório retornar automaticamente à leitura estática, sem apagar dados nem reescrever o histórico.
A contagem abaixo é calculada diretamente a partir dos módulos atuais. Ela funciona como linha de base para os testes de paridade da migração.
Catálogo de referência dos 17 ODS usado em políticas, indicadores, séries e sínteses.
Número do ODS único entre 1 e 17; não permitir exclusão quando houver vínculos.
Registro mestre de bases, órgãos, URLs, prioridade e cuidados metodológicos.
ID estável e URL rastreável; fonte em uso não pode ser removida sem revisão de dependências.
Matriz ODS-S1 com 115 políticas e seus vínculos principal/secundários aos ODS.
Preservar o ID ODS-S1 como chave de negócio e normalizar todos os vínculos ODS.
Relação N:N com tipo de vínculo principal ou secundário.
Uma política pode ter somente um ODS principal e não pode repetir o mesmo ODS.
A camada atual é parcialmente derivada das políticas; a migração deve gerar um snapshot inicial revisável.
Cada registro deve manter política, status, confiança, URL, data de atualização e autoria da revisão.
Catálogo dos 34 indicadores e seus vínculos com políticas públicas.
Preservar IND-ODS-xxx; ODS e fonte devem existir antes do indicador.
Relação N:N entre políticas e indicadores formais do Observatório.
Não aceitar vínculo com política ou indicador inexistente; impedir duplicidade do par.
Ficha técnica completa de conceito, fórmula, unidade, periodicidade, fonte, limitações e auditoria.
Relação 1:1 com indicador; fórmula e regra de auditoria obrigatórias antes de publicar novas coletas.
Valores oficiais iniciais e itens de contexto municipal que ainda não formam série completa.
Valor, ano, unidade, fonte, URL, confiança e data de coleta devem permanecer rastreáveis.
Estrutura temporal com séries, pontos anuais, eventos e controle de comparabilidade.
Não duplicar ano/período na mesma série; manter fonte e situação em cada ponto.
Comparações territoriais, observações e seis critérios de compatibilidade por benchmark.
Métricas relativas só podem ser publicadas quando os seis critérios essenciais forem aprovados.
Resultados derivados que devem ser recalculados a partir da base canônica e, quando publicados, congelados como snapshot auditável.
Snapshot deve registrar versão do algoritmo, data de cálculo e referências de entrada.
O desenho separa fatos canônicos, relações, resultados derivados e governança. Essa separação reduz duplicidade, facilita auditoria e impede que scores ou rankings calculados sejam confundidos com dados primários.
Registrar commit, contagens e versão dos arquivos TypeScript antes de qualquer carga externa.
Working tree limpo, commit identificado e inventário V1.0A revisado.
Nenhuma alteração em produção; continuar usando os arquivos atuais.
Criar tabelas, chaves, constraints e políticas iniciais sem conectar o site ao banco.
Schema vazio validado e sem escrita pública habilitada.
Descartar o ambiente isolado; produção não é afetada.
Carregar ODS, fontes, políticas, indicadores, metadados e relacionamentos.
Paridade de contagem e amostras de integridade aprovadas.
Limpar somente o schema isolado e repetir a carga; arquivos TypeScript permanecem intactos.
Carregar coletas, séries, pontos, eventos, benchmarks, observações e critérios do gate.
Contagens idênticas e resultados derivados reproduzidos a partir das mesmas entradas.
Recriar o schema isolado; nenhum corte de produção é necessário.
Adicionar repositórios de dados com fallback explícito para a base estática.
Páginas críticas apresentam paridade visual e numérica usando Supabase em modo leitura.
Definir a fonte de dados como static e redeployar.
Criar login, sessão SSR, perfis ativos e papéis admin/editor antes de qualquer fluxo de mutação.
Login, bloqueio sem sessão, perfil inativo, papel autorizado, painel read-only e logout aprovados.
Desabilitar o acesso administrativo sem alterar a leitura pública ou o fallback.
Permitir que admin salve propostas ODS em tabela separada e registrar cada mutação em trilha append-only.
Rascunho salvo, auditoria conferida, editor bloqueado, cancelamento sem DELETE e paridade pública preservada.
Cancelar o rascunho e manter public.ods intacta; nenhuma publicação é executada na V1.0D.
Executar preflight, painel operacional, recuperação, snapshot e checklist final antes de expandir os domínios.
Sem falha crítica, migrations alinhadas, rollback comprovado e runbook revisado.
Manter a V1.0D em operação; nenhum schema novo é obrigatório para a V1.0E.
Leitura: Somente registros publicados
Escrita: Nenhuma
Aprovação: Nenhuma
Auditoria: Sem acesso
Leitura: Base publicada + rascunhos autorizados
Escrita: Nenhuma na V1.0; consulta interna
Aprovação: Não publica
Auditoria: Visualiza o próprio histórico
Leitura: Base completa
Escrita: Comentar, revisar e corrigir
Aprovação: Aprovar ou devolver
Auditoria: Consulta alterações do escopo revisado
Leitura: Base completa
Escrita: Gerenciar dados e usuários
Aprovação: Publicação e reversão controlada
Auditoria: Consulta integral; não apaga logs
Os arquivos TypeScript atuais continuam sendo a fonte de fallback após o encerramento da V1.0E.
Nenhuma tabela existente é apagada, truncada ou substituída durante a V1.0B.
A V1.0C adiciona autenticação administrativa sem service role e sem liberar escrita nos dados públicos.
A V1.0D libera somente rascunhos ODS por RPC autenticada; public.ods continua sem UPDATE direto.
IDs públicos atuais — ODS-S1, IND-ODS, SER e BENCH — devem ser preservados como chaves de negócio.
Dados derivados são recalculados a partir da base canônica; snapshots precisam registrar versão e data.
O gate metodológico continua bloqueando métricas quando qualquer critério essencial falhar.
Toda futura escrita administrativa da V1.0D precisa produzir trilha de auditoria append-only.
O rollback da leitura deve continuar possível apenas trocando a fonte para static e reiniciando ou redeployando.
A V1.0E não exige nova migration; estabilização não deve introduzir mudança de schema sem necessidade.
A V1.0 só deve ser fechada após preflight local, migrations alinhadas, paridade perfeita, fallback comprovado, autenticação protegida e ciclo de auditoria validado.
Abrir painel operacional