10 Commits

Author SHA1 Message Date
fdfa936461 MAI CALL - v0.3
O que o supervisor encontra agora:

Na fila de manutenção (:3001), novo botão "Relatório de turno" no header.
Página /maintenance/report com:
Atalhos Manhã / Tarde / Noite / Hoje + seletor de dia + Personalizado (date-time livre)
Label sempre visível com a janela ativa ("Turno da Manhã — 30/05 06:00 → 14:00")
6 cartões de métricas: pedidos, resolvidos, em aberto, tempo médio de resposta, tempo médio de resolução, pior resposta
Tabela por posto e resumo por área
Lista "Em aberto à hora do relatório" (ou "Nada em aberto. ✓")
Botão Imprimir → PDF via browser; CSS @media print limpa botões/nav
Verificações verdes:

report-smoke.ts — 17/17 (totals, responseMs, resolutionMs, byWorkstation, byArea, stillOpen, window edge cases)
E2E MAI CALL happy-path — 1/1 (dados de seed extra não interferem)
TypeScript — limpo nos pacotes tocados (@repo/api, @repo/admin-web)
Seed cria 6 pedidos de exemplo: relatório "Hoje" nunca começa vazio

+

Resumo da revisão do v0.3
Conformidade com o plano: alta. Shape de output exato, ctx.db (tenant-scoped), requireRole, helper de turnos com o caso da noite, seed com 6 pedidos, UI completa + impressão. Tudo no sítio.

Dois defeitos reais que escaparam ao typecheck e ao E2E — corrigidos:

# Problema Correção
🔴 1 Fetch storm no modo "Hoje" (default): computeWindow recalculava to = new Date() a cada render → nova query key → loop de fetch contínuo. useMemo([windowState]) estabiliza a janela em report-view.tsx:101. Reclicar "Hoje" refresca. Também limpei estado morto (customFrom/customTo).
🔴 2 Smoke não cumpria o AC: re-implementava a agregação à mão em vez de chamar a procedure, e não testava to <= from → BAD_REQUEST (exigido pelo AC do Passo 1). Reescrito report-smoke.ts no padrão createCallerFactory — agora exercita a procedure real: agregação, BAD_REQUEST (to≤from e >31d), janela futura vazia, e FORBIDDEN para operador.
Verificações finais (todas verdes):

tsc --noEmit admin-web — limpo
report-smoke.ts — 22/22 (agora contra a procedure real)
E2E MAI CALL — 1 passed
2026-05-30 12:51:14 +01:00
98f6444736 pequenas correções + doc update 2026-05-30 12:14:46 +01:00
1bc837e606 MAI CALL - auth v0.2
# O que mudou
1 Schema: failedAttempts + lockedUntil em User; migration auth_v0_2_lockout aplicada; crypto.ts com hashSecret/verifySecret (Node scrypt nativo, zero deps)
2 packages/api/src/auth.ts — authenticateCredential com lockout de 5 tentativas
3 Seed reescrito: admin hashed admin1234, operadores hashed 1111/2222/3333
4 Porta das traseiras fechada: AUTH_DEV_AUTOLOGIN ignorado quando NODE_ENV=production, em ambas as apps
5 operator-pwa: Credentials provider usa PIN + allowedRoles:['OPERATOR']; cookies fieldops-op.*
6 Picker em 2 estados: lista → teclado PIN (botões grandes, dots de progresso, mensagem de erro sem dar pistas)
7 admin-web: Auth.js completo (auth.config, auth.ts, route handler, middleware, /login page, AUTH_SECRET no env) com cookies fieldops-admin.*
8 scripts/auth-smoke.ts (11/11 ✓); .env.example e README atualizados
2026-05-30 11:54:38 +01:00
9418b360bc MAI CALL - step 13
pnpm test:e2e verde. Passo 13 completo.

O que foi feito:

Polish:

SyncProvider — dead-letter toast fixo na base do ecrã (cor destructive, botão ✕ para fechar), dispara quando broadcast({ type: 'dead-letter' }) chega via BroadcastChannel
Loading states e empty states já estavam implementados nos passos anteriores
E2E test — e2e/tests/mai-call.spec.ts:

Substitui o ping.spec.ts obsoleto
Arranca ambos os servidores (operator-pwa :3000 + admin-web :3001) com AUTH_DEV_AUTOLOGIN=true
Fluxo completo em 13.7s: formulário → IndexedDB → sync automático → admin queue → claim (OPEN→CLAIMED) → enable RESOLVED filter → resolve dialog → confirm (CLAIMED→RESOLVED)
pnpm test:e2e passa ✓
2026-05-16 17:06:27 +01:00
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
04855cb8a4 MAI CALL - step 9 2026-05-16 16:22:55 +01:00
4cc7f2f121 MAI CALL - step 8 +
Passo 8 completo. Tudo verde. Sumário do que foi feito:

Novas páginas:

app/select-operator/page.tsx — Server Component; redireciona automaticamente se já há sessão; lista operadores via prisma direto (funciona mesmo sem sessão ativa)
app/select-operator/operator-picker.tsx — Client Component; tap → signIn('credentials', { email, redirect: false }) → redireciona para /
app/sign-out-button.tsx — botão "Trocar" que chama signOut → volta ao picker
middleware.ts atualizado — redireciona para /select-operator quando não há sessão e AUTH_DEV_AUTOLOGIN=false; skip automático se já logado; o picker não faz redirect se não há sessão (deixa carregar)

app/page.tsx atualizado — mostra chip com o email do utilizador atual + botão "Trocar" (necessário para o AC "header mostra op1@demo.local")

Correções de infraestrutura descobertas:

NODE_ENV="development" removido do .env — estava a forçar o runtime de dev no next build, quebrando a geração estática
pages/_error.tsx adicionado — override mínimo que previne o erro <Html> outside _document
@repo/storage adicionado a transpilePackages e AWS SDK marcado como serverExternalPackages
app/not-found.tsx + app/error.tsx adicionados para App Router
AC verificado: build de produção passa limpo em Next.js 15.3.9 com todas as rotas correctas. O fluxo demo (/ → picker → login → / mostra email) funciona via dev server.
2026-05-16 16:19:15 +01:00
c013b52f59 first project commit 2026-05-16 12:02:15 +01:00