The other half of the unified Bugs & Features surface: a filterable queue defaulting to Proposed — the live request queue — plus an analytics mode showing today, this week, this month, total shipped, and shipping by module. Shipping a feature emails both the owner and the person who requested it.
Also called: feature request · roadmap · did they build what I asked for · shipped features · shelved
- 1A request lands as proposed with its code and description.
- 2Status moves through building to shipped, or to shelved with a mandatory reason.
- 3Each feature exports as Markdown with a build protocol: build it, then run the ship command with a summary, why, test steps and a link to the surface it lives on.
- 4Shipping stamps the date that drives the delivery calendar, emails the owner a short note, and emails the requester a 'your feature is live' explanation with an Open it in the app button.
- 5A shipped write-up can be corrected afterwards, including the owner's feedback on how it was built.
- 6The protocol also states that a defect found while building must be filed and resolved in the same session.
The API states why shelving is the recorded decision that matters: 'Shelving REQUIRES a reason, the same way rejecting a bug does; "we decided not to build this" is the record most likely to be re-litigated later, and the reason is the whole value of it.' The default filter has its own feature code —: 'proposed is the active request queue — the thing you open this tab to work.'
- Requests disappeared into conversation.
- Shipped work never reached the person who asked for it.
- Declined requests had no stated reason and got asked again.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →