Límites conocidos del sistema
Son límites de diseño intencionados, no fallos. Conocerlos mantiene las expectativas realistas y ahorra tiempo cuando algo parece incorrecto pero no lo es.
No hay reequilibrado proactivo
El dispatcher nunca saca un pedido normal de la ruta de un repartidor solo para hacer sitio a un pedido Platinum. La protección Platinum funciona únicamente mediante la doble simulación descrita en Clientes prioritarios (Platinum).
Los pedidos en reparto están congelados
Una vez que un repartidor ha salido de la tienda con un pedido, el dispatcher no vuelve a tocar ese pedido. Se sigue usando para estimar cuándo quedará libre ese repartidor, pero no puede reasignarse, revalidarse ni cancelarse desde el algoritmo.
Las decisiones son locales, no globales
Cada decisión de asignación compara al repartidor actual con un repartidor candidato. El dispatcher no intenta encontrar una solución óptima global para todos los repartidores y todos los pedidos a la vez.
Por eso dos decisiones que individualmente parecen correctas pueden, juntas, resultar mejorables vistas en retrospectiva.
La urgencia del pedido no es un criterio de reasignación
Solo cuenta la prioridad del repartidor al decidir si se reasigna. Un pedido normal muy urgente no se adelanta por sí mismo a otro menos urgente. Ver Cuándo un pedido cambia de repartidor.
Last-Option puede superar la tolerancia normal de retraso
Como último recurso, un pedido puede colocarse con una estimación de llegada algo más tardía de lo que permitiría la tolerancia normal, en lugar de quedarse sin asignar. Ver Last-Option: la red de seguridad final.
Una tienda sin cambios se omite
Si nada ha cambiado en una tienda desde la última ejecución, se omite en lugar de reprocesarse. Una ejecución que parece "no haber hecho nada" en una tienda tranquila está funcionando correctamente — ver El ciclo de asignación, paso a paso.