[IMPROVEMENT] UI/UX Architecture layers: Package Bundle Catalogue and Startup Operations Integration

The issue covers two separate design proposals: a Package Bundles library view that recognizes local .ubundle files and groups them under collapsible headers, and adding Operation History and logs as options in the UniGetUI startup page setting. Start by reading how the Package Bundles page and the startup page setting currently work, then ask the maintainers which option to pursue before writing code. Done means an agreed scope and a design that the maintainers have accepted.

Please confirm these before moving forward.

• I have searched for my feature proposal and have not found a work-in-progress/duplicate/resolved/discarded issue.
• This improvement refers to an existing feature. If you want to suggest a new feature, please use this template.
• This improvement is not a bug. If you want to report a bug, please use this template.

Describe the improvement

Summary of the Enhancement

This issue proposes two distinct UI/UX improvements to optimize existing capabilities within UniGetUI, minimizing the need for net-new backend features while improving user navigation and workflow validation.

Suggestion A: Package Bundles could incorporate a Library View

• Current Behavior: The Package Bundles page functions primarily as a launcher for bulk installation or downloading after manual interaction with Sources/Filters/Search.
• Proposed Behavior: Transform the visual layer of this page to act as a proper catalog for existing bundles in the system.
• Local Recognition: The application could automatically recognize and display saved .ubundle files located on the local machine.
• Collapsible UI: Group bundle components under collapsible headers for each individual bundle, rather than displaying the complete list of all bundle elements natively. This allows the page to serve as an organizational library, recognizing that different bundles serve distinct operational purposes. It preserves the functionality of current UI buttons while expanding the utility of this tab beyond "one single backup folder" into transferable architectural templates (e.g., development stacks vs. general backups) for cross-system application.
• Cloud Accessibility: For authenticated users with active sync enabled, introducing a cloud view or a direct hyperlink to the associated GitHub Gist could be particularly benefitial. This capability is currently indicated via text in settings or as an icon overlay in the account page; surfacing it here consolidates bundle management into a tangible interface, maximizing the utility of existing UniGetUI resources currently scattered across separate sections.

Suggestion B: Operation History as Startup Page

• Current Behavior: Under Settings > User interface preferences > UniGetUI startup page, the user can select Discover Packages, Software Updates, Installed Packages, Package Bundles, or Settings. However, operational logs—the actual output of user-defined system configurations—are nested under the "..." secondary menu that ccontains mostly contextual info and external sources.
• Proposed Behavior: Add Operation History, Package Manager logs, and UniGetUI Log as selectable options for the startup page—either individually or consolidated as a unified "Source Control" or "System Outcomes" bundle.
• Rationale: Operational logs are critical tools for validating system behavior, particularly when adjusting administrative rights or advanced configurations. Relegating these to a secondary menu categorized as "Other" obscures critical system feedback. Allowing users to launch directly into an "Updates & Patches" or "Versioning" context provides immediate visibility into system execution outcomes, eliminating the need to reverse-engineer hypothetical scenarios when multiple settings might have been redefined.

Describe how this improvement could help users

How can these suggestions help users

Both suggestions utilize mechanisms and data already present within the application architecture. The objective is strictly architectural hierarchy and user path optimization.

• Suggestion A (Package Bundles as Library View): Consolidates bundle management into a tangible collection interface, integrating descriptive characteristics into inherent operational functionalities. This shift empowers users to transition from viewing bundles as mere "backup folders" to managing them as core structural deployments. It allows users to easily track and deploy specific, purpose-built configurations (e.g., spinning up an IDE stack on one system or a security ecosystem on another) while maintaining strict architectural coherence both locally and in the cloud.
• Suggestion B (Operation History as Startup Page): Establishes a consistent, logical framework for iterative settings calibration. By registering the status of outcomes (Succeeded / Failed / Canceled) as immediately traceable elements upon launch, it connects the yellow-text warnings found in the settings tab to practical, concrete workflow results—shifting user engagement from inference-based troubleshooting (guessing the combined effect of several "dangerous settings") to a clear review of collective policy implications. Technically, although not inherent to this improvement/enhancement suggestion, such foundation can also pave the way to re-frame operational logs to proactively capture "Decision Gateways." Rather than just reviewing binary or historical outcomes, this view could eventually facilitate granular engagement with predefined execution workflows, allowing users to review and authorize "pending approvals" upon launching the app. This creates a highly meaningful authorization point, which can be particularly relevant when tracking specific WinGet updates or engaging with development stages beyond stable releases.

Alternatives Considered

• Regarding Startup Pages: Creating a newly dedicated "System Updates" or "Versioning" tab was considered. However, leveraging the existing Startup Page configuration dropdown is a lower-friction implementation that utilizes valuable data already present in existing views.
• Regarding Settings as a Startup Page: Currently, Settings is an interesting case: it is a current option available despite not showing active user definitions (only navigation categories). Furthermore, the settings architecture as presented tends to dictate a system organized more heavily at the initial setup stage, followed by lower-frequency, targeted adjustments based on the callibrations of those permissions. It is thus functionally superior to view the procedural outcomes (logs) before revisiting potentially correlated settings (often marked with the yellow cautionary text) to decide if indeed a "dangerous setting" will be escalated. Replacing or supplementing the Settings startup option with actual log screens provides higher immediate utility that in general might look more obvious for power users. But It also serves as a clearer gateway for users operating under restrict enterprise policies too, as it lays the groundwork for displaying revisions that assume more global conditions awaiting final command.