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/ZyperWave/ZyperWinOptimize 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 — Slowing — last commit 7mo ago

• Last commit 7mo ago
• ⚠ Slowing — last commit 7mo ago
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ 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 ZyperWave/ZyperWinOptimize repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ZyperWave/ZyperWinOptimize.

What it runs against: a local clone of ZyperWave/ZyperWinOptimize — 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 ZyperWave/ZyperWinOptimize | Confirms the artifact applies here, not a fork | | 2 | Default branch main exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 245 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of ZyperWave/ZyperWinOptimize. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/ZyperWave/ZyperWinOptimize.git
#   cd ZyperWinOptimize
#
# 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 ZyperWave/ZyperWinOptimize and re-run."
  exit 2
fi

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

# 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 "ZyperWin++/ZyperWin++/Program.cs" \\
  && ok "ZyperWin++/ZyperWin++/Program.cs" \\
  || miss "missing critical file: ZyperWin++/ZyperWin++/Program.cs"
test -f "ZyperWin++/ZyperWin++/MainWindow.cs" \\
  && ok "ZyperWin++/ZyperWin++/MainWindow.cs" \\
  || miss "missing critical file: ZyperWin++/ZyperWin++/MainWindow.cs"
test -f "ZyperWin++/ZyperWin++/Optimize.cs" \\
  && ok "ZyperWin++/ZyperWin++/Optimize.cs" \\
  || miss "missing critical file: ZyperWin++/ZyperWin++/Optimize.cs"
test -f "ZyperWin++/ZyperWin++/ZyperWin++.csproj" \\
  && ok "ZyperWin++/ZyperWin++/ZyperWin++.csproj" \\
  || miss "missing critical file: ZyperWin++/ZyperWin++/ZyperWin++.csproj"
test -f "ZyperWin++/packages/AntdUI.2.1.3/lib/net48/AntdUI.dll" \\
  && ok "ZyperWin++/packages/AntdUI.2.1.3/lib/net48/AntdUI.dll" \\
  || miss "missing critical file: ZyperWin++/packages/AntdUI.2.1.3/lib/net48/AntdUI.dll"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 245 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~215d)"
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/ZyperWave/ZyperWinOptimize"
  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).

ZyperWin++ is a lightweight Windows optimization utility built in C# (.NET 4) for Windows 7–11 that performs system performance tuning, service optimization, junk cleanup, system activation, and Office installation. It uses the AntDUI UI framework to provide a modern interface while maintaining a minimal footprint, with features including batch optimization, Defender disabling, Edge uninstallation, AppX app management, and configuration import/export for reproducible tweaks. Single .NET 4 WinForms application with a monolithic structure: MainWindow.cs serves as the hub, with feature-specific form classes (Optimize.cs, Clean.cs, Defender.cs, Activate.cs, Office.cs, Appx.cs, Edge.cs, Backup.cs, etc.) for each major module. Resources folder holds images, App.config holds settings, and Properties/ contains assembly metadata and auto-generated UI designer code.

Windows system administrators and individual users who want to quickly optimize multiple PCs (e.g., classroom labs, corporate deployments) without bloatware or external runtime dependencies. Contributors are C# developers familiar with WinForms and system-level Windows registry/service manipulation.

The project is actively maintained at version 4.1 with recent UI/UX polish (batch optimization UI, configuration persistence, Defender controls), suggesting ongoing development rather than abandoned status. However, no CI/CD pipeline, automated tests, or public issue tracker are evident from the file structure, so production readiness depends on the maintainer's internal validation.

Single-maintainer risk is high (no visible contributors in the description), and direct system-level operations (registry edits, service disabling, Windows Defender manipulation) carry inherent danger if buggy. The absence of test coverage for critical paths like Clean.cs and Activate.cs is concerning; no recent commit date is visible, making maintenance velocity unclear.

Version 4.1 focuses on UI improvements (batch optimization, item selection checkboxes, module descriptions), reliability (fixed minimize/maximize flicker), and new features (Defender toggle, Edge uninstaller, AppX manager, configuration backup/restore). No open PRs or public issue tracker visible; development appears internal.

Clone and build using Visual Studio 2015+ or MSBuild: git clone https://github.com/ZyperWave/ZyperWinOptimize.git && cd ZyperWin++/ZyperWin++ && msbuild ZyperWin++.csproj /p:Configuration=Release. No NuGet restore needed (appears to use only built-in .NET 4 assemblies). Run the .exe from Release output folder with admin privileges.

Daily commands: Open ZyperWin++.sln in Visual Studio, select Release configuration, and build. Run the compiled .exe with administrator privileges (app.manifest in Properties/ declares admin requirement). Double-click compiled exe or: ZyperWin++/bin/Release/ZyperWin++.exe

• ZyperWin++/ZyperWin++/Program.cs — Application entry point that initializes the WinForms application and main window; all contributors must understand how the app bootstraps.
• ZyperWin++/ZyperWin++/MainWindow.cs — Primary UI container and navigation hub for all optimization features; the core orchestrator of user interactions and tab switching.
• ZyperWin++/ZyperWin++/Optimize.cs — Core optimization logic that handles batch system optimization operations; the heaviest business logic in the application.
• ZyperWin++/ZyperWin++/ZyperWin++.csproj — Build configuration specifying .NET 4.0 target, AntdUI dependency, and output settings; required to understand project structure and dependencies.
• ZyperWin++/packages/AntdUI.2.1.3/lib/net48/AntdUI.dll — Primary UI framework dependency (AntdUI) that provides modern themed controls; foundation for all visual components.
• ZyperWin++/ZyperWin++/Activate.cs — Windows system activation module with potentially sensitive registry/licensing operations; critical security-sensitive component.
• ZyperWin++/ZyperWin++/Clean.cs — Garbage cleanup and file removal logic; handles destructive filesystem operations that require careful review.

Add a New Optimization Module (e.g., new system cleanup feature)

1. Create a new Form class in ZyperWin++/ directory following naming convention: YourFeature.cs (e.g., Browser.cs, Services.cs) (ZyperWin++/ZyperWin++/YourFeature.cs)
2. Implement optimization logic as private methods; expose a public method (e.g., RunOptimization()) that interacts with Windows Registry or filesystem APIs (ZyperWin++/ZyperWin++/YourFeature.cs)
3. Create corresponding designer file YourFeature.Designer.cs with WinForms controls (checkboxes, buttons, progress bars) using AntdUI components (ZyperWin++/ZyperWin++/YourFeature.Designer.cs)
4. Register the new form as a tab in MainWindow.cs by adding it to the tab control in MainWindow_Load() or MainMenu navigation handlers (ZyperWin++/ZyperWin++/MainWindow.cs)
5. Add corresponding .resx file for any localized strings or icons (ZyperWin++/ZyperWin++/YourFeature.resx)

Add a New UI Tab/Page to Main Window

1. Open MainWindow.Designer.cs and locate the TabControl definition; add a new TabPage with appropriate Name and Text properties (ZyperWin++/ZyperWin++/MainWindow.Designer.cs)
2. Create the associated feature Form class (e.g., NewFeature.cs) that will be hosted in the new tab (ZyperWin++/ZyperWin++/NewFeature.cs)
3. In MainWindow.cs constructor or Load event, instantiate the new form and dock it within the TabPage (ZyperWin++/ZyperWin++/MainWindow.cs)
4. Wire up event handlers in MainWindow.cs if the new tab needs to communicate with other modules (e.g., backup/restore integration) (ZyperWin++/ZyperWin++/MainWindow.cs)

Extend Optimization Logic with New System Tweaks

1. Open Optimize.cs and locate the optimization method list; add a new checkbox item and corresponding Registry key path to be modified (ZyperWin++/ZyperWin++/Optimize.cs)
2. Implement Registry read/write operations using Microsoft.Win32.RegistryKey; follow the existing pattern of backup-then-modify for reversibility (ZyperWin++/ZyperWin++/Optimize.cs)
3. Update the UI checkboxes in Optimize.Designer.cs to include the new optimization option (ZyperWin++/ZyperWin++/Optimize.Designer.cs)
4. Ensure new tweaks are captured in Backup.cs export/import config so users can save and restore optimization profiles (ZyperWin++/ZyperWin++/Backup.cs)

Update Application Icons or Branding

1. Replace image files in ZyperWin++/Resources/ directory (zw+.png, logos) with new assets maintaining same filenames (ZyperWin++/ZyperWin++/Resources/zw+.png)
2. Update application icon by replacing zw+.ico in project root (ZyperWin++/ZyperWin++/zw+.ico)
3. Refresh Resources.resx if adding new embedded image assets; regenerate Resources.Designer.cs by saving the .resx file (ZyperWin++/ZyperWin++/Properties/Resources.resx)
4. Update assembly metadata (company, product, version) in AssemblyInfo.cs (ZyperWin++/ZyperWin++/Properties/AssemblyInfo.cs)

• .NET Framework 4.0 (C#) — Provides direct Windows API access for Registry manipulation, service management, and system-level operations without additional runtime dependencies on Win7+
• WinForms (System.Windows.Forms) — Lightweight desktop UI framework requiring minimal overhead; ideal for system utilities where simplicity and performance are prioritized over modern paradigms
• AntdUI 2.1.3 — Ant Design-based

Admin privileges are mandatory (app.manifest requestedExecutionLevel='requireAdministrator'); app will fail silently or crash if not run as admin. Registry modifications are direct and non-transactional—partial failures could leave system in broken state. No rollback mechanism except via Backup.cs import. CleanUp operations delete files immediately without recycle bin. Defender disabling may trigger antivirus alerts on some machines. Office/Activation features require internet connectivity but no explicit error messaging visible in file list.

• Windows Registry Manipulation — Core mechanism for system optimization; all registry tweaks in Optimize.cs depend on safe Registry class usage and understanding hive structure (HKLM, HKCU, etc.).
• Windows Service Control — Optimize.cs disables/modifies Windows services for performance; requires understanding service states (Running, Disabled, Manual) and SC.exe/ServiceController API.
• User Access Control (UAC) Elevation — app.manifest requestedExecutionLevel='requireAdministrator' forces UAC prompt; critical for registry/service operations but breaks automation without privilege.
• WinForms Designer Code Generation — *.Designer.cs files are auto-generated from visual editor; modifying them manually breaks the designer, so contributors must understand the split between designer and hand-written logic.
• Batch File Cleanup with Transactional Guarantees — Clean.cs deletes multiple file types without rollback; understanding safe deletion patterns (verify before delete, log failures, handle permission errors) prevents data loss.
• Microsoft Office Click-to-Run (C2R) Deployment — Office.cs supports both quick install and C2R uninstall; requires knowledge of Office Deployment Tool, ODT XML config, and C2R service architecture.
• AppX Package Management — Appx.cs enumerates and removes UWP/AppX apps; depends on Windows.Management.Deployment API and understanding package vs. user vs. system app scope.

• W4RRI0R/Speedup-Master-v3 — Direct competitor: Windows optimization tool with similar features (registry cleanup, service disabling, junk removal).
• WerWolv/ImHex — Ecosystem: Advanced hex editor for binary analysis, useful for reverse-engineering or debugging Windows file formats manipulated by cleanup operations.
• tinyapps/tiny-apps-collection — Companion: Curated Windows optimization and utility tools; potential integration or feature inspiration source.
• microsoft/terminal — Ecosystem: Modern Windows terminal for scripting and automation; complement for advanced users wanting CLI-based optimization alongside ZyperWin++'s GUI.

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.

Extract shared UI logic from form classes into a reusable UIHelper utility module

The codebase contains 12 form classes (About.cs, Activate.cs, Appx.cs, Backup.cs, Clean.cs, Defender.cs, Edge.cs, Office.cs, Optimize.cs, Others.cs, MainMenu.cs, MainWindow.cs) with likely duplicated UI initialization, event handling, and validation logic. Creating a shared UIHelper or FormBase class would reduce code duplication, improve maintainability, and make it easier for new contributors to add features consistently.

• [ ] Analyze About.Designer.cs, Activate.Designer.cs, and Clean.Designer.cs to identify common UI patterns (button initialization, checkbox handling, progress indicators)
• [ ] Create a new FormBase.cs or UIHelper.cs in the root ZyperWin++ directory with extracted common methods
• [ ] Refactor 2-3 existing form classes (e.g., About.cs, Defender.cs) to inherit from FormBase or use UIHelper
• [ ] Update corresponding .Designer.cs files to use the new shared utility
• [ ] Add XML documentation comments to UIHelper explaining available helper methods for future contributors

Create unit tests for core optimization operations (Optimize.cs, Clean.cs, Defender.cs)

The repo contains critical system modification functionality (service optimization, garbage cleaning, Windows Defender disabling) but has no visible test suite. Adding tests for these modules would prevent regressions, document expected behavior, and give confidence to contributors modifying sensitive system operations. Start with mocking system calls to avoid actual system modifications during testing.

• [ ] Create a new ZyperWin++.Tests project in the solution file (ZyperWin++.sln)
• [ ] Write unit tests for Optimize.cs covering service enable/disable scenarios with mocked registry access
• [ ] Write unit tests for Clean.cs covering temp file detection and safe deletion logic
• [ ] Write unit tests for Defender.cs covering enable/disable state detection
• [ ] Add a GitHub Actions workflow file (.github/workflows/test.yml) to run tests on PR submissions

Add comprehensive feature documentation to README with specific operation details and safety warnings

The README.md is incomplete (cuts off at 'Add导入导出配置') and lacks critical information about what each feature does, which Windows versions it affects, and safety implications. This is especially important for a system optimization tool that modifies services and system settings. New contributors need clear documentation of each module's behavior (Optimize.cs, Defender.cs, Activate.cs, Office.cs) to safely extend functionality.

• [ ] Complete the truncated README.md with a full feature list including: Performance Optimization, Service Optimization, Garbage Cleanup, System Activation, Office Installation, Defender Control, Edge Management, Backup/Restore
• [ ] Add a 'Safety & Reversibility' section documenting which operations are reversible and which create backups (reference Backup.cs)
• [ ] Create a FEATURES.md file with detailed descriptions of each form module (Optimize.cs, Clean.cs, Activate.cs, Office.cs, Defender.cs, etc.) including affected registry keys and services
• [ ] Add a CONTRIBUTING.md section documenting how to safely test new optimization features without harming the development machine
• [ ] Include version compatibility matrix (Win7/Win10/Win11 support by feature) since code explicitly targets Win7-Win11

• Add unit tests for Optimize.cs registry modification functions to prevent accidentally corrupting registry keys; create a test suite that mocks Registry class calls and validates key/value changes.
• Implement logging to a file (e.g., OptimizationLog.txt) for all major operations in Clean.cs, Optimize.cs, and Defender.cs so users can debug failures without GUI-only feedback.
• Refactor system operation code (registry, service, file operations) from individual form button handlers into a separate Utilities/ class library to eliminate duplication and enable reuse across modules like Optimize, Clean, and Edge.

• High · System Activation and Office Installation Functionality — ZyperWin++/ZyperWin++/Activate.cs, ZyperWin++/ZyperWin++/Office.cs. The application includes system activation (Activate.cs) and Office quick installation (Office.cs) features. These functionalities may involve bypassing legitimate licensing mechanisms or distributing unauthorized software, which could violate software licensing agreements and expose users to legal liability. Fix: Remove or redesign system activation and Office installation features to comply with Microsoft licensing terms. If retained, ensure they only facilitate legitimate, licensed activations through authorized channels.
• High · Potential Unsafe System Operations — ZyperWin++/ZyperWin++/Optimize.cs, ZyperWin++/ZyperWin++/Defender.cs, ZyperWin++/ZyperWin++/Clean.cs. The application performs system-level operations including service modifications (Optimize.cs), Windows Defender control (Defender.cs), and garbage cleaning (Clean.cs). These operations could be exploited or cause system instability if user input is not properly validated or if operations are performed without proper privilege escalation warnings. Fix: Implement comprehensive input validation for all system operations. Add explicit user confirmations for critical operations. Ensure proper error handling to prevent system corruption. Request and validate administrator privileges with clear user consent.
• High · Absence of Code Signing and Trust Verification — ZyperWin++/ZyperWin++/Properties/app.manifest, ZyperWin++/ZyperWin++/obj/Release/ZyperWin++.exe. The application manifest (app.manifest) and absence of visible code signing mechanisms indicate the executable may not be digitally signed. This increases the risk of tampering and makes it difficult for users to verify software authenticity. Fix: Implement Authenticode code signing to sign the executable with a trusted certificate. This ensures authenticity and helps protect against tampering. Obtain a code signing certificate from a trusted Certificate Authority.
• Medium · Outdated Dependency - AntdUI 2.1.3 — ZyperWin++/packages/AntdUI.2.1.3/. The application uses AntdUI version 2.1.3, which may contain known vulnerabilities. The package targets multiple .NET versions (net40, net46, net48) without evidence of regular security updates. Fix: Update AntdUI to the latest stable version. Regularly monitor and apply security patches for all dependencies. Consider implementing dependency scanning in your CI/CD pipeline using tools like OWASP Dependency-Check or Snyk.
• Medium · Insufficient Input Validation for Registry/System Operations — ZyperWin++/ZyperWin++/Optimize.cs, ZyperWin++/ZyperWin++/Others.cs. System optimization tools typically interact with Windows Registry and system services. Without visible comprehensive input validation and sanitization mechanisms, there's potential for registry injection or unintended system modifications. Fix: Implement strict input validation for all registry operations. Use parameterized APIs instead of string concatenation. Maintain a whitelist of safe registry paths that can be modified. Implement comprehensive logging of all system modifications.
• Medium · Weak Application Configuration Security — ZyperWin++/ZyperWin++/App.config, ZyperWin++/ZyperWin++/Properties/Settings.settings. The App.config file may contain sensitive configuration data without encryption. Settings.settings file in Properties may also expose configuration details. Fix: Encrypt sensitive configuration data using DPAPI (Data Protection API) or similar mechanisms. Never store credentials or sensitive information in plain text configuration files. Use secure configuration management practices.
• Medium · No Evidence of Security Testing or Vulnerability Disclosure — Repository root, README.md. The repository provides no indication of security testing, vulnerability scanning, or a responsible disclosure policy for security issues. Fix: Implement automated security scanning in CI/CD pipeline (SAST tools). Create a SECURITY.md file with responsible disclosure guidelines. Conduct regular security audits. Use tools like Roslyn analyzers for C# code analysis.
• Low · Build Artifacts in Source Control — undefined. Compiled bin Fix: undefined

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.