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/hellzerg/optimizer 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 4mo ago

• Last commit 4mo ago
• 17 active contributors
• GPL-3.0 licensed
• CI configured
• ⚠ Slowing — last commit 4mo ago
• ⚠ Concentrated ownership — top contributor handles 67% of recent commits
• ⚠ GPL-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 hellzerg/optimizer repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/hellzerg/optimizer.

What it runs against: a local clone of hellzerg/optimizer — 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 hellzerg/optimizer | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 139 days ago | Catches sudden abandonment since generation |

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

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

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

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

# 4. Critical files exist
test -f "Optimizer/Program.cs" \\
  && ok "Optimizer/Program.cs" \\
  || miss "missing critical file: Optimizer/Program.cs"
test -f "Optimizer/Forms/MainForm.cs" \\
  && ok "Optimizer/Forms/MainForm.cs" \\
  || miss "missing critical file: Optimizer/Forms/MainForm.cs"
test -f "Optimizer/OptimizeHelper.cs" \\
  && ok "Optimizer/OptimizeHelper.cs" \\
  || miss "missing critical file: Optimizer/OptimizeHelper.cs"
test -f "Optimizer/CoreHelper.cs" \\
  && ok "Optimizer/CoreHelper.cs" \\
  || miss "missing critical file: Optimizer/CoreHelper.cs"
test -f "Optimizer/Models/Options.cs" \\
  && ok "Optimizer/Models/Options.cs" \\
  || miss "missing critical file: Optimizer/Models/Options.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 139 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~109d)"
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/hellzerg/optimizer"
  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).

Optimizer is a Windows system utility written in C# that disables telemetry, removes bloatware, applies security hardening tweaks, and provides system cleanup tools—designed to maximize privacy and performance on fresh Windows 10/11 installations. It combines registry modification, service disabling, UWP app uninstallation, and network diagnostics (DNS flushing, IP geolocation, latency testing) into a single WinForms GUI application with batch scripting automation support. Single monolithic WinForms desktop application: Optimizer/ root contains App.config entry point, custom UI controls under Controls/ (MoonCheck, MoonList, MoonTabs, etc. for themed UI), Forms hierarchy under Forms/ (AboutForm, FileUnlockForm, FirstRunForm, etc.), and utility helpers (CleanHelper.cs, CoreHelper.cs, FileHandleHelper.cs, ErrorLogger.cs, DebugHelper.cs) for system operations. ByteSize namespace handles binary/decimal unit conversions.

Windows power users and system administrators who need fine-grained control over privacy settings, telemetry, and performance optimization post-installation. Also used by security-conscious individuals and organizations deploying hardened Windows images.

⚠️ Deprecated and no longer maintained—the README explicitly states 'Optimizer is now deprecated and replaced by OptimizerNXT.' The project remains on GitHub as a legacy archive with 745KB of C# code, but active development has ceased in favor of the successor project. Not production-recommended for new deployments.

High risk for new deployments: project is officially deprecated with no active maintenance, likely outdated registry/service knowledge for Windows 11 24H2+, single-maintainer historical pattern, and direct registry/service modifications can brick systems if misconfigured. No visible automated test coverage in file list and CI/CD pipeline presence unclear. Users should migrate to OptimizerNXT instead.

Project is in maintenance-only mode post-deprecation announcement. No active feature development visible. Successor project OptimizerNXT is where new work occurs per the README banner.

Clone the repository: git clone https://github.com/hellzerg/optimizer.git && cd optimizer. Open Optimizer.sln in Visual Studio (C# project, targets .NET Framework). Build via Visual Studio or msbuild Optimizer.sln. No external package manager (NuGet deps not listed); check Optimizer/App.config for any assembly bindings. Run the compiled .exe from bin/ folder.

Daily commands:

1. Open Optimizer.sln in Visual Studio. 2. Build → Build Solution. 3. Debug → Start Debugging (F5) to launch WinForms UI. Command-line execution: Optimizer.exe /disabledefender (admin required for system modifications). See CONFS.md and AUTOMATION.md for all switches.

• Optimizer/Program.cs — Application entry point; initializes the UI framework, splash screen, and main application flow—every contributor must understand how the app bootstraps.
• Optimizer/Forms/MainForm.cs — Primary UI controller that orchestrates all optimization features and user interactions; core navigation hub for the entire application.
• Optimizer/OptimizeHelper.cs — Core optimization logic engine containing the primary Windows system tweaks and cleanup operations; heavily used across all optimization workflows.
• Optimizer/CoreHelper.cs — Utility layer for system registry manipulation, file operations, and core Windows API interactions; foundational for all system-level changes.
• Optimizer/Models/Options.cs — Configuration data model that defines all available optimization options and their state; required to understand feature toggles and settings.
• Optimizer/OptionsHelper.cs — Manages persistence and retrieval of user settings; critical for feature state management and configuration flow.
• Optimizer/Controls/MoonTabs.cs — Custom UI framework component defining tab navigation and styling conventions used throughout the application.

Add a New Optimization Feature Toggle

1. Add a new enumeration value to the feature type in Optimizer/Models/Enums.cs (Optimizer/Models/Enums.cs)
2. Add the option definition to Optimizer/Models/Options.cs with default enabled/disabled state (Optimizer/Models/Options.cs)
3. Implement the optimization logic in Optimizer/OptimizeHelper.cs using the pattern: check if option enabled, execute registry/file changes, log results (Optimizer/OptimizeHelper.cs)
4. Add a ToggleCard UI element in the appropriate tab/section in Optimizer/Forms/MainForm.Designer.cs and bind it in MainForm.cs (Optimizer/Forms/MainForm.cs)
5. Wire the toggle event to call OptimizeHelper with the new option in the optimization workflow (Optimizer/Forms/MainForm.cs)

Add a New Secondary Dialog/Form

1. Create a new form class inheriting from SubForm in Optimizer/Forms/ (e.g., NewFeatureForm.cs) (Optimizer/Forms/SubForm.cs)
2. Design the UI using the Designer (.Designer.cs) and apply Moon-themed custom controls (MoonCheck, MoonToggle, etc.) (Optimizer/Controls/MoonToggle.cs)
3. Implement feature logic and validation in the new form's code-behind (Optimizer/Forms/NewFeatureForm.cs)
4. Add a button or menu item in MainForm.cs that instantiates and shows the new form (Optimizer/Forms/MainForm.cs)

Add Support for a New Windows Service Disable

1. Define the service name constant in Optimizer/Constants.cs or directly in OptimizeHelper (Optimizer/Constants.cs)
2. Add the service disabling logic to Optimizer/OptimizeHelper.cs using CoreHelper registry operations (set service Start value to 4=disabled) (Optimizer/OptimizeHelper.cs)
3. Link the service disable to an existing or new Options toggle in Optimizer/Models/Options.cs (Optimizer/Models/Options.cs)
4. Create a UI control (ToggleCard) in the Services section of MainForm that triggers the optimization on toggle (Optimizer/Forms/MainForm.cs)

Add a New Utility Helper Module

1. Create a new helper class in Optimizer/ (e.g., NewHelper.cs) with static methods for the utility functionality (Optimizer/NewHelper.cs)
2. Use CoreHelper.WriteReg(), CoreHelper.DeleteReg(), File I/O, and Process execution as building blocks for system operations (Optimizer/CoreHelper.cs)
3. Add error handling with try-catch and logging via ErrorLogger.Write() for exceptions (Optimizer/ErrorLogger.cs)
4. Call the helper from MainForm.cs or OptimizeHelper.cs at the appropriate point in the workflow (Optimizer/Forms/MainForm.cs)

• Windows Forms (WinForms) — Native Windows desktop UI framework enabling direct integration with Windows APIs and system resources without external dependencies
• Registry API (via P/Invoke & .NET) — Direct access to Windows registry for system configuration changes, the core mechanism for applying OS-level optimizations
• Custom Moon Theme Controls — Provides consistent, branded UI appearance across the application while maintaining performance on lower-end systems
• .NET Framework / C# — Mature ecosystem with strong Windows system integration libraries, process management, and file I/O capabilities
• Newtonsoft.Json (embedded) — Lightweight JSON serialization for configuration persistence and data exchange

• Windows Forms instead of WPF or modern .NET 6+ frameworks

  • Why: Windows Forms is lightweight, has minimal dependencies, and is fully compatible with Windows 7+; WPF would increase complexity and resource footprint
  • Consequence: Limited modern UI animations and design patterns, but faster startup and lower memory usage

• Direct registry manipulation via P/Invoke instead of WMI or PowerShell abstraction

  • Why: Direct registry operations are faster and more granular for system tweaking; avoids dependency on WMI/PowerShell services
  • Consequence: Higher complexity in error handling and permission management;

1. Elevation Required: Most system modifications demand Administrator privileges; many operations silently fail without elevation. 2. Registry Volatility: Registry paths and service names vary significantly between Windows 10 versions and Windows 11; hardcoded paths in CoreHelper.cs may break on newer builds. 3. Defender Interlock: Disabling Windows Defender requires Safe Mode or /restart=disabledefender automation; running in normal mode will fail silently or require restart. 4. UWP App Removal: Uninstalling UWP apps via C# requires WinRT APIs; ensure test system has consistent AppXManifest locations. 5. No Error Recovery: Batch operations can leave system in half-modified state if one step fails; no transaction/rollback mechanism evident. 6. Deprecated .NET Framework: Target framework is legacy .NET Framework, not .NET 5+; toolchain and Windows API surface may diverge from modern Windows.

• Windows Registry Hive Modification — Optimizer's CoreHelper.cs directly modifies HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER; understanding registry structure, permissions (elevation), and rollback risks is mandatory to avoid bricking user systems
• Windows Service Lifecycle Management — Core feature disables services like DiagTrack, WSearch, OneDrive integration via SC.exe or C# ServiceController; misunderstanding service dependencies can cause boot failures or OS corruption
• Windows Defender/SmartScreen Bypass Mechanics — README documents /disabledefender switch requiring Safe Mode or restart automation; understanding UAC elevation, boot-phase execution, and Defender's kernel hooks is critical to this feature's implementation
• P/Invoke and Native Windows API Calls — FileHandleHelper.cs and system operations rely on unmanaged Win32 API calls (likely CreateToolhelp32Snapshot, Process32First, etc.) to enumerate file handles; errors in P/Invoke signatures cause crashes or undefined behavior
• WinForms Theming and Custom Control Rendering — MoonCheck, MoonToggle, MoonTabs custom controls use OnPaint overrides for dark-mode aesthetic; understanding GDI+ graphics and control composition is needed to maintain visual consistency across new UI elements
• Batch Automation and Template-Based Configuration — AUTOMATION.md describes template-driven silent runs; understanding how config files drive feature toggles and how command-line switches override them is essential for scripting and mass deployment
• UWP App Enumeration and Removal via Windows Runtime — Optimizer uninstalls Universal Windows Platform (Store) apps programmatically; requires WinRT interop and understanding of AppX manifests, which differ from traditional Win32 uninstall mechanisms

• hellzerg/optimizerNXT — Direct successor project where all active development has moved; next-generation privacy/security optimizer for Windows
• W4RH4WK/Debloat-Windows-10 — Similar Windows privacy/bloatware removal approach using PowerShell scripts; shows alternative implementation strategy to Optimizer's C# WinForms GUI
• Builtbybel/O-O-User-Do — Lightweight Windows tweaking utility with comparable feature set (disable services, remove bloat, privacy hardening); active alternative in the same problem space
• 10se1ucgo/DisableWinTracking — Focused telemetry disabler for Windows; narrower scope than Optimizer but shares same core registry/service manipulation approach
• Microsoft/winget-cli — Windows Package Manager; relevant as Optimizer's 'download multiple useful apps' feature could leverage winget instead of custom app downloader

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.

Create unit tests for ByteSize conversion helpers

The ByteSize folder contains BinaryByteSize.cs and DecimalByteSize.cs classes that handle critical size calculations across the UI. These classes lack test coverage and are used throughout CleanHelper.cs and other modules. Adding comprehensive unit tests would catch edge cases (overflow, precision loss) and prevent regressions when refactoring storage calculation logic.

• [ ] Create new project: Optimizer.Tests/ByteSize/
• [ ] Add xUnit test fixtures for BinaryByteSize.cs (test conversions: bytes→KB→MB→GB, boundary values, zero/negative inputs)
• [ ] Add xUnit test fixtures for DecimalByteSize.cs (same coverage as binary variant)
• [ ] Update .github/workflows/build.yml to run tests on every push
• [ ] Add test results badge to README

Add unit tests for helper utility classes (CoreHelper, FileHandleHelper, CleanHelper)

The repo has multiple critical helper classes that orchestrate system operations (FileHandleHelper.cs, CoreHelper.cs, CleanHelper.cs) but no visible test coverage. These directly impact user data and system stability. Unit tests would validate file locking detection, registry operations, and cleanup safety before reaching production.

• [ ] Create Optimizer.Tests/Helpers/ folder with test files
• [ ] Add CoreHelper tests covering Windows version detection and privilege checks
• [ ] Add FileHandleHelper tests mocking file system calls and handle enumeration
• [ ] Add CleanHelper tests validating cleanup logic with isolated file systems
• [ ] Integrate into build.yml workflow with coverage reporting

Document configuration and automation capabilities in CONFS.md and AUTOMATION.md

The repo references CONFS.md and AUTOMATION.md in the file structure but the README is truncated and doesn't describe what configurations users can apply or how to automate Optimizer. Contributors and users need detailed documentation of the tweaks in Constants.cs, registry modifications, and service disabling logic to understand scope and contribute safely.

• [ ] Review Constants.cs and MainForm.Designer.cs to catalog all available configuration options
• [ ] Expand CONFS.md with table: [Setting Name] | [Category] | [Effect] | [Reversible: Y/N]
• [ ] Expand AUTOMATION.md with CLI/batch automation examples and configuration file formats
• [ ] Add code example in AUTOMATION.md showing how to programmatically apply tweaks via OptimizerNXT successor
• [ ] Link these docs from README in 'Key Features' section

• Migrate CoreHelper.cs registry paths to Windows 11 24H2 compatibility: Add detection for Windows 11 build version and conditional registry key paths; current hardcoded paths likely fail on latest Windows 11 builds. Start by researching affected services (e.g., DiagTrack, dmwappushservice locations) in 24H2.
• Add automated test suite for CleanHelper.cs file cleanup operations: Currently no unit tests visible; create NUnit or xUnit tests for temp file deletion, %TEMP% parsing, and browser cache removal logic. Mock file system using Moq to avoid side effects.
• Document all registry keys modified in CONFS.md with Windows version support matrix: Currently CONFS.md lacks a table of which tweaks work on which Windows versions; audit CoreHelper.cs registry calls and create a structured reference table to reduce support burden.

• Critical · Deprecated Project - No Active Maintenance — README.md. The project is explicitly marked as deprecated in the README and replaced by OptimizerNXT. This means the codebase is no longer actively maintained, security patches are unlikely to be applied, and vulnerabilities discovered will not be remediated. Fix: Migrate to OptimizerNXT (https://github.com/hellzerg/optimizerNXT) for continued security support and maintenance. Do not deploy this deprecated version in production environments.
• High · Potential Privilege Escalation via System Modifications — Optimizer/Forms/HostsEditorForm.cs, Optimizer/IntegratorHelper.cs, Optimizer/CoreHelper.cs. The application is designed to modify Windows system settings, disable services, and access system registry. If the application has insufficient input validation or authorization checks, it could be exploited to make unauthorized system changes. The presence of HostsEditorForm, IntegratorHelper, and CoreHelper suggests low-level system access. Fix: Implement comprehensive input validation for all system-modifying operations. Ensure UAC (User Account Control) prompts are properly used. Audit all registry operations and file modifications. Implement logging of all privileged operations.
• High · Incomplete Security Documentation — SECURITY.md. The SECURITY.md file appears truncated and incomplete (cuts off mid-sentence at 'If an update'). This indicates inadequate security documentation and possibly missing guidance on vulnerability reporting procedures. Fix: Complete the SECURITY.md file with: (1) A clear vulnerability disclosure process, (2) Contact information for security reports, (3) Response SLA for security issues, (4) PGP key if applicable, (5) Complete statement on supported versions and patch timelines.
• Medium · Unsafe Assembly Loading - EmbeddedAssembly — Optimizer/EmbeddedAssembly.cs. The presence of EmbeddedAssembly.cs suggests the application loads embedded .NET assemblies at runtime. This pattern is frequently exploited for DLL injection attacks or loading malicious code if assembly validation is insufficient. Fix: Implement strong assembly validation: (1) Verify digital signatures of all loaded assemblies, (2) Use strong naming, (3) Implement hash-based validation of embedded assemblies, (4) Avoid loading user-supplied or untrusted assemblies, (5) Document the assembly loading mechanism.
• Medium · Potential Code Execution via FileHandleHelper — Optimizer/FileHandleHelper.cs. FileHandleHelper.cs suggests file handle manipulation operations. Improper file handle management could lead to TOCTOU (Time-of-Check-Time-of-Use) vulnerabilities or unauthorized file access/modification. Fix: Review all file handle operations for race conditions. Use atomic file operations where possible. Implement proper access control checks before file operations. Validate file paths to prevent directory traversal attacks.
• Medium · Automatic Update Mechanism - Potential Attack Vector — Optimizer/Forms/UpdateForm.cs. The README mentions automatic update checking on each application run. If the update mechanism lacks proper validation (HTTPS enforcement, signature verification, certificate pinning), it could be exploited for Man-in-the-Middle (MITM) attacks to distribute malicious updates. Fix: Ensure all updates are: (1) Downloaded over HTTPS with certificate pinning, (2) Digitally signed and verified before installation, (3) Downloaded from hardened infrastructure, (4) Include rollback capabilities, (5) Log all update operations.
• Medium · Registry and System Configuration Modifications — Optimizer/CoreHelper.cs, Optimizer/CleanHelper.cs, Optimizer/IntegratorHelper.cs. The application modifies Windows registry, disables services, and manipulates system configurations. Insufficient validation in these operations could corrupt system state or introduce security misconfigurations. Fix: Implement: (1) Backup mechanisms before system modifications, (2) Comprehensive validation of all configuration changes, (3) Undo/restore functionality, (4) Detailed logging of all system changes, (5) Pre-flight checks to ensure system stability.
• Low · Missing Dependency Manifest — undefined. No dependency file (packages.config, .csproj with NuGet references, etc.) is visible in the 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.