У каждой команды есть своя версия этой истории. Кто-то сообщает, что PDF со счётом выводится с неправильным логотипом. Дизайнер кидает правильный файл в Slack. QA записывает видео с экрана и кладёт его на общий диск. Клиент присылает по почте брендбук. Через три недели тикет всплывает снова, а четыре файла, которые всё объясняют, лежат в четырёх разных местах, и два из них уже недоступны.
Баг-репорт — в трекере. Доказательства — где угодно, только не там.
Почему вложения расползаются
Файлы оказываются вне бага по причинам, каждая из которых в ту минуту разумна.
Файл появляется раньше бага. Дизайнер присылает спецификацию, пока проблема ещё обсуждается в канале. Тикета, к которому её можно прикрепить, ещё нет, поэтому она остаётся там, куда попала.
Прикреплять неудобно. Если прикрепить файл — значит скачать его из одного приложения и загрузить в другое, люди вставляют ссылку. Ссылки на ветки в чатах протухают быстрее всего остального в рабочем процессе.
Чат кажется самым быстрым путём. Так и есть — для отправителя. Расплачивается тот, кто возьмёт баг в следующем месяце.
Никто не решил, где хранить файлы. Без правила каждый следует своему, и каждое из них по отдельности разумно.
Во что обходится разбросанность
Очевидная цена — время. Кто-то заново просит файл, который уже существует, и ждёт.
Вторая цена хуже: исправление делают по неправильному образцу, потому что правильный лежал в ветке, которую никто не нашёл. Код верный, а результат всё равно неправильный.
Третья цена незаметна. Баг, который трудно восстановить, откладывают, а не исправляют, и потом он открывается снова с ещё меньшим контекстом, чем в первый раз.
Что стоит прикреплять к багу
Не всё. Задача с двадцатью вложениями полезна примерно так же, как задача без них. Проверка простая: отвечает ли файл на вопрос, который возникнет у следующего человека.
Образец. Дизайн, макет, абзац спецификации, где сказано, какое поведение правильное. Большинство споров о баге оказываются спорами о замысле.
Доказательства, до которых не дотянулся автоматический сбор. Фото экрана телефона, видео того, как человек работает с устройством, PDF, который сгенерировало ваше приложение.
Данные, на которых баг воспроизводится. CSV, который ломает импорт, конфиг, который вызывает падение, — предварительно очищенные.
Контекст с сервера. Лог приложения за ту же минуту, что и отчёт, когда одной браузерной стороны мало, чтобы понять, что произошло.
Что прикреплять не нужно
Секреты. Токены, учётные данные, реальные записи клиентов. Вложение видно ровно тем, кому видна задача, а задачами делятся.
То, что легко получить заново. Скриншот страницы, которую любой откроет за пять секунд, — шум в списке.
Архивы целиком. Папку на 200 МБ, прикреплённую «на всякий случай», никто никогда не откроет. Вытащите нужную часть и прикрепите её.
Четыре привычки, на которых всё держится
Прикрепляйте в момент просьбы. Когда просите у коллеги спецификацию, попросите положить её в задачу, а не прислать вам. Одно лишнее предложение — и файл там, где его будет искать следующий человек.
Называйте файлы так, чтобы список читался как ответы. correct-invoice-logo.svg лучше, чем Screenshot 2026-03-04 at 14.22.11.png. Список вложений должен быть понятен с первого взгляда, без открытия файлов.
Объясняйте, зачем здесь файл. Строка в описании со ссылкой на вложение превращает кучу файлов в аргумент. «Шапка должна совпадать со вторым фреймом в макете» стоит намного больше, чем макет сам по себе.
Удаляйте устаревшие файлы. Макет, который заменили новым, но оставили во вложениях, рано или поздно кто-нибудь возьмёт за основу. Удалить его — часть исправления.
Как это устроено в BugDump
Отчёты приходят с уже приложенными доказательствами: логами консоли, сетевыми запросами, воспроизведением сессии, скриншотом, окружением пользователя. Это покрывает то, что произошло в браузере. Но не то, что должно было произойти, — эту половину дают ваши собственные файлы.
У каждой задачи под описанием есть раздел «Вложения». Файлы можно прикрепить при создании задачи, добавить позже со страницы задачи или из боковой панели доски, а можно просто перетащить с рабочего стола в любое место экрана задачи.
Файлы, которые живут внутри описания, — вставленная картинка, плашка документа в тексте, — тоже там перечислены, отдельной группой: их удаляют, редактируя текст, к которому они относятся, а не из списка.
Есть и польза поменьше, которая оказалась важнее, чем я ожидал. Когда ИИ-агент читает баг через MCP-сервер, он теперь видит не только отчёты задачи, но и её вложения. Агент, который может прочитать приложенную вами спецификацию, опирается на те же доказательства, что и вы.
Правило, из которого всё вытекает
Кладите файл туда, где зададут вопрос.
«Как это должно было выглядеть?» спрашивают в баге — через месяцы после того, как прислали макет, и спрашивает человек, которого не было в исходном разговоре, в тот момент, когда он решает, что делать. Только там ответ и приносит пользу.
Читайте также
Как написать хороший баг-репорт (с чек-листом) — чем отчёт, который исправят, отличается от закрытого с пометкой «не воспроизводится», и чек-лист для проверки.
Шаблон баг-репорта, который работает (и как его автоматизировать) — шаблон, который стоит оставить, и почему три четверти его полей может заполнить браузер.
Анатомия баг-репорта: что собирает BugDump и зачем — каждый сигнал, который собирает виджет, и какие из них правда помогают найти баг.