Reglas operativas (parámetros y SLA)¶

Estos son los números y reglas de negocio que gobiernan el comportamiento del sistema; cambiarlos cambia la operación. Todo lo que sigue está verificado contra el código del backend (no contra documentos previos): cada fila apunta al archivo y la línea que la define. Si mañana alguien edita un default, este documento queda desactualizado salvo que se actualice junto al código.

1. Parámetros configurables de negocio¶

1.1. Algoritmo del tap — app.tap¶

Definidos en TapProperties.java (@ConfigurationProperties(prefix = "app.tap")). El constructor compacto del record fija el default si el valor es <= 0.

1.2. Anti-abuso del Smiley — app.smiley¶

Definidos en SmileyProperties.java (prefix = "app.smiley").

1.3. Estado de conexión de dispositivos — app.monitor¶

Definidos en MonitorDispositivoProperties.java (prefix = "app.monitor"). Derivan el estado de conexión a partir de ultimoContactoTs.

2. "Limpieza válida" y cuentaParaSla — la regla más importante¶

Una limpieza resetea el SLA del sanitario (es decir, vuelve a poner el reloj de "última limpieza" en cero) solo si cumple TODO lo siguiente. Si falla cualquiera de los criterios, no cuenta y el sanitario sigue acumulando tiempo sin limpiar.

Evidencia: TrabajoRepository.findUltimaLimpiezaValida (TrabajoRepository.java:95-108) y su gemela existsLimpiezaValidaById (líneas 115-127), que aplican los mismos criterios.

2.1. El default y quién lo cambia¶

Trabajo.cuentaParaSla arranca en Boolean.TRUE por construcción de la entidad (Trabajo.java:78-79). Casi nadie lo baja a false. Solo dos caminos lo tocan:

2.2. Los dos cierres automáticos que se comportan distinto¶

Esta es la causa de la confusión clásica: "hay dos cierres automáticos y se comportan distinto". Y es cierto. Ambos dejan el trabajo en estado EGRESO_CIERRE_AUTOMATICO y truncan la duración a cierreAutomaticoMaxMinutes (30 min), pero solo uno toca cuentaParaSla.

flowchart TD
    A[Trabajo abierto sin egreso] --> B{¿Quién lo cierra?}
    B -->|Operario tapea otro sanitario| C[Cierre por tap]
    B -->|Scheduler tras N horas| D[Cierre por scheduler]
    C --> E[estado = EGRESO_CIERRE_AUTOMATICO<br/>cuentaParaSla NO se toca = true]
    D --> F[estado = EGRESO_CIERRE_AUTOMATICO<br/>cuentaParaSla = false]
    E --> G[Resetea el SLA del sanitario]
    F --> H[NO resetea el SLA]

3. Cierre automático y truncado de duración¶

Cuando el operario abre en el sanitario A y tapea B sin cerrar A, el sistema cierra A automáticamente. El fin_ts no es simplemente "ahora": se calcula como el mínimo entre el tope de 30 min y el momento del ingreso a B.

fin_ts(A) = min( inicio_ts(A) + cierreAutomaticoMaxMinutes , ts_ingreso(B) )

Evidencia: calcularCierreAutomatico (TrabajoTapService.java:672-675), invocado desde el flujo de cierre+ingreso (TrabajoTapService.java:334-356):

private Instant calcularCierreAutomatico(Instant inicioAbierto, Instant tapActual) {
    Instant maxFin = inicioAbierto.plus(Duration.ofMinutes(props.cierreAutomaticoMaxMinutes()));
    return tapActual.isBefore(maxFin) ? tapActual : maxFin;
}

4. Reglas de aceptación / rechazo del tap¶

El orden de validación importa: el rol se chequea antes de resolver el tag, y los operarios inactivos no se rechazan.

4.1. Operario con rol ADMIN → ROL_NO_PERMITIDO (no persiste nada)¶

Un operario con rol = ADMIN que tapea devuelve RolNoPermitido y no persiste absolutamente nada: ni el trabajo, ni un TAG_DESCONOCIDO, ni su alerta. El cliente ADMIN purga el tap sin reintentar.

Evidencia: TrabajoTapService.java:200-203.

RolOperario rol = operario.getRol() != null ? operario.getRol() : RolOperario.OPERADOR_LIMPIEZA;
if (rol == RolOperario.ADMIN) {
    return new RolNoPermitido(rol);
}

4.2. Operario inactivo → se ACEPTA (con warning + alerta)¶

Contraintuitivamente, un operario inactivo que tapea no se rechaza: el trabajo se crea igual, se le agrega el warning operario_inactivo_offline y se genera la Alerta OPERARIO_INACTIVO_OFFLINE.

Evidencia: el flag se calcula sin cortar el flujo en TrabajoTapService.java:190, se agrega el warning en la línea 194, y la alerta se emite tras el cierre/ingreso (líneas 257-261, 328, 355).

boolean operarioInactivo = !Boolean.TRUE.equals(operario.getActivo());
// ...
if (operarioInactivo) warnings.add(WARN_OPERARIO_INACTIVO);

4.3. Resumen de resoluciones del tap¶

5. Acumulación de warnings¶

El trabajo guarda sus warnings en una sola columna warnings NVARCHAR(500), concatenados con |, y truncados a 500 caracteres. No es una tabla de eventos: es un string plano.

Constantes definidas en TrabajoTapService.java:78-86; concatenación y truncado en appendWarnings (TrabajoTapService.java:680-694):

private static void appendWarnings(Trabajo t, List<String> warnings) {
    if (warnings == null || warnings.isEmpty()) return;
    String joined = String.join("|", warnings);
    if (t.getWarnings() == null || t.getWarnings().isBlank()) {
        t.setWarnings(joined);
    } else {
        t.setWarnings(t.getWarnings() + "|" + joined);
    }
    // Mantener dentro del límite de 500 chars
    if (t.getWarnings().length() > 500) t.setWarnings(t.getWarnings().substring(0, 500));
}

Warnings posibles:

Ver también¶

• Sincronización — el protocolo de sync donde se procesan los taps y se aplican estas reglas.
• Jobs y alertas — los schedulers (SlaSchedulerService, monitor G3) que cierran colgados y derivan estados de conexión.
• Modelo de datos — los campos cuenta_para_sla, duracion_anomala, warnings y la tabla de eventos.