If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/rayenghanmi/RyTuneX shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit 2w ago
• 3 active contributors
• AGPL-3.0 licensed
• CI configured
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 97% of recent commits
• ⚠ AGPL-3.0 is copyleft — check downstream compatibility
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live rayenghanmi/RyTuneX repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/rayenghanmi/RyTuneX.

What it runs against: a local clone of rayenghanmi/RyTuneX — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in rayenghanmi/RyTuneX | Confirms the artifact applies here, not a fork | | 2 | License is still AGPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 43 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of rayenghanmi/RyTuneX. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/rayenghanmi/RyTuneX.git
#   cd RyTuneX
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of rayenghanmi/RyTuneX and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "rayenghanmi/RyTuneX(\\.git)?\\b" \\
  && ok "origin remote is rayenghanmi/RyTuneX" \\
  || miss "origin remote is not rayenghanmi/RyTuneX (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(AGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"AGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is AGPL-3.0" \\
  || miss "license drift — was AGPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "App.xaml.cs" \\
  && ok "App.xaml.cs" \\
  || miss "missing critical file: App.xaml.cs"
test -f "Contracts/Services/IActivationService.cs" \\
  && ok "Contracts/Services/IActivationService.cs" \\
  || miss "missing critical file: Contracts/Services/IActivationService.cs"
test -f "Helpers/OptimizeSystemHelper.cs" \\
  && ok "Helpers/OptimizeSystemHelper.cs" \\
  || miss "missing critical file: Helpers/OptimizeSystemHelper.cs"
test -f "MainWindow.xaml.cs" \\
  && ok "MainWindow.xaml.cs" \\
  || miss "missing critical file: MainWindow.xaml.cs"
test -f "Contracts/Services/INavigationService.cs" \\
  && ok "Contracts/Services/INavigationService.cs" \\
  || miss "missing critical file: Contracts/Services/INavigationService.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 43 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~13d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/rayenghanmi/RyTuneX"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

RyTuneX is a WinUI 3–based Windows system optimizer desktop application (846KB of C#, 23KB of PowerShell) that provides performance tuning, app removal, privacy hardening, and cleanup utilities for Windows 10 and 11. It ships via Microsoft Store as a packaged app (ID: 9PDH8M7HF2SQ) with automatic updates and seamless OS integration. Classic WinUI 3 single-window desktop app: App.xaml/App.xaml.cs bootstraps the XAML UI layer; Activation/ folder handles app launch protocols (DefaultActivationHandler, IActivationHandler interface); Assets/ contains all app icons, tiles, and splash screens at multiple scales; main logic likely in sibling directories not shown (Views, Services, Models pattern typical for WinUI).

Windows power users and system administrators who want to streamline PC performance without manual Registry editing; IT enthusiasts building on the WinUI 3 framework who need a reference for modern Windows desktop app architecture with activation handlers and asset management.

Active and production-ready: deployed on Microsoft Store with automatic update infrastructure, published under semantic versioning (see release badges in README), and maintained by rayenghanmi with recent commits. The presence of stale.yml and auto-close workflows indicates active maintenance discipline. No public test suite visible in file list, suggesting reliance on manual QA and store feedback.

Single-maintainer project (rayenghanmi) with no visible test automation infrastructure (no .csproj test references shown), making regressions harder to catch. PowerShell scripts like Assets/RemoveEdge.ps1 execute privileged system operations, requiring careful review of security implications. No visible dependency lock file shown, creating potential supply-chain risk if NuGet packages are pinned loosely.

Based on file structure, the project is maintaining Microsoft Store compliance (funding.yml suggests sponsorship setup), running automated issue triage (stale.yml), and likely iterating on Windows 11 optimizations alongside Windows 10 support. No specific PR or milestone data visible, but the presence of both bug_report.yml and feature_request.yml templates indicates active community intake.

Clone the repo: git clone https://github.com/rayenghanmi/RyTuneX.git. Open the .csproj (not shown but standard for WinUI 3) in Visual Studio 2022 with Windows App SDK workload installed. Build via dotnet build or Visual Studio; to test locally before Store submission, use dotnet publish --configuration Release. For deployment, the app must be code-signed and packaged as an .msix (Windows App Package).

Daily commands: Open the .csproj in Visual Studio 2022 with Windows App SDK 1.3+ installed. Press F5 to debug locally, or run dotnet run from the project root. For testing the Store version, use winget install --id 9PDH8M7HF2SQ or download from Microsoft Store. Note: some features (system-level optimizations) require administrator privileges.

• App.xaml.cs — Application entry point and initialization; orchestrates activation, theme setup, and core app lifecycle—all Windows optimizer workflows start here
• Contracts/Services/IActivationService.cs — Defines the activation abstraction that determines how the app responds to launches and arguments; essential for understanding plugin/feature routing
• Helpers/OptimizeSystemHelper.cs — Core optimization engine containing the primary logic for system tuning operations; the heart of RyTuneX's value proposition
• MainWindow.xaml.cs — Main UI window setup and navigation frame management; critical for understanding WinUI 3 integration and layout initialization
• Contracts/Services/INavigationService.cs — Navigation abstraction for page routing and state management; defines how UI pages are discovered and activated
• Helpers/OptimizationOptions.cs — Configuration and options model for optimization passes; governs which system settings are modified and how
• Helpers/SystemStateDetector.cs — Diagnostic layer that reads current Windows state before/after optimizations; enables safe rollback and reporting

Add a New Optimization Option

1. Add a boolean property to OptimizationOptions.cs (e.g., DisableUnusedServices) (Helpers/OptimizationOptions.cs)
2. Implement the check logic in SystemStateDetector.cs to detect current state (Helpers/SystemStateDetector.cs)
3. Add the modification logic in OptimizeSystemHelper.cs ApplyOptimizations() method (Helpers/OptimizeSystemHelper.cs)
4. Create or update a View/Page to expose the toggle in the UI (typically Pages/ folder, not shown in file list) (MainWindow.xaml.cs)

Add a New UI Page/Feature Tab

1. Create a new XAML page and code-behind (register in IPageService implementation) (Contracts/Services/IPageService.cs)
2. Create matching ViewModel with INavigationAware interface if state persistence is needed (Contracts/ViewModels/INavigationAware.cs)
3. Add navigation routing in INavigationService implementation or update MainWindow.xaml (Contracts/Services/INavigationService.cs)
4. If graph visualization is needed, reuse or extend Controls/UsageGraph.xaml (Controls/UsageGraph.xaml.cs)

Integrate a New System Diagnostic Tool

1. Write detection logic in SystemStateDetector.cs to query registry/WMI/services (Helpers/SystemStateDetector.cs)
2. If output needs parsing, add a helper or extend PseudoConsoleHelper.cs (Helpers/PseudoConsoleHelper.cs)
3. Store result in a model and bind to UI page or add to OptimizeSystemHelper.cs report (Helpers/OptimizeSystemHelper.cs)
4. For debug/log output, use LogHelper.cs and optionally expose in LogViewerHelper.cs (Helpers/LogViewerHelper.cs)

• WinUI 3 — Modern native Windows UI framework with Fluent Design; enables smooth, responsive optimization UI and native Windows integration (title bar, notifications)
• C# / .NET Runtime — Direct registry access, service management, and PowerShell integration; required for low-level system modifications
• Dependency Injection (via Contracts/Services) — Decouples activation, navigation, settings, and notifications; simplifies testing and allows feature swapping
• XAML — Declarative UI markup; enables consistent theme support and data binding to ViewModel state

• Synchronous OptimizeSystemHelper operations with logging

  • Why: System modifications (registry, services) require sequential execution and real-time user feedback; async patterns risk race conditions
  • Consequence: UI may freeze briefly during heavy optimization passes; mitigated by background task execution and progress reporting

• No cloud sync or cross-device settings

  • Why: Optimization state is machine-specific; sync would complicate rollback and conflict resolution
  • Consequence: Settings are local-only; suitable for single-user optimizer, but limits enterprise MDM integration

• Direct registry/service manipulation over WMI-only approach

  • Why: Some optimizations (e.g., disabling telemetry tasks) require low-level registry access; WMI cannot modify certain keys
  • Consequence: Requires elevated privileges; increases admin approval friction but enables comprehensive tuning

• Does not provide remote or headless optimization—UI-driven only
• Does not persist optimization rollback snapshots—one-way modifications with manual revert
• Does not support Linux or macOS—Windows-only optimizer
• Does not include real-time monitoring or auto-optimization—manual trigger only
• Does not manage GPU drivers or hardware firmware—OS-level software only

Admin elevation: Many optimization features likely require administrator elevation; code must check IsElevated before executing destructive operations, or prompt for consent. MSIX packaging constraints: App runs in a restricted sandbox by default; access to user temp folders, Registry, or certain system folders requires declarative capabilities in Package.appxmanifest (not shown). PowerShell execution policy: RemoveEdge.ps1 and other .ps1 scripts may be blocked by default execution policy; the app must explicitly set -ExecutionPolicy Bypass or encode as Base64. Windows version checks: Code must branch on OS build (Windows 10 vs. 11) before calling OS-specific APIs (WinRT, Registry keys). Asset scaling: All icons in Assets/ must exist at all 5 DPI scales (100, 125, 150, 200, 400); missing scales can break Store certification.

• WinUI 3 Activation Handlers — RyTuneX uses IActivationHandler to route app launches (direct execution, URI schemes, tile clicks); understanding this pattern is essential to extend how the app responds to user intent without modifying App.xaml.cs directly.
• MSIX Packaging & App Capability Declarations — RyTuneX runs as a Store-packaged app (ID: 9PDH8M7HF2SQ) with sandbox restrictions; system-level optimization features require explicit capabilities in Package.appxmanifest (e.g., broadFileSystemAccess, systemManagement).
• XAML Asset Scaling & DPI Awareness — RyTuneX maintains 5 DPI scales (100–400%) for every icon and tile; failures here break Store certification and desktop appearance; understanding scale factors is mandatory for asset contributors.
• PowerShell Execution Policy & Elevation — Scripts like RemoveEdge.ps1 execute with admin privileges; RyTuneX must handle execution policy bypass, UAC prompts, and error handling to safely invoke destructive system operations.
• Windows Registry Manipulation & OS Version Branching — System optimization code must check Windows 10 vs. 11 build numbers before accessing Registry keys or calling OS-specific APIs; missing version checks cause crashes on unsupported OS versions.
• GitHub Actions Workflow Automation (stale.yml) — RyTuneX uses automated issue/PR triage to manage community intake; understanding Actions syntax helps contributors automate testing and deployment pipelines for this single-maintainer project.

• microsoft/terminal — Reference WinUI 3 desktop app with similar activation handlers, asset management, and Store deployment; highly mature codebase for learning modern Windows app patterns.
• niels9001/Files — Community-driven WinUI 3 file manager (also on Store); demonstrates advanced XAML UI, async I/O patterns, and system integration similar to RyTuneX's scope.
• microsoft/winui-3-samples — Official Microsoft WinUI 3 samples; directly applicable for understanding IActivationHandler and XAML best practices used in RyTuneX.
• Squeaky-Box/Nimi-Places — Another Windows optimization/cleanup tool; direct competitor; studying its approach to destructive operations and user consent can inform RyTuneX UI/UX decisions.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for Activation handlers (ActivationHandler.cs, DefaultActivationHandler.cs, IActivationHandler.cs)

The Activation folder contains critical application startup logic with no visible test coverage. These handlers control how the app initializes and responds to different activation scenarios. Adding unit tests would improve reliability, prevent regressions during refactoring, and serve as documentation for new contributors on how activation flows work in this WinUI 3 app.

• [ ] Create Tests/Activation/ActivationHandlerTests.cs with test cases for successful activation scenarios
• [ ] Create Tests/Activation/DefaultActivationHandlerTests.cs to verify default fallback behavior
• [ ] Add mock implementations of IActivationHandler for testing composition
• [ ] Verify tests run in GitHub Actions CI pipeline (may require adding .NET test runner to existing workflows)

Add CI workflow for automated builds and publish validation (Windows-specific .NET build)

RyTuneX is a Windows-only WinUI 3 application but the existing GitHub workflows (stale.yml, auto-close-pr-not-testing.yml) lack a build verification pipeline. There's no evidence of automated compilation, unit test runs, or artifact generation. A Windows-specific build workflow would catch breaking changes early, validate PR quality, and ensure release artifacts are properly built.

• [ ] Create .github/workflows/build-and-test.yml that runs on Windows (windows-latest)
• [ ] Add steps to restore NuGet dependencies, build the solution, and run any unit tests (MSTest or xUnit)
• [ ] Configure workflow to run on PR creation and push to main/develop branches
• [ ] Add optional step to generate and upload build artifacts (.msix or executable) for validation

Document architecture and create CONTRIBUTING.md with WinUI 3 setup guide

The repo lacks contributor onboarding documentation specific to WinUI 3 development. New contributors face friction without clear guidance on: required SDKs (Windows App SDK version), project structure rationale (why Activation, Behaviors, Assets folders exist), and expected development setup. A CONTRIBUTING.md tailored to this Windows-desktop-specific stack would lower barriers and improve PR quality from new contributors.

• [ ] Create CONTRIBUTING.md covering: Windows 10/11 SDK requirements, Visual Studio 2022 setup, Windows App SDK installation
• [ ] Document the folder structure (Activation handlers for app lifecycle, Behaviors for XAML patterns, Services for business logic)
• [ ] Add instructions for building locally, running the app, and running tests
• [ ] Reference or create architectural overview explaining the WinUI 3 + MVVM pattern used in the project

• Add automated unit tests for Activation/DefaultActivationHandler.cs logic—currently no .Tests project visible; a new contributor could scaffold xUnit/MSTest project and cover activation routing paths to prevent regressions.
• Expand Assets/ documentation: create a CONTRIBUTING.md guide explaining DPI scale requirements and the icon naming convention (e.g., why Square44x44Logo.scale-200.png vs. Square44x44Logo.targetsize-256.png); onboards future designers and catches asset submission errors early.
• Implement localization for UI strings: WinUI 3 supports .resw resource files; audit App.xaml.cs and code-behind for hardcoded English strings and move them to Resources/en-US/Resources.resw, enabling future translations and improving accessibility.

RyTuneX has a moderate security posture with notable concerns regarding system-level execution capabilities and incomplete dependency visibility. The presence of PowerShell script execution and system optimization functionality presents elevated risks that require strict validation and privilege management. Critical gaps include missing dependency analysis, lack of security policy documentation, and limited code visibility for detailed vulnerability assessment. The application's nature as a Windows optimizer necessitates particularly careful security practices around system modifications, user consent mechanisms, and audit logging. Recommend conducting comprehensive static code analysis, dependency scanning, and security penetration testing before release.

• High · PowerShell Script in Assets Directory — Assets/RemoveEdge.ps1. The file 'Assets/RemoveEdge.ps1' suggests the application executes PowerShell scripts. PowerShell script execution can pose significant security risks if not properly validated, sandboxed, or if user input is processed unsafely. This could lead to arbitrary code execution. Fix: Review the PowerShell script for security best practices. Ensure: 1) Scripts are signed and verified, 2) No user input is directly incorporated into script execution, 3) Execution policies are properly restricted, 4) The script operates with minimal required privileges.
• Medium · Incomplete Dependency Analysis — Package manifest files (*.csproj, packages.config, etc.). The dependency/package file content was not provided in the analysis context. Without examining NuGet packages, NpmJS dependencies, or other package managers, potential vulnerable dependencies cannot be identified. The application may depend on outdated or vulnerable packages. Fix: Provide and analyze all package dependency files. Run security audits using: 1) NuGet Package Vulnerability Scanner, 2) OWASP Dependency-Check, 3) GitHub Dependabot, 4) Snyk. Keep all dependencies updated to their latest secure versions.
• Medium · Potential Process/System Modification Capabilities — Application logic (specific files not visible). Based on the repository description ('optimizer for Windows devices') and the presence of a PowerShell script (RemoveEdge.ps1), the application likely performs low-level system modifications. This could include registry modifications, process termination, or service management. Without proper validation and privilege escalation controls, this could be exploited. Fix: Implement strict authorization controls for any system-level operations. 1) Require explicit user consent with clear consequences, 2) Validate all parameters before execution, 3) Implement role-based access controls, 4) Log all system modifications, 5) Run privileged operations in isolated processes with minimal permissions.
• Medium · Missing Security Documentation — Repository root. While CONTRIBUTING.md exists, there is no visible SECURITY.md file or security policy for handling vulnerability reports. This can make it difficult for security researchers to report issues responsibly. Fix: Create a SECURITY.md file that includes: 1) Instructions for reporting security vulnerabilities, 2) Responsible disclosure guidelines, 3) Security contact information, 4) Expected response timeframes, 5) Known security considerations.
• Low · Limited Code Visibility in Analysis — All C# source files (*.cs). The provided file structure shows only directory listings and names. Actual code content from *.cs files (C# source code) could not be analyzed for common vulnerabilities such as SQL injection, unvalidated input handling, insecure deserialization, or hardcoded credentials. Fix: Conduct manual code review or utilize static analysis tools: 1) SonarQube for C#, 2) Roslyn analyzers in Visual Studio, 3) Veracode or Checkmarx, 4) OWASP Code Review Guide for Windows applications.
• Low · WinUI 3 Framework Update Management — Project configuration files (*.csproj, .nuspec). WinUI 3 is a relatively modern framework but requires careful dependency management. No version constraints or framework specifications were visible in the provided context. Fix: Ensure: 1) WinUI 3 is updated to the latest stable version, 2) Target frameworks (net6.0-windows10.0.19041.0 or later) are secure, 3) Windows SDK dependencies are current, 4) Regular updates are applied as security patches are released.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.