7. Reservas y servicios

Cubre booking_services (catálogo de servicios reservables) y bookings (las reservas en sí).

Historial de ejecución

Servicios

CP RES-01: Crear servicio con duración y precio

• Resultado esperado: se crea con duration en minutos y queda disponible para reservar.
• Resultado obtenido: Pendiente.

CP RES-02: Crear servicio con duración 0 o negativa

• Resultado esperado a verificar: el campo no tiene validación min en el DTO — confirmar si acepta duration: -30 y qué efecto tiene al calcular el horario de fin de una reserva.
• Resultado obtenido: Pendiente.

Reservas

CP RES-03: Crear reserva para un servicio existente, fecha/hora futura

• Resultado esperado: status inicial "pending"; aparece en el listado de reservas de la tienda.
• Resultado obtenido: Pendiente.

CP RES-04: Crear reserva sin customer_name (campo obligatorio)

• Resultado esperado: error 400 claro.
• Resultado obtenido: Pendiente.

CP RES-05: Crear reserva con fecha en el pasado

• Resultado esperado a verificar: ¿el backend valida que date/time sean futuros? Si no, se podría agendar “ayer” sin ningún aviso — confirmar si el frontend al menos lo advierte.
• Resultado obtenido: Pendiente.

CP RES-06: Dos reservas para el mismo horario exacto (mismo servicio, mismo recurso)

• Objetivo: el sistema no tiene concepto explícito de “cupo” o “recurso único” — confirmar si permite doble-agendar el mismo horario sin ninguna advertencia de choque.
• Resultado esperado a verificar: si se permite sin aviso, es un hallazgo de negocio importante para un negocio que reserva, por ejemplo, una sola cancha o una sola silla de masajes.
• Resultado obtenido: Pendiente.

CP RES-07: Confirmar una reserva (POST /bookings/:id/confirm)

• Resultado esperado: status pasa a "confirmed" y se registra confirmed_at.
• Resultado obtenido: Pendiente.

CP RES-08: Cancelar una reserva ya confirmada

• Resultado esperado: status pasa a "cancelled"; confirmar que no se puede “revivir” por error (ej. volver a confirmar una cancelada).
• Resultado obtenido: Pendiente.

CP RES-09: Completar una reserva (POST /bookings/:id/complete) directamente desde "pending", sin pasar por "confirmed"

• Resultado esperado a verificar: ¿el backend exige una secuencia de estados (pending→confirmed→completed), o permite saltarse pasos? Si lo permite sin validar, confirmar si eso es aceptable para el negocio o debería bloquearse.
• Resultado obtenido: Pendiente.

CP RES-10: Editar el monto de pago (payment_amount) de una reserva ya completada

• Resultado esperado a verificar: ¿se permite modificar el pago después de completada? Si sí, confirmar si queda algún registro de auditoría del cambio (fuera del activity_log genérico de creación).
• Resultado obtenido: Pendiente.

CP RES-11: Error típico de usuario — reservar sin seleccionar servicio (service_id=0)

• Resultado esperado a verificar: el campo service_id no tiene binding:"required" en el DTO (solo service_name lo tiene indirectamente al requerir customer_name) — confirmar si se puede crear una reserva “huérfana” sin servicio real asociado, solo con el nombre de texto libre.
• Resultado obtenido: Pendiente.

Notas de usabilidad y sugerencias

Se completa durante la ejecución.