8 Commits

Author SHA1 Message Date
b7e3208eb2 MAI CALL - step 12
Passo 12 completo. Build limpo, AC server-side totalmente verificado.

O que foi implementado:

lib/queue/ — camada de persistência offline:

db.ts — Dexie 4 com tabelas pending e deadLetters
broadcast.ts — BroadcastChannel helper (mai-call-sync) para comunicar entre tabs
sync.ts — loop de sync com retry/backoff: signPhotoUpload → PUT MinIO → create; 409 = sucesso; 4xx = dead-letter; erros de rede = paragem + retry na próxima volta
SyncProvider — React Context que:

Arranca sync ao reconectar (online event + visibilitychange)
Polling de 10s como fallback
Regista Background Sync API quando disponível
Expõe pendingCount / deadLetterCount via useSyncState()
Formulário (/maintenance/new) — refatorado: ao submeter, escreve em IndexedDB e navega imediatamente para /sent sem esperar pelo servidor. O SyncProvider processa a fila em background.

Feedback visual:

SyncChip na home: "Tudo sincronizado" / "N pedidos por enviar" / erro dead-letter
/maintenance/sent: mostra "Em fila" (Clock) ou "Enviado" (CheckCircle2) reactivamente via BroadcastChannel
Workbox (@ducanh2912/next-pwa) — app shell precaching ativo, para que o app carregue mesmo sem rede depois da primeira visita.
2026-05-16 16:55:59 +01:00
617c81357f MAI CALL - step 11
Passo 11 completo. Build limpo, AC verificado.

O que foi construído no admin-web (localhost:3001):

Infraestrutura completa a partir do zero: Tailwind, tRPC client/server, auth por autologin, env.ts, providers
/maintenance — cliente de polling com refetchInterval: 5000ms:
Header com contador de pedidos abertos + filtros por estado (checkboxes) e área (select)
Grid de cards com thumbnail (presigned GET), posto, descrição, reporter + tempo relativo, badge de status
OPEN → botão Aceitar (mutation claim)
CLAIMED → info "Aceite por X há Ym" + botão Marcar resolvido (dialog com nota opcional)
RESOLVED → badge verde + info "Resolvido por X há Ym"
Badge no document.title: (N) FieldOps — Manutenção
Toggle de notificação sonora via Web Audio API (beep ao detectar novo OPEN)
2026-05-16 16:41:16 +01:00
03c15fd069 MAI CALL - step 10
Passo 10 completo. AC verificado end-to-end:

Sem foto — row criada com photoKey=null ✓
Com foto — upload para MinIO via presigned PUT + row criada com photoKey correto + conteúdo verificado via presigned GET ✓
O que foi implementado:

/maintenance/new — Client Component com: select de posto (carregado via trpc.workstation.list), input de foto com compressão canvas (max 1600px, JPEG q=0.8), preview + botão remover, textarea com contador, submit que faz upload + create + redirect
/maintenance/sent — Server Component que mostra o clientRequestId e o botão "Voltar ao início"
Build de produção limpo com 7 rotas
2026-05-16 16:26:23 +01:00
0fe6da884d MAI CALL - step 7 2026-05-16 15:50:47 +01:00
bfc3fa4faf MAI CALL - step 6 2026-05-16 15:45:29 +01:00
d5ab1e5463 MAI CALL - step 5 2026-05-16 15:42:52 +01:00
f10a346356 MAI CALL - step 4 2026-05-16 15:36:38 +01:00
8e57ccc7f0 MAI CALL - step 3 2026-05-16 15:32:56 +01:00