Every team has a version of this story. Someone reports that the invoice PDF renders with the wrong logo. The designer drops the correct asset into Slack. QA records a screen capture and puts it on the shared drive. The client emails over the brand guidelines. Three weeks later the ticket comes back around, and the four files that explain it are in four places — two of which have since expired.
The bug report is in the tracker. The evidence is everywhere else.
Why attachments scatter
Files end up outside the bug for reasons that each make sense in the moment.
The file arrives before the bug does. A designer sends the spec while the issue is still a conversation in a channel. There is no ticket to attach it to yet, so it stays where it landed.
The tool makes it awkward. If attaching means downloading from one app and uploading to another, people paste a link instead. Links into chat threads rot faster than anything else in a workflow.
Chat feels like the fastest path. It is — for the sender. The cost lands on whoever picks the bug up next month.
Nobody ever decided where files go. Without a rule, everyone applies their own, and every one of them is individually reasonable.
What the scattering costs
The obvious cost is time. Someone re-asks for a file that already exists, and waits.
The second cost is worse: a fix gets built against the wrong reference, because the correct one was in a thread nobody found. The code is right and the result is still wrong.
The third cost is silent. A bug that is hard to reconstruct gets postponed rather than fixed, then reopens later with even less context than it had the first time.
What belongs on a bug
Not everything. A task with twenty attachments is about as useful as one with none. The test is whether a file answers a question the next person will actually have.
The reference. The design, the mockup, the paragraph of the spec that says which behaviour is correct. Most disagreements about a bug turn out to be disagreements about intent.
Evidence the automatic capture could not reach. A photo of a phone screen, a video of a hardware interaction, the PDF your app generated.
Data that reproduces it. The CSV that breaks the importer, the config that triggers the crash — sanitised first.
Server-side context. The application log from the same minute as the report, when the browser side alone does not explain what happened.
What does not belong
Secrets. Tokens, credentials, real customer records. An attachment is exactly as visible as the task it sits on, and tasks get shared.
Anything trivially regenerated. A screenshot of a page that anyone can open in five seconds is noise in the list.
Whole archives. A 200 MB folder attached "just in case" is a file nobody will ever open. Extract the part that matters and attach that.
Four habits that keep it working
Attach at the moment of asking. When you ask a colleague for the spec, ask them to put it on the task rather than send it to you. One extra sentence, and the file is where the next person will look.
Name files so the list reads as answers. correct-invoice-logo.svg beats Screenshot 2026-03-04 at 14.22.11.png. Someone should be able to scan the attachment list without opening anything.
Say why the file is there. A line in the description that refers to the attachment turns a pile of files into an argument. "The header should match the second frame in the design file" is worth far more than the design file on its own.
Remove files that stop being true. A superseded mockup left attached will eventually be used by someone. Deleting it is part of finishing the fix.
How this works in BugDump
Reports arrive with their evidence already attached — console logs, network requests, a session replay, a screenshot, the environment the user was in. That covers what happened in the browser. It does not cover what should have happened, and that is the half your own files supply.
Every task has an Attachments section under its description. You can attach files as you create the task, add more later from the task page or the board's side panel, or drag a file from your desktop and drop it anywhere on the task screen.
Files that live inside the description — an image you pasted, a document chip in the text — are listed there too, grouped separately, because those are removed by editing the text they belong to rather than from the list.
There is a smaller benefit that turns out to matter more than we expected. When an AI agent reads a bug through the MCP server, it now sees the task's attachments as well as its reports. An agent that can read the spec you attached argues from the same evidence you would.
The rule underneath all of it
Put the file where the question will be asked.
"What was this supposed to look like?" gets asked on the bug — months after the design was sent, by someone who was not in the original conversation, at the moment they are deciding what to build. That is the only place the answer does any good.