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/IgorMundstein/WinMemoryCleaner 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 5mo ago

• Last commit 5mo ago
• 2 active contributors
• GPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 5mo ago
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 93% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility

_{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 IgorMundstein/WinMemoryCleaner repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/IgorMundstein/WinMemoryCleaner.

What it runs against: a local clone of IgorMundstein/WinMemoryCleaner — 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 IgorMundstein/WinMemoryCleaner | 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 main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 171 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "IgorMundstein/WinMemoryCleaner(\\.git)?\\b" \\
  && ok "origin remote is IgorMundstein/WinMemoryCleaner" \\
  || miss "origin remote is not IgorMundstein/WinMemoryCleaner (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "src/App.xaml.cs" \\
  && ok "src/App.xaml.cs" \\
  || miss "missing critical file: src/App.xaml.cs"
test -f "src/Core/DependencyInjection.cs" \\
  && ok "src/Core/DependencyInjection.cs" \\
  || miss "missing critical file: src/Core/DependencyInjection.cs"
test -f "src/Interfaces/IMemoryService.cs" \\
  && ok "src/Interfaces/IMemoryService.cs" \\
  || miss "missing critical file: src/Interfaces/IMemoryService.cs"
test -f "src/Interop/NativeMethods.cs" \\
  && ok "src/Interop/NativeMethods.cs" \\
  || miss "missing critical file: src/Interop/NativeMethods.cs"
test -f "src/Core/Settings.cs" \\
  && ok "src/Core/Settings.cs" \\
  || miss "missing critical file: src/Core/Settings.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 171 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~141d)"
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/IgorMundstein/WinMemoryCleaner"
  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).

WinMemoryCleaner is a portable C# desktop application that aggressively optimizes Windows RAM by invoking native Windows APIs to reclaim memory from processes that don't properly release allocated heap/cache regions. It runs with administrator privileges and provides both manual memory cleaning and automated optimization triggers (time-based or threshold-based), targeting Windows XP through Windows 11 and Server 2003–2025. Monolithic WPF/WinForms C# desktop application (559KB codebase) living under src/ with a companion documentation website (docs/) using Tailwind CSS. Single executable deliverable; no plugin system or microservices. Likely structured as a single Visual Studio project with UI layer, memory API wrappers (P/Invoke to Windows APIs), settings persistence, and localization resource files.

Windows system administrators, power users, and PC enthusiasts who need to recover RAM from memory leaks or bloated applications without installing heavy RAM cleaning suites; also contributors maintaining a single-purpose, lightweight utility across 20+ language translations and multiple distribution channels (Chocolatey, Scoop, WinGet).

Production-ready and actively maintained. The project has substantial GitHub downloads, automated CI/CD pipelines (13+ GitHub Actions workflows including CodeQL security scanning, Virus Total checks, and multi-platform release workflows), multi-language support (30+ locales), and consistent release cadence evidenced by the CHANGELOG.md and release automation. Stable enough for real-world use but focused and intentionally scoped to a single function.

Low risk from dependencies (pure C# with minimal external NuGet packages expected, leveraging only .NET BCL and Windows APIs), but single-maintainer model (IgorMundstein) creates potential for extended response times on critical bugs. Active CI/CD and security scanning workflows mitigate supply-chain risk. No obvious technical debt signals in file structure; risk is primarily operational/continuity rather than code quality.

Active release and distribution pipeline: Chocolatey, Scoop, and WinGet automation workflows, along with security scanning (Hybrid Analysis, Microsoft Security Intelligence, VirusTotal) and changelog generation on each release. Multi-language community translations are ongoing (evident from translation_request.yml issue template). The project is stable-state maintenance with steady incremental updates rather than feature explosions.

git clone https://github.com/IgorMundstein/WinMemoryCleaner.git
cd WinMemoryCleaner
# Open src/ folder in Visual Studio 2022+ (C# project)
# Build as Release for a portable .exe
# Or run directly from IDE with F5 (requires admin elevation)

Daily commands: Open src/ in Visual Studio 2022+, press F5 to debug (will prompt for admin elevation), or Ctrl+Shift+B to build Release configuration, then execute the resulting .exe. The website (docs/) builds CSS with npm run build:css (requires Node.js + npm).

• src/App.xaml.cs — Application entry point and lifecycle management; every contributor must understand how the app initializes and bootstraps core services.
• src/Core/DependencyInjection.cs — Service registration and DI container setup; essential for understanding how all services are wired together and extended.
• src/Interfaces/IMemoryService.cs — Core abstraction for memory optimization operations; defines the contract that all memory-cleaning implementations must follow.
• src/Interop/NativeMethods.cs — P/Invoke declarations for Windows native API calls; critical for understanding how the app leverages Windows memory management APIs.
• src/Core/Settings.cs — Application configuration and persistence layer; governs how user preferences and application state are stored and retrieved.
• src/Model/Memory/MemoryStats.cs — Data model for memory statistics; foundation for tracking and displaying memory usage information throughout the UI.
• src/Core/Localizer.cs — Localization and language management system; enables multi-language support and internationalization across the application.

• Memory Service (IMemoryService) (P/Invoke, Windows Native APIs, MemoryStats Model) — Orchestrates memory optimization by invoking native Windows APIs to trim working sets, clear standby lists, and gather memory statistics.
  • Failure mode: Fails silently if elevation is insufficient; throws exception if OS API is unavailable on older Windows versions.
• Settings Service (Settings.cs) —

Add a New Memory Optimization Strategy

1. Create a new implementation class in the Services folder that implements IMemoryService interface (src/Interfaces/IMemoryService.cs)
2. Add P/Invoke declarations for required Windows API calls to NativeMethods.cs (src/Interop/NativeMethods.cs)
3. Register the new service in the DependencyInjection container (src/Core/DependencyInjection.cs)
4. Add logging for the optimization in the implementation using Logger service (src/Core/Logger.cs)

Add Support for a New Language

1. Create a new Language model entry with ISO language code (src/Model/Language.cs)
2. Add language strings and translations to Localization model (src/Model/Localization.cs)
3. Register new language in Localizer service initialization (src/Core/Localizer.cs)
4. Update application settings to include new language option (src/Core/Settings.cs)

Add a New Application Setting

1. Define the setting property and default value in Settings class (src/Core/Settings.cs)
2. Update Enums.cs if the setting requires an enumerated type (src/Core/Enums.cs)
3. Create or update a Settings UI View to expose the setting to users (src/App.xaml.cs)
4. Add serialization/deserialization logic using IJsonSerializable interface (src/Interfaces/IJsonSerializable.cs)

• WPF (Windows Presentation Foundation) — Native Windows desktop UI framework providing rich XAML-based UI, MVVM binding support, and deep OS integration.
• P/Invoke & Windows Native APIs — Required for direct access to Windows memory management functions (GlobalMemoryStatusEx, SetProcessWorkingSetSize, etc.) that cannot be accessed through .NET managed APIs.
• Dependency Injection Container — Enables loose coupling between services, simplifies testing, and makes the codebase extensible for new memory optimization strategies.
• .NET / C# — Cross-platform language with strong Windows integration, modern language features, and excellent tooling for desktop applications.

• Portable executable (no installer) over Windows installer package

  • Why: Simplifies deployment and reduces user friction for one-off tools.
  • Consequence: Must handle application data/settings in a portable-friendly way; less integration with Windows Add/Remove Programs.

• Direct P/Invoke calls to Windows native APIs rather than managed wrappers

  • Why: Provides lowest-latency, most direct memory optimization with minimal overhead.
  • Consequence: Requires administrator privileges and tight OS version testing; harder to maintain cross-version compatibility.

• In-memory settings storage with JSON serialization rather than registry

  • Why: Portable and doesn't require elevation for reads; simpler to backup/migrate.
  • Consequence: Settings not integrated with Windows Group Policy; no automatic OS synchronization.

• Does not perform garbage collection on third-party applications; only optimizes memory pages that Windows exposes through native APIs.
• Not a system-wide memory manager; operates on demand rather than as a continuous background service.
• Does not provide Linux or macOS support; Windows-only application targeting XP through Windows 11.
• Does not include advanced profiling or per-process memory analysis; focuses on whole-system memory optimization.

1. Admin elevation required: Application must run with administrator privileges to invoke native memory APIs; debugging in Visual Studio requires elevation or manually launching with 'Run as Administrator'.
2. No .NET Core / cross-platform: This is a Windows-only application using WPF or WinForms; cannot be ported to .NET 8+ without rewriting the UI layer or using MAUI (which also won't help on non-Windows).
3. P/Invoke marshaling: Native Windows API calls require careful attention to struct layouts, string encoding (ANSI vs Unicode), and handle cleanup; mistakes here cause memory leaks or crashes.
4. Code signing workflow: Release builds expect a code-signing certificate (likely stored as a GitHub secret); local builds without signing will fail the release pipeline.
5. Localization resource binding: Adding new UI strings requires updating .resx files for all 30+ languages; CI doesn't auto-generate these, so incomplete translations must be handled manually or via community contribution.

• Working Set (Memory Management) — Core to how WMC optimizes memory: the working set is the subset of a process's virtual address space currently in physical RAM; trimming it forces the OS to drop non-critical pages to disk, freeing RAM for other uses.
• P/Invoke (Platform Invocation Services) — WinMemoryCleaner relies on P/Invoke to call native Windows APIs (e.g., SetProcessWorkingSetSize, EmptyWorkingSet) from C# code; understanding marshaling, struct layouts, and error codes is critical for memory API development.
• Virtual Address Space & Paging — Memory optimization manipulates the OS paging system (moving pages to disk, zeroing cache buffers); developers need to understand page faults, page file usage, and virtual memory limits to avoid performance cliffs.
• Global Hotkeys (Windows Message Loop) — The 'Global Hotkey' feature (default CTRL+SHIFT+M) requires hooking into the Windows message loop and registering with RegisterHotKey API; this is a non-trivial concurrent UI pattern in WPF/WinForms applications.
• Administrator Privilege Elevation (UAC) — The app requires admin elevation to call memory APIs; contributors must understand UAC manifests, privilege levels, and why certain Windows API calls are blocked without elevation.
• Localization & Resource Satellite Assemblies — With 30+ translations, the project uses .NET resource (.resx) files compiled into satellite assemblies; understanding culture-aware loading and fallback chains is essential for maintaining multi-language support.
• Code Signing & Authenticode — The release pipeline code-signs the .exe to avoid Windows Defender SmartScreen warnings; contributors working on builds need to understand Authenticode, certificate management, and timestamping to avoid signing failures.

• andi-nl/quickRAM — Another lightweight Windows RAM optimizer; direct competitor solving the same problem with different approach/UI.
• Xalcon/SteadyTune — Windows system optimization tool (network, CPU, memory); overlaps in memory cleaning but broader scope.
• ntop/ntopng — Network monitoring with system resource tracking; a user of WinMemoryCleaner might also monitor what's consuming freed memory.
• microsoft/WindowsAppSDK — Official Microsoft framework for building Windows desktop applications; relevant for potential UI modernization (WinUI 3) of WinMemoryCleaner away from legacy WinForms.
• dotnet/runtime — .NET runtime that executes WinMemoryCleaner; understanding GC pauses and memory pinning relevant for app performance during aggressive memory clearing.

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 Core utilities (Constants.cs, ExtensionMethods.cs, Enums.cs)

The repo has extensive CI/CD workflows (codeql.yml, ci.yml, verify-and-test-packages.yml) but no visible test project structure in src/. The Core folder contains critical utilities (Constants, ExtensionMethods, Enums) that lack test coverage. Adding a src/Tests project with xUnit/NUnit tests would improve code reliability, catch regressions early, and align with the mature CI/CD pipeline already in place.

• [ ] Create src/Tests/ directory with a new C# test project file
• [ ] Add unit tests for src/Core/Constants.cs covering all constant definitions
• [ ] Add unit tests for src/Core/ExtensionMethods.cs covering each extension method
• [ ] Add unit tests for src/Core/Enums.cs covering enum conversions and validations
• [ ] Update .github/workflows/ci.yml to run dotnet test on the new test project
• [ ] Document testing approach in .github/CONTRIBUTING.md

Add Converter unit tests (src/Converters/ directory)

The Converters folder contains 7 WPF value converters (BrushToHexConverter, EnumToBooleanConverter, InverseBooleanConverter, etc.) that are UI-critical. These have no visible test coverage despite being used in App.xaml bindings. WPF converter bugs are hard to catch in UI testing. Adding dedicated converter tests would prevent binding failures and improve maintainability.

• [ ] Create src/Tests/Converters/ test class directory
• [ ] Add test cases for BrushToHexConverter.cs (test color conversion edge cases)
• [ ] Add test cases for EnumToBooleanConverter.cs and InverseBooleanConverter.cs
• [ ] Add test cases for PercentageToWidthConverter.cs and SumNumericConverter.cs
• [ ] Test null/invalid input handling for all converters
• [ ] Reference tests in workflow ci.yml if not already present

Document Command pattern implementation in CONTRIBUTING.md (src/Command/RelayCommand.cs)

The codebase uses the RelayCommand pattern (MVVM), which is referenced in .github/CONTRIBUTING.md but lacks detailed documentation on how to implement new commands. New contributors touching the UI layer (App.xaml.cs, ViewModels) need clear guidance. Adding a section with before/after examples of creating RelayCommand instances would reduce friction and maintain architectural consistency.

• [ ] Review src/Command/RelayCommand.cs implementation
• [ ] Add 'MVVM & Commands' section to .github/CONTRIBUTING.md
• [ ] Provide code example of implementing a new RelayCommand in a ViewModel
• [ ] Document when to use CanExecute vs. non-parameterized commands
• [ ] Link to ICommand interface documentation and existing command implementations in src/
• [ ] Include testing guidance for commands (async patterns, cancellation)

• Add test coverage for memory API wrappers: No obvious *Tests/ or test/ folder in the repo structure; adding unit tests for P/Invoke memory cleanup functions (safe mocking via dependency injection) would improve confidence in platform-specific behavior and help catch regressions. Start by creating src/Tests/NativeMemoryTests.cs with mock Windows API calls.
• Document memory optimization algorithm in README or wiki: README lists features but doesn't explain how WMC clears memory (which Windows API calls, which memory regions it targets, why it works for 'leaked' memory). A new contributor could add a 'Technical Details' section explaining the memory working set trimming, pagefile operations, or cache clearing approach.
• Add locale validation and linting to CI pipeline: 30+ language .resx files are contributed by community members without automated validation; adding a GitHub Action to check for missing keys, encoding issues, or untranslated strings would reduce manual review burden. See .github/workflows/ci.yml to add a .resx linting step.

WinMemoryCleaner demonstrates good security practices with comprehensive GitHub workflows for security scanning, dependency analysis, and vulnerability checks. The codebase appears well-maintained with established security policies (.github/SECURITY.md). Primary concerns are minor: loose dependency version constraints in the website's package.json, missing lock files for reproducible builds, and the need for verification that configuration/registry files contain no hardcoded secrets. The Windows-focused application requiring admin privileges is appropriately scoped. No evidence of injection vulnerabilities, exposed secrets, or critical misconfigurations was found in the visible structure. Recommend implementing stricter dependency pinning and SBOM generation for enhanced supply chain security.

• Medium · Tailwind CSS Build Dependency Version Constraint — docs/package.json - devDependencies. The package.json uses caret (^) version constraints for tailwindcss and @tailwindcss/cli dependencies (^4.1.17). This allows automatic updates to minor and patch versions, which could introduce breaking changes or vulnerabilities without explicit review. While these are dev dependencies, they could affect the build process and distributed CSS. Fix: Consider using exact versions (e.g., '4.1.17' instead of '^4.1.17') for production security, or implement dependency pinning with lock files (package-lock.json or yarn.lock) in version control to ensure reproducible builds.
• Low · Missing Package Lock File — docs/ directory. No package-lock.json or yarn.lock file is present in the repository structure. This makes dependency versions non-deterministic across installations and CI/CD environments, potentially leading to inconsistent builds and supply chain vulnerabilities. Fix: Generate and commit a package-lock.json file (using 'npm install') or yarn.lock file to ensure consistent, reproducible dependency resolution across all environments.
• Low · Potential Secrets in Script Files — docs/scripts/ and root configuration files. The presence of registry script files (docs/scripts/WMC-RESET-SETTINGS.reg) and configuration files should be reviewed to ensure no hardcoded credentials, API keys, or sensitive paths are stored. While not explicitly confirmed from the structure alone, registry scripts and config files are common locations for accidental secret exposure. Fix: Audit all configuration files, registry scripts, and settings files for hardcoded credentials, API keys, or sensitive information. Implement secret scanning in CI/CD pipelines and use environment variables for sensitive data.
• Low · No Evidence of SBOM or Dependency Scanning — Repository root and .github/workflows/. While GitHub workflows for dependency analysis and vulnerability scanning are present (analyze-dependencies.yml, codeql.yml, virus-total.yml), no SBOM (Software Bill of Materials) file is visible in the repository structure. This could impact transparency and vulnerability tracking. Fix: Generate and maintain an SBOM using tools like CycloneDX or SPDX. Integrate SBOM generation into the release workflow for better transparency and supply chain security.

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.