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/builtbybel/Bloatynosy 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 1y ago

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

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

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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/Bloatynosy/Program.cs" \\
  && ok "src/Bloatynosy/Program.cs" \\
  || miss "missing critical file: src/Bloatynosy/Program.cs"
test -f "src/Bloatynosy/MainForm.cs" \\
  && ok "src/Bloatynosy/MainForm.cs" \\
  || miss "missing critical file: src/Bloatynosy/MainForm.cs"
test -f "src/Bloatynosy/Experience/FeatureBase.cs" \\
  && ok "src/Bloatynosy/Experience/FeatureBase.cs" \\
  || miss "missing critical file: src/Bloatynosy/Experience/FeatureBase.cs"
test -f "src/Bloatynosy/JsonPluginHandler.cs" \\
  && ok "src/Bloatynosy/JsonPluginHandler.cs" \\
  || miss "missing critical file: src/Bloatynosy/JsonPluginHandler.cs"
test -f "src/Bloatynosy/PSPluginHandler.cs" \\
  && ok "src/Bloatynosy/PSPluginHandler.cs" \\
  || miss "missing critical file: src/Bloatynosy/PSPluginHandler.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 510 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~480d)"
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/builtbybel/Bloatynosy"
  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).

Bloatynosy Nue is a native Windows 11 debloating utility written in C# that removes pre-installed bloatware, disables telemetry features, and strips advertising/tracking from Windows installations. It provides a desktop GUI application (.exe) that targets Windows 11 primarily (with Windows 10 support) and executes both JSON-based configuration tasks and PowerShell scripts (found in /plugins/) to remove Copilot, Recall, OneDrive, Outlook, and disable Start menu ads, file explorer ads, and personalized tracking. The project is a monolithic C# WinForms desktop application structured as /src/Bloatynosy/ containing the main UI (App.config, BloatynosyNue.csproj) with feature modules organized under /Experience/ (AI/, Ads/, Gaming/) inheriting from FeatureBase.cs. Plugin system in /plugins/ uses JSON manifests and PowerShell scripts for system tweaks; /languages/ contains .NET satellite assemblies for localization (de, it, ko); core logic likely in FeaturePanel.cs and FeatureNode.cs for UI binding.

Windows power users and system administrators who want to clean up fresh Windows 11 installations by removing Microsoft bloatware, AI features (Copilot/Recall), and telemetry without using web-based tools or complex scripts. Contributors are developers comfortable with C# desktop applications and Windows system-level modifications via registry/PowerShell.

The project is actively developed (reborn from the classic Bloatynosy 0.85 with a fresh interface labeled 'Nue'). GitHub shows production-ready release infrastructure with versioning starting from 11.x; however, no visible CI/CD pipeline files suggest manual release builds. The codebase is lean and focused rather than enterprise-scale; test coverage and automated testing are not apparent in the file structure.

Single-maintainer risk (builtbybel) with no visible test suite or CI automation increases regression risk for a tool that modifies system registry/services. Dependencies are minimal but include Newtonsoft.Json.dll in plugins; the tool manipulates critical Windows components (UAC, telemetry, system apps) so bugs could render systems unstable. Last activity visibility is unclear from file timestamps, but the project is young (11.x versioning suggests recent reboot).

Active focus on Windows 11 24H2 upgrade automation (see plugins for 'Inplace Upgrade to 24H2 via Registry.json', 'Force Windows Update to Windows 11 24H2.json'). Localization expansion underway with German, Italian, and Korean resource DLLs. Recent additions include AI removal (RemoveWindowsAI.ps1, CopilotTaskbar.cs, RecallMachine.cs, RecallUser.cs) and Windows Rollback Timer feature. The 'Nue' branding and version 11.x are the current active iteration.

git clone https://github.com/builtbybel/Bloatynosy.git
cd Bloatynosy
cd src/Bloatynosy
dotnet build BloatynosyNue.csproj
dotnet publish -c Release

Or open BloatynosyNue.csproj in Visual Studio 2019+ (targets .NET Framework based on .csproj structure) and build the solution. The compiled .exe will be in /bin/Release/.

Daily commands:

# After building:
./bin/Release/BloatynosyNue.exe

The application is self-contained; plugins and language files should be in the same directory or configured via App.config. No external services required—all operations are local Windows system modifications via registry/WMI/PowerShell.

• src/Bloatynosy/Program.cs — Application entry point that initializes the main form and sets up the core runtime environment.
• src/Bloatynosy/MainForm.cs — Primary UI controller managing user interactions, view switching, and feature execution orchestration.
• src/Bloatynosy/Experience/FeatureBase.cs — Abstract base class that all feature implementations inherit from; defines the core plugin execution contract.
• src/Bloatynosy/JsonPluginHandler.cs — Loader and executor for JSON-based plugins that perform registry and system modifications.
• src/Bloatynosy/PSPluginHandler.cs — Handler for PowerShell-based plugins that execute script-driven system configurations and upgrades.
• plugins/plugins_manifest.json — Master manifest declaring all available plugins, their metadata, and execution requirements.

Add a new Debloat Feature (C# class)

1. Create a new class inheriting from FeatureBase in the appropriate category folder (e.g., Experience/Ads, Experience/Privacy) (src/Bloatynosy/Experience/Ads/NewFeature.cs)
2. Implement Execute() method with registry modifications via Helper.cs WriteToRegistry() (src/Bloatynosy/Helper/Helper.cs)
3. Optionally implement Undo() to allow reversal of changes (src/Bloatynosy/Experience/FeatureBase.cs)
4. Wire feature into appropriate View (ExperienceView) with checkbox control and event handler (src/Bloatynosy/Views/ExperienceView.cs)

Add a new JSON Plugin

1. Create a new .json file in plugins/ directory with registry key-value pairs and operation metadata (plugins/NewPlugin.json)
2. Register the plugin in plugins_manifest.json with name, description, category, and dependencies (plugins/plugins_manifest.json)
3. JsonPluginHandler.cs automatically discovers and parses the plugin; verify with PluginsReview view (src/Bloatynosy/JsonPluginHandler.cs)

Add a PowerShell Plugin

1. Create a new .ps1 file in plugins/ directory with system modifications or installations (plugins/NewScript.ps1)
2. Register in plugins_manifest.json with type='powershell' and required elevation flag (plugins/plugins_manifest.json)
3. PSPluginHandler.cs executes the script with admin elevation; output streamed to LoggerView (src/Bloatynosy/PSPluginHandler.cs)

Add Localization for a New Language

1. Create Strings.[LANG].resx file in src/Bloatynosy/Locales/ (e.g., Strings.fr.resx) with translated string keys (src/Bloatynosy/Locales/Strings.fr.resx)
2. Generate Strings.[LANG].Designer.cs by right-clicking .resx in Visual Studio (src/Bloatynosy/Locales/Strings.fr.Designer.cs)
3. Update language selection logic in MainForm.cs to include new culture code (src/Bloatynosy/MainForm.cs)

• Windows Forms (.NET Framework) — Enables lightweight, single-process UI for system administration tasks without external dependencies; native Windows integration for registry access and admin elevation.
• C# with direct Registry API — Provides low-level Windows Registry access via Microsoft.Win32.Registry for direct debloat operations without WMI overhead.
• JSON plugins + PowerShell scripts — Dual-mode extensibility allows both declarative registry changes (JSON) and imperative system operations (PS1) without recompiling the core application.
• Localization via .resx files — Built-in .NET resource system for multi-language support (DE, IT, KO) with minimal overhead.

• Single monolithic Windows Forms application rather than modular services

  • Why: Simplifies distribution and avoids complex IPC; single-process model guarantees sequential registry execution and transactional integrity.
  • Consequence: Limited to single-threaded operation; cannot parallelize feature execution without complex threading; tightly coupled UI and business logic.

• No built-in undo/rollback mechanism; relies on user-initiated Undo() calls

  • Why: Reduces complexity and avoids shadow registry snapshots; keeps memory footprint minimal.
  • Consequence: If application crashes mid-operation, user may face partially-applied registry changes; recovery requires manual intervention or PowerShell scripts.

• Plugins executed in-process without sandboxing

  • Why: Enables direct registry mutations and system calls without elevation overhead.
  • Consequence: Malicious or buggy plugins can destabilize the entire application or Windows OS; requires careful vetting of third-party plugins.

• No update mechanism built into the application

  • Why: Keeps app lightweight and avoids automatic background processes.
  • Consequence: Users must manually download new versions from GitHub; no auto-patching for critical debloat features.

• Cross-platform support (Windows-only; directly manipulates Windows Registry and system APIs)
• Real-time monitoring or daemon operations (one-shot debloat tool, not a service)
• Authentication or user accounts (targets local admin only; no multi-user coordination)
• Backup/snapshot of original system state before modifications
• Graphical diff or preview of registry changes before execution
• Integration with third-party MDM or enterprise management tools

Admin elevation required: Most features (registry modifications, service disabling, app uninstallation) require running the .exe as Administrator—no error handling visible if launched without elevation. Plugin loading: /plugins/ directory and plugins_manifest.json must be co-located with the .exe or configured in App.config; missing plugins fail silently. .NET Framework version: The csproj targets a specific .NET Framework version (check BloatynosyNue.csproj)—targeting wrong runtime causes startup failure. Localization fallback: Resource DLLs in /languages/ are satellite assemblies; missing language DLL falls back to embedded English strings. Registry/service dependencies: Features like DisableUAC, RemoveOneDrive execute destructive registry operations without transactions; rollback requires manual reversal or system restore. PowerShell execution policy: .ps1 scripts in /plugins/ may fail if Windows PowerShell execution policy is Restricted—no internal bypass visible.

• Windows Registry Hives and Registry Keys — Bloatynosy disables telemetry, ads, and features by modifying HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER registry keys (e.g., disabling Copilot, UAC, OneDrive integration); understanding registry structure is essential to debug or extend feature modifications.
• Windows Services and AppX Packages — Features like RemoveWindowsAI.ps1 and RemoveOneDrive.ps1 uninstall or disable Windows services and Universal Apps (AppX); understanding service lifecycle and AppX (MSIX) package management is required to safely remove bloatware without breaking Windows.
• Windows Telemetry and Diagnostic Data Collection — Core purpose: Bloatynosy disables Windows' Connected User Experiences (DiagTrack, dmwappushservice) and telemetry pipelines; understanding what data Microsoft collects and how to disable it is the domain-specific knowledge for this tool.
• PowerShell Script Execution and RemoteSigned Policy — Plugins execute .ps1 scripts (ChrisTitusApp.ps1, Remove Windows AI.ps1); understanding PowerShell execution policies, signed scripts, and script isolation is critical for safe plugin loading and debugging.
• .NET Satellite Assemblies for Localization — Bloatynosy uses .resources.dll files in /languages/de/, /languages/it/, /languages/ko/ for multi-language support; understanding satellite assembly structure is required to add new localizations or fix translation issues.
• WinForms Data Binding and UI Inheritance — The UI uses WinForms with FeatureBase inheritance hierarchy and FeaturePanel binding; understanding WinForms databinding patterns is essential to add new UI elements or modify the feature list layout.
• Windows Task Scheduler and DWORD Registry Values — Many debloat features toggle settings via DWORD values (0=disabled, 1=enabled) in scheduled tasks and system configurations; understanding Task Scheduler registry locations and DWORD semantics is needed to add new toggles.

• W4RH4WK/Debloat-Windows-10 — Direct competitor for Windows debloating via PowerShell and registry scripts; reference for debloat patterns and feature completeness on Windows 10
• builtbybel/Winpilot — Author's previous web-based debloating attempt (mentioned in README as discontinued); understand what was wrong with the web approach vs. native Bloatynosy Nue
• ChrisTitusTech/winutil — Modern PowerShell-based Windows optimization and debloating tool; see /plugins/ChrisTitusApp.ps1 for integration pattern and feature parity comparison
• ntdevlabs/tiny11builder — Windows 11 image debloating at ISO level; complementary approach—Bloatynosy removes bloat post-install while tiny11builder removes it pre-install
• builtbybel/Bloatynosy-Nue-Lite — Hypothetical lite variant (not confirmed in repo data); would be a lightweight subset targeting minimal Windows 11 installs

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 Experience feature classes (AI, Ads, Privacy, Gaming, UI modules)

The repo has 20+ feature classes under src/Bloatynosy/Experience/ (CopilotTaskbar.cs, Telemetry.cs, GameDVR.cs, etc.) with no visible test project. These are critical system modification features that modify Windows registry/services. Unit tests would catch regressions, validate logic before deployment, and give contributors confidence when modifying sensitive features. This is high-value given the destructive nature of debloating operations.

• [ ] Create src/Bloatynosy.Tests project (.NET xUnit or NUnit)
• [ ] Add tests for FeatureBase.cs to validate inheritance contract
• [ ] Add tests for src/Bloatynosy/Experience/Privacy/Telemetry.cs (validate registry key targets)
• [ ] Add tests for src/Bloatynosy/Experience/AI/CopilotTaskbar.cs (mock Windows API calls)
• [ ] Add tests for src/Bloatynosy/Experience/Ads/ classes to verify they target correct registry hives
• [ ] Integrate test project into .csproj build

Refactor and document the plugins system (plugins/plugins_manifest.json loader)

The plugins/ directory contains 14+ PowerShell scripts and JSON configs (AppInstaller.json, Block New Outlook.json, Remove Windows AI.ps1, etc.) but there's no visible documentation on how the manifest system works, no schema validation for JSON plugins, and no loader code visible in the src/ tree. Adding a Plugin loader class, JSON schema, and docs would make contributions easier and prevent malformed plugins from breaking the app.

• [ ] Create src/Bloatynosy/Plugins/PluginManifest.cs to deserialize plugins_manifest.json (using Newtonsoft.Json.dll already in plugins/)
• [ ] Create src/Bloatynosy/Plugins/PluginValidator.cs to validate JSON structure and required fields
• [ ] Create plugins/schema.json defining the manifest structure (name, version, description, dependencies, type: PowerShell|JSON)
• [ ] Add README.md in plugins/ directory documenting how to create new plugins with examples
• [ ] Add integration tests for PluginManifest loader

Add GitHub Actions CI workflow for building and testing across Windows versions

This is a Windows-specific .NET application that modifies system settings. There's no visible CI/CD pipeline to catch build breaks or verify functionality on different Windows versions (21H2, 22H2, 24H2 based on plugin names). A GHA workflow would validate that PRs compile, pass tests, and don't break on target Windows versions—critical for a debloating tool that touches the registry.

• [ ] Create .github/workflows/build-test.yml with: checkout, setup .NET, restore deps, build src/Bloatynosy/BloatynosyNue.csproj
• [ ] Add test step: 'dotnet test src/Bloatynosy.Tests' (after tests are added per Idea #1)
• [ ] Configure matrix strategy to test on windows-2022 (Windows Server 2022/Windows 11 equivalent) and windows-2019 (if supporting older versions)
• [ ] Add artifact upload for built .exe and .dll files
• [ ] Add status badge to README.md

• Add unit tests for FeatureBase and its concrete subclasses (CopilotTaskbar.cs, RecallMachine.cs, etc.). The repo has no visible test project; create /src/Bloatynosy.Tests/ with NUnit/xUnit and stub tests for feature enable/disable logic.: Test coverage protects against regressions in destructive system modifications.
• Create comprehensive documentation for the plugin system: document the JSON schema for plugins_manifest.json with examples, PowerShell requirements, and how to add a new plugin. Add this to README.md or a new PLUGIN_DEVELOPMENT.md file.: Current /plugins/ are undocumented; external contributors cannot easily add new debloat tasks.
• Implement error handling and logging for failed PowerShell script execution in the plugin loader. Add a log file output (e.g., /logs/bloatynosy.log) and UI feedback when plugins fail (e.g., red status icon in FeaturePanel for failed tweaks).: Silent failures in system modifications are dangerous; users have no visibility into what succeeded/failed.
• Add a French (fr/) localization by extracting all hardcoded strings from .cs files into a French .resources.dll satellite assembly, following the pattern of /languages/de/, /languages/it/, /languages/ko/.: README promises 'Localizations coming soon'; French is a high-value addition for EU users.

This Windows debloating utility has significant security concerns related to dynamic plugin execution, registry

• High · PowerShell Script Execution Without Validation — src/Bloatynosy/PSPluginHandler.cs, plugins/*.ps1 files. Multiple PowerShell scripts (.ps1 files) in the plugins directory are loaded and executed dynamically by the application (PSPluginHandler.cs). These scripts perform system-level operations like registry modifications, app uninstallation, and Windows updates. Without proper validation and sandboxing, malicious or tampered scripts could execute arbitrary code with application privileges. Fix: Implement script signing and validation using PowerShell execution policies, validate script hashes before execution, run scripts in a restricted execution environment, and implement comprehensive code review processes for all plugin scripts.
• High · Dynamic JSON Plugin Loading Without Schema Validation — src/Bloatynosy/JsonPluginHandler.cs, plugins/*.json files. The JsonPluginHandler.cs loads and processes JSON configuration files from the plugins directory without apparent schema validation. Malicious or malformed JSON could lead to unexpected behavior, code injection, or denial of service attacks. Fix: Implement strict JSON schema validation, use a whitelist approach for allowed configuration keys, sanitize all values before use, and implement digital signatures for plugin manifests.
• High · Registry Modification Without Authorization Checks — src/Bloatynosy/Experience/*.cs files. Multiple modules (PrivacyExperience.cs, various AI/Ads/Gaming/UI modules) perform direct Windows Registry modifications. The application appears to modify sensitive registry keys related to Windows Defender, telemetry, and system services without explicit user consent dialogs or rollback capabilities. Fix: Add explicit pre-modification user confirmation dialogs, implement transaction-based registry changes with rollback capability, log all registry modifications for auditing, and require elevated privileges with clear warnings.
• Medium · Unvalidated External Plugin Manifest — plugins/plugins_manifest.json, src/Bloatynosy/JsonPluginHandler.cs. The plugins_manifest.json file is loaded to orchestrate plugin execution, but there is no evidence of signature verification or integrity checking of the manifest or its referenced plugins. Fix: Implement digital signatures for the manifest file, verify checksums of all referenced plugins, use HTTPS with certificate pinning for any remote plugin sources, and maintain a secure plugin registry.
• Medium · Third-party DLL Without Version Pinning — plugins/Newtonsoft.Json.dll. Newtonsoft.Json.dll is included in the plugins directory without visible version information. Using third-party libraries without version constraints or security checks could expose the application to known vulnerabilities. Fix: Pin specific versions of all dependencies, maintain an SBOM (Software Bill of Materials), regularly scan dependencies with vulnerability checkers (e.g., OWASP Dependency-Check), and update dependencies through controlled processes.
• Medium · Logging May Contain Sensitive Information — src/Bloatynosy/Helper/Logger.cs. The Logger.cs utility may log sensitive operations including registry modifications, system changes, and user configurations without proper redaction mechanisms. Fix: Implement log sanitization to redact sensitive data, restrict log file access permissions, implement log rotation and retention policies, and avoid logging registry values or configuration data that may contain secrets.
• Low · Missing Input Validation in Helper Utilities — src/Bloatynosy/Helper/Helper.cs, src/Bloatynosy/Helper/Utils.cs. Helper classes (Helper.cs, Utils.cs) may process user input or file paths without comprehensive validation, potentially leading to path traversal or injection attacks. Fix: Implement input validation for all user-provided data and file paths, use safe path APIs, validate against whitelist patterns, and sanitize strings used in any dynamic operations.
• Low · No Evidence of Code Signing — Root repository structure. No code signing certificates or executable signing procedures are visible in the repository structure, which could allow tampering with distributed binaries. Fix: Implement executable code signing with a trusted certificate, publish signature hashes with releases, provide transparent verification instructions for users, and consider implementing Windows SmartScreen whitelisting.

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.