As work functions multiply, a flat list becomes harder to navigate. Reading the browser’s actual platform classifier and UI integration led me to examine preference preservation beyond simply collapsing a long menu.
Platform and function are different choices
Image, question, attachment and download actions originally shared one list. Selecting a platform before a function separates navigation criteria. The actual grouping function reads registered site information and keeps multi-platform operations among common tools.
It does not duplicate the catalog. Original identifiers, names and enabled states remain intact while presentation groups them. Another registered function follows the same rule. Replacing identifiers for the sake of grouping would have required reconnecting existing preferences unnecessarily.
Persist group and individual pins separately
A group pin leaves a platform button near the address bar, while an individual pin still opens its own function directly. Forcing a choice between them would remove familiar shortcuts. The implementation stores group pins independently in project memory and preserves individual pin ordering.
A toolbar group disappears when it has no enabled children, without meaning that every saved pin was erased. Preference restoration and current availability are different states; one boolean should not have to represent both.
Avoid a second competing enabled switch
A group-wide switch beside individual switches would need another rule explaining which state wins. This design manages enabled status at the function level. Disabled functions leave the run popup but remain recoverable in management. Collapsing a group does not stop its functions.
Search shows function and platform together, and guidance uses the existing detail view. Repeated prefixes are shortened only for display; actual program and accessibility names remain unchanged. Presentation cleanup should not break semantic identification used by automation.
Current-platform priority is not target verification
Showing the current tab’s platform first can reduce search effort, but it does not authenticate an account or establish the run target. The source explicitly treats grouping as presentation without retargeting a program. Existing tab, profile and completion checks remain in execution.
Other platforms stay discoverable for cross-service workflows. Tests check that prioritizing the current platform preserves all items and original settings. A presentation priority must not be described as an access-control or account-verification result.
Read checks at the right UI layer
The historical record includes actual clicks in an owned isolated Electron environment for group selection, search, group and individual pins, enable changes and restart restoration. New hierarchy scenarios were checked without weakening earlier flat-list expectations. They made no external publication or provider-AI call.
The report also retains corrections involving a temporary directory and a nonexistent test-runner command. I read those conditions rather than borrow only the final successful total. This task compared the report with classifier, toolbar and popup source without manipulating the operating interface again.
Preserve choices as navigation grows
The earlier classification story concerns content topics and eligibility filters. This one asks how pins, enabled functions and project preferences survive growth in an executable catalog. It links the earlier judgment without pretending that the implementations are identical or copying another module unnecessarily.
Other administration screens can face the same problem. Separating grouping from run targets, and saved preference from current availability, makes a change explainable. The aim is not merely a shorter menu but keeping existing users’ choices intact after expansion.