The Problem

Windows accumulates bloatware, background services, telemetry, and registry settings that degrade performance and compromise privacy. Manually hunting these down through Settings, Services, Group Policy, and the registry takes hours and risks breaking things. optimizerDuck centralizes that cleanup into a single, auditable tool with per-optimization risk ratings and revert capability.

What This Does

optimizerDuck is a WPF desktop application (C#/.NET, 166 C# files) that applies and reverts Windows optimizations. The domain model under optimizerDuck/Domain/Optimizations/Categories/ organizes tweaks into BloatwareAndServices, Performance, SecurityAndPrivacy, PowerManagement, Gpu, and UserExperience. Each optimization is a BaseOptimization subclass that can apply, revert, and report its own risk level.

The app also handles customization (registry toggles) and system information, with a full revert system (Domain/Revert/Steps/) that records each change as a RevertStep (registry, service, scheduled task, shell, USB power) so users can undo applied tweaks. It ships with 10 locale resource files and an embedded power plan (optimizerDuck.Resources/optimizerDuck.pow).

How It Is Wired

The import graph for this repo is flat: 7 internal modules, 0 import edges, 0 circular dependencies. The wiring is largely unidirectional from UI to services to domain models.

Execution starts at optimizerDuck/App.xaml.cs (WPF entry point). The user selects optimizations in the UI, which routes through optimizerDuck/Services/Optimization/OptimizationService.cs. That service iterates over selected IOptimization instances, calls their Apply() method, and collects ApplyResult objects. Each optimization executes shell commands, registry writes, service changes, or AppX package removals directly against the OS. Revert flows through Services/Managers/RevertManager.cs, which replays IRevertStep implementations.

The widest blast radius sits in optimizerDuck/Services/Configuration/ConfigManager.cs and optimizerDuck/Services/Optimization/OptimizationRegistry.cs — both have deep nesting (max depth 9) and are the routing hubs for all optimization definitions and configuration state. A change there affects every category and every apply/revert cycle. The system touches the registry, Windows services, scheduled tasks, the filesystem (AppX packages, temp files), and the power plan — all directly, no database or network layer.

How To Use It

Setup: Clone and build:

git clone https://github.com/moses-y/optimizerDuck
cd optimizerDuck
dotnet build optimizerDuck.slnx

Running: Build produces a WPF executable. Run optimizerDuck.exe directly (portable, no install). The .csproj targets .NET with Windows-specific publish profiles (Portable.pubxml, Single.pubxml) for packaging.

Configuration: No environment variables or config files are required. All settings live in the UI; the app writes changes directly to the OS. The README recommends creating a system restore point before applying optimizations.

Real-World Use

A typical workflow: run the app, review the SecurityAndPrivacy category, select "Disable telemetry" and "Block tracking domains," apply, then use the Revert tab to undo any tweak that causes issues. The revert system serializes each step (RevertStepSerializationTests.cs covers this), so a partial rollback is possible without a full restore point.

Code Health & Issues

Static analysis (deterministic, from the pipeline) found 56 findings: 16 high, 40 medium, 0 low, across 5 kinds.

  • High - Deep nesting (x43) — optimizerDuck/Services/Configuration/ConfigManager.cs, OptimizationRegistry.cs, OptimizationService.cs. Max indentation depth 9; control flow is hard to follow. Fix with early returns and guard clauses.
  • High - Duplicated code blocks — .agents/skills/resx-translation/helpers/*.py. 140 repeated 6-line blocks across 47 files. Extract shared helpers.
  • High - Oversized files (x7) — Optimizations/Categories/SecurityAndPrivacy.cs (2819 lines), SystemInfoService.cs, Translations.Designer.cs. Split by responsibility.
  • Medium - Broad exception handling — resx_helpers.py. Bare except swallows errors. Catch specific exceptions.
  • Medium - High branching density (x4) — RegistryToggle.cs, ScheduledTaskCreateDialog.xaml.cs. 43 branch points over 95 lines. Consider strategy dispatch.

Additional SDLC findings:

  • High - CI actions unpinned — .github/workflows uses softprops/action-gh-release@v3. Pin to commit SHAs.
  • High - No test suite — 173 source files, 19 test files exist but cover only a subset of services; integration coverage is thin.
  • Medium - GITHUB_TOKEN permissions — ci.yml declares no permissions. Add least-privilege.
  • Low - No job timeouts — ci.yml and release.yml lack timeout-minutes.

The Bottom Line

Solid, well-structured Windows optimization tool with a genuine revert system — that's the differentiator. The codebase is readable but has real maintainability debt in the largest service files. Good for anyone who wants a free, auditable alternative to closed-source Windows tweakers. The .agents/ skills directory suggests AI-assisted development is part of the workflow, which is worth knowing before contributing.