Rework a product's navigation before it collapses under its own feature count

You are redesigning the primary navigation for a product whose feature count has outgrown the navigation structure it launched with, where new features have been bolted onto the existing nav rather than the nav being rethought.

CURRENT NAVIGATION ITEMS
Dashboard, Projects, Tasks, Reports, Team, Integrations, Billing, Automations, Templates, Settings, Help.

USAGE FREQUENCY PER ITEM (if known)
Tasks and Projects opened daily by nearly all users; Automations and Templates opened by under 15% monthly; Billing opened almost only by admins.

USER ROLES THAT USE THIS PRODUCT
Individual contributors (mostly Tasks/Projects), team admins (Team/Billing/Integrations), and viewers with read-only access (mostly Reports).

NAV PATTERN CONSTRAINTS
Left sidebar nav, currently no support for nested flyout menus, mobile app uses a separate bottom tab bar limited to 5 items.

ITEMS THAT MUST STAY IN PRIMARY NAV REGARDLESS
Billing must stay visible in primary nav per a compliance requirement that payment status be easily reachable.

Decide, for each current nav item, whether it belongs in primary navigation, a secondary/nested location, or a contextual surface (inside a specific workflow rather than global nav at all). Base this on USAGE_FREQUENCY where given — an item used daily by most roles has a different claim on primary nav real estate than one used monthly by a fraction of roles, even if both were added to the nav at the same time historically. Where USER_ROLES differ meaningfully in what they need, decide whether the nav should be role-adaptive (different roles see a different primary set) or a single shared structure — state which you're recommending and why, since a role-adaptive nav has a real cost: it means no two users can be walked through the interface identically, which affects support and training as much as it affects design.

For any item you move out of primary nav, name specifically where it moves to and why a user looking for it would still find it there — never demote an item to a location that's effectively equivalent to deleting it. Respect every entry in MUST_STAY_ITEMS as non-negotiable even if usage data would argue against it; state the tension explicitly rather than silently overriding the constraint or silently complying without noting the conflict with the data.

Group the surviving primary items into a structure with a clear organizing logic (by user goal, by object type, by workflow stage) rather than an unordered flat list — name which logic you used and why it fits this product better than the alternatives.

WHAT NOT TO DO
Do not simply alphabetize or evenly distribute items across a fixed number of top-level slots as if the count were the only constraint — the organizing principle matters more than hitting a specific number of items. Do not recommend adding a search bar as a substitute for actually deciding the structure; search is a fallback for a bad hierarchy, not a fix for one.

OUTPUT FORMAT
1. Table: nav item | current location | recommended location | reason.
2. The organizing logic chosen for the primary nav group, stated in one sentence.
3. If role-adaptive nav is recommended, what differs per role and what stays constant.
4. Any conflict between MUST_STAY_ITEMS and the usage data, named explicitly.