US-025 — Actualización manual de estatus

Detalle de la historia¶

Historia¶

Como operador de FleteChat que gestiona la ejecución de los embarques, quiero actualizar manualmente el estatus desde el backoffice, para reflejar el avance real de la operación a medida que lo confirman el proveedor y el operador logístico.

Persona de usuario¶

Aplica a los operadores de FleteChat con rol admin u operator que gestionan embarques. No aplica al cliente final (que consulta y recibe notificaciones) ni a otros roles del backoffice (price_manager no gestiona embarques).

Contexto de negocio¶

En v1.0, FleteChat no integra actualizaciones automáticas con sistemas externos de tracking (navieras, aerolíneas, aduanas): la fuente de verdad del avance es lo que el operador actualiza manualmente a partir de las comunicaciones con el proveedor y el operador logístico. Esta decisión simplifica el alcance del MVP y se trata como tal.

Con el operador al mando, la UX del backoffice es crítica: debe hacer fácil avanzar al siguiente estatus válido (sin saltos inválidos ni regresiones accidentales), dejar escribir un comentario interno que explique el cambio, y disparar inmediatamente la notificación proactiva al cliente (ver historia de notificación de cambio de estatus). Los errores de estatus mal puesto se corrigen con un flujo de reversión controlado.

Criterios de aceptación¶

Selección del próximo estatus¶

1. La UI de actualización de estatus muestra únicamente los próximos estatus válidos según la secuencia dinámica del embarque (ver historia de secuencia dinámica de estatus). Estatus fuera de secuencia no son seleccionables.
2. El operador puede seleccionar entre las opciones válidas; no puede escribir un estatus libre.
3. La UI muestra el estatus actual y la secuencia completa restante para dar contexto.

Comentario y actor¶

1. Al actualizar, el operador puede agregar un comentario interno opcional asociado al cambio. El comentario vive junto con la entrada en el historial y es visible sólo para admin y operator (ver historia de historial de cambios de estatus).
2. Cada cambio registra autor (usuario con identidad), timestamp, estatus anterior, estatus nuevo y comentario (si hubo).

Efectos del cambio¶

1. Un cambio válido dispara automáticamente la notificación proactiva al cliente por WhatsApp (ver historia de notificación de cambio de estatus).
2. El cambio se refleja inmediatamente en la consulta de estatus del cliente y en el historial (ver historias correspondientes).

Reversión controlada¶

1. En caso de error, el operador admin puede revertir el último cambio de estatus desde la ficha: la reversión crea una nueva entrada en el historial (no borra la anterior) marcada como reversión con comentario obligatorio.
2. La reversión no envía una notificación automática al cliente; el operador decide si envía un mensaje aclaratorio manualmente desde el chat del backoffice (ver historia de chat de handoff).

Edge cases¶

• Operador intenta actualizar a un estatus fuera de la secuencia del embarque. La UI no lo permite: las opciones fuera de secuencia no aparecen. Si el operador cree que la secuencia es incorrecta, lo escala al admin que ajusta el catálogo (ver historia de servicios y estatus).
• Dos operadores intentan actualizar el mismo embarque simultáneamente. El sistema acepta la primera actualización y rechaza la segunda con un mensaje claro (conflicto); el segundo operador recarga la ficha y decide qué hacer.
• Cliente sin número verificado activo al momento del cambio. El estatus se actualiza normalmente; la notificación del cliente se omite y registra un warning (ver historia de notificación de cambio de estatus).
• Embarque cancelado. La cancelación es un estatus terminal; después de cancelar, no se permiten nuevos cambios salvo reversión por admin.

Tamaño, prioridad y tipo¶

• Tamaño: M
• Prioridad: P0 — sin actualización manual la trazabilidad del embarque se queda en el estado inicial.
• Tipo: feature

Premisas¶

La historia está redactada bajo las siguientes premisas. Si alguna cambia, la historia debe revisarse y ajustarse en consecuencia. Todas deben ser confirmadas por el cliente antes de cerrar la historia.

• PR-111 — Actualización manual como única fuente en v1.0. El avance del estatus proviene únicamente de actualizaciones manuales del operador. Integraciones automáticas con trackers externos están fuera del alcance de v1.0.
• PR-112 — Secuencia dinámica como restricción dura. El operador no puede saltar estatus fuera de la secuencia dinámica del embarque; la UI sólo expone las opciones válidas. Ajustar la secuencia requiere cambiar el catálogo (ver historia de servicios y estatus).
• PR-113 — Reversión con historial intacto. La reversión de un cambio crea una nueva entrada en el historial (no elimina entradas previas) y no dispara notificación automática al cliente; la comunicación al cliente queda bajo criterio del operador.

Refinamiento y Definition of Ready¶

Notas¶

Checklist¶

• ✅ Historia escrita en formato Como / Quiero / Para
• ✅ Persona de usuario identificada
• ✅ Contexto de negocio documentado
• ✅ Criterios de aceptación observables y pass/fail
• ✅ Edge cases relevantes listados
• ✅ Tamaño y prioridad asignados
• ⬜ Premisas PR-111 a PR-113 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente