Why it matters
Burnup charts gives ForkMesh a concrete mechanism for scope and completion trends that show whether a release is converging. Built-in burnup charts show scope and completion over time, so you can see a release converging (or not) at a glance.
Planning loses force when it drifts away from the code history and pull requests it is supposed to guide. In ForkMesh, burnup charts addresses that need at the feature level, keeping the behavior close to the repository instead of buried in a detached hosted layer.
How ForkMesh handles it
ForkMesh handles burnup charts through the same split it uses across the product: issues are repository-linked records surfaced in desktop and web views beside branches, pull requests, milestones, and agent sessions.
The behavior is intentionally narrow: Built-in burnup charts show scope and completion over time, so you can see a release converging (or not) at a glance. State changes stay portable because the planning layer follows the repository instead of one private dashboard.
Where it fits
Use burnup charts when triage and progress tracking should live beside the repository and remain portable.
It pairs with the rest of Issues & planning because Burnup charts keeps scope and completion trends that show whether a release is converging connected to the repository, its signatures, and the nodes that serve it.