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/xM4ddy/OFGB 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 — Stale — last commit 2y ago

• 3 active contributors
• Unlicense licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 90% of recent commits
• ⚠ 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 xM4ddy/OFGB repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/xM4ddy/OFGB.

What it runs against: a local clone of xM4ddy/OFGB — 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 xM4ddy/OFGB | Confirms the artifact applies here, not a fork | | 2 | License is still Unlicense | 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 ≤ 634 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Unlicense)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Unlicense\"" package.json 2>/dev/null) \\
  && ok "license is Unlicense" \\
  || miss "license drift — was Unlicense 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 "MainWindow.xaml.cs" \\
  && ok "MainWindow.xaml.cs" \\
  || miss "missing critical file: MainWindow.xaml.cs"
test -f "MainWindow.xaml" \\
  && ok "MainWindow.xaml" \\
  || miss "missing critical file: MainWindow.xaml"
test -f "App.xaml.cs" \\
  && ok "App.xaml.cs" \\
  || miss "missing critical file: App.xaml.cs"
test -f "OFGB.csproj" \\
  && ok "OFGB.csproj" \\
  || miss "missing critical file: OFGB.csproj"
test -f "dark.xaml" \\
  && ok "dark.xaml" \\
  || miss "missing critical file: dark.xaml"

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

OFGB is a WPF-based C# GUI utility that disables advertisements injected by Microsoft into Windows 11 (File Explorer, Start Menu, etc.) via the April 2024 KB5036980 update. It works by programmatically modifying Windows Registry keys to flip ad-related feature flags off, providing a user-friendly interface instead of requiring manual registry edits. Monolithic WPF application: MainWindow.xaml.cs contains the core logic (Registry key list and modification methods), App.xaml.cs handles application lifecycle, and dark.xaml provides UI theming. No separation of concerns—business logic lives directly in the UI layer rather than in a dedicated services or models folder.

Windows 11 users frustrated with system-level ads who want a one-click solution without touching the Registry directly; also for power users and system administrators managing Windows 11 deployments who need repeatable ad-removal configuration.

Early-stage but focused: single-language C# codebase (~9.3KB), minimal file structure, no visible test suite or CI/CD pipeline, and appears to be a targeted response to a specific Windows 11 update rather than a long-lived project. Verdict: functional and usable but experimental — solves a real problem well but not battle-hardened for all edge cases.

Single maintainer (xM4ddy), no visible dependency management file shown, and direct Windows Registry manipulation carries inherent risk if keys are written incorrectly. The lack of rollback mechanisms or pre-flight validation of changes before committing them could leave users' systems in inconsistent states. However, the scope is narrow and well-defined (registry keys from a trusted source: Shawn Brink's script), limiting blast radius.

No recent PR or commit data visible in the file listing provided. The project appears stable but dormant—created as a one-off response to the April 2024 Windows update and likely in maintenance mode rather than active development.

git clone https://github.com/xM4ddy/OFGB
cd OFGB
# Open OFGB.sln in Visual Studio 2022 or later
# Build via Ctrl+Shift+B or Build > Build Solution

Requires: Visual Studio (Community, Professional, or Enterprise) and .NET 8.0 SDK installed.

Daily commands:

1. Open OFGB.sln in Visual Studio. 2. Press Ctrl+Shift+B to build. 3. Press Ctrl+F5 to run (or F5 with debugger). The WPF application window launches immediately; no CLI, dev server, or additional setup required.

• MainWindow.xaml.cs — Core logic for registry key modifications and ad-removal operations; contains the 33+ registry keys that define the tool's functionality.
• MainWindow.xaml — UI layout and control definitions for the main application window; defines all user-facing buttons and status displays.
• App.xaml.cs — Application entry point and startup logic; initializes the WPF application and window lifecycle.
• OFGB.csproj — Project configuration and build settings; defines assembly version, target framework, and Windows SDK dependencies.
• dark.xaml — Theme resource dictionary for dark mode styling; applied globally to all UI controls for consistent appearance.

• MainWindow.xaml (UI Layer) (XAML, WPF) — Declares all visual controls: buttons, labels, status displays; binds events to code-behind handlers
  • Failure mode: If XAML is malformed, InitializeComponent throws XamlParseException at runtime
• MainWindow.xaml.cs (Logic Layer) (C#, Microsoft.Win32.Registry) — Implements registry key array, event handlers for ad removal, status updates; orchestrates Registry API calls
  • Failure mode: If registry keys are invalid or user lacks admin privileges, RegistryKey.SetValue throws UnauthorizedAccessException
• dark.xaml (Theme Layer) (XAML) — Defines global brushes, colors, and control styles; applied via App.xaml MergedDictionaries
  • Failure mode: If referenced brushes are undefined, controls fall back to system defaults; no visual theme applied
• Windows Registry (Data Layer) (Windows Registry, HKEY_LOCAL_MACHINE, DWORD values) — Persistent storage for Windows 11 ad-disable settings; modified via DWORD values in specific hives
  • Failure mode: If registry hive is corrupted or locked, SetValue blocks indefinitely or throws IOException

• User Click Event → MainWindow.xaml.cs Click Handler — User presses Remove Ads button; routed event bubbles to code-behind
• Click Handler → RegistryKey Array — Logic layer loads hardcoded array of 33+ registry key paths and values
• RegistryKey Array → Windows Registry Hive — Loop iterates each key, calls Microsoft.Win32.Registry.SetValue to persist DWORD=0 values
• Registry API Call → UAC Elevation Prompt — If user lacks admin rights, first SetValue call triggers OS-level privilege elevation dialog
• Registry Operation Result → Status Label (UI) — Success/failure result copied to MainWindow status label; user sees confirmation or error message

Add a new Windows 11 ad removal target

1. Identify the registry key path and value name from Windows documentation or community forums (MainWindow.xaml.cs)
2. Add a new RegistryKey object to the array around line 33 in MainWindow.xaml.cs with the key path, value name, and description (MainWindow.xaml.cs)
3. The existing foreach loop in MainWindow.xaml.cs will automatically iterate and apply the new registry key when the user clicks the removal button (MainWindow.xaml.cs)

Modify the UI theme or add new buttons

1. Add new Button or Label controls to the Grid layout in MainWindow.xaml with appropriate Grid.Row and Grid.Column attributes (MainWindow.xaml)
2. Define a corresponding Click event handler name in the XAML button element (MainWindow.xaml)
3. Implement the event handler method in MainWindow.xaml.cs with the same name as referenced in XAML (MainWindow.xaml.cs)
4. Update color schemes and styles in dark.xaml if new control types require theming (dark.xaml)

Change application styling or theme

1. Edit color values and brush definitions in dark.xaml for global theme changes (dark.xaml)
2. Add control-specific styles to dark.xaml if custom styling is needed for a particular control type (dark.xaml)
3. Verify the merged ResourceDictionary reference in App.xaml points to dark.xaml (App.xaml)

• C# & .NET Framework — Native Windows desktop development language; direct access to Windows Registry APIs and WPF framework.
• WPF (Windows Presentation Foundation) — Modern declarative UI framework for Windows desktop; XAML-based design with data binding and theming support.
• Windows Registry API — Only mechanism to persist Windows 11 ad-disabling configuration changes; built-in to .NET via Microsoft.Win32.Registry.

• Single monolithic MainWindow instead of MVVM architecture

  • Why: Minimal complexity for a single-purpose utility; rapid development and easy maintenance for non-complex scenarios.
  • Consequence: Code-behind logic tightly couples presentation to business logic; harder to unit test registry modifications; difficult to extend with new features without UI refactoring.

• Hardcoded registry keys in code rather than external config file

  • Why: Eliminates dependency management and config parsing; keys are static and determined by Windows OS version.
  • Consequence: Adding new registry keys requires code recompilation and redistribution; no runtime configuration without rebuilding.

• No async/await for registry operations

  • Why: Registry operations are typically very fast (~10–50ms per key); synchronous calls keep UI logic simple.
  • Consequence: UI may freeze briefly during bulk registry writes if network latency or system load increases; no progress indication during operation.

• Does not provide a way to re-enable ads; removal is one-way
• Does not support non-Windows platforms; Windows 11 registry access only
• Does not include automatic updates; manual download required for new versions
• Does not provide detailed logging of individual registry key modifications
• Does not handle partial failures gracefully; all-or-nothing operation

• Hardcoded Registry Keys in Source Code (Medium) — MainWindow.xaml.cs line 33: All 33+ registry key definitions are embedded as a static array; prevents runtime configuration and requires recompilation to add new targets
• Synchronous Registry Operations on UI Thread (Low) — MainWindow.xaml.cs Click Handler: Registry writes block the UI thread with no async/await; UI becomes unresponsive if registry access is slow or fails
• No Exception Handling for Registry Access (Medium) — MainWindow.xaml.cs: UnauthorizedAccessException, IOException, or other Registry errors not caught; application may crash or display unhelpful error to user
• Monolithic Code-Behind Logic (Low) — MainWindow.xaml.cs: All business logic (registry operations, validation, status updates) mixed with UI event handlers; violates separation of concerns and complicates testing

• MainWindow.xaml.cs Click Handler Loop (CPU/IO Blocking) — Sequential iteration and SetValue calls for each registry key; 33 keys × ~50ms per write = ~1.5s total latency on UI thread
• Windows Registry Hive Lock Contention (External Resource Contention) — If registry hive is heavily accessed by other processes, SetValue calls may stall or timeout; no timeout configurable in code
• UAC Elevation Prompt (undefined) — undefined

No rollback mechanism: Once Registry keys are modified, there is no 'undo' button in the UI—users must manually revert via Registry Editor or re-run the installer to restore defaults. Requires admin elevation: The application must run as Administrator to write to HKEY_LOCAL_MACHINE; this is not enforced in the file structure shown, so it may fail silently. No validation: The code does not appear to validate that Registry keys exist before writing, so typos or OS version mismatches could corrupt the Registry. Single-threaded UI: Registry modifications happen on the UI thread, so large batches of changes may freeze the window.

• Windows Registry — OFGB directly manipulates Registry hives (HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER) to toggle OS-level features; understanding Registry structure, key paths, and value types is essential to understand what the tool does and why it works.
• WPF (Windows Presentation Foundation) — The entire UI is built in WPF using XAML markup and C# code-behind; a junior contributor must understand WPF's data binding, event routing, and resource system to modify the GUI.
• XAML (eXtensible Application Markup Language) — MainWindow.xaml and dark.xaml are declarative XML-based UI definitions; changing layout, buttons, or styling requires editing XAML syntax and understanding how it binds to C# code-behind.
• Registry Key Enumeration and Modification — The core functionality relies on System.Microsoft.Win32.Registry API to read, write, and delete DWORD/String values; knowing the RegistryKey class methods is critical to safely modify Windows settings.
• Resource Dictionary Theming — dark.xaml uses WPF ResourceDictionary to define colors, brushes, and styles globally; understanding how resources merge and override is necessary to maintain or extend the dark theme.
• User Account Control (UAC) and Admin Elevation — Registry writes to HKEY_LOCAL_MACHINE require Administrator privileges; the app needs UAC prompts or manifest configuration to request elevation—this is a hidden requirement not explicitly coded in the visible files.
• Feature Flags (Registry-based) — Windows stores ad-opt-out settings as Registry DWORD values (0 = disabled, 1 = enabled); OFGB flips these flags to suppress ads—understanding feature flag patterns helps predict which Registry keys control which ads.

• Cyrillic/win11-explorer-patcher — Similar Windows 11 modification utility that patches File Explorer; overlaps in audience and Registry manipulation techniques.
• valinet/ExplorerPatcher — Comprehensive Windows 11 customization tool that restores classic UI elements and disables telemetry; addresses the same ecosystem of user frustrations.
• atlas-os/Atlas — Lightweight Windows 11 ISO modification project that strips bloat and ads at the OS level; represents a more aggressive, system-wide alternative approach.
• elevenforum/Shawn-Brink-Scripts — Inspiration source (Shawn Brink's registry scripts) that OFGB wraps in a GUI; understanding the original script clarifies why each Registry key matters.

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 Registry Operations into a Separate Service Class

MainWindow.xaml.cs likely contains hardcoded registry key modifications scattered throughout event handlers. Creating a dedicated RegistryService.cs class would improve testability, maintainability, and allow for error handling/logging of registry operations. This is critical since the tool modifies sensitive Windows Registry entries.

• [ ] Create new file RegistryService.cs to encapsulate all registry read/write operations referenced in MainWindow.xaml.cs:L33
• [ ] Extract the registry key constants and their modification logic into this service with methods like DisableAds(), EnableAds(), and VerifyChanges()
• [ ] Update MainWindow.xaml.cs to use RegistryService instead of direct registry calls
• [ ] Add try-catch blocks in RegistryService for permission errors and invalid operations
• [ ] Add XML documentation comments to all public methods in RegistryService

Add Unit Tests for Registry Key Modifications (RegistryServiceTests.cs)

This tool directly modifies Windows Registry, which is high-risk. There are no test files visible in the repo. Adding unit tests using mock registry operations would catch regressions, validate that correct keys are being targeted, and ensure the tool works as intended before release.

• [ ] Create new Tests folder at root level with RegistryServiceTests.cs
• [ ] Add Moq or similar mocking framework to OFGB.csproj for mocking Windows.Win32.Registry APIs
• [ ] Write tests verifying each registry key modification (File Explorer ads, Start Menu ads, etc.) based on registry constants in MainWindow.xaml.cs:L33
• [ ] Add tests for error cases: insufficient permissions, registry key not found, invalid registry values
• [ ] Add test for VerifyChanges() to confirm all modifications persisted correctly

Create CONTRIBUTING.md with Setup Instructions and Registry Key Documentation

New contributors need to understand what registry keys this tool modifies, why each one matters, and how to safely test changes. Currently only a partial README exists with credits. A CONTRIBUTING.md file would document the development environment, testing procedures, and the specific purpose of each registry key being modified.

• [ ] Create CONTRIBUTING.md at repo root with development setup instructions (Visual Studio version, .NET version required)
• [ ] Document each registry key from MainWindow.xaml.cs:L33 with: its full path, what ads it disables, and the DWORD values used
• [ ] Add a 'Testing Safely' section explaining how to backup registry before testing and verify changes
• [ ] Include instructions for building OFGB.sln and running any test suites
• [ ] Add a section on how to validate changes work across different Windows 11 builds (referencing the April 2024 KB5036980 mentioned in README)

• Add a pre-flight validation check: before modifying Registry, query each key to confirm it exists and is writable; display a warning if not.: MainWindow.xaml.cs: Low—simple Registry.GetValue() calls with error handling.
• Implement a rollback/restore feature: add a button to reset all modified keys back to their default Windows values (store original values in memory before first modification).: MainWindow.xaml.cs and MainWindow.xaml: Medium—requires tracking original state and reversing each write operation.
• Add admin elevation check on startup: detect if the app is running as Administrator and display a prominent warning if not; prevent Registry modifications without it.: App.xaml.cs or a new helper class: Low—use System.Security.Principal.WindowsIdentity to check admin status at application start.

The OFGB application is a Windows registry modification tool with moderate security concerns. Primary risks stem from the requirement to perform elevated privilege registry operations without visible input validation mechanisms and incomplete transparency around security practices. The partial codebase visibility prevents comprehensive analysis. Critical recommendations include: implementing robust registry operation validation, documenting security practices, auditing NuGet dependencies, and conducting thorough static code analysis of the core implementation files. The tool requires user trust due to its system-level modifications, making security transparency essential.

• High · Direct Windows Registry Manipulation — MainWindow.xaml.cs (referenced in README, lines around L33). The application directly modifies Windows Registry keys to disable ads. Registry manipulation requires elevated privileges and can potentially be exploited if the application's registry modification logic is not properly validated. Improper registry key handling could lead to system instability or unintended configuration changes. Fix: Implement input validation and sanitization for all registry operations. Use registry APIs safely with proper error handling. Validate all registry key paths and values before modification. Consider implementing rollback functionality for changes.
• High · Privilege Escalation Requirement — MainWindow.xaml.cs, App.xaml.cs. The application requires administrator/elevated privileges to modify Windows Registry keys. If the elevation process is not properly implemented or if the application runs with unnecessary elevated privileges, it could be exploited for privilege escalation attacks. Fix: Ensure the application only requests elevated privileges when absolutely necessary. Implement proper UAC (User Account Control) prompts. Document why elevation is required and ensure the principle of least privilege is followed.
• Medium · Missing Dependency Information — OFGB.csproj. No package dependency file (packages.config, .csproj dependencies section) was provided for analysis. Without visibility into NuGet dependencies, potential vulnerable third-party libraries cannot be identified. Fix: Regularly audit and update all NuGet package dependencies. Use tools like OWASP Dependency-Check or Snyk to identify vulnerable dependencies. Pin versions and maintain a Software Bill of Materials (SBOM).
• Medium · Incomplete Code Review Surface — MainWindow.xaml.cs, App.xaml.cs. Only partial file structure was provided. The actual implementation in MainWindow.xaml.cs and App.xaml.cs could not be fully analyzed for injection vulnerabilities, unsafe registry operations, or other code-level security issues. Fix: Perform comprehensive static code analysis using tools like Roslyn analyzers, SonarQube, or Fortify. Conduct security code review focusing on registry operations, input handling, and error management.
• Low · No Security Headers or Documentation — README.md. The application lacks documented security considerations, threat model, or security best practices in the README. Users are not informed about the security implications of running this tool. Fix: Add a 'Security Considerations' section to the README explaining: the need for administrator privileges, what registry changes are made, risks of using the tool, and recommendations for safe usage.

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.