Documentação Completa do Sistema

Aba de Backend / Banco de Dados Firebase

Esta aba detalha tudo que o sistema precisa no Firebase: plano, serviços, estrutura das coleções, índices, regras, custos e lista de verificação de produção.

1) Qual plano deve estar ativo

Para este sistema completo (chamadas, push, automações e integracao externa), manter projeto com billing ativo no plano Blaze.

2) Servicos Firebase usados

• Firebase Authentication (autenticação)
• Cloud Firestore (banco em nuvem)
• Cloud Functions (funções na nuvem)
• Firebase Cloud Messaging (FCM - mensagens em nuvem)
• Firebase Hosting (hospedagem opcional para paineis web)
• Firebase Storage (quando aplicavel)

3) Estrutura de banco (coleções)

4) Índices compostos recomendados

• trips: truckPlate (ASC) + dateTime (DESC)
• trips: truckId (ASC) + dateTime (DESC)
• trips: tripType (ASC) + dateTime (DESC)
• prefixes: isActive (ASC) + createdAt (DESC)
• qr_code_error_logs: errorType (ASC) + timestamp (DESC)
• qr_code_error_logs: operatorEmail (ASC) + timestamp (DESC)

Sem esses índices, consultas com where + orderBy podem falhar em produção.

5) Regras de seguranca Firestore

O arquivo atual de regras esta permissivo para desenvolvimento (allow read, write: if true), o que não e seguro para produção.

Recomendacao de endurecimento

1. Exigir autenticação (request.auth != null).
2. Restringir escrita por papel (admin/operator/driver).
3. Liberar calls apenas para admin.
4. Liberar trips para operator/admin.
5. Validar campos e tipos no write.

6) Funções na nuvem e variáveis de ambiente

Funções principais em functions/index.js:

• sendCallNotification
• notifySuplentes

Variáveis opcionais para WhatsApp/Twilio:

• twilio.account_sid
• twilio.auth_token
• twilio.whatsapp_number

firebase functions:config:set twilio.account_sid="..." twilio.auth_token="..." twilio.whatsapp_number="+14155238886"
firebase deploy --only functions

Se Twilio não estiver configurado, o sistema usa alternativa por link wa.me.

7) Custos, monitoramento e produção

• Ativar orcamento e alertas no Google Cloud Billing.
• Monitorar leituras/escritas no Firestore.
• Acompanhar logs de erro das funcoes.
• Revisar consultas para reduzir custo por leitura.

Lista de verificação final

• [ ] Blaze ativo com billing
• [ ] Regras seguras publicadas
• [ ] Índices compostos criados
• [ ] Funções implantadas sem erro
• [ ] Fluxo de chamada validado (aceite/recusa/suplente)

Segurança e robustez do servidor da aplicação

Esta aba descreve apenas o ambiente onde sua página esta hospedada: https://lvatech.com/. O foco aqui e mostrar o que ja esta ativo no servidor e o que reforca a seguranca da página em produção.

1) Sistema hospedado em produção

2) Protocolos e recursos de seguranca ativos na página

Observacao: os dados acima foram levantados diretamente das respostas HTTP do domínio em 06/03/2026.

3) Beneficios de seguranca e robustez para a sua página

4) Resultado geral para o sistema hospedado

• Comunicacao protegida para os usuários que acessam o sistema.
• Entrega web moderna, com melhor desempenho e estabilidade.
• Maior consistência no carregamento de recursos da página.
• Base sólida para operação contínua e crescimento do projeto.
• Experiencia de acesso mais confiavel para equipe e clientes.

Migração para outro servidor

Esta aba resume o que precisa para migrar o sistema web para outro ambiente de hospedagem, incluindo servidor próprio de empresa.

1) Itens obrigatórios para migrar

2) Passo a passo de migracao

1. Gerar backup completo da hospedagem atual.
2. Subir o conteúdo do site no novo servidor.
3. Configurar virtual host e HTTPS no novo ambiente.
4. Aplicar cabeçalhos de seguranca e regras de cache.
5. Validar login, dashboards, leituras e integrações Firebase.
6. Trocar DNS do domínio para o novo IP.
7. Monitorar erros e desempenho nas primeiras 24 a 72 horas.

3) Exemplo: migrar para servidor próprio da empresa

4) Checklist final de aprovação da migracao

• [ ] Dominio respondendo no novo servidor com HTTPS valido.
• [ ] Login e navegação das abas funcionando sem erro.
• [ ] Integracao com Firebase funcionando em produção.
• [ ] Tempo de carregamento dentro do esperado.
• [ ] Backups e monitoramento ativos.
• [ ] Procedimento de rollback documentado e testado.

Guia de Telas do Sistema

Aqui voce encontra todas as telas, para que servem, quem usa e como funciona cada uma.

1) Telas Web

2) Telas do App Android (rotas)

3) Fluxo resumido de uso

1. Usuário entra no sistema e autentica (web ou app).
2. Sistema identifica perfil e libera telas permitidas.
3. Operador registra viagens por QR com prefixo ativo.
4. Admin acompanha indicadores, relatórios e chamadas.
5. Motorista atualiza presença e responde chamadas recebidas.

4) Prints de tela

Prints reais do projeto com as três telas principais: Login, Admin e Operador.

Tela de Login: logo Minerita, campos E-mail e Senha, botão Entrar e link para cadastro de novo usuário.

Tela do Admin: dashboard com última atualização, cartão de prefixo ativo (cliente, supervisor, data de início e viagens realizadas) e quadro de viagens por prefixo.

Tela do Operador: cabeçalho de descargas, progresso de viagens, vagões preenchidos, última atualização e detalhes da leitura registrada.

5) Informações sobre as funcoes

Tela do Operador (visão do print enviado)

Funções da Tela de Login

Funções da Tela do Admin

Funções principais da tela web do Operador (operador.html)

Funções principais de backend (functions/index.js)

I.T Instrução de Trabalho para Operadores

Esta aba foi criada para orientar operadores no uso correto do app em rotina normal e em situação de falha. O objetivo é padronizar ação rápida no local, reduzir tempo parado e manter registro das ocorrências.

1) Procedimento padrão de uso do app

1. Confirmar bateria acima de 30% e GPS/rede disponíveis quando possível.
2. Abrir o app e entrar com usuário e senha corretos.
3. Verificar se o perfil exibido está correto (Operador).
4. Conferir tipo de viagem e prefixo antes de iniciar leitura QR.
5. Escanear QR e validar dados da viagem na tela antes de confirmar.
6. Conferir se a viagem apareceu no histórico local após o registro.

2) Processo em caso de falhas do sistema

3) Como resolver falhas no app (passo a passo técnico local)

1. Registrar horário da falha e qual operação estava em andamento.
2. Fechar totalmente o app (remover da lista de recentes).
3. Abrir o app novamente e repetir a operação uma única vez.
4. Se persistir, limpar cache do app em Configurações do Android.
5. Reiniciar o aparelho e testar novamente.
6. Confirmar se existe atualização mais recente do app instalada.
7. Se não resolver, abrir chamado com print e descrição objetiva.

Checklist rápido do chamado:
- Nome do operador
- Aparelho (marca/modelo)
- Horário exato da falha
- Tela/função com problema
- Print ou vídeo curto do erro
- Situação da internet no momento

4) Procedimento quando o app travar

1. Não clicar repetidamente na tela para evitar ações duplicadas.
2. Fechar o app e reabrir após 10 segundos.
3. Conferir no histórico se a última operação foi salva.
4. Se travar novamente, reiniciar o celular.
5. Persistindo o travamento, trocar para aparelho reserva quando disponível.
6. Informar equipe técnica para análise de logs e versão do app.

Importante: em caso de dúvida sobre duplicidade, validar sempre com o painel administrativo antes de repetir leitura QR.

5) Procedimento quando o app não conectar à rede

1. Manter a operação no app: os registros são salvos localmente (offline).
2. Evitar reinstalar ou limpar dados durante período sem rede.
3. Quando houver sinal, abrir o app e aguardar sincronização automática.
4. Atualizar a tela e confirmar envio das viagens no histórico.
5. Conferir no painel web/admin se os dados chegaram ao Firebase.
6. Se algo não sincronizar, registrar evidências e acionar suporte.

Sem internet, o foco é manter produção e preservar dados locais. A ação principal é garantir sincronização assim que a rede retornar.

6) Fluxo de reparo no local (resumo operacional)

7) Instrução técnica para desenvolvedor em caso de falhas

Este procedimento deve ser executado pela equipe de desenvolvimento quando houver falha recorrente, perda de sincronização, travamento crítico ou divergência entre app e painel.

Checklist mínimo do desenvolvedor

• [ ] Reproduziu a falha em ambiente de teste.
• [ ] Confirmou comportamento offline-first sem perda de registro.
• [ ] Validou sincronização após reconexão de rede.
• [ ] Revisou possíveis duplicatas e consistência de dados.
• [ ] Publicou correção com versão e changelog.
• [ ] Informou equipe de operação sobre procedimento atualizado.