Pular para o conteúdo
Logotipo InfraMov — Observatório de Mobilidade
02 · Modelo do site

Roadmap estrutural do InfraMov

Este roadmap não organiza pesquisas sobre cidades. Ele organiza a evolução do próprio observatório: modelo de dados, navegação, governança editorial, experiência e capacidade de manutenção.

Regra de separação

A Agenda responde “o que investigar?”. Este roadmap responde “como o site deve evoluir para receber conhecimento sem se desorganizar?”. O Manual responde “como o Codex deve trabalhar?”.

Agora
M01
Modelo de dados

Cobertura territorial por evidência

Cada cidade mostra o que está documentado, o que é apenas indicado e quais camadas ainda estão ausentes.

Por que agora: A entrada de JET, Uber Moto, táxi e ciclovias mostrou que disponibilidade anunciada não é a mesma coisa que popularidade, cobertura ou impacto.
Guardrails
  • • Separar cidade, organização, serviço e fonte.
  • • Não preencher lacunas por inferência silenciosa.
  • • Permitir evolução sem duplicar entidades.
Dependências
  • • MobilityServicePresence
  • • Validador de conteúdo
  • • Cobertura das cidades
M02
Experiência

Cidades como eixo de navegação

A cidade selecionada organiza contexto, leituras, comparações e serviços sem prender a plataforma a uma única cidade.

Por que agora: O observatório já é multi-cidade e recebe novas camadas com ritmos diferentes.
Guardrails
  • • Manter visão geral sem foco territorial.
  • • Permitir trocar cidade sem perder contexto.
  • • Exibir status de cobertura com baixa carga visual.
Dependências
  • • Seletor de cidade
  • • Rotas de cidade
  • • Estado de foco
M03
Governança

Evolve separado em agenda, método e modelo

Pesquisas de conteúdo entram na Agenda; decisões estruturais entram neste roadmap; regras de execução ficam no Manual.

Por que agora: A pesquisa JET evidenciou uma mudança do modelo, não apenas uma nova pesquisa: precisamos registrar presenças territoriais sem criar exceções.
Guardrails
  • • Não usar a Agenda para esconder decisões de produto.
  • • Registrar aprendizados do método após cada pesquisa.
  • • Manter registros históricos distintos do planejamento atual.
Dependências
  • • Manual do Codex
  • • Agenda de pesquisa
  • • Registro de versões
M07
Modelo de dados

Futuros como camada dinâmica do observatório

A rota /futuros apresenta gráficos, linha de base, cenários e sinais alimentados por datasets de cidade, sem carregar a documentação do método.

Por que agora: A antiga rota acumulava framework, documentação e leitura territorial. A separação permite que o Evolve evolua o método sem remodelar a experiência pública a cada pesquisa.
Guardrails
  • • Toda série declara unidade, data, natureza, fonte e limitação.
  • • Cenários são hipóteses, nunca previsões ou políticas aprovadas.
  • • Cidade sem dataset prospectivo mostra lacuna, não conteúdo genérico.
Dependências
  • • CityFutureDataset
  • • Agenda P007
  • • Validador de conteúdo
  • • Pesquisas e análises
M08
Experiência

Navegação contínua e transições compreensíveis

O usuário mantém acesso ao contexto, à cidade em foco e à navegação durante a leitura, enquanto mudanças de rota e conteúdo acontecem sem saltos ou flashes desorientadores.

Por que agora: A plataforma já reúne páginas longas, menus contextuais e troca de cidade; sem uma camada comum de continuidade, cada mudança pode parecer uma quebra de estado.
Guardrails
  • • Cabeçalho compacto e navegável durante a rolagem.
  • • Transições devem preservar posição e contexto, sem bloquear interação.
  • • Respeitar prefers-reduced-motion e não usar animação para esconder carregamento ou ausência de dado.
Dependências
  • • SiteHeader
  • • Estado de cidade
  • • Transições do roteador
  • • Revisão visual em viewport pequena e grande
Próximo
M04
Modelo de dados

Contratos comuns para fontes e indicadores

Fontes, datas, confiabilidade, validade e metodologia passam a ser reutilizáveis em cidades, organizações, infraestrutura e pesquisas.

Por que agora: Os dados já precisam carregar níveis diferentes de evidência, mas ainda usam contratos próximos e não totalmente unificados.
Guardrails
  • • Data da fonte não é data da revisão.
  • • Indicador sem metodologia não entra como métrica comparável.
  • • Histórico não deve ser apagado quando fica antigo.
Dependências
  • • SourceRef
  • • Pesquisa
  • • CityDataset
  • • Validações
M05
Experiência

Catálogos orientados por relações

Usuário navega de cidade para serviço, organização, infraestrutura e pesquisa por relações reais, não por listas isoladas.

Por que agora: A mesma Uber ou 99 pode ter serviços distintos em várias cidades, e JET é relevante em Ubatuba sem ser uma operadora de ônibus.
Guardrails
  • • Relações devem ter sentido semântico.
  • • Não transformar todo vínculo em destaque editorial.
  • • Filtros devem respeitar a ausência de evidência.
Dependências
  • • Organizações
  • • Presenças territoriais
  • • Comparador
Depois
M06
Performance

Dados locais com atualização controlada

A plataforma poderá revisar fontes e atualizações sem depender de reconstrução manual de páginas ou de uma base remota imediata.

Por que agora: A base ainda é local-first; antes de conectar serviços externos, precisamos estabilizar contratos e fluxo editorial.
Guardrails
  • • Nenhuma sincronização automática sem fonte e política de revisão.
  • • Preservar o modo estático/local como fallback.
  • • Auditar mudanças antes de alterar dados públicos.
Dependências
  • • Contratos de dados
  • • Fila de revisão
  • • Estratégia futura de persistência