Modo Offline First: o que a recepção ainda consegue fazer sem internet
A rota /sync-center guarda uma fila local de ações e sincroniza tudo com o servidor quando a conexão volta — sem confiar cegamente no que foi feito offline.
O Modo Offline First não é offline total: consultas, tarefas, cadastro básico de paciente e status de conversa continuam funcionando sem internet, numa fila local que sincroniza depois. Login, IA, cálculos financeiros e importação exigem conexão — por desenho, não por limitação técnica escondida.
O que acontece na tela quando a internet da clínica cai?
A recepção continua vendo os dados já carregados — agenda do dia, pacientes, tarefas — porque essas telas ficam guardadas no banco local do navegador (IndexedDB). Um aviso indica que a conexão caiu, mas a tela não trava nem some.
Se a página que a pessoa tentar abrir nunca foi visitada antes, o Service Worker mostra a página de fallback `/offline` em vez de um erro genérico do navegador. É uma resposta prevista, não uma falha silenciosa.
A rota `/sync-center` é o painel dessa camada: mostra o que está pendente de sincronizar e o que já foi confirmado pelo servidor.
Como funciona a fila local que guarda as ações feitas offline?
Cada ação permitida offline — confirmar uma consulta, criar uma tarefa, editar o contato de um paciente — entra numa fila de mutações pendentes dentro do IndexedDB, organizada por clínica e por usuário. Nada é descartado enquanto a internet não volta.
Quando a conexão retorna, o Modo Offline First envia essa fila para o servidor na ordem em que foi registrada. Cada item sai da fila só depois de ser processado — não antes.
Isso separa a experiência (a recepção não para de trabalhar) do dado oficial (o que vale é sempre o que o servidor confirma).
O que o servidor faz com uma ação que veio de quando a clínica estava offline?
Tudo que sai da fila local é revalidado no servidor como se tivesse sido feito online agora — mesmas regras de permissão, mesmas checagens de estado. O sistema não confia cegamente no que veio do dispositivo offline.
Isso existe porque, entre o momento em que a ação foi registrada offline e o momento em que ela chega ao servidor, o mesmo dado pode ter mudado por outra via — outro usuário, outro dispositivo. A revalidação é o que evita um conflito silencioso.
Os logs de sincronização, guardados também no IndexedDB, registram o que foi enviado e o resultado de cada item — isso é o que aparece no painel do `/sync-center` quando a recepção quer conferir se tudo foi realmente confirmado.
O que continua funcionando sem internet, na prática?
Consultas: confirmar, marcar comparecimento, marcar falta. Tarefas: criar, concluir ou iniciar, ajustar prazo. Pacientes: criar cadastro básico, editar contato ou origem, registrar opt-out.
Conversas: mudar status, sem enviar nada para fora do sistema. Oportunidades: mudar status, definir próxima ação. Orçamentos: registrar follow-up, marcar como ganho ou perdido.
Item do Plano de Receita da Semana: mudar status. Notificações: marcar como lida ou resolvida. É o conjunto de ações do dia a dia da recepção — não é o produto inteiro funcionando sem rede.
O que exige internet e não tem alternativa offline?
Login, aceitar convite e recuperar senha exigem conexão — autenticação nunca roda a partir de dado guardado localmente. Qualquer coisa que dependa de IA assistiva também exige conexão, incluindo gerar o Plano de Receita da Semana.
Recalcular o Dashboard, o Modo Dono e o Painel de Dinheiro Vazando também depende do servidor, porque são agregações que precisam do dado mais recente de toda a clínica, não só do que já está no dispositivo.
Jobs e automações, importação de CSV e o painel administrativo (equipe, permissões, configurações) seguem a mesma regra: são operações que alteram ou dependem de estado compartilhado, não de uma ação isolada de um usuário.
Por que existe essa separação entre o que funciona offline e o que não funciona?
As ações liberadas offline têm uma coisa em comum: são registros pontuais, de um usuário, sobre um item específico — confirmar uma consulta, criar uma tarefa. Não dependem de olhar o resto da clínica para fazer sentido.
As ações bloqueadas offline dependem do contrário: de autenticação segura, de cálculo sobre toda a base, ou de mudar algo que outras pessoas usam ao mesmo tempo (permissão, configuração, equipe). Fazer isso sem conexão abriria brecha de segurança ou de dado desatualizado.
Por isso o Modo Offline First não tenta cobrir o produto inteiro — ele cobre exatamente o pedaço em que continuar trabalhando sem rede é seguro.
Qual é o papel do Service Worker e por que algumas rotas nunca são cacheadas?
O Service Worker guarda o "shell" estático da aplicação e as páginas já visitadas, usando estratégia network-first — ele sempre tenta buscar a versão mais nova no servidor antes de usar a guardada. Isso evita mostrar uma tela desatualizada quando a internet está normal.
Rotas sensíveis têm bypass explícito e nunca são cacheadas: autenticação, admin, IA, importação, automação, health e a própria rota offline. Cachear essas rotas poderia mostrar uma tela de permissão ou de login antiga, o que é um risco maior do que a tela simplesmente não abrir sem internet.
Esse bypass é uma decisão de segurança, não um esquecimento — é a mesma lógica que separa o que entra na fila offline do que não entra.
Por que o Clinic Revenue OS não promete funcionar 100% offline?
Prometer offline total exigiria replicar localmente cálculos financeiros, permissões e IA assistiva — e revalidar tudo isso depois, com risco real de dado divergente entre dispositivos. O produto escolhe não fazer essa promessa.
O nome "Modo Offline First" descreve exatamente o que existe: a experiência é pensada primeiro para funcionar mesmo com internet instável, não para eliminar a internet do fluxo de trabalho da clínica.
Para a recepção, isso significa uma regra simples de lembrar: se a ação é sobre um paciente, uma consulta ou uma tarefa específica, ela provavelmente funciona offline. Se envolve login, dinheiro ou IA, precisa de conexão.
Fatos verificáveis
A camada offline roda na rota /sync-center, usa PWA + IndexedDB e organiza os dados em quatro áreas: entidades em cache, fila de mutações pendentes, logs de sincronização e metadados de sessão — tudo por clínica e por usuário.
Fonte: Documentação interna do produto — docs/offline-mode.md (Clinic Revenue OS)
Toda ação registrada offline é revalidada no servidor quando a conexão volta; o sistema não aceita como definitivo o que foi feito sem conexão sem checagem posterior.
Fonte: Documentação interna do produto — docs/offline-mode.md (Clinic Revenue OS)
O Service Worker usa estratégia network-first para o shell e páginas visitadas, com página de fallback /offline, e faz bypass total (nunca cacheia) das rotas de autenticação, admin, IA, importação, automação, health e offline.
Fonte: Documentação interna do produto — docs/offline-mode.md (Clinic Revenue OS)
Login, recuperação de senha, geração do Plano de Receita da Semana, recálculo do Dashboard/Modo Dono/Dinheiro Vazando, importação de CSV e o painel administrativo não funcionam offline.
Fonte: Documentação interna do produto — docs/offline-mode.md (Clinic Revenue OS)