Cada equipo tiene su versión de esta historia. Alguien reporta que el PDF de la factura sale con el logo equivocado. El diseñador deja el archivo correcto en Slack. QA graba la pantalla y deja la grabación en el disco compartido. El cliente manda por correo la guía de marca. Tres semanas después el ticket vuelve, y los cuatro archivos que lo explican están en cuatro sitios distintos, dos de los cuales ya han caducado.
El reporte de bug está en el tracker. La evidencia está en todas partes menos ahí.
Por qué se dispersan los adjuntos
Los archivos acaban fuera del bug por razones que, en el momento, tienen sentido.
El archivo llega antes que el bug. Un diseñador manda la especificación cuando el problema todavía es una conversación en un canal. Aún no hay ticket al que adjuntarlo, así que se queda donde cayó.
La herramienta lo complica. Si adjuntar significa descargar de una app y subir a otra, la gente pega un enlace. Los enlaces a hilos de chat se rompen antes que cualquier otra cosa en un flujo de trabajo.
El chat parece el camino más rápido. Lo es, para quien envía. El coste recae en quien retome el bug el mes que viene.
Nadie decidió nunca dónde van los archivos. Sin una regla, cada uno aplica la suya, y cada una, por separado, es razonable.
Lo que cuesta la dispersión
El coste obvio es el tiempo. Alguien vuelve a pedir un archivo que ya existe, y espera.
El segundo coste es peor: la corrección se hace sobre la referencia equivocada, porque la correcta estaba en un hilo que nadie encontró. El código está bien y el resultado sigue estando mal.
El tercer coste no hace ruido. Un bug difícil de reconstruir se aplaza en lugar de corregirse, y más tarde se reabre con aún menos contexto que la primera vez.
Qué debe ir en un bug
No todo. Una tarea con veinte adjuntos es casi tan útil como una sin ninguno. El criterio es si un archivo responde a una pregunta que la siguiente persona de verdad se va a hacer.
La referencia. El diseño, el mockup, el párrafo de la especificación que dice qué comportamiento es el correcto. La mayoría de los desacuerdos sobre un bug resultan ser desacuerdos sobre la intención.
Evidencia a la que la captura automática no llega. Una foto de la pantalla de un teléfono, una grabación de una interacción con hardware, el PDF que generó tu app.
Datos que lo reproducen. El CSV que rompe el importador, la configuración que provoca el fallo, anonimizados antes.
Contexto del servidor. El log de la aplicación del mismo minuto que el reporte, cuando el lado del navegador por sí solo no explica qué pasó.
Qué no debe ir
Secretos. Tokens, credenciales, registros reales de clientes. Un adjunto es exactamente tan visible como la tarea en la que está, y las tareas se comparten.
Cualquier cosa que se regenere sin esfuerzo. Una captura de pantalla de una página que cualquiera puede abrir en cinco segundos es ruido en la lista.
Archivos comprimidos enteros. Una carpeta de 200 MB adjuntada «por si acaso» es un archivo que nadie abrirá nunca. Extrae la parte que importa y adjunta eso.
Cuatro hábitos para que funcione
Adjunta en el momento de pedir. Cuando le pidas la especificación a un compañero, pídele que la ponga en la tarea en lugar de enviártela. Una frase más, y el archivo queda donde mirará la siguiente persona.
Nombra los archivos para que la lista se lea como respuestas. correct-invoice-logo.svg es mejor que Screenshot 2026-03-04 at 14.22.11.png. Cualquiera debería poder recorrer la lista de adjuntos sin abrir nada.
Explica por qué está el archivo. Una línea en la descripción que haga referencia al adjunto convierte un montón de archivos en un argumento. «La cabecera debería coincidir con el segundo frame del archivo de diseño» vale mucho más que el archivo de diseño por sí solo.
Quita los archivos que ya no son válidos. Un mockup sustituido que se queda adjunto acabará usándolo alguien. Borrarlo es parte de terminar la corrección.
Cómo funciona en BugDump
Los reportes llegan con su evidencia ya adjunta: logs de consola, solicitudes de red, una repetición de sesión, una captura de pantalla y el entorno en el que estaba el usuario. Eso cubre lo que pasó en el navegador. No cubre lo que debería haber pasado, y esa es la mitad que aportan tus propios archivos.
Cada tarea tiene una sección «Archivos adjuntos» debajo de la descripción. Puedes adjuntar archivos al crear la tarea, añadir más después desde la página de la tarea o desde el panel lateral del tablero, o arrastrar un archivo desde el escritorio y soltarlo en cualquier parte de la pantalla de la tarea.
Los archivos que viven dentro de la descripción (una imagen que pegaste, un chip de documento en el texto) también aparecen ahí, agrupados aparte, porque se eliminan editando el texto al que pertenecen y no desde la lista.
Hay una ventaja menor que resultó importar más de lo que esperaba. Cuando un agente de IA lee un bug a través del servidor MCP, ahora ve los adjuntos de la tarea además de sus reportes. Un agente que puede leer la especificación que adjuntaste razona a partir de la misma evidencia que tú.
La regla de fondo
Pon el archivo donde se hará la pregunta.
«¿Cómo se suponía que debía verse esto?» se pregunta en el bug: meses después de que se enviara el diseño, lo pregunta alguien que no estuvo en la conversación original, justo cuando decide qué construir. Es el único sitio donde la respuesta sirve de algo.
Te puede interesar
Cómo escribir un buen reporte de bug (con checklist) — qué separa un reporte que se corrige de uno que se cierra como «no se puede reproducir»: estructura, contexto y una lista práctica.
Anatomía de un reporte de bug: qué captura BugDump y por qué — cada señal que recoge el widget de BugDump, por qué está ahí y cuáles resuelven bugs de verdad.
Plantilla de reporte de bug que sí funciona (y cómo automatizarla) — una plantilla que vale la pena conservar, y por qué tres cuartas partes de ella las puede rellenar el navegador.