US-027 — Secuencia dinámica de estatus

Detalle de la historia¶

Historia¶

Como administrador de FleteChat que gestiona el catálogo de servicios, quiero que la secuencia de estatus del embarque se arme automáticamente según los servicios contratados, para no tener que configurar un flujo distinto embarque por embarque.

Persona de usuario¶

Aplica a los administradores de FleteChat que gestionan el catálogo (servicios, estatus por servicio, secuencias). Indirectamente, aplica a cada embarque y a sus operadores, que reciben la secuencia ya armada sin intervención manual.

Contexto de negocio¶

Un embarque marítimo LCL con entrega en bodega tiene una secuencia de estatus distinta a uno aéreo con retiro en terminal, y distinta a un FCL con inspección previa. Armar cada secuencia a mano en el momento de la aprobación es propenso a errores: el operador olvida un paso, lo repite, cambia el orden. La alternativa sana es definir los estatus por servicio en el catálogo; cuando se aprueba un embarque, FleteChat compone la secuencia uniendo los estatus de los servicios contratados en el orden configurado.

La secuencia queda fija para ese embarque al momento de emisión: cambios posteriores del catálogo no alteran embarques en curso. Esto protege tanto al cliente (que recibe notificaciones en un orden predecible) como al operador (que sabe qué viene después sin depender del catálogo actual).

Criterios de aceptación¶

Composición de la secuencia¶

1. Al aprobar formalmente un embarque (Paso 3; ver historia de aprobación por WhatsApp), FleteChat compone la secuencia de estatus del embarque a partir de los servicios contratados y del catálogo vigente al momento de la emisión.
2. La secuencia resultante se almacena junto con el embarque como una copia inmutable; cambios posteriores del catálogo no alteran embarques ya emitidos.
3. La secuencia siempre incluye el estatus inicial (emisión) y un estatus terminal (entregado o cancelado); los estatus intermedios dependen de los servicios contratados.

Configuración desde el catálogo¶

1. El admin configura los estatus por servicio en el catálogo: para cada servicio, define qué estatus aporta al flujo y su posición relativa.
2. Cuando dos servicios aportan estatus al mismo punto del flujo, el catálogo define cómo se ordenan; si hay ambigüedad, el admin la resuelve explícitamente en el catálogo (no se ordena por criterio implícito).
3. Estatus marcados como opcionales por servicio (por ejemplo, "inspección previa" sólo cuando el servicio fue contratado) no aparecen en la secuencia si el servicio no está en el embarque.

Visibilidad¶

1. La secuencia completa del embarque es visible en la ficha de embarque del backoffice, mostrando el estatus actual, los estatus ya completados (con fecha) y los pendientes.
2. El cliente no ve la secuencia completa por defecto; si la pregunta en WhatsApp, FleteChat responde con los estatus pendientes en texto legible sin exponer nombres técnicos.

Protección ante cambios del catálogo¶

1. Un cambio del catálogo (agregar / quitar / reordenar estatus por servicio) aplica únicamente a embarques nuevos emitidos después del cambio. Los embarques en curso mantienen su secuencia congelada.
2. El admin puede ver la versión del catálogo (fecha y hash conceptual) con la que fue compuesta la secuencia de un embarque; esto facilita auditoría y soporte.

Preguntas del cliente sobre hitos futuros¶

1. Cuando el cliente pregunta por un hito ubicado 2–3 pasos por delante del estatus actual (por ejemplo, "¿cuándo llega a destino?" cuando el embarque aún está en tránsito), FleteChat consulta la secuencia congelada y la fecha estimada del hito:
2. Si existe fecha estimada, FleteChat la entrega etiquetada explícitamente como "estimado" (consistente con US-011 AC 6).
3. Si no existe fecha estimada (el hito está en la secuencia pero el sistema aún no tiene fecha), FleteChat explica que el hito aún no está programado y que avisará proactivamente cuando avance.
4. FleteChat no infiere ni promedia fechas para hitos sin dato registrado.

Edge cases¶

• Embarque con un servicio al que no se le configuraron estatus. La secuencia resultante usa sólo los estatus de los servicios que sí tienen definición; el operador recibe un warning en la ficha del embarque para que el admin complete el catálogo (este warning no bloquea la operación).
• Admin agrega un estatus nuevo al catálogo después de aprobar un embarque. El embarque en curso no recibe el nuevo estatus; embarques nuevos sí lo incluyen.
• Cancelación temprana del embarque. La secuencia termina en cancelado y los estatus pendientes quedan marcados como no aplicables; quedan visibles en el histórico para trazabilidad.
• Dos servicios aportan el mismo nombre de estatus. El catálogo debe resolver la duplicación; si no se resolvió, el admin recibe un error al intentar guardar el catálogo con ambigüedad.

Tamaño, prioridad y tipo¶

• Tamaño: M
• Prioridad: P0 — habilita la actualización manual de estatus (US-025) y la notificación proactiva (US-026) con comportamiento predecible.
• 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-118 — Secuencia inmutable por embarque. Al emitirse un embarque se congela su secuencia de estatus; cambios posteriores del catálogo no alteran embarques ya emitidos.
• PR-119 — Composición declarativa en catálogo. Los estatus por servicio, su orden relativo y su opcionalidad se declaran en el catálogo de FleteChat. FleteChat no infiere secuencias por criterio implícito.
• PR-120 — Trazabilidad del catálogo. Cada embarque registra la versión del catálogo (fecha / identificador conceptual) con la que se compuso su secuencia, para auditoría y soporte.

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-118 a PR-120 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente