Bienvenido a WorkDone Sanitarios¶
Si recién entrás al equipo, esta es tu puerta de entrada. WorkDone Sanitarios es el producto de LubecaTech que controla, registro a registro, la limpieza de los sanitarios de aeropuertos y shoppings: el personal acerca el teléfono a una placa NFC pegada en el baño, y eso queda asentado como un turno de limpieza con su hora exacta. El cliente piloto es Corpal Servicios de Limpieza (Córdoba, AR). Antes de leer una línea de código, conviene entender qué problema resuelve el sistema, quiénes lo usan y cómo encajan las piezas.
Ver toda la documentación en PDF
Qué problema resuelve y para quién¶
En un sanitario de aeropuerto o shopping, la pregunta operativa de todos los días es simple y difícil a la vez: ¿se limpió este baño, cuándo, y se está cumpliendo la frecuencia comprometida? Hasta ahora eso se resolvía con planillas en papel o con la confianza de que "alguien pasó". WorkDone reemplaza esa incertidumbre por un registro confiable y trazable:
- El personal de limpieza marca con un toque (tap NFC) el inicio y fin de cada limpieza, sin papeleo.
- La supervisión ve en tiempo real qué sanitario está libre, cuál se está limpiando y cuál tiene su SLA vencido (se pasó de la frecuencia comprometida).
- La administración del cliente recibe alertas, reportes y, a futuro, un portal de transparencia.
- El visitante del baño puede dejar su opinión con tres caritas en una terminal a la salida.
Está pensado para un escenario concreto: sanitarios con mala conectividad (subsuelos, terminales, zonas sin WiFi), muchos operarios rotando, y la necesidad de que ninguna limpieza real se pierda por un problema de red, de placa o de teléfono.
Cliente piloto
El piloto corre en Corpal (Córdoba). Dimensiones de referencia: ~30 sanitarios, ~25 operarios, ~240 trabajos por día. Cargas chicas para la infraestructura — el foco está en la confiabilidad, no en la escala.
Actores y roles del sistema¶
WorkDone distingue claramente quién hace qué. Los tres roles operativos viven en la entidad operario y definen qué puede hacer cada persona en la app móvil:
| Rol | Quién es | Qué hace |
|---|---|---|
| OPERADOR_LIMPIEZA | Personal de limpieza | Hace tap NFC y registra trabajos de tipo LIMPIEZA. |
| SUPERVISOR | Supervisor de Corpal | Hace tap NFC y registra trabajos de tipo SUPERVISION (control de calidad, no limpieza). |
| ADMIN | Encargado de equipamiento | No registra limpiezas: su app es Gestión NFC (alta, asignación y baja de placas). |
A estos se suman dos actores que no usan la app móvil:
- Supervisor / administración en el BackOffice web — autenticación web propia (
jhi_user), separada de la del móvil. Hace ABM de catálogos, mira el dashboard, gestiona alertas y dispositivos. - Visitante del sanitario — anónimo, deja su opinión en la terminal Smiley (3 caritas) o mediante un QR público. No tiene login.
Dos mundos de autenticación
Las personas con login (operarios, web) se autentican con credenciales y reciben un JWT. Los dispositivos (teléfonos, terminales Smiley) se identifican con una api_key propia. Son dos planos distintos: admin (web) no sirve para la app móvil, y un operario no entra al portal del cliente. El detalle vive en Arquitectura.
Los componentes del ecosistema¶
WorkDone no es una sola aplicación, sino un backend más tres clientes, cada uno en su propio repositorio:
| Componente | Repo | Stack | Qué hace |
|---|---|---|---|
| Backend | workdone-backend |
Spring Boot 4 + JHipster + Java 25 + MSSQL | Sistema de registro central: API REST, autenticación, motor de trabajos (taps), sincronización offline, scheduler de SLA, exportes. La única fuente de verdad. |
| App móvil | workdone-mobile |
Kotlin + Jetpack Compose + Room | App Android para operarios. Lee el tag NFC del sanitario, registra trabajos, opera 100% offline y sincroniza cuando hay red. |
| Kiosk Smiley | workdone-smiley-kiosk |
Kotlin + Compose (modo kiosko) | Tablet montada a la salida del baño. El visitante opina con 3 caritas; muestra "Último servicio: hace X min" en reposo. Sin login. |
| BackOffice | dentro de workdone-backend (src/main/webapp) |
Vite + React + shadcn/ui + Tanstack Query | Panel web de supervisión y administración: ABM (Estructura, Operarios, Rutas…), dashboard en tiempo real, reportes, alertas, y el portal del cliente. Ya construido y servido por el backend. |
Por qué repos separados
Cada cliente tiene su propio ciclo de release, su stack y su equipo. El backend es la fuente de verdad de los contratos: los clientes no inventan endpoints, los consumen. Lo desarrollamos en detalle en Arquitectura.
Diagrama de alto nivel del ecosistema¶
graph TD
subgraph Clientes
MOBILE["App móvil<br/>(operarios)<br/>Kotlin + Room"]
KIOSK["Kiosk Smiley<br/>(visitantes)<br/>Compose kiosko"]
BO["BackOffice<br/>(supervisión)<br/>React · en el backend"]
end
subgraph Backend["Backend — sistema de registro"]
API["API REST<br/>Spring Boot 4"]
DB[("MSSQL Server<br/>catálogos + trabajos<br/>+ opiniones")]
API --> DB
end
MOBILE -->|"JWT + api_key<br/>/api/v1/app/* · /sync"| API
KIOSK -->|"api_key<br/>/api/v1/smiley/*"| API
BO -->|"JWT web<br/>/api/v1/admin/*"| API
TAG["Placa NFC<br/>del sanitario"] -.->|"tap"| MOBILE
VISIT["Visitante"] -.->|"3 caritas"| KIOSK
Cómo leer esta documentación¶
El onboarding está pensado como un recorrido en tres tramos. No saltees el primero por más que quieras tocar código ya.
-
Entender el sistema (estás acá). Empezá por esta página y seguí con Arquitectura para captar el porqué de la separación en repos y del enfoque offline-first. Cuando aparezca un término que no conozcas — tap, sector, cierre automático, SLA — está definido en el Glosario.
-
Referencia técnica. El modelo de datos, los contratos de API y el protocolo de sincronización son la letra chica del sistema. El protocolo de sync y el motor de taps son el corazón del negocio: leelos enteros antes de tocar nada que los roce.
-
Empezar a programar. Recién entonces levantás el backend en local, corrés la app móvil contra él y empezás a contribuir. Cada repo tiene su
CLAUDE.mdcon comandos, convenciones y reglas de oro.
Regla de oro del ecosistema
El backend es la fuente de verdad de los contratos. Si un cliente (móvil o kiosk) tiene una copia de un contrato y no coincide con el backend real, gana el backend: se reporta, no se "arregla" en el cliente.