Instalável e pensado para offline
O app tem manifest.webmanifest e sw.js.
Cache de assets, tema próprio e lançamento pela tela inicial do
celular — sem app store, sem download, sem fricção pro operador.
← Voltar para projetos
Projeto desenvolvido
Gestão de Paradas
PWA mobile-first para registrar, atender e analisar paradas industriais. Cobre o ciclo completo — do QR colado na máquina até o indicador no relatório — com captura de foto, vídeo e áudio direto no navegador, ditado por voz e leitura de QR sem sair do app.
- PWA offline-first
- QR Code via câmera
- Áudio + voz in-browser
- SPA sem framework
- Arquitetura modular
Visão geral
Um problema simples, resolvido com profundidade.
Quando uma máquina para, o time precisa responder rápido: o que parou, quando, por quê, quem atende, quanto custou em tempo? Papel não sobrevive ao turno. Planilha vira ilha. Indicador chega tarde.
Este sistema centraliza o fluxo inteiro em uma interface que funciona na mão do técnico em campo — com registro offline, anexos capturados na hora e sincronização quando volta o sinal.
5
views funcionais
8
services de domínio
~15
módulos CSS
3
tipos de mídia in-browser
0
frameworks de front-end
1
lib externa (jsQR)
Como funciona
Do apontamento no chão de fábrica ao indicador do mês.
-
1
Identificação por chapa
Técnico digita a chapa. O sistema consulta o cadastro e preenche automaticamente nome, cargo e gestor — evitando digitação redundante em campo.
-
2
Setor → Máquina em cascata
Escolher o setor filtra as máquinas disponíveis. No salvar, há validação cruzada: se a máquina não pertence ao setor informado, o registro é bloqueado com mensagem clara.
-
3
Classificação estruturada
Tipo de falha, causa-raiz e componente saem de listas controladas — com
<datalist>de sugestões. Nada de campo livre que vira bagunça no relatório. -
4
Ação no componente + preventiva
Chips clicáveis categorizam o que foi feito na hora e o que fica como ação preventiva. Vira dado estruturado para o Pareto, não texto solto.
-
5
Anexos na hora da ocorrência
Foto via câmera, vídeo curto (limite de 20 MB) e áudio de até 60 s — todos capturados no próprio navegador com
MediaRecordere enviados com barra de progresso. -
6
Fechamento e status
Status (já encerrada ou em andamento) + tempo total em formato livre (
45min,1h30,2h). Observação aceita ditado por voz viaSpeechRecognition.
Como aparece na prática
Reproduções da interface com dados fictícios. Nomes, códigos e horários foram alterados por confidencialidade.
🟥 PARADAS AGORA 3
Prensa 1242 min
Injetora 0218 min
Esteira 07Em atendimento
USINAGEM 7
Prensa 12
PARADA
⏱ Parada há 42 min
Torno CNC 03
OPERANDO
Identificação
12/10/2026
Turno A
Impacto: Alto
CHAPA
0001234567
✓
Nome:Téc. Silva
Cargo:Mecânico
Localização
Usinagem ▾
Prensa 12 ▾
📷 Foto
🎤 Áudio
🎥 Vídeo
✅ Já encerrada
🟡 Em andamento
Nota de confidencialidade. Por acordo com o cliente, nenhuma tela de produção é exibida. Os mockups acima reproduzem o comportamento real da interface com dados fictícios.
Decisões técnicas que valem a pena
Seis pontos do sistema que mostram maturidade de produto, não só de tela.
Chapa vira identidade, não digitação
Com 10 dígitos, o sistema busca o técnico em state.db.tecnicos
e preenche nome, cargo e gestor automaticamente. Se a chapa
não bate com ninguém, avisa. Se bate com o currentUser,
usa o próprio usuário como fallback — sem travar o fluxo em campo.
Validação cruzada no salvar
A cascata filtra no select, mas o salvar revalida: se a máquina não pertence ao setor escolhido, o registro é bloqueado com mensagem explícita. Nada de dado inconsistente entrar no banco por causa de estado velho em memória.
Foto, vídeo e áudio sem backend dedicado
Câmera via capture="environment", vídeo com limite de
20 MB, e áudio gravado com MediaRecorder — 60 s
máx, com contador ao vivo e preview. Upload feito em paralelo com
contador “enviando 2 de 5…”.
Ditado por voz na observação
O campo de observação tem botão de microfone que usa
SpeechRecognition. Em ambiente industrial, técnico de
luva agradece: descreve a ocorrência falando, não digitando.
Adapter de persistência trocável
Toda leitura/escrita passa por data/api.js. Hoje ele
persiste em localStorage — amanhã vira Supabase ou
qualquer outro back-end sem tocar em service ou view. Zero
acoplamento com o storage.
Arquitetura
Cada pasta com uma responsabilidade. Fácil de achar as coisas quando o sistema cresce.
core/
- state.js
- router.js
- storage.js
- events.js
- utils.js
data/
- api.js (adapter)
- constants.js
- seed.js
services/
- paradas.service
- maquinas.service
- os.service
- relatorios.service
- qr · audio · voz · foto
ui/
- modal.js
- toast.js
- undo.js
- badges.js
- icons.js
components/
- chip-status
- parada-card
- kanban-card
- big-action-button
- form-fields
views/
- radar
- registro
- maquinas
- os
- relatorios
Stack
Ferramentas escolhidas pelo problema, não por moda.
- Front-endHTML, CSS modular com tokens + JavaScript ES Modules
- Estadostore central em
core/state.js+draftisolado por formulário - Roteamentorouter próprio, zero dependência
- PWA
manifest.webmanifest+sw.jscom cache de assets - Câmera / QR
getUserMedia+jsQR - Áudio
MediaRecorder+Web Audio API(alerta crítico) - Voz
SpeechRecognitionpara ditado - Persistênciaadapter em
data/api.js— hojelocalStorage, pronto para Supabase - Design systemtokens → base → layout → componentes → views
O que ficou
Sistema que a operação usa de verdade não é o que tem mais recurso — é o que sobrevive ao turno. Boa parte do tempo foi ouvindo o time de manutenção pra descobrir o que era essencial no meio de uma parada e cortando o resto. Foi assim que recursos como ditado por voz e captura de áudio em 60 s entraram — o técnico de luva não vai digitar uma observação longa no meio do corredor. E foi assim que decisões técnicas como o adapter de persistência e a validação cruzada de setor × máquina vieram: não porque “é boa prática”, mas porque o problema exigia.
Sua operação precisa de algo assim?
Conta o que trava hoje. A gente pensa junto no sistema — do registro ao indicador.
Conversar pelo WhatsApp