Every project used to draw task numbers from one counter shared across all of BugDump. Create a project today and its first bug could be #913, which tells you nothing except that other people have been busy.
Numbering now starts at 1 in each project and counts up independently. Your first bug is your first bug.
Every project has a key
Each project also carries a short key, so a task reads as BD-42 rather than #42. The key is derived from the project name when the project is created — Bug Dump becomes BD, Quality Control becomes QC — and you can change it in Project → Settings.
The key shows up everywhere the number does: board cards, the task page, the public portal, notifications, report emails, and the Slack, Telegram and email integrations.
Both forms work in the URL
A task answers to its number and to its key:
/projects/your-project/tasks/42
/projects/your-project/tasks/BD-42BugDump's own links always use the bare number, so the prefixed form is there for the label somebody copied off a card and pasted into a message. Whichever one you open stays in the address bar. The same applies to the board's side panel, ?peek=42 and ?peek=BD-42.
An address that is not this task is refused rather than quietly resolved: another project's prefix, a padded number like BD-007, and a number no task holds all land on a 404.
What this means for existing projects
Tasks that already exist keep the numbers they have. Each project's counter continues from its own highest number, so nothing you have already shared — a link, an email, a webhook payload — changes meaning.
Numbers are never reused. Delete the newest task and the next one still takes the following number, so an old link can never quietly point at a different bug.
Integrations and the API
Webhook and integration payloads keep sending publicId and taskPublicId as plain numbers, and they gain a taskKey field carrying the display form. Nothing you already parse changes shape.
Through the MCP server, get_task still takes the integer behind the label, and list_tasks and get_current_project now report the project key so an agent can render BD-42 back to you.
One thing to know before renaming a key
Renaming a key relabels every task in the project immediately and renumbers nothing. Links that carry the old prefix stop resolving, because a prefix that is not the project's key is treated as a wrong address. Links using the bare number are unaffected, and that is the form BugDump puts in every link, email and payload.