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.

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