La familia de bugs que solo aparece en producción

El catálogo

Y el octavo, que no es tuyo

Hay uno más que no está en la lista porque no lo produce tu código: la máquina del usuario no tiene lo que la tuya tenía.

En Windows, el componente de webview puede no estar instalado si el sistema es antiguo; la configuración del bundle decide qué hacer entonces —descargarlo, empaquetarlo, o dar por hecho—, y esa decisión es del nivel 59. En Linux, la aplicación enlaza contra bibliotecas del sistema, y las versiones de la máquina de destino no son las de la tuya: es el problema entero del nivel 3.4. En macOS es donde menos pasa, porque el sistema es más homogéneo.

El síntoma característico es que la aplicación no llega ni a abrir la ventana, o abre y se cierra sola. Cuando eso ocurre en una máquina y no en otra, la sospecha no es el código: es el entorno.

El orden de diagnóstico

Descartar en este orden es lo que más rápido llega a la causa:

El paso 2 es el que la gente se salta, y es el que resuelve cuatro de los siete. La intuición engaña: una ventana en blanco parece un problema del core, y casi siempre es un mensaje esperando en una consola que nadie ha abierto.

Cuáles se pueden cazar automáticamente

No todos, y conviene saber cuáles para no confiar de más:

La conclusión práctica: con tres pasos automáticos —el grep de rutas, las comprobaciones de desbordamiento activas, y una prueba de humo sobre la versión compilada— se cazan cinco de los ocho. Los otros tres exigen ejecutar la aplicación de verdad en una máquina que no sea la tuya, que es lo que la fase XV monta en serio.