Informes anónimos de errores: lo que vemos de tus fallos, nunca de tus proyectos

Una aplicación que comunica sus fallos aprende inevitablemente algo sobre ti. Detallamos los seis datos que envía Maestro cuando una pantalla falla, los que nunca salen de tu Mac y las dos veces en que esas líneas nos sirvieron.

Un informe anónimo de errores transmite categorías de fallo, nunca el contenido de tus proyectos. El de Maestro envía el número de versión, la pantalla que falló y el tipo de error, según nuestras propias notas de operación de agosto de 2026. Está activado por defecto y se desactiva con una casilla en los ajustes.

Lo que sale cuando algo falla

Dos familias de líneas y nada más. Al abrir la aplicación: un identificador de instalación generado al azar la primera vez, el número de versión, la fecha y la hora. Cuando una pantalla se niega a aparecer: el nombre de esa pantalla y el tipo de error encontrado. El identificador no lleva tu nombre ni tu dirección; sirve para distinguir tres fallos de un mismo equipo de tres fallos de tres equipos. Esas líneas llegan a una base de datos en línea que gestionamos y nada de tu trabajo toma ese camino.

Lo que nunca sale

El trabajo permanece contigo: el brief que validaste, el documento de requisitos, el código escrito por los agentes, los documentos que adjuntaste y el historial de tus conversaciones con el equipo. Tus claves de acceso a los asistentes viven en el Llavero de macOS y no salen de él. Tampoco recibimos el nombre de tus proyectos, una captura de pantalla ni el texto de ninguno de tus mensajes. Sabemos que una pantalla falló, no lo que mostraba. El detalle figura en nuestra página de datos.

El probador bloqueado que vimos sin ver su pantalla

En agosto, nuestro primer probador de la beta nunca llegó a la segunda pantalla: la aplicación no encontraba el asistente de IA que usaba a diario. El informe nos dio tres hechos y nada más: utilizaba la primera versión publicada, había abierto la aplicación tres veces en menos de una hora y se detenía siempre en el mismo lugar. La causa salió de una mañana de razonamiento, no de una línea de la base: la aplicación buscaba el asistente donde mira Finder, mientras se había instalado en otro sitio. Un informe anónimo sitúa el fallo, no lo diagnostica.

El día en que esas líneas nos hicieron volver atrás

A finales de agosto, una versión publicada por la mañana rompió la apertura de todos los proyectos: un mensaje de disculpa en lugar del taller. Las primeras líneas recibidas nombraron la pantalla culpable y el tipo de error en unos minutos. Volvimos a servir la versión anterior en menos de un minuto, corregimos y publicamos el arreglo esa mañana. Sin esas líneas habríamos esperado a que un probador escribiera y después le habríamos pedido repetir la operación para reproducirla, lo que cuesta un día a alguien que solo quería trabajar.

Por qué viene activado

Un fallo que no le ocurre a nadie no existe para nosotros. Una beta por invitación tiene pocos probadores y parte de quienes tropiezan con un defecto nunca escribe: cierran la aplicación y pasan a otra cosa. El argumento contrario se sostiene y varias herramientas que respetamos piden el acuerdo antes del primer envío; es la opción más limpia para el usuario y no la consideramos absurda. Elegimos el envío por defecto con un contenido reducido a lo que no puede identificarte ni a ti ni a tu trabajo. El mismo razonamiento nos llevó a publicar la autopsia de la clave que era visible en el código: un defecto oculto no se repara.

Desactivar el envío o escribir

Abre los ajustes: se desmarca el informe anónimo y el envío se detiene. La lista exacta de campos transmitidos figura en nuestra página de datos, para decidir con ella delante. Y si un defecto te cuesta una tarde, escríbenos en lugar de esperar a que hable el informe: una categoría dice que una pantalla falló para alguien; tu mensaje dice qué estabas haciendo, lo que vale diez líneas de base de datos.