Cabizz · QA → Desarrollo · Roadmap

Lo que falta desarrollar, y en qué orden abordarlo

Consolida todas las brechas detectadas al auditar el código contra los planes de prueba: los 10 casos sin código (🔴), los parciales que necesitan trabajo (🟡) y los bugs de dinero ya documentados en el repo. Cada ítem lleva escenarios afectados, área de código y esfuerzo estimado, y cierra con una secuencia recomendada.

Backend: app-api-v2 · basado en la auditoría de código + qa/DIAGNOSTICO_API_V2.md + docs/escenarios-excepcion-estado.md · 14-jul-2026

S ≤1 semM 1–2 semL 2–4 sem

El patrón es claro: el motor de pedidos está sano, pero el dinero no está blindado y la operación en calle no tiene red de seguridad. La máquina de estados, la asignación atómica de conductores y el tiempo real ya funcionan. Lo que falta se concentra en tres frentes: reembolsos y seguridad de pagos, manejo de fallos del conductor en ruta (timeout, reasignación) y un puñado de detalles de UX baratos pero visibles.

Mi recomendación en una línea: primero el dinero (es riesgo real, no cosmético), en paralelo los quick-wins de front (un dev distinto), después el despacho de calle, y al final la resiliencia. Los cuatro bloques de abajo están en ese orden.

Bloque A

Dinero y seguridad

Reembolsos, confirmación por webhook, idempotencia + 3 bugs de pago.

▸ primero · riesgo real

Bloque C

Quick-wins UX

Calificar, deep-link del push, dashboard, offline. Front, barato.

▸ en paralelo con A

Bloque B

Despacho en calle

Timeout de pickup, reasignación, re-oferta, cron.

▸ después de A

Bloque D

Resiliencia

Cancelación por política, disputas, sesión offline.

▸ al final

⚠ Antes que todo: 3 bugs de dinero ya confirmados en el código (no están en el plan de pruebas, pero preceden a todo)

API-01 · El precio lo pone el cliente, no el servidor. HomeService.php arma el subtotal con el precio que manda el teléfono; el precio real de products nunca se lee. Cualquiera compra por un centavo. Arreglo: resolver el precio por product_id contra la base. Esfuerzo bajo, criticidad máxima.
API-02 · El límite de usos del cupón tiene race condition. Chequeo e incremento son operaciones separadas sin transacción → un cupón de un uso se canjea dos veces. Arreglo: UPDATE … WHERE usage_count < usage_limit atómico.
Stock que no se decrementa. Se valida que haya stock pero quantity nunca baja: la misma unidad se vende infinitas veces. Arreglo: decremento transaccional con FOR UPDATE.

Bloque A · Dinero y seguridad de pagos crítico · hacer primero

Hoy un pedido pagado que se cancela o rechaza deja la plata cobrada. Es el hueco de mayor riesgo — desbloquea de un golpe todo el bloque de cancelaciones.

APagosDesbloquea E1.1, E1.2, E1.3, E1.5, E4.1, E4.4, E7.1

Ítem	Escenarios	Qué falta	Área	Esf.
Reembolsos Stripe	E1.1 · E4.4 · E7.1	No existe `refundPayment()` ni estado `refunded`. Cancelar/rechazar no devuelve dinero.	StripeService + migración BD	M
Confirmar pedido vía webhook	E4.1	El pedido se crea antes de que Stripe confirme. Falta estado `awaiting_payment` y confirmar solo con el webhook.	HomeService + WebhookAction	S
Idempotencia de checkout (servidor)	E4.3	Solo hay bloqueo de doble-click en UI. Falta `Idempotency-Key` + tabla de intentos.	HomeAction + BD	S
Idempotencia de webhooks Stripe	E5.5	El `switch` procesa el evento aunque venga duplicado; falta guard "ya procesado".	WebhookAction	S
Precio server-side + cupón atómico + stock	API-01/02	Ver callout de arriba. Los 3 bugs de dinero confirmados en código.	HomeService · CouponService · Product repo	S

Bloque C · Quick-wins de UX barato · en paralelo con A (dev de front)

Cambios chicos, casi todo front, que cierran varios 🔴/🟡 visibles y mejoran la percepción de calidad sin tocar el backend de pagos.

CUX cliente / conductor / adminCierra flujo 7.3, 11.2, 10.2/10.3 y varios 🟡

Ítem	Escenarios	Qué falta	Área	Esf.
Botón "Calificar" / rating post-entrega	Flujo 11.2 · 10.2 · 10.3	Hoy es `console.log` (stub) o no existe. Falta el flujo real de calificación.	Myorders.vue (3 apps user)	S
Deep-link del push (abrir el pedido)	E2.6 · Flujo 7.3 · 4.1 · 5.2 · 8.2	Los handlers FCM solo loguean. Tocar el push no navega ni abre el modal del pedido.	pushNotifications.js (user + driver)	S
Contador real del Dashboard del conductor	Flujo 11.1 · 10.1	`Dashboard.vue` está hardcodeado a 0; `loadDashboardData` es un TODO vacío.	union-driver-user Dashboard.vue	S
Banner "sin conexión" + GPS degradado	E5.3 · E3.3	Falta indicador explícito offline (`navigator.onLine`) y "ubicación no disponible" vs mapa congelado.	useOrdersRealtime · useDriverTracker	S
Historial / timestamp de entrega en admin	Flujo 11.3 · 10.3 · 10.4	El panel muestra el estado final pero no guarda historial de transiciones ni hora de entrega.	*-admin Orders.vue + BD	M
i18n ES completo en cheers-go-admin	Flujo 2.1	Varias etiquetas (`Status updated`, `Delivery`, `Orders`…) caen a inglés.	cheers-go-admin/i18n/es.js	S

Bloque B · Despacho y fallos en calle alto impacto operativo · después de A

El bloque más débil hoy. Sin esto, un pedido cuyo conductor desaparece queda atascado para siempre. Es lo que evita incidentes reales en operación.

BDespacho y rutaCierra E3.1, E3.2, E3.5, E3.6, E3.7, E2.3, E2.4

Ítem	Escenarios	Qué falta	Área	Esf.
Timeout de pickup + re-oferta	E3.1 · E3.6	Deadline de recogida → alerta al admin o re-oferta automática. No existe ningún job de timeout.	cron + BD + admin	M
Reasignación de conductor	E3.7 · E3.2	El admin libera al conductor y re-despacha; el anterior lo pierde, el cliente es notificado.	API admin + order_offers	M
Re-oferta activa tras rechazo + pool agotado	E2.4 · E2.3	Hoy el rechazo depende de que el cron reencuentre candidatos. Falta re-oferta activa y estado/alerta cuando no hay conductores.	OrderDispatchService	M
Asegurar el cron de despacho en v2	Fases 7–11	La oferta (`order-offered`) la emite `cli/events.php`, no la transición. Debe estar corriendo en producción y consolidado en v2.	app-api-v2/cli/events.php	S
Última ubicación + acción ante dispositivo apagado	E3.5	Se guarda la última posición; falta exponerla en el admin y permitir actuar.	admin + driver_status	S
Reasignación automática por inactividad GPS	E3.1 · E3.2	Reglas configurables que detecten inactividad y reasignen solas. Es la versión avanzada del timeout.	servicio + reglas	L

Bloque D · Resiliencia y largo plazo cuando A–C estén cerrados

Mejoras de robustez y operación que no bloquean el día a día pero cierran los últimos 🟡.

DResilienciaCierra E1.2, E1.4, E6.2, E6.3, E6.5, E7.3

Ítem	Escenarios	Qué falta	Área	Esf.
Cancelación con política por estado	E1.2 · E1.4	Reglas antes/en tránsito + cobro parcial + refund según política de cancelación tardía.	OrderCancellationService	M
Escalamiento de pedido huérfano	E6.2	Alerta al admin cuando un pedido lleva demasiado tiempo En camino al punto (3) sin conductor. Hoy solo hay conteo.	cron + admin	S
Canal de disputa con evidencia	E6.3	Ya hay status 8 y tabla de disputas; falta el canal completo (evidencia, ubicación, flujo cliente↔admin).	BD + user + admin	M
Sesión: device_id/409 + cola offline + retry	E6.5	Refresh de token ya funciona; falta exigir `device_id` (409) y encolar acciones offline reintentando tras el refresh.	Auth + interceptors + stores	M
Cierre de negocio con pedidos activos	E7.3	Política al desactivar un negocio: completar los pedidos en curso o cancelarlos con reembolso.	reglas al desactivar business	S
Dedup por message_id en servidor	E5.5 · E6.6	Identificador único de evento en Pusher/FCM para dedupe robusto de punta a punta.	todos los triggers	S

Recomendación de secuencia

Por qué este orden

El dinero primero, no lo fácil primero. Los bugs de pago (cobrar sin devolver, precio puesto por el cliente) son riesgo económico y de disputa real, no cosmético. Bloque A + los 3 bugs de seguridad van antes que nada. Casi todo es esfuerzo S–M.
Front en paralelo, desde el día uno. El Bloque C no toca el backend de pagos, así que un dev de front puede avanzarlo mientras backend hace el A. Cierra varios 🔴 visibles (calificar, deep-link, dashboard) con esfuerzo mínimo → sube la percepción de calidad rápido.
Despacho de calle después de estabilizar el dinero. El Bloque B es alto impacto operativo pero solo pega cuando ya hay volumen de pedidos reales; no bloquea la validación de Fase 1. Requiere backend enfocado, por eso va después de A.
Resiliencia al final. El Bloque D pule los últimos 🟡 y no frena la operación diaria.

Cómo se conecta con las pruebas

Fase 1 (ya ejecutable): corré los 63 casos de flujo + 33 de excepción que no dependen de esto.
Cerrar Bloque A → habilita re-testear E1.1, E1.2, E1.3, E1.5, E4.1, E4.3, E4.4, E7.1 (el grueso de los 🟡 de pagos).
Cerrar Bloque C → convierte en 🟢 los 🔴 de flujo (7.3, 11.2, 10.2, 10.3) y varios 🟡 de notificaciones.
Cerrar Bloque B → habilita por primera vez E3.1, E3.2, E3.6, E3.7 (hoy no hay nada que probar).