Why it matters
Full issue tracker gives ForkMesh a concrete mechanism for signed issue metadata with the fields teams expect. Open and closed states, priorities, assignees, and custom fields, all stored as signed events in the repository and browsable on the web.
Planning loses force when it drifts away from the code history and pull requests it is supposed to guide. In ForkMesh, full issue tracker 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 full issue tracker 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: Open and closed states, priorities, assignees, and custom fields, all stored as signed events in the repository and browsable on the web. State changes stay portable because the planning layer follows the repository instead of one private dashboard.
Where it fits
Use full issue tracker when triage and progress tracking should live beside the repository and remain portable.
It pairs with the rest of Issues & planning because Full issue tracker keeps signed issue metadata with the fields teams expect connected to the repository, its signatures, and the nodes that serve it.