Workflow — Anomalías

Esta página se importa íntegra desde la fuente de verdad técnica: yms-docs/03-workflows-operativos/anomalias.md — cualquier corrección debe hacerse allí.

Workflow de resolución de una anomalía

stateDiagram-v2
  [*] --> Open: Sistema detecta automáticamente
  Open --> InProgress: Yard Manager toma el caso
  InProgress --> Resolved: Se resuelve con razón
  InProgress --> Dismissed: Falsa alarma o irrelevante
  Open --> Dismissed: Descartada sin investigación
  Resolved --> [*]
  Dismissed --> [*]

  note left of Open
    Notificación al Yard Manager
    según severidad
  end note

  note right of Resolved
    Razón obligatoria
    desde catálogo
  end note

Cada anomalía pasa por un workflow estructurado y auditado

Mapa visual de las 10 categorías

flowchart TB
  subgraph CAPTURA[Captura y confirmación]
      A1[ManualEntryNeedsGpsConfirmation<br/>LOW]
      A2[VisitorZoneUnconfirmed<br/>LOW]
      A3[UnexpectedManualGap<br/>HIGH]
  end
  subgraph ZONAS[Zonas y rondín]
      Z1[OperatorCorrectedGpsZone<br/>INFO]
      Z2[GpsZoneMismatch<br/>MEDIUM]
      Z3[TrailerNotFoundOnRound<br/>MEDIUM]
  end
  subgraph FISICAS[Físicas y compliance]
      F1[SealMismatch<br/>HIGH]
      F2[TrailerDamaged<br/>MEDIUM/HIGH]
      F3[LongDwell<br/>LOW]
      F4[IncidenteFisico<br/>variable]
  end

  style A3 fill:#dc3545,color:#fff
  style F1 fill:#dc3545,color:#fff
  style F2 fill:#ffc107,color:#212529
  style Z2 fill:#ffc107,color:#212529
  style Z3 fill:#ffc107,color:#212529
  style A1 fill:#6c757d,color:#fff
  style A2 fill:#6c757d,color:#fff
  style F3 fill:#6c757d,color:#fff
  style Z1 fill:#17a2b8,color:#fff
  style F4 fill:#17a2b8,color:#fff

Las 10 anomalías agrupadas por dominio y severidad

Documento ejecutivo de referencia

Versión: 1.5 (depuración post-cobertura) Última actualización: 13 de mayo de 2026 Cambios desde versión anterior: ADRs 038-040. Tipos de anomalía actualizados: 6 nuevos (ManualEntryNeedsGpsConfirmation, VisitorZoneUnconfirmed, OperatorCorrectedGpsZone, UnexpectedManualGap, SealMismatch, TrailerNotFoundOnRound). GpsZoneMismatch reformulada (compara GPS vs zona confirmada por personal de patio, no vs zona del slot del assignment). Tipos SlotAssigned/SlotReleased eliminados. Severidades recalibradas para el nuevo paradigma de GPS-como-confirmación.

Este documento explica de forma concreta cómo el sistema YMS detecta automáticamente situaciones que requieren atención humana (anomalías) y cómo se resuelven mediante un workflow estructurado. Las anomalías son la garantía de calidad operativa del sistema: convierten datos sospechosos en tareas concretas para el equipo, evitando que pequeños errores se acumulen silenciosamente.

🛠️ Tipos vigentes: ver §8.0.6 de propuesta-maestra.md para la lista canónica. Las descripciones detalladas de cada tipo en este documento se mantienen como referencia, complementadas con los 6 tipos nuevos introducidos por la depuración:

Tipo Severidad Cuándo se genera Quién resuelve
ManualEntryNeedsGpsConfirmation Medium Personal de patio registró entrada de trailer con Samsara, pero GPS no confirma en >15 min YardManager investiga si GPS está fallando o si la captura fue errónea
VisitorZoneUnconfirmed Low Trailer visitante (IsGpsCapable = false) con zona pendiente de confirmar en rondín >4h Operator confirma zona en rondín, anomalía se resuelve sola
OperatorCorrectedGpsZone Low (informativa) Personal de patio corrigió zona reportada por GPS en rondín Auto-resuelve; YardManager revisa patrones para detectar dispositivos GPS calibrados mal
UnexpectedManualGap Medium GPS reporta entrada/salida sin registro manual previo YardManager investiga: ¿entrada fantasma? ¿personal de patio olvidó capturar?
SealMismatch High Los sellos al salir no coinciden con los del entrar YardManager investiga (rotura, cambio, error de captura); puede requerir reporte al transportista
TrailerNotFoundOnRound Medium Personal de patio buscó trailer en rondín y no estaba físicamente YardManager coordina búsqueda; si confirma ausencia, fuerza cierre del Assignment

Tipo	Severidad	Cuándo se genera	Quién resuelve
`ManualEntryNeedsGpsConfirmation`	Medium	Personal de patio registró entrada de trailer con Samsara, pero GPS no confirma en >15 min	YardManager investiga si GPS está fallando o si la captura fue errónea
`VisitorZoneUnconfirmed`	Low	Trailer visitante (`IsGpsCapable = false`) con zona pendiente de confirmar en rondín >4h	Operator confirma zona en rondín, anomalía se resuelve sola
`OperatorCorrectedGpsZone`	Low (informativa)	Personal de patio corrigió zona reportada por GPS en rondín	Auto-resuelve; YardManager revisa patrones para detectar dispositivos GPS calibrados mal
`UnexpectedManualGap`	Medium	GPS reporta entrada/salida sin registro manual previo	YardManager investiga: ¿entrada fantasma? ¿personal de patio olvidó capturar?
`SealMismatch`	High	Los sellos al salir no coinciden con los del entrar	YardManager investiga (rotura, cambio, error de captura); puede requerir reporte al transportista
`TrailerNotFoundOnRound`	Medium	Personal de patio buscó trailer en rondín y no estaba físicamente	YardManager coordina búsqueda; si confirma ausencia, fuerza cierre del Assignment

¿Qué es una anomalía?

Una anomalía es una situación detectada por el sistema (o reportada manualmente por un integrante del personal de patio) que requiere revisión humana porque indica que algo no encaja con la realidad esperada.

Ejemplos de situaciones reales que generan anomalía:

El personal de patio confirmó en rondín que un trailer está en Zona Norte, pero el GPS lo coloca consistentemente en Zona Sur.
Un trailer lleva 15 días en el patio sin moverse.
Un trailer lleva 3 horas sin reportar GPS aunque debería estar transmitiendo continuamente.
Un integrante del personal de patio detecta visualmente que un trailer está dañado al registrar la salida.
El sistema detecta vía GPS que un trailer salió del geofence sin que su salida fuera registrada manualmente (UnexpectedManualGap).

Cada anomalía NO bloquea la operación — solo genera una alerta para que alguien la revise. El sistema sigue funcionando aunque haya anomalías abiertas.

Conceptos fundamentales

Estados de una anomalía

Open  →  InProgress  →  Resolved
  │                 │
  │                 └──→  Dismissed
  └──→  Resolved
  └──→  Dismissed

Estado	Significado
Open	Anomalía recién detectada. Nadie la está atendiendo aún.
InProgress	Alguien (jefe de patio) está investigando. Asignada a un usuario específico.
Resolved	La situación fue resuelta. Razón documentada.
Dismissed	Descartada (falso positivo, error de datos, no aplica). Razón documentada.

Severidad de una anomalía

Low  <  Medium  <  High

La severidad se determina automáticamente según el tipo y el contexto:

Severidad	Significado operativo
Low	Atender en algún momento del turno. No urgente.
Medium	Atender en el día. Puede afectar operación si se acumula.
High	Atender pronto. Indica problema potencial significativo.

Reglas duras del sistema

Las anomalías se generan automáticamente o se reportan manualmente; nunca se “crean” por capricho.
No hay anomalías duplicadas del mismo tipo para el mismo trailer abiertas simultáneamente (anti-duplicación).
Solo el jefe de patio puede resolver o descartar anomalías. El personal de patio puede reportarlas y verlas, pero no cerrarlas.
Toda resolución requiere razón documentada — no se puede cerrar una anomalía sin explicar por qué.
Cada cambio de estado queda auditado con usuario, timestamp y razón.

Tipos de anomalía detallados

Hay 10 tipos vigentes tras la depuración. Los 6 nuevos están resumidos en la tabla de la cabecera de este documento. Los 4 históricos (GpsZoneMismatch, LongDwell, NoGpsSignal/GpsLost, UnexpectedManualGap) se detallan a continuación con causas típicas y severidad. El tipo ManualReport para reportes manuales del personal de patio se documenta en su propia sección abajo.

Tipo 1 — GpsZoneMismatch (Inconsistencia GPS↔Zona confirmada en rondín)

Reformulada tras ADRs 038-039. Su semántica vigente compara GPS contra Trailer.LastConfirmedZoneId (zona que el personal de patio confirmó en rondín), NO contra una zona derivada de un slot del assignment.

Qué es: el GPS de un trailer reporta posiciones que caen consistentemente en una zona distinta a la que el personal de patio confirmó manualmente en su último rondín.

Cómo se detecta:

Cada vez que llega una posición GPS de un trailer (con IsGpsCapable = true), el sistema determina la zona donde cae esa posición.
Si la zona del GPS coincide con Trailer.LastConfirmedZoneId → todo OK, sin anomalía.
Si la zona del GPS difiere de la confirmada por el personal de patio y la divergencia se repite (umbral configurable, ej. ≥3 posiciones consecutivas en zona distinta) → genera anomalía GpsZoneMismatch.
Si el personal de patio aún no ha confirmado zona en rondín (Trailer.LastConfirmedZoneId = null) → NO se genera GpsZoneMismatch; se genera ManualEntryNeedsGpsConfirmation o VisitorZoneUnconfirmed en su lugar.

Severidad automática (según relación entre zonas):

Relación entre zona GPS y zona confirmada en rondín	Severidad
Zona reportada por GPS es adyacente a la confirmada	Low
Zona reportada por GPS NO es adyacente pero está en el mismo yard	Medium
Zona reportada por GPS está muy lejos (>2 zonas de distancia)	High

Causas reales típicas:

El trailer fue movido entre zonas sin que el personal de patio lo confirmara en el siguiente rondín.
GPS averiado del dispositivo Samsara (impreciso, errático, o datos viejos).
Zona mal mapeada (las coordenadas de la zona en el sistema no coinciden con la realidad).
El personal de patio corrigió zona en rondín pero el dispositivo GPS está fijado en el extremo del remolque que cae en la zona vecina (offset físico).

Acción esperada:

En el siguiente rondín, el personal de patio valida físicamente y, si la zona GPS es la correcta, ejecuta “Corregir zona” → la zona confirmada se actualiza, la anomalía se resuelve. Si la zona confirmada era la real (el GPS está mal), el YardManager resuelve la anomalía con razón GpsCalibrationIssue.

Cuándo NO se genera (a propósito):

Cuando ya hay una anomalía abierta del mismo tipo para el mismo trailer (anti-duplicación).
Cuando el personal de patio aún no ha confirmado zona en rondín (sería ManualEntryNeedsGpsConfirmation o VisitorZoneUnconfirmed).
Cuando el trailer tiene IsGpsCapable = false (sin GPS no hay comparación).
Cuando el GPS cae en pasillo entre zonas pero dentro de la tolerancia de la zona confirmada.

Lo que el sistema NO valida (intencional):

❌ NO valida sub-posiciones dentro de zona (no hay slots; ADR-038).
❌ NO genera anomalía con una sola posición divergente — requiere persistencia para evitar falsos positivos por jitter GPS.

Tipo 2 — LongDwell (Trailer olvidado)

Detección de trailers “estacionados para siempre”.

Qué es: un trailer lleva más tiempo del esperado en el patio sin moverse. Indica posible olvido administrativo, problema mecánico, o conflicto comercial pendiente.

Cómo se detecta:

Un job nocturno revisa todos los trailers en patio.
Si un trailer no ha tenido movimiento (cambio de zona, salida, registro nuevo) en X días, genera anomalía.
Umbral configurable por yard (default 7 días).

Severidad automática (según días sin movimiento):

Días estacionado	Severidad
7-14 días	Low
14-30 días	Medium
> 30 días	High

Causas reales típicas:

Cliente abandonó el trailer (problema comercial sin resolver).
Trailer en mantenimiento prolongado sin marcar formalmente.
Conflicto pendiente (esperando documentación, autorización, etc.).
Olvido administrativo (nadie recuerda por qué está ahí).

Beneficio operativo: ayuda al jefe de patio a identificar oportunidades de registrar la salida de trailers olvidados que de otra forma quedarían silenciosas.

Nota: este tipo de anomalía es post-MVP (sección 15.1 del documento técnico). El esquema ya está, pero el detector se activa en una fase posterior. Documentamos aquí para contexto completo.

Tipo 3 — NoGpsSignal / GpsLost (GPS perdido)

Detección de dispositivos GPS averiados.

Qué es: un trailer que tiene GPS Samsara instalado lleva más tiempo del esperado sin reportar posición. El GPS debería transmitir cada 30 segundos en operación normal.

Cómo se detecta:

Sistema monitorea el campo LastPositionAt de cada trailer.
Si han pasado más de N horas (configurable, típicamente 2-4h) sin reportar, marca el trailer como “GPS perdido”.
Genera anomalía y aparece como tarea pendiente del personal de patio para verificación física.

Severidad automática:

Tiempo sin GPS	Severidad
2-6 horas	Low
6-24 horas	Medium
> 24 horas	High

Causas reales típicas:

Batería del dispositivo Samsara agotada (requiere recarga o reemplazo).
Dispositivo Samsara averiado físicamente.
Trailer fuera de cobertura celular (zona muerta del proveedor de telefonía).
Trailer apagado o sin energía (algunos modelos requieren tracto encendido).

Acción operativa esperada: el personal de patio verifica físicamente que el trailer está en su zona reportada en el siguiente rondín; reporta el problema al equipo de mantenimiento del Samsara.

Tipo 4 — UnexpectedManualGap (Salida fantasma sin registro)

Detección de salidas no registradas.

Qué es: un trailer cuya asignación está activa (Confirmed) pero el GPS lo coloca fuera del geofence del patio. Indica que el trailer salió sin que el personal de patio registrara la salida manualmente.

Cómo se detecta:

Cada vez que llega una posición GPS, el sistema verifica si el trailer está fuera del polígono del patio Y aún tiene asignación activa.
NO genera anomalía con la primera posición fuera — espera 3 posiciones consecutivas fuera del yard antes de generar la anomalía.
Si una posición vuelve a estar dentro del yard, el contador se resetea (evita falsos positivos por GPS impreciso momentáneo).

Por qué 3 posiciones consecutivas: el GPS comercial ocasionalmente reporta posiciones erráticas por reflexión multipath (rebotes en estructuras metálicas o edificios). Una sola posición fuera del yard NO es suficiente evidencia de salida real. Tres posiciones consecutivas (separadas por intervalos de ~30 segundos cada una) sí indican movimiento real. Este threshold es configurable vía setting.

Severidad: generalmente Medium (indica error de proceso, no robo o problema grave).

Causas reales típicas:

Personal de patio olvidó registrar la salida cuando el trailer abandonó el patio.
Salida no autorizada (caso raro, requiere investigación).
GPS persistentemente impreciso que coloca el trailer fuera durante varias posiciones consecutivas.

Acción operativa esperada: el jefe de patio verifica si el trailer realmente salió y registra la salida (o fuerza el cierre del Assignment) con razón GhostExit.

Anomalías reportadas manualmente

Además de las 4 anomalías automáticas, el personal de patio puede reportar manualmente situaciones que detecta visualmente.

Reporte manual del personal de patio

Cuándo se usa:

Trailer dañado al llegar o al salir (golpe, raspón, llanta baja, etc.).
Zona bloqueada por algo que no es trailer (basura, equipo de mantenimiento, vehículo no autorizado).
Trailer abandonado sin documentación.
Cualquier situación que requiere atención del jefe de patio.

Acciones del personal de patio para reportar:

T+0   Personal de patio detecta visualmente la situación.
      Abre yms-mobile.

T+1   Toca "+ Reportar" en el menú principal.

T+2   Modal: "¿Qué situación detectaste?"
      Tipos disponibles:
      - Trailer dañado
      - Zona bloqueada
      - Trailer abandonado
      - Otro

T+3   Selecciona tipo. Modal expandido pide:
      - Trailer afectado (autocomplete o lista de recientes).
      - Zona afectada (selector con autocomplete).
      - Foto obligatoria (evidencia visual).
      - Notas opcionales.

T+4   [Reportar]. Anomalía creada con tipo "ManualReport"
      y severidad por defecto Medium.
      Notificación inmediata al jefe de patio (SignalR).

Severidad de reporte manual: por defecto Medium. El jefe de patio puede reclasificar al investigar.

Workflow de resolución (el flujo principal del jefe de patio)

Cómo aparecen las anomalías al jefe de patio

1. Sistema detecta anomalía o personal de patio la reporta.
2. Anomalía aparece automáticamente en el dashboard del jefe de patio
   con badge contador de severidad.
3. Notificación en tiempo real (SignalR) si está conectado.
4. Aparece en lista priorizada: High primero, luego Medium, luego Low.
   Dentro de cada nivel, ordenadas por antigüedad.

Acciones disponibles en cada estado

Estado actual	Acciones posibles	Quién puede ejecutar
Open	Iniciar investigación	Jefe de patio, Admin
Open	Resolver directamente	Jefe de patio, Admin
Open	Descartar	Jefe de patio, Admin
InProgress	Resolver	Jefe de patio (asignado), Admin
InProgress	Descartar	Jefe de patio (asignado), Admin
Resolved	(Final, no más acciones)	—
Dismissed	(Final, no más acciones)	—

Flujo típico de resolución

Caso simple: revisar y resolver inmediatamente

T+0   Jefe de patio ve anomalía nueva en dashboard:
      "GpsZoneMismatch: Trailer ABC-1234 confirmado en Zona Roja
       pero GPS reporta en Zona Verde"

T+1   Click en la anomalía. Ve detalle:
      - Tipo, severidad, timestamp.
      - Trailer, zona confirmada por personal de patio en último rondín.
      - Zona reportada por GPS.
      - Mapa visual con ambas zonas resaltadas.

T+2   Investiga (puede llamar al personal de patio por radio para verificar).

T+3   Confirma con el personal de patio que la zona real es la del GPS
      (el personal de patio la corrige en el siguiente rondín).

T+4   Click en "Resolver".

T+5   Modal pide razón obligatoria:
      - OnSiteVerification — Personal de patio verificó físicamente.
      - ZoneCorrected — El personal de patio corrigió la zona en rondín.
      - FalsePositive — Datos no concluyentes (GPS impreciso, etc.).
      - GpsCalibrationIssue — Dispositivo Samsara mal calibrado o averiado.
      - Other — Razón en texto libre.

T+6   Selecciona "ZoneCorrected" + nota.

T+7   [Confirmar resolución]. Anomalía pasa a Resolved.
      Si aplica, el jefe de patio puede cambiar la zona del trailer
      sin esperar al personal de patio (acción especial del YardManager).

Tiempo total: ~30-60 segundos.

Caso complejo: requiere investigación

T+0   Jefe de patio ve anomalía High:
      "LongDwell: Trailer XYZ-9999 lleva 35 días sin moverse"

T+1   Click. Ve detalle: histórico del trailer, último movimiento,
      asignación activa.

T+2   Click en "Iniciar investigación".
      Modal: confirma que se asigna a su usuario.
      Anomalía pasa a InProgress.

T+3   Investiga (consulta cliente, revisa documentación, llama).
      Puede tardar horas o días.

T+4   Cuando tiene la información, vuelve a la anomalía.

T+5   Click en "Resolver".

T+6   Modal pide razón. Selecciona "Other" + nota:
      "Cliente solicitó retención hasta el 15 de mayo
       por proceso de inspección sanitaria. OK del jefe comercial."

T+7   [Confirmar]. Anomalía pasa a Resolved.

Tiempo total: variable (minutos a días dependiendo de la investigación).

Razones de resolución y cuándo usarlas

Razón	Cuándo se usa
OnSiteVerification	El personal de patio o jefe de patio verificó físicamente que la situación está OK. Ejemplo: GPS reportaba mal pero el trailer está donde debería.
ZoneCorrected	Se tomó acción correctiva. Ejemplo: el trailer estaba en zona equivocada, el personal de patio lo corrigió en rondín.
FalsePositive	Los datos no eran concluyentes. Ejemplo: GPS impreciso por mal clima, trailer recién entrando con posición todavía en cálculo.
EquipmentFailure	Problema externo al sistema. Ejemplo: dispositivo Samsara averiado, requiere reemplazo.
Other	Razón específica que no encaja en las anteriores. Requiere texto libre obligatorio.

Razón de descarte

Cuando se descarta (Dismiss) en lugar de resolver, se usa cuando:

La anomalía no debería haberse generado (configuración mal, dato corrupto).
La situación se autoresolveía antes de que alguien la atendiera.
La anomalía es duplicada de otra que ya está en investigación.

El descarte requiere razón obligatoria igual que la resolución.

Tabla resumen de tipos de anomalías

Tipo	Detección	Frecuencia esperada	Severidad típica	Acción esperada
GpsZoneMismatch	Automática en cada evento GPS	Diaria (1-5/día)	Low-High según relación entre zonas	Personal de patio corrige zona en rondín; YardManager resuelve si GPS averiado
ManualEntryNeedsGpsConfirmation	Timer >15 min sin confirmación GPS	Diaria (varía)	Medium	YardManager investiga GPS o captura errónea
VisitorZoneUnconfirmed	Timer >4h sin confirmación de zona en rondín (visitantes)	Diaria (varía)	Low	Personal de patio confirma zona en rondín
OperatorCorrectedGpsZone	Auto-generada al corregir zona en rondín	Diaria (varía)	Low (informativa)	Auto-resuelve; revisar patrones de GPS calibrado mal
UnexpectedManualGap	Automática (GPS reporta evento sin contraparte manual)	Mensual (rara)	Medium	YardManager registra salida o fuerza cierre
SealMismatch	Automática al verificar sellos al salir	Rara	High (compliance)	YardManager investiga + reporta a transportista
TrailerNotFoundOnRound	Reporte del personal de patio en rondín	Rara	Medium	YardManager coordina búsqueda; fuerza cierre si ausente
NoGpsSignal / GpsLost	Monitoreo continuo	Semanal (1-5/semana)	Low-High según horas	Verificar dispositivo Samsara
LongDwell	Job nocturno (post-MVP)	Semanal (1-3/semana)	Low-High según días	Investigar con cliente o registrar salida
ManualReport	Reportada por personal de patio	Diaria (varía)	Medium por defecto	Investigar visualmente

Beneficios operativos del sistema de anomalías

Para el cliente

Visibilidad de problemas que antes pasaban desapercibidos. Sin sistema, los errores se descubrían cuando un cliente reclamaba; con sistema, se detectan automáticamente.
Trazabilidad completa. Cada situación queda documentada con razón, lo cual reduce disputas internas y con clientes.
Reducción de “trailers perdidos”. El histórico siempre tiene la última posición conocida; las anomalías ayudan a identificar discrepancias antes de que se vuelvan crisis.
Mejora continua. Patrones en las anomalías revelan oportunidades operativas (ej. “cada lunes hay muchos GpsZoneMismatch en Zona Norte” → tal vez el personal de patio del lunes están escaneando QRs de zonas equivocadas).

Para el jefe de patio

Lista priorizada de qué atender primero (severidad + antigüedad).
Notificaciones en tiempo real sin necesidad de estar revisando manualmente.
Razones estructuradas que facilitan reportes posteriores (“¿cuántos GpsZoneMismatch fueron por GPS averiado este mes?”).

Para el personal de patio

Anomalías como tareas pendientes en su app móvil, ordenadas por urgencia.
Notificación cuando reporta una anomalía manualmente (sabe que el jefe la verá).
Sin presión de “resolver” anomalías (esa responsabilidad es del jefe de patio).

Lo que SÍ y NO permite el sistema

Operación	¿Permitido?	Quién
Reportar anomalía manualmente	✅ Sí	Personal de patio, Jefe de patio
Iniciar investigación	✅ Sí	Jefe de patio, Admin
Resolver anomalía con razón	✅ Sí	Jefe de patio, Admin
Descartar anomalía con razón	✅ Sí	Jefe de patio, Admin
Resolver sin razón documentada	❌ No	—
Personal de patio resolviendo anomalía	❌ No	—
Eliminar anomalía del histórico	❌ No	—
Editar razón de resolución después	❌ No	—
Reabrir anomalía resuelta	❌ No	Crear nueva si vuelve a ocurrir

Decisiones de diseño tomadas

Decisión 1: Anti-duplicación automática

Adoptado: el sistema NO genera una segunda anomalía del mismo tipo para el mismo trailer si ya hay una abierta. Esto evita saturar al jefe de patio con alertas redundantes.

Justificación: un trailer con GPS averiado generaría una anomalía cada 30 segundos sin esta regla. Con anti-duplicación, genera una sola hasta que se resuelva.

Decisión 2: Severidad automática, no manual

Adoptado: la severidad se calcula automáticamente según métricas objetivas (distancia, días, horas). El jefe de patio NO la edita.

Justificación: evita subjetividad y permite reportes consistentes. Si el algoritmo no refleja bien la severidad real, se ajusta el algoritmo, no las anomalías individuales.

Decisión 3: Razón obligatoria de un enum + texto opcional

Adoptado: las razones están predefinidas (5 opciones) más un campo de texto libre para “Other”. No se permite resolver sin razón estructurada.

Justificación: permite reportes agregados (“¿cuántas anomalías fueron por GPS averiado?”). Texto libre solo cubre casos no anticipados.

Decisión 4: Solo el jefe de patio resuelve

Adoptado: el personal de patio pueden reportar y ver, pero no resolver ni descartar. Esa responsabilidad es exclusiva del jefe de patio.

Justificación: evita conflicto de interés (personal de patio resolviendo su propia anomalía sin investigación) y mantiene control de calidad.

Decisión 5: Anomalías son append-only en su histórico

Adoptado: una vez resuelta o descartada, una anomalía no se reabre ni se modifica. Si la situación vuelve a ocurrir, se genera una nueva anomalía.

Justificación: preserva el histórico inmutable. Cada anomalía representa “un evento detectado en un momento específico”; intentar reabrirla pierde el sentido cronológico.

Documentos relacionados

registro-entrada.md — flujo que origina ManualEntryNeedsGpsConfirmation y VisitorZoneUnconfirmed
registro-salida.md — flujo que origina SealMismatch y UnexpectedManualGap
rondin.md — flujo que origina OperatorCorrectedGpsZone y TrailerNotFoundOnRound
incidentes.md — incidentes físicos como anomalía PhysicalIncident
../00-vision-general/roles-permisos.md — quién puede resolver y descartar
../00-vision-general/glosario.md — estados y tipos de anomalía

Para mapa completo de la documentación, ver yms-indice.md.

Documento ejecutivo del workflow de anomalías — referencia operativa.