MAI CALL - step 1

.claude/settings.local.json

@@ -9,7 +9,16 @@
       "PowerShell(docker exec fieldops-postgres psql -U fieldops -d fieldops -c \"\\\\dt\" 2>&1)",
       "PowerShell(docker exec fieldops-postgres psql -U fieldops -d fieldops -c \"SELECT id, name FROM \\\\`\"Tenant\\\\`\";\" 2>&1)",
       "PowerShell(docker exec fieldops-postgres psql -U fieldops -d fieldops -c \"SELECT email, role FROM \\\\`\"User\\\\`\";\" 2>&1)",
-      "PowerShell(docker exec fieldops-postgres psql -U fieldops -d fieldops -c \"SELECT code, name, area FROM \\\\`\"Workstation\\\\`\";\" 2>&1)"
+      "PowerShell(docker exec fieldops-postgres psql -U fieldops -d fieldops -c \"SELECT code, name, area FROM \\\\`\"Workstation\\\\`\";\" 2>&1)",
+      "Bash(pnpm --version)",
+      "PowerShell(pnpm --version; Write-Output \"---\"; \\(Get-Content .env | Select-String \"AUTH_DEV_AUTOLOGIN\"\\); Write-Output \"---\"; Test-Path node_modules; Test-Path packages\\\\db\\\\node_modules)",
+      "PowerShell(corepack --version; Write-Output \"---\"; \\(Get-Command pnpm -ErrorAction SilentlyContinue\\).Source; Write-Output \"---\"; npx pnpm --version 2>&1 | Select-Object -First 3)",
+      "PowerShell(corepack enable pnpm 2>&1)",
+      "PowerShell(corepack pnpm --version 2>&1)",
+      "PowerShell(corepack pnpm exec prisma migrate status --schema packages/db/prisma/schema.prisma 2>&1)",
+      "PowerShell($env:npm_config_verify_deps_before_run = \"false\"; corepack pnpm exec prisma migrate status --schema packages/db/prisma/schema.prisma 2>&1 | Select-Object -Last 25)",
+      "Bash(pnpm --filter @repo/db exec prisma migrate dev --name add_maintenance_request)",
+      "Bash(pnpm --filter @repo/db exec prisma db execute --schema=prisma/schema.prisma --stdin)"
     ]
   }
 }

docs/plans/mai-call-v0.1.md

@@ -0,0 +1,324 @@
+# Plano — MAI CALL v0.1 (ciclo mínimo)
+
+> Autor: Opus 4.7 (sessão de design, 2026-05-16). Destinado a implementação pelo Sonnet.
+> Estado do scaffold no momento do design: Next.js 15 + tRPC v11 + Prisma 6 + Postgres + Auth.js v5 beta + Tailwind 3 + shadcn (inlined) + Docker Compose + pnpm 11 monorepo + Turbo + Playwright. `packages/domain` vazio. Auth = dev-autologin sem password.
+
+## Decisões fixadas (não revisitar sem motivo forte)
+
+1. **Offline-first com fila persistente** (IndexedDB + service worker, sync on reconnect). Justificação: zonas pintura/Wi-Fi mau são restrição declarada do projeto.
+2. **MinIO em Docker** como storage de fotos, acedido via AWS S3 SDK v3 (portável para cloud).
+3. **Dev-autologin mantém-se na v0.1**, mas operador "escolhe-se" via picker que chama `signIn('credentials')` do Auth.js — não inventar canal de identidade paralelo.
+4. **Destino: demo agora, piloto a seguir.** Abstracções certas (ObjectStorage interface), mas sem construir auth real / backup / observabilidade ainda.
+
+## 1. Modelo de dados
+
+Adiciona-se **um** modelo novo e mantém-se o `DomainEvent` existente como log de transições.
+
+```prisma
+enum MaintenanceRequestStatus {
+  OPEN
+  CLAIMED
+  RESOLVED
+}
+
+model MaintenanceRequest {
+  id              String                   @id @default(cuid())
+  tenantId        String
+  workstationId   String
+  reportedByUserId String
+  description     String                   // max 1000 chars (Zod)
+  photoKey        String?                  // chave no MinIO; null se sem foto
+  status          MaintenanceRequestStatus @default(OPEN)
+  clientRequestId String                   // idempotência (UUID do cliente)
+  createdAt       DateTime                 @default(now())
+
+  claimedByUserId String?
+  claimedAt       DateTime?
+
+  resolvedByUserId String?
+  resolvedAt       DateTime?
+  resolutionNote   String?
+
+  tenant       Tenant      @relation(fields: [tenantId], references: [id], onDelete: Cascade)
+  workstation  Workstation @relation(fields: [workstationId], references: [id])
+  reportedBy   User        @relation("reported", fields: [reportedByUserId], references: [id])
+  claimedBy    User?       @relation("claimed", fields: [claimedByUserId], references: [id])
+  resolvedBy   User?       @relation("resolved", fields: [resolvedByUserId], references: [id])
+
+  @@unique([tenantId, clientRequestId])    // idempotência por tenant
+  @@index([tenantId, status, createdAt])   // alimenta fila do admin
+  @@index([tenantId, reportedByUserId])
+}
+```
+
+Adicionar relations inversas em `User`, `Workstation`, `Tenant`. Acrescentar `'MaintenanceRequest'` a `TENANT_SCOPED_MODELS` em `packages/db/src/tenant-extension.ts`.
+
+**Máquina de estados (deliberadamente mínima):**
+
+- `OPEN` (estado inicial — qualquer OPERATOR/ADMIN/SUPERVISOR pode criar)
+- → `CLAIMED` (ADMIN/SUPERVISOR fazem `claim`; grava `claimedByUserId`, `claimedAt`)
+- → `RESOLVED` (apenas a partir de `CLAIMED`; grava `resolvedByUserId`, `resolvedAt`, `resolutionNote` opcional)
+
+Sem reopen, sem cancel, sem "in-progress" separado de claimed. Transições inválidas devolvem 409.
+
+A cada transição emite-se um `DomainEvent` (`aggregateType='MaintenanceRequest'`, `eventType ∈ {'created','claimed','resolved'}`) na mesma transacção Prisma. Custo: ~5 linhas; benefício: relatório de fim de turno e auditoria caem-nos no colo depois sem refactor.
+
+**`clientRequestId`** é fundamental para offline-first: o service worker pode tentar submeter duas vezes; o `@@unique([tenantId, clientRequestId])` garante idempotência. O endpoint trata violação de unique como "already created, return existing".
+
+## 2. tRPC — procedures
+
+Tudo `protectedProcedure`. Sem necessidade de procedures públicas neste módulo.
+
+| Router.procedure | Tipo | Quem | Input | Output |
+|---|---|---|---|---|
+| `maintenanceRequest.create` | mutation | OPERATOR+ | `{ workstationId, description, photoKey?, clientRequestId }` | `{ id, status, createdAt }` |
+| `maintenanceRequest.queue` | query | ADMIN/SUPERVISOR | `{ statuses?: Status[], area?: string }` | lista paginada (cursor) |
+| `maintenanceRequest.myRecent` | query | OPERATOR | `{ limit?: number }` | últimos N do próprio user |
+| `maintenanceRequest.claim` | mutation | ADMIN/SUPERVISOR | `{ id }` | request actualizado |
+| `maintenanceRequest.resolve` | mutation | ADMIN/SUPERVISOR | `{ id, resolutionNote? }` | request actualizado |
+| `maintenanceRequest.getById` | query | qualquer (tenant scope) | `{ id }` | request com relations |
+| `workstation.list` | query | qualquer | — | `Workstation[]` |
+| `user.listOperators` | query | qualquer | — | `{ id, email }[]` filtrado por role=OPERATOR |
+| `storage.signPhotoUpload` | mutation | OPERATOR+ | `{ contentType, byteSize }` | `{ uploadUrl, photoKey, expiresAt }` |
+| `storage.signPhotoDownload` | query | qualquer | `{ photoKey }` | `{ url, expiresAt }` (curta) |
+
+Acrescenta-se **role middleware** simples em `packages/api/src/trpc.ts`: `requireRole(...roles)` derivado de `protectedProcedure`. Usado nas mutations admin (`claim`, `resolve`).
+
+Validação Zod:
+
+- `description`: `z.string().trim().min(3).max(1000)`
+- `photoKey`: regex `^tenants/[a-z0-9-]+/maintenance/[a-z0-9-]+\.(jpg|jpeg|png|webp)$`
+- `byteSize`: `z.number().int().min(1).max(10 * 1024 * 1024)` (10 MB cap)
+- `contentType`: enum `['image/jpeg','image/png','image/webp']`
+
+## 3. Storage — abstracção + MinIO
+
+Cria-se `packages/storage` com:
+
+```ts
+export interface ObjectStorage {
+  signPut(key: string, contentType: string, byteSize: number, ttlSec: number): Promise<{ url: string; expiresAt: Date }>;
+  signGet(key: string, ttlSec: number): Promise<{ url: string; expiresAt: Date }>;
+  delete(key: string): Promise<void>;
+}
+export function makeStorage(): ObjectStorage { /* lê env, devolve MinIO impl */ }
+```
+
+Impl única na v0.1: `MinioStorage` usando `@aws-sdk/client-s3` + `@aws-sdk/s3-request-presigner` (a mesma SDK serve AWS, R2, Wasabi, MinIO — só muda endpoint). **Não** instalar SDK específica do MinIO; manter S3 protocol universal é o ponto.
+
+**Compose** ganha:
+
+```yaml
+minio:
+  image: minio/minio:latest
+  command: server /data --console-address ":9001"
+  environment: { MINIO_ROOT_USER, MINIO_ROOT_PASSWORD }
+  ports: ["9000:9000", "9001:9001"]
+  volumes: ["minio-data:/data"]
+minio-init:           # job one-shot que cria o bucket fieldops
+  image: minio/mc:latest
+  depends_on: { minio: { condition: service_started } }
+  entrypoint: >
+    /bin/sh -c "mc alias set local http://minio:9000 $$MINIO_ROOT_USER $$MINIO_ROOT_PASSWORD &&
+                mc mb -p local/fieldops || true &&
+                mc anonymous set none local/fieldops"
+```
+
+Env novas: `S3_ENDPOINT`, `S3_REGION` (us-east-1 default p/ MinIO), `S3_BUCKET=fieldops`, `S3_ACCESS_KEY`, `S3_SECRET_KEY`, `S3_FORCE_PATH_STYLE=true`. Validar em `apps/operator-pwa/env.ts` e no admin-web.
+
+**Convenção de chaves:** `tenants/{tenantId}/maintenance/{requestId-or-clientRequestId}.{ext}`. Determinismo da chave permite ao cliente pre-calcular antes de submeter — essencial para o fluxo offline (foto sobe primeiro, mutation guarda só a key).
+
+Lifecycle: nenhum (v0.1). Backup: documenta-se `mc mirror` no README; sem cron ainda.
+
+## 4. Identidade do operador
+
+Decisão: **manter dev-autologin, mas usar a Auth.js signIn já existente** para distinguir operadores em vez de inventar um canal paralelo.
+
+Concretamente:
+
+- O picker da PWA chama `signIn('credentials', { email, redirect: false })` quando o operador se selecciona. Credentials provider já aceita email-sem-password (`apps/operator-pwa/lib/auth.ts:38-58`), portanto não precisa de mudança.
+- `resolveUser()` continua igual: a sessão Auth.js real ganha precedência sobre `AUTH_DEV_AUTOLOGIN`. O fallback admin só dispara quando ninguém ainda escolheu (primeiro load).
+- A escolha persiste via cookie de sessão Auth.js — sobrevive a reload e a fechar/abrir tab.
+- "Trocar utilizador" é um botão que chama `signOut` + manda para o picker.
+
+Isto deixa o **TAG/cartão para o MY QUALITY** num caminho limpo: substituis o picker por um leitor de RFID que devolve um email/id de operador → chamas o mesmo `signIn`. Zero refactor no resto do sistema.
+
+Para o admin-web: continua com `AUTH_DEV_AUTOLOGIN=true` a entrar como `admin@demo.local`. Sem picker do lado admin na v0.1 — é "demo, qualquer um que abra é o admin".
+
+## 5. UI Operador (`operator-pwa`)
+
+Quatro ecrãs. Mobile-first, target tablet/telemóvel em portrait.
+
+**E1 — Picker de operador** (`/select-operator`)
+
+- Lista grande, tap-friendly, dos OPERATOR do tenant. Avatar opcional, label = email ou nome.
+- Tap → `signIn('credentials')` → redirect a `/`.
+- Skip automático se já houver sessão.
+
+**E2 — Home** (`/`)
+
+- Header: nome do operador + botão "Trocar".
+- Estado de sync: chip "Tudo sincronizado" / "N pedidos por enviar" se a fila IndexedDB não estiver vazia.
+- Botão grande primário: **"Pedir manutenção"** → E3.
+- Lista colapsada "Os meus pedidos" (últimos 5): query `myRecent` + união com pendentes da IndexedDB (status local "pending"). Cores por status. Sem detalhes — só feedback.
+
+**E3 — Novo pedido** (`/maintenance/new`)
+
+- Campo 1 — **Posto**: dropdown searchable (Combobox da shadcn). Itens vêm de `workstation.list` com cache SWR longo. Sticky "Recentes" no topo (localStorage dos últimos 3 escolhidos). Obrigatório.
+- Campo 2 — **Foto** (opcional): `<input type="file" accept="image/*" capture="environment" />`. Preview redimensionado client-side com `<canvas>` para max 1600px lado maior + compressão JPEG q=0.8 (reduz upload em zona pintura). Botão "Remover foto".
+- Campo 3 — **Descrição**: textarea, 3-1000 chars, contador. Obrigatório.
+- Submeter:
+  1. Gerar `clientRequestId = crypto.randomUUID()`.
+  2. Gerar `photoKey` deterministicamente: `tenants/{tenantId}/maintenance/{clientRequestId}.jpg`.
+  3. Enfileirar em IndexedDB (Dexie): `{ clientRequestId, photoKey, photoBlob, workstationId, description, queuedAt }`.
+  4. Marcar SW para sync.
+  5. Navegar a `/maintenance/sent?cid={clientRequestId}` (E4) **sem esperar pelo servidor**.
+
+**E4 — Confirmação** (`/maintenance/sent`)
+
+- Mostra "Pedido em fila" (se ainda em IndexedDB) ou "Pedido enviado #abc" (se sincronizado). Reactivo a updates do sync. Botão "Voltar".
+
+**Service worker + sync (offline-first):**
+
+- Lib: `workbox` (caching app shell) + Dexie 4 (queue).
+- App shell precaching: HTML/JS/CSS estáticos, ícones, fontes.
+- Runtime caching: `workstation.list` e `user.listOperators` com StaleWhileRevalidate (servem picker e dropdown offline).
+- **Worker de sync** (lógica em TS, corrida no main thread quando o tab estiver visível + Background Sync API quando suportado):
+  - Loop: enquanto fila não-vazia e online (`navigator.onLine` + ping a `/api/health`):
+    - Para cada item: (a) `signPhotoUpload` → PUT directo ao MinIO (se houver foto); (b) `maintenanceRequest.create`; (c) remove da fila ao sucesso; (d) retry com backoff exponencial em falhas de rede; (e) erros 4xx (excepto 409) → move para "dead-letter" local + toast ao operador "Pedido X falhou, contactar supervisor".
+  - 409 (duplicate `clientRequestId`) é tratado como sucesso — robustez face a retries duplicados.
+- UI tem que reagir: emite eventos `BroadcastChannel('mai-call-sync')` que o React assina.
+
+**Critério-chave:** desligar o Wi-Fi do tablet, criar 3 pedidos, ligar de novo. Os 3 chegam ao admin-web sem o operador fazer nada.
+
+## 6. UI Manutenção (`admin-web`)
+
+Uma única página `/maintenance` (sem ainda preocupação com dashboard, login screen, settings).
+
+- Header: contador "**N pedidos abertos**" + filtros (status multi-select, área dropdown).
+- Lista (cards verticais; tabela é hostil em ecrã pequeno):
+  - Thumbnail foto (signed GET URL com TTL curto, lazy-loaded).
+  - Posto (`{code} — {name} • {area}`).
+  - Descrição.
+  - "Reportado por {operador} • há {Xm}".
+  - Footer: badge status, e dependendo do estado:
+    - `OPEN` → botão **Aceitar** (mutation `claim`).
+    - `CLAIMED` (por mim ou outro): mostra "Aceite por {user} há {Xm}" + botão **Marcar resolvido** (abre dialog com `resolutionNote` opcional, mutation `resolve`).
+    - `RESOLVED`: badge verde, "Resolvido por {user} há {Xm}", sem acções.
+
+**Real-time: polling.** `queue` faz `useQuery` com `refetchInterval: 5000` e `refetchIntervalInBackground: false`. Justificação:
+
+1. SSE/WS exigem canal extra no Next route handler + auth no upgrade + reconexão. Polling de 5s em fila de manutenção fabril é amplamente suficiente — não é trading.
+2. Migrar para SSE depois é trivial e isolado a esta query (`tRPC subscriptions` ou endpoint SSE puro).
+
+**Notificações:** badge no `document.title` (`(3) FieldOps — Maintenance`) + `<audio>` curto opcional ao detectar novo pedido OPEN (toggle persistido em localStorage). Sem push, sem email, sem websocket. Custos quase zero, valor enorme.
+
+## 7. Cortes propositados — o que NÃO entra na v0.1
+
+| Cortado | Porquê | Quando volta |
+|---|---|---|
+| Severidade / categoria | UX-cost na linha sem valor demonstrado; defaults razoáveis funcionam | v0.2, junto com SLAs |
+| SLAs / alertas / timers | Requer infra de scheduling | v0.2 |
+| Relatório fim de turno automático | DomainEvents já registados → gerar depois sem refactor | v0.2 ou v0.3 |
+| Múltiplas fotos / vídeo / áudio | Triplica complexidade upload/storage | quando piloto pedir |
+| Reabrir pedido fechado / chat operador-técnico | Workflow real, não MVP | v0.2+ |
+| Categorização AI da descrição | Tentação clássica de over-engineer | só com dados reais |
+| Export CSV/PDF | Stakeholder pedirá; resposta é "ver Insights & Sim" | módulo separado |
+| Push notifications mobile | PWA push web tem suporte Apple irregular; badge+polling chega | só se piloto exigir |
+| Auth real (passwords, SSO, MFA) | Definido como demo→piloto; v0.1 dev-autologin | v0.2, pré-piloto |
+| TAG/cartão | Substitui-se o picker; arquitectura já preparada | quando MY QUALITY entrar |
+| Multi-tenant onboarding UI | Cria-se via seed/SQL | só com 2º cliente |
+| i18n PT/EN | Hardcoded PT na v0.1 (cliente é Mangualde) | v0.2 com cliente piloto |
+| Testes E2E completos | 1 happy-path Playwright basta na v0.1 | expandir com piloto |
+| Observabilidade | Logs estruturados via `logger` já existente; chega | quando piloto exigir |
+
+## 8. Próximo módulo a ligar — MY QUALITY
+
+Razão: reusa Workstation + identidade-de-operador-num-posto, não introduz integração brownfield nova, e fecha o segundo case de uso de "operador na linha que reporta algo". MAI BOM exige integração com stock/MAI (mais canalização); SWA DIGITAL exige standard work formalizado (mais conteúdo); Paperless precisa de forms engine. MY QUALITY é o mais barato a seguir.
+
+**O que o MAI CALL v0.1 deve já deixar preparado (sem código extra agora, só desenho que não fecha portas):**
+
+1. **`OperatorSession` é um futuro modelo, não inventes ainda.** Mas o picker de operador da PWA já se comporta como o "badge-in" futuro: escolher operador é uma acção persistente, não uma form-field por pedido. Quando MY QUALITY chegar, acrescenta-se `OperatorSession(tenantId, userId, workstationId, startedAt, endedAt?)` e o picker passa a perguntar **também** o posto (binding operador↔posto), o que substitui o dropdown de posto em E3 do MAI CALL (deixa de ser por-pedido, passa a vir da sessão). Refactor pequeno, contido a 1 ecrã.
+2. **`DomainEvent` já registado** alimenta queries cross-módulo ("últimos 10 eventos no posto X") sem schema novo.
+3. **Storage abstrato** (`ObjectStorage`) serve também as fotos de defeitos do QCP.
+4. **Polling pattern** em `admin-web` generaliza-se trivialmente para a vista de roteamento RFS→operador.
+
+## 9. Plano de implementação (passos pequenos, ordenados)
+
+Cada passo é mergeable independentemente, com critério de aceitação testável.
+
+### Passo 1 — Schema + extension
+
+**Faz:** Adicionar `MaintenanceRequest` + enum + relations + indexes ao schema. Acrescentar `'MaintenanceRequest'` aos modelos tenant-scoped. Criar migration.
+**AC:** `pnpm db:migrate` corre sem erro; `prisma studio` mostra a tabela vazia; `select * from "MaintenanceRequest" where "tenantId"='x'` funciona.
+
+### Passo 2 — Seed alargado
+
+**Faz:** Estender `db:seed` para criar 3 OPERATOR users (`op1@demo.local`, `op2@demo.local`, `op3@demo.local`) e 3 Workstations (`CTR04`, `QVN_RTL_2`, `MTG_01`).
+**AC:** Após `pnpm db:seed`, picker em http://localhost:3000 lista 3 operadores; dropdown de posto lista 3 postos.
+
+### Passo 3 — Pacote `@repo/storage`
+
+**Faz:** Criar `packages/storage` com a interface `ObjectStorage` e impl `MinioStorage` usando AWS SDK v3. Adicionar env vars S3_*. Adicionar serviço MinIO + minio-init ao `docker-compose.yml`.
+**AC:** Script ad-hoc `pnpm tsx scripts/storage-smoke.ts` consegue: gerar presigned PUT, fazer upload com `curl`, gerar presigned GET, descarregar o ficheiro de volta.
+
+### Passo 4 — Role middleware em tRPC
+
+**Faz:** Acrescentar `requireRole(...roles)` em `packages/api/src/trpc.ts` que estende `protectedProcedure`.
+**AC:** Procedure de teste com `requireRole('ADMIN')` devolve 403 para OPERATOR; passa para ADMIN.
+
+### Passo 5 — Router `workstation` + `user`
+
+**Faz:** Criar `workstation.list` (todos) e `user.listOperators` (filter role=OPERATOR). Montar em `_app.ts`.
+**AC:** Chamada por tRPC client devolve seeds do Passo 2.
+
+### Passo 6 — Router `storage`
+
+**Faz:** Criar `storage.signPhotoUpload` (mutation) e `storage.signPhotoDownload` (query). Validar Zod (content-type, size). TTL: 5min upload, 1min download.
+**AC:** Chamada por tRPC devolve URL válida; upload direto ao MinIO com a URL funciona.
+
+### Passo 7 — Router `maintenanceRequest`
+
+**Faz:** Procedures `create`, `claim`, `resolve`, `queue`, `myRecent`, `getById`. Cada transição emite `DomainEvent` na mesma `$transaction` (usar pattern de scoped tx do header de `tenant-extension.ts`). Tratar `P2002` em `create` (unique violation em clientRequestId) como sucesso devolvendo a request existente.
+**AC:** Teste integração: cria-se um pedido por op1; claim por admin; resolve por admin; queue mostra na ordem certa. Repetir `create` com mesmo `clientRequestId` devolve a mesma row sem erro.
+
+### Passo 8 — Picker de operador
+
+**Faz:** Ecrã `/select-operator` na operator-pwa. Lista `user.listOperators`. Tap → `signIn('credentials', { email, redirect: false })`. Redirect a `/`. Middleware `middleware.ts` redirecciona a `/select-operator` se não houver sessão e não houver autologin.
+**AC:** Demo flow: limpar cookies, abrir `/`, é redirigido ao picker, escolher op1, voltar a `/`, header mostra `op1@demo.local`.
+
+### Passo 9 — Home da PWA
+
+**Faz:** Substituir `/` actual por: header com operador + botão trocar; botão "Pedir manutenção" → `/maintenance/new`; lista "Os meus pedidos" via `myRecent`.
+**AC:** Botão visível, navega correctamente.
+
+### Passo 10 — Ecrã novo pedido (online-only primeiro)
+
+**Faz:** `/maintenance/new` com posto (Combobox), foto (input capture, compress canvas), descrição. Submissão **directa** ao servidor (sem fila ainda). Confirmação em `/maintenance/sent`.
+**AC:** Submeter um pedido (com e sem foto) cria a row, MinIO tem o objecto, redirect mostra ID.
+
+### Passo 11 — Admin-web `/maintenance`
+
+**Faz:** Page com lista (cards), filtros simples (status/area), polling 5s, botões claim/resolve (este último abre dialog com note opcional). Thumbnails via signed GET. Badge no title.
+**AC:** Pedido criado no Passo 10 aparece em ≤5s; claim move o card para CLAIMED; resolve move para RESOLVED.
+
+### Passo 12 — IndexedDB + service worker + sync
+
+**Faz:** Instalar Dexie + Workbox. Refactorizar E3 para enfileirar em IndexedDB e devolver controlo imediatamente. Service worker faz precache de app shell + StaleWhileRevalidate para `workstation.list` e `user.listOperators`. Worker de sync com retry/backoff. UI mostra "N por enviar" e reage via BroadcastChannel.
+**AC:** Cenário offline: Chrome DevTools → Network=Offline → criar 3 pedidos com 1 foto cada → vê-los listados como "por enviar" → Network=Online → em ≤30s os 3 estão no admin-web com fotos.
+
+### Passo 13 — Polish + happy-path E2E
+
+**Faz:** Tratamento de erros visíveis (toasts), loading states, empty states. Um único teste Playwright que percorre operador-cria → admin-claim → admin-resolve.
+**AC:** `pnpm test:e2e` verde.
+
+### Passo 14 — README + runbook curto
+
+**Faz:** Atualizar README com (a) como subir o stack (`docker compose up` + `pnpm db:migrate` + `pnpm db:seed` + `pnpm dev`); (b) credenciais MinIO/console em http://localhost:9001; (c) limitações conhecidas v0.1 (dev-autologin, sem auth real, demo only).
+**AC:** Outro dev clona o repo, segue o README, vê o demo flow a funcionar em <15 min.
+
+---
+
+**Sequência crítica:** Passos 1→7 são backend e dão-se naturalmente em PRs pequenos. Passo 8 é o pivot para frontend. Passos 9-11 podem ir em paralelo (operator-pwa vs admin-web) se houver 2 devs. Passo 12 é o passo mais arriscado/longo — deixar para o fim, depois de o fluxo online estar verificado, para não misturar bugs de sync com bugs de domínio.
+
+**Risco principal não-mitigado:** comportamento do service worker no Safari iOS (caso a fábrica use iPads). Workbox lida com a maioria mas Background Sync API não é suportada — cai-se no fallback "sync quando o tab está visível". Aceitar e seguir.

original-docs/Lista de Ideias_Teste Bed - Ideias.csv

@@ -0,0 +1,116 @@
+UR,Nº Ideias,Índice Ideias por UR,"Potenciais produtos, processos ou serviços para testing",Notas
+Ferragem,1,1.,"Ligação técnicas importantes ao Qualif, através de anomalias processo e/ou situações:","Controlo de anomalias e falhas na gravação do número VIN, parafusos soldados, cordões MIG/MAG  (presença e posição; visão artificial), pontos de soldadura, colas e mastiques.
+Seria criado um programa à parte do sistema informático de controlo qualidade (Qualif) onde esta informação estaria reunida e o operador de retoques do fim de linha validava ou não, procedendo ao retoque se necessário                                                                    "
+,,1.1,VIN fora de serviço; cair defeito num programa a criar quando robo fora de serviço,
+,,1.2,Anomalia máquina VIN durante o processo de marcação;,
+,,1.3,"Falha de cabeçais tucker (erros tipo: falta de goujon (parafuso soldado), saltar goujon, tolerâncias ultrapassadas, …);",
+,,1.4,Falhas Pontos de Soldadura (salto PSE ou todos os outros casos em que normalmente o robot envia o registo de anomalias com determinado número de PSE’s); pontos de soldadura,
+,,1.5,Falhas aplicação colas e mastiques (erros que normalmente surgem no controlador/doseador),
+,,1.6,Falhas cordões MIG/MAG (normalmente surge a info no final do ciclo do robot).,
+,2,2.,Câmaras de controlo Processo,
+,,2.1,Cordões MIG/MAG; presença e posição (visão artificial),
+,3,3.,Digitalização Planos de Vigilância (Controlo de Parâmetros de Processos),
+,,3.1,"Gestão do plano de vigilância: Sistema infomático que permita integrar todos os parâmetros de processo que tem de ser vigiados, alertas quando algum parâmetro sai dos limites de vigilância, histórico (arquivo dos parâmetros recolhidos), alertas quando a periodicidade dos planos de vigilância não é cumprida, criação de um panelview para a visualização da totalidade dos planos",
+,,3.2, Automatização do registo da troca de elétrodos no processo de soldadura;,
+,4,4.,"Sistemas de troca automática de elétrodos: já existem algumas soluções no mercado (EXROD), poderá existir alguma solução mais inovadora ou diferente ",
+,5,5.,"Sistema de deteção de contaminação de matriz portas e capot: matriz/molde ganha sujidade e danifica a pele das portas; visualizar se existe alguma sujidade e emitir alerta para o operador proceda à limpeza. Poderá ser incorporado um segundo sistema que faria a limpeza da matriz/molde em caso de deteção de sujidade (Causas possíveis: restos de colas, mastiques, projeções de soldadura, impurezas que possam vir na pele da porta)",
+Pintura,6,1.,Deteção automática posicionamento cordões,"ideia idêntica da FER (2.1), controlo de anomalias e falhas do posicionamento dos cordões, por comparação                                                          (visao artificial)"
+,,1.1,Deteção Automática de posicionamento dos cordões baixo de caixa,
+,,1.2,Deteção Automática de posicionamento dos cordões de sertis (enquadramento das portas e capot),
+,7,2.,Eliminação não conformidades Tampa de Combustível,Criação de um pick to light para as tampas de combustivel e/ou um sistema de deteção de conformidade
+,,2.1,Sistema análogo ao Pick to light para identificar a correta tampa de combustível a montar,
+,,2.2,Sistema anti-erro para garantir a correta colocação da embalagem (referência) no local correspondente a essa referência ou sistema de controlo que idêntifique que a tampa de combustível que foi montada no véiculo corresponde a esse veículo,
+,,3.,Deteção de Defeitos de Pintura na Carroçaria ," 1- Sistema automático de deteção e indicação do posicionamento do defeito 
+2- retoque automático defeitos
+3 -  Deteção automática das cores das caixas "
+,8,3.1,"Deteção automática dos defeitos (lixos, escorridos, cratera, gota, falta de tinta,...)",
+,,3.2,Visualização do posicionamento dos defeitos,
+,9,3.3,"Retoque automático dos defeitos (lixar+polir) ou Polidora com temporizador, reconhecia a cor da caixa e em função da cor, definia os seg que devia trabalhar para evitar marcas de polimento",
+,,,,
+,10,3.4,Deteção automática das cores das caixas: Diferença de tonalidade em comparação com a tonalidade padrão,
+,,4.,Automatização Parâmetros TTS (Tratamento de Superfície); ,
+,11,4.1,Sensorização dos parametros quimicos dos banhos e garantir que as bombas doseadoras de produtos são ajustados (TTS/Cata) em tempo real,
+,12,4.2,"Ajuste automático dos produtos químicos, desengordorantes + oxsilan",
+,13,4.3,"Acelerar processo de eletrodeposição: através de ferramenta de simulação multi-fisico das tinas de tratamento de superfícies do TTS CATA, avaliação da eficiência do processo por imersão assim como possibilidade de melhoria dos mesmos.",
+,14,5.,"Desenvolvimento de soluções e meios mais sustentáveis e amigos do ambiente de todos os elementos de apoio associados ao processo pintura e tratamentos superfícies: materiais que não se deixam acumular com os produtos das tinas (ex: material super ""hidrofóbico"" ou polímeros que desempanhe a mesma função)",
+,15,6.,"Manutenção preditiva de equipamentos críticos (pintura/estufa): Desenvolvimento de sistemas sensorizados para equipamentos de pintura/estufa sujeitos a situações fadiga, vibrações entre outros (equipamentos sugeridos - ventiladores e extratores de ar da estufa, condicionadores de ar, bombas de lavagem e as bombas das mituradoras de tinta). - Controlo de equipamentos dinâmicos por wireless com alertas -",
+,16,7.,"Sistemas de convecção/radiação para melhoria da eficiência térmica das estufas: (base nos resultados do ponto posterior) - (Ex: Sistemas elétricos em detrimento ao gás para maior controlo térmico,…)",
+,17,8., Simulador de eficiência térmica de estufas: análise da eficiência térmica da estufa de Lacas e da estufa de Cata.,
+Montagem,,1.,MAI CALL,
+,18,1.1,"Na linha de montagem existem por vezes diversos pedidos de intervenção, ao mesmo tempo, via telemóvel.
+A aplicação deveria permitir receber os pedidos, com a informação (Foto/vídeo, posto, descrição avaria – em forma de lista), o monitor da fabricação preenchia este pedido e enviava para a Manutenção (MAI). 
+O Monitor da Manutenção recebia esta informação, com o respetivo pedido de intervenção, desta forma nenhuma intervenção ficaria esquecida porque iriam ficando em carteira do MAI CALL e seriam fechados à medida que a intervenção estava terminada.
+Esta aplicação evitaria o esquecimento por parte da Manutenção, quando tem intervenções em simultâneo.
+Melhoria o seguimento das intervenções que ao dia de hoje não é robusto.
+Permitiria no final do dia de trabalho realizar um relatório da atividade do dia, com difusão ao DUR/RG MAI/RG PROD/Técnicos, hoje em dia é manual, passaria a ser automático.",
+,,2.,MY QUALITY,
+,19,2.1,"Reatividade imediata com identificação do (SETOR/UEP/POSTO/OPERADOR).
+Todos os operadores ao entrarem no posto, passavam uma TAG / CARTÃO empresa do inicio da atividade no posto, ficando registado o primeiro chassis que ele iria iniciar a produção, se tivesse que sair do posto voltava a registar.
+Desta forma conseguíamos ter a traçabilidade dos carros fabricados individualmente, e poderíamos realizar uma reatividade mais acertiva aos defeitos realizados por cada operador.
+Seria lançado o post it pelo QCP (Qualidade), a RFS (código de barras) do defeito estaria ligada ao respetivo posto, que iria automaticamente sair um alerta que está a chegar um defeito ao BTU (Qualidade) daquele posto (Ecran tátil). 
+O operador tomaria conhecimento do defeito em automático, e poderia corrigir a operação que estava mal realizada.
+Esta informação seria enviada para o processo individual dos operadores de modo a ficar registado (gestão da performance individual dos operadores/avaliação ). 
+",
+,,3.,SWA DIGITAL (antigas VRS’s),
+,20,3.1,"Realização das VRS’s (verificação do respeito ao standard) em formato digital, as operações do posto iam aparecendo de acordo com a cronologia do posto (necessário digitalizar os standards), e facilmente iam sendo validadas.
+Resultado em automático e lançado na BHF (Base de Habilitação e Formação).",
+,,4.,QUICK CONTROL,
+,21,4.1,"Podermos instalar medidas conservatórias em qualquer ponto do processo de Montagem, que não dependessem dos operadores.
+Termos um equipamento com câmera e tecnologia deap learning que pudesse ser móvel/versátil (fácil manipulação e instalação rápida).
+Apenas tínhamos de realizar a aprendizagem, OK/NOK…ao fim de 10/15 ciclos ficava em automático a controlar.",
+,,5.,CONTROL LOG,
+,22,5.1,"Ter um sistema semi automático de controlo da receção das embalagens na logística Montagem. 
+Controlo à receção das embalagens com a respetiva pesagem.
+Identificação automática da referência e respetivo peso teórico.
+Pesagem da embalagem real e comparação com o valor teórico dando o resultado VERT/ROUGE.
+Relatório de controlo à receção com envio do resultado.",
+,,6.,MAI BOM,
+,23,6.1,"Durante uma intervenção da Manutenção, o operacional deve poder identificar rapidamente a peça danificada com uma simples foto do equipamento.
+Os equipamentos identificados com QR-CODE, através desse QRCode o operacional consegue entrar nos planos de conjunto do equipamento e seguida de detalhe, com a foto, deve indicar qual a peça defeituosa, referência de armazém, stock em armazém.
+No caso de não existir em armazém deverá ser possível enviar imediatamente um mail ao Técnico MAI, para realizar as providencias necessárias para adquirir a peça.",
+,24,7.,"APP android para o SW&Kaisen, permitia fazer SW com filmagens incluídas e yamazumis incluídos",
+,25,8.,Sistema Pick-to-light facilmente configurável e móvel,
+,26,9.,"Luvas inteligentes (machine learning), confirma a boa conexão dos conetores elétricos em tempo real","QUARA, The Intelligent Glove for Assembly"
+,27,10.,Aplicação de gestão de rota de AGV tendo em conta a velocidade e os locais de carga e descarga com otimização de rotas através de IA ,
+,28,11.,Realidade aumentada para formação de novos operadores: Visualização virtual das operações a executar,
+,29,12.,Ajuda Auditiva de execução de operações,
+,30,13.,"Realidade aumentada para peças pouco montadas / com mais defeitos:  Ter um ecran por posto onde era reproduzida a operação sempre que chegassem diversidades raras ou operações com elevado NR. Associado ao écran teríamos um pick to voice, onde era enviada uma mensagem via auricular para alertar o operador da diversidade rara ou do elevado NR. o operador após realizar a operação dava o retorno por voz ao sistema.",
+,31,14.,"APP com IA para fazer equilibragens dos postos tendo em conta as precedências das operações:  A Montagem, fruto de evoluções de produto, processo ou alterações de mix pode ter a necessidade de equilibrar operações nos diferentes postos. Com os Yamazumis criados ( blocos com os tempos de operações empilhados ) a IA tendo em conta as precedências iria sugerir qual o melhor posto para receber essas operações.
+",
+,32,15.,AGV para deslocar com precisão as paletes e posicionar as cargas na zona desejada em armazém,
+,33,16.,"Robô para entrega de kits, ferramentas ou peças enquanto operador está a executar as tarefas",
+,34,17.,Robô para operações de picking na linha de montagem com cameras que possa ser programado e controlado por pessoas que não têm experiência na área da robótica,
+,35,18.,"Predictive data for tightening process: Os apertos que são realizados na Montagem têm de respeitar valores de binário e ângulo. Estes valores têm de estar compreendidos entre limites mínimos e máximos. Com evoluções no produto, ou desgaste dos meios esses valores nominais vão-se alterando e aproximando dos limites. Para não reagirmos só quando saiem fora das janelas de limite, a aplicação iria dar o alerta quando o aperto começa a ter uma tendência de saída do nominal.",
+,36,19.,Exoesqueletos para postos ergonomicamente difíceis,
+,37,20.,Impressora 3D para impressão em metal,
+,38,21.,Dispensador automático de Etiquetas e Adesivos,
+,39,22., Robot colaborativo para manuseamento de peças e componentes sensíveis: sistema robótico colaborativo para manipulação de peças complexas e como por exemplo de estofos / bancos estofados / polímeros de grande dimensão e outros componentes que impliquem alta especificidade e cuidado no manuseamento.,
+,40,23.,"Cadeira ergonómico: assento com encosto que está fixo a um braço móvel que incorpora um suporte para os parafusos e aparafusadoras, necessários à realização das operações no interior do veículo, para que estejam sempre acessíveis ao colaborador.",
+QCP/BTU,41,1.,Sistema de gestão e informação das caracteristicas do veículo que substituia a Etiqueta RFID,
+,42,2.,FAV (Folha de Acompanhamento Viatura)  E-PAPER (paperless),
+,43,3.,"Raio-X ao veículo para detetar corpos estranhos (parafusos, molas, …)",
+,44,4.,"Conformidades Paperless: para os postos CTR04 DRT e ESQ e QVN_RTL_2: Deixar de fazer as conformidades com recurso a uma folha de papel impressa e passar a visualizar a informação que consta na folha num disposistivo tipo óculos, ecrã,…",
+,45,5.,Localizadador nos veículos para melhor identificação da zona no parque de expedição,
+,46,6.,Máquina para realização controlo jogos e afloramentos em automático,
+,47,7.,Introdução defeitos no sistema informático de controlo qualidade via oral (falar localização e defeito e ser introduzido no sistema informático de controlo qualidade) . Algo parecido com o que existe no google e iphone.,
+,48,8.,Transporte automático das etiquetas RFID da QCP para a Pintura. Exemplo: Drone,
+,49,9.,Sistema de transporte de pessoas com retorno automático ao ponto de partida (tipo o Segway do BTU),
+,50,10.,AGV com plataforma que eleva e ajusta a altura automática para movimentação dos carros ao fim do BTU (para parque de expedição),
+CPL,51,1.,Técnicas machine learning para acompanhamento dos níveis de tráfego em tempo real para que a logística/cpl tenha um elevado nível de visibilidade e rastreabilidade das mercadorias expedidas minimizando o risco de perdas ou falhas nas entregas.,
+,52,2.,Sistema de tracking de camiões através do GPS (inclui descrição da carga e horários de descanso),
+,53,3.,Receção automática dos motoristas: Sistema informático que tenha um interface que permita ao motorista aquando da sua chegada possa inserir os dados dos transporte e que posteriormente emita uma mensagem para o telemóvel a dar ordem de entrada,
+Energia e Ambiente,54,1.,"Desenvolvimento de limpeza verde: equipamentos de limpeza automatizados, soluções de produtos e equipamentos associados à manutneção/limpeza de instalações",
+,55,2.,"Fornecimento de água mais sustentável, novos equipamentos, novas soluções: sistemas de osmoza inversa",
+,56,3.,Soluções para separação de resíduos,
+,57,4.,Soluções para conversão biomassa ,
+,58,5.,"Mini geração Eólica: Desenvolvimento de turbinas eólicas de pequena dimensão, para produção de energia local. Desenvolvimento de desenho de alta eficiência, com baixo índice de ruido. Processo de fabrico por tecnologias de impressão 3D low-cost.",
+,59,6.,Reciclagem de resíduos Industriais: Soluções de valorização ambiental de resíduos,
+,60,8.,"Simulador de mistura de gás natural e Hidrogénio: ferramenta de otimização de mistura de gás natural e hidrogénio, para viabilizar a mistura perfeita e adequada nos equipamentos/instalações.",
+,61,9.,Sistema automatico de leitura em tempo real do nível de zinco nas águas residuais após tratamento ETARi,
+Armazém MHF,,1.,Desenvolvimento de soluções de gestão do armazém de peças de reposição (MHF),
+,62,1.1,Sistema de controlo de acesso de pessoas ao MHF,
+,63,1.2,Sistema de controlo de saída de componentes do MHF,
+,64,1.3,Sistema de alerta para gestão e emissão de encomendas ,
+Recuros Humanos ,65,1.,"Criação de uma aplicação para smartphone com todas as informações necessários para os colaboradores (Infos atuais, inscrições, docs RH) e  de um ecrã vertical  VM VERYBRIGHT | Ecrã LCD de grande formato de alto brilho | Vitrinemedia",
+,66,2.,Criação de uma aplicação que facilite o processo de marcação de refeição na cantina,
+,67,3.,"Escola de formação: Equipamentos que permitem determinar o nível de destreza, precisão, entre outros, de novos coloboradores ",

packages/db/prisma/migrations/20260516142042_add_maintenance_request/migration.sql

@@ -0,0 +1,46 @@
+-- CreateEnum
+CREATE TYPE "MaintenanceRequestStatus" AS ENUM ('OPEN', 'CLAIMED', 'RESOLVED');
+
+-- CreateTable
+CREATE TABLE "MaintenanceRequest" (
+    "id" TEXT NOT NULL,
+    "tenantId" TEXT NOT NULL,
+    "workstationId" TEXT NOT NULL,
+    "reportedByUserId" TEXT NOT NULL,
+    "description" TEXT NOT NULL,
+    "photoKey" TEXT,
+    "status" "MaintenanceRequestStatus" NOT NULL DEFAULT 'OPEN',
+    "clientRequestId" TEXT NOT NULL,
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "claimedByUserId" TEXT,
+    "claimedAt" TIMESTAMP(3),
+    "resolvedByUserId" TEXT,
+    "resolvedAt" TIMESTAMP(3),
+    "resolutionNote" TEXT,
+
+    CONSTRAINT "MaintenanceRequest_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE INDEX "MaintenanceRequest_tenantId_status_createdAt_idx" ON "MaintenanceRequest"("tenantId", "status", "createdAt");
+
+-- CreateIndex
+CREATE INDEX "MaintenanceRequest_tenantId_reportedByUserId_idx" ON "MaintenanceRequest"("tenantId", "reportedByUserId");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "MaintenanceRequest_tenantId_clientRequestId_key" ON "MaintenanceRequest"("tenantId", "clientRequestId");
+
+-- AddForeignKey
+ALTER TABLE "MaintenanceRequest" ADD CONSTRAINT "MaintenanceRequest_tenantId_fkey" FOREIGN KEY ("tenantId") REFERENCES "Tenant"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE "MaintenanceRequest" ADD CONSTRAINT "MaintenanceRequest_workstationId_fkey" FOREIGN KEY ("workstationId") REFERENCES "Workstation"("id") ON DELETE RESTRICT ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE "MaintenanceRequest" ADD CONSTRAINT "MaintenanceRequest_reportedByUserId_fkey" FOREIGN KEY ("reportedByUserId") REFERENCES "User"("id") ON DELETE RESTRICT ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE "MaintenanceRequest" ADD CONSTRAINT "MaintenanceRequest_claimedByUserId_fkey" FOREIGN KEY ("claimedByUserId") REFERENCES "User"("id") ON DELETE SET NULL ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE "MaintenanceRequest" ADD CONSTRAINT "MaintenanceRequest_resolvedByUserId_fkey" FOREIGN KEY ("resolvedByUserId") REFERENCES "User"("id") ON DELETE SET NULL ON UPDATE CASCADE;

packages/db/prisma/schema.prisma

@@ -19,14 +19,21 @@ enum UserRole {
   OPERATOR
 }
 
+enum MaintenanceRequestStatus {
+  OPEN
+  CLAIMED
+  RESOLVED
+}
+
 model Tenant {
   id        String   @id @default(cuid())
   name      String
   createdAt DateTime @default(now())
 
-  users        User[]
-  workstations Workstation[]
-  events       DomainEvent[]
+  users               User[]
+  workstations        Workstation[]
+  events              DomainEvent[]
+  maintenanceRequests MaintenanceRequest[]
 }
 
 model User {
@@ -39,6 +46,10 @@ model User {
 
   tenant Tenant @relation(fields: [tenantId], references: [id], onDelete: Cascade)
 
+  reportedRequests MaintenanceRequest[] @relation("reported")
+  claimedRequests  MaintenanceRequest[] @relation("claimed")
+  resolvedRequests MaintenanceRequest[] @relation("resolved")
+
   @@unique([tenantId, email])
   @@index([tenantId])
 }
@@ -50,7 +61,8 @@ model Workstation {
   name     String
   area     String
 
-  tenant Tenant @relation(fields: [tenantId], references: [id], onDelete: Cascade)
+  tenant              Tenant               @relation(fields: [tenantId], references: [id], onDelete: Cascade)
+  maintenanceRequests MaintenanceRequest[]
 
   @@unique([tenantId, code])
   @@index([tenantId])
@@ -72,3 +84,32 @@ model DomainEvent {
   @@index([tenantId, processedAt])
   @@index([tenantId, aggregateType, aggregateId])
 }
+
+model MaintenanceRequest {
+  id               String                   @id @default(cuid())
+  tenantId         String
+  workstationId    String
+  reportedByUserId String
+  description      String
+  photoKey         String?
+  status           MaintenanceRequestStatus @default(OPEN)
+  clientRequestId  String
+  createdAt        DateTime                 @default(now())
+
+  claimedByUserId String?
+  claimedAt       DateTime?
+
+  resolvedByUserId String?
+  resolvedAt       DateTime?
+  resolutionNote   String?
+
+  tenant      Tenant      @relation(fields: [tenantId], references: [id], onDelete: Cascade)
+  workstation Workstation @relation(fields: [workstationId], references: [id])
+  reportedBy  User        @relation("reported", fields: [reportedByUserId], references: [id])
+  claimedBy   User?       @relation("claimed", fields: [claimedByUserId], references: [id])
+  resolvedBy  User?       @relation("resolved", fields: [resolvedByUserId], references: [id])
+
+  @@unique([tenantId, clientRequestId])
+  @@index([tenantId, status, createdAt])
+  @@index([tenantId, reportedByUserId])
+}

packages/db/src/tenant-extension.ts

@@ -84,7 +84,7 @@ import type { PrismaClient } from '@prisma/client';
  * ============================================================================
  */
 
-const TENANT_SCOPED_MODELS = ['User', 'Workstation', 'DomainEvent'] as const;
+const TENANT_SCOPED_MODELS = ['User', 'Workstation', 'DomainEvent', 'MaintenanceRequest'] as const;
 type TenantScopedModel = (typeof TENANT_SCOPED_MODELS)[number];
 
 function isTenantScoped(model: string | undefined): model is TenantScopedModel {