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/FlyOOBE 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
• 5 active contributors
• MIT licensed
• ⚠ Slowing — last commit 4mo ago
• ⚠ Single-maintainer risk — top contributor 95% 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/FlyOOBE repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/builtbybel/FlyOOBE.

What it runs against: a local clone of builtbybel/FlyOOBE — 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/FlyOOBE | 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 | Last commit ≤ 155 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "builtbybel/FlyOOBE(\\.git)?\\b" \\
  && ok "origin remote is builtbybel/FlyOOBE" \\
  || miss "origin remote is not builtbybel/FlyOOBE (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"

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

FlyOOBE is a Windows 11 setup assistant that bypasses hardware requirements (TPM 2.0, Secure Boot, CPU checks) by leveraging the Windows Server variant of setup media, allowing installation on unsupported hardware while still delivering standard Windows 11. It evolved from Flyby11 (a pure upgrade tool) to include OOBE customization, debloating, tweaks, and scriptable extensions. Monolithic C# WinForms desktop application with a deprecated legacy codebase (Flyby11-deprecated/) alongside active code. Main app structure: MainForm.cs/Designer.cs for UI orchestration, specialized Forms (CanIUpgradeView, CompatibilityForm, ProblemsForm) for workflows, FAQHandler.cs and IsoHandler.cs for logic, Locales/ folder for 14+ language .resx files, and legacy C++/C code (CpuCheckNative) for native CPU capability detection.

End-users with older PCs (lacking TPM/Secure Boot/supported CPUs) who want to upgrade to Windows 11 without replacing hardware; also power users seeking OOBE control and system debloating. Contributors are system-level developers familiar with Windows internals, setup media manipulation, and C# WinForms GUI development.

Actively maintained but not heavily tested in CI/CD; the deprecated Flyby11 folder indicates a prior iteration now incorporated into the main tool. No visible GitHub Actions or automated test suite in the file list. The project has served thousands of users and demonstrates maturity through real-world feedback, but lacks formal test coverage and release automation.

Single-author maintainer (builtbybel) creates continuity risk. Relies on Microsoft's undocumented Server setup variant which could break with OS updates; POPCNT CPU requirement cannot be bypassed (hard architectural limitation). No visible dependency lock file (package-lock.json/packages.lock.json) suggests manual or implicit dependency management. The method's legality and support status remain a user responsibility.

Active evolution from WinForms Flyby11 to the newer FlyOOBE architecture with expanded scope (OOBE toolkit, tweaks, debloat). The README indicates version 2.3+ introduced a compatibility checker to warn older CPUs. Recent work appears focused on multi-language support and refinement of the upgrade/OOBE experience rather than major architectural shifts.

git clone https://github.com/builtbybel/FlyOOBE.git
cd FlyOOBE
# Open .sln in Visual Studio, build the C# project (FlyOOBE.csproj or equivalent)
# Or build from command line: msbuild FlyOOBE.sln

Note: This is a .NET Framework WinForms app (not .NET Core); requires Visual Studio 2019+ or msbuild on Windows.

Daily commands: Launch the compiled executable (AppIcon.exe or equivalent) post-build. No dev server; it's a desktop GUI that runs standalone. Requires Administrator privileges for ISO mounting, setup media patching, and Windows configuration changes.

• Flyby11-deprecated/Flyby11/MainForm.cs: Primary UI orchestrator and application entry point; handles wizard flow, form sequencing, and user interactions
• Flyby11-deprecated/Flyby11/IsoHandler.cs: Core logic for downloading, mounting, and patching Windows Server setup ISO to bypass hardware checks
• Flyby11-deprecated/Flyby11/CompatibilityForm.cs: Hardware compatibility checking UI; integrates native POPCNT detection and displays upgrade feasibility warnings
• Flyby11-deprecated/Flyby11/Locales/Strings.resx: Master English string resource; all UI text and messages sourced here; basis for 14+ language translations
• Flyby11-deprecated/CpuCheckNative/PopcntCheck.cpp: Native C++ POPCNT (Population Count) CPU instruction detection; critical for determining Windows 11 24H2 compatibility
• Flyby11-deprecated/Flyby11/FAQHandler.cs: Handles FAQ data, retrieval, and display; referenced in UI to guide users through common issues
• Flyby11-deprecated/Flyby11/Program.cs: .NET WinForms entry point; application startup, main event loop, and initial form instantiation

UI changes: Edit MainForm.Designer.cs and MainForm.cs (main orchestration), or specialized forms like CanIUpgradeView.cs for upgrade flow. Localization: Add or edit .resx files in Locales/ folder (copy Strings.resx to Strings.xx-YY.resx and translate). Logic: FAQHandler.cs for FAQ logic, IsoHandler.cs for ISO/setup media handling, CompatibilityForm.cs for hardware checks. Strings: Modify Locales/Strings.resx and regenerate Strings.Designer.cs.

Admin privileges required: Many operations (ISO mounting, registry modification, setup media patching) demand elevated execution; app must run as Administrator. ISO download dependency: Relies on external Fido script (pbatard/Fido) for Windows Server ISO retrieval; network/API changes could break this. POPCNT is non-negotiable: CPU lacking POPCNT instruction support cannot run Windows 11 24H2 even with FlyOOBE — this is a hard CPU-level limitation, not a software check. Localization deadness: 14 .resx files must be kept in sync; Strings.Designer.cs is auto-generated and will overwrite manual edits if not careful. Deprecated folder confusion: Flyby11-deprecated/ contains old WinForms code; ensure new development doesn't accidentally reference old classes from there.

• Windows Server Setup Variant Bypass — FlyOOBE's core technique relies on using Windows Server setup media instead of Consumer Windows 11 to skip TPM/CPU/Secure Boot checks; understanding this method is critical to grasping why the tool works and its limitations
• POPCNT (Population Count) CPU Instruction — Windows 11 24H2 requires POPCNT hardware support; FlyOOBE's native CpuCheckNative.dll detects this via CPU instruction set queries; understanding POPCNT is essential to knowing what cannot be bypassed
• Windows Registry Hive Patching (Offline) — IsoHandler.cs likely modifies setup media registry hives to disable hardware requirement checks; offline registry editing (mounting VHD/WIM and patching SYSTEM/SOFTWARE hives) is the mechanism enabling the bypass
• WinForms Localization via .resx Resources — FlyOOBE uses .NET WinForms .resx files for 14-language UI; understanding resource-driven localization patterns (culture-specific naming: Strings.de.resx, Strings.ja.resx, etc.) is essential for UI/translation contributions
• P/Invoke and Native DLL Interop — CpuCheckNative C++ DLL is called from C# via P/Invoke; understanding marshaling, calling conventions, and safe DLL loading is necessary for maintaining or extending native CPU detection logic
• ISO 9660 Mounting and Virtual Disk Handling — IsoHandler.cs must download and mount Windows Server ISO; understanding ISO mounting via Windows APIs (or PowerShell Mount-DiskImage) and subsequent file extraction/patching is core to the tool's operation
• Out-of-Box Experience (OOBE) Customization — FlyOOBE's newer phase (beyond Flyby11) includes OOBE toolkit to skip privacy screens, remove junk apps, and pre-configure settings; understanding Windows OOBE automation and registry/PowerShell-driven post-install config is essential for this feature area

• pbatard/Fido — FlyOOBE's ISO download mechanism; Fido script automates Windows Server media retrieval that FlyOOBE uses to bypass hardware checks
• abbodi1406/KMS_VL_ALL — Ecosystem companion for Windows activation on unsupported hardware; users upgrading with FlyOOBE often also need KMS activation workarounds
• ntdevlabs/VB-SYNC — Related Windows setup media manipulation; demonstrates registry patching and setup.exe customization patterns relevant to FlyOOBE's core technique
• massgravel/MediaCreationTool.bat — Alternative Windows 11 installation method without hardware restriction bypasses; direct competitor in the 'unsupported hardware upgrade' space
• Atlas-OS/Atlas — Post-install Windows 11 debloating and tweaking tool; complementary to FlyOOBE's OOBE customization phase; users often chain both together

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 Extension Validation & Testing Framework for Flyoobe.Extensions

The Flyoobe.Extensions folder contains multiple PowerShell extension scripts (Developer Essentials.ps1, Gaming tweaks.ps1, etc.) but lacks validation, linting, or testing infrastructure. A new contributor could build a PowerShell script validator that ensures all extensions follow the documented standards (from Write-an-Extension.md), catch syntax errors early, and provide a CI workflow to validate new extensions. This prevents broken scripts from shipping and makes the extension ecosystem more reliable.

• [ ] Create a PowerShell linting/validation script in Flyoobe.Extensions/ that checks syntax, required metadata, and documented structure against Write-an-Extension.md
• [ ] Add GitHub Action workflow (.github/workflows/validate-extensions.yml) to run the validator on PRs affecting any .ps1 files in Flyoobe.Extensions/
• [ ] Document the validation rules and add examples in Flyoobe.Extensions/EXTENSIONS.md

Add CPU Check Unit Tests for Flyby11/CpuCheck.cpp (and deprecated variant)

Both Flyby11/CpuCheck.cpp and Flyby11-deprecated/CpuCheckNative are native C++ modules that perform CPU capability detection (POPCNT instruction check visible in PopcntCheck.cpp). These have no visible test suite, making it risky to refactor or maintain. A contributor could create a C++ test project (using Google Test or similar) that validates CPU detection logic across different scenarios, especially since this is critical for Windows 11 hardware compatibility checks.

• [ ] Create a new Visual Studio project in the solution (e.g., CpuCheck.Tests) targeting C++ unit tests
• [ ] Write test cases for CpuCheck.cpp covering: POPCNT detection, fallback behavior, edge cases on different CPU architectures
• [ ] Integrate test project into CI (GitHub Actions with MSBuild) to run on PRs modifying Flyby11/CpuCheck.cpp or related files

Refactor & Document Flyby11-deprecated Cleanup & Migration Path

The Flyby11-deprecated folder is substantial (~30+ files) and represents the old WinForms-based architecture. The README mentions FlyOOBE is the 'natural evolution' but there's no documented migration guide or deprecation path for users. A contributor could create a clear deprecation notice, document what FlyOOBE replaces in the old codebase, and add a migration guide for contributors/users still referencing the old code.

• [ ] Create Flyby11-deprecated/DEPRECATION.md explaining what features moved to FlyOOBE, timeline, and migration path
• [ ] Add a prominent note in Flyby11-deprecated/Flyby11.sln or README linking to FlyOOBE equivalents
• [ ] Document in main README which old features (e.g., CanIUpgradeView, CompatibilityForm) are now part of FlyOOBE and where to find them

• Add unit tests for FAQHandler.cs and IsoHandler.cs logic (validation of FAQ data structure, ISO download URL parsing, error handling paths). Currently no test files exist in the repo; start with a simple MSTest or NUnit project.: Core business logic is untested; critical for reliability and regression detection as the tool evolves.
• Extend CompatibilityForm.cs with detailed hardware report export (CSV/JSON). Currently shows compatibility status in UI only; add a 'Save Report' button that exports CPU model, POPCNT support, TPM version, Secure Boot status to a file for troubleshooting.: Users requesting support often struggle to communicate their hardware config; structured export helps maintainers diagnose issues faster.
• Create comprehensive documentation for the ISO patching process in IsoHandler.cs (diagram the steps: download → mount → identify setup.exe → patch registry hives → unmount). Add inline comments and a TECHNICAL.md guide explaining how the Windows Server bypass works.: Future contributors and fork-maintainers need to understand the core upgrade mechanism; currently undocumented in repo, relying on external Microsoft KB articles.

• High · Deprecated and Unmaintained Code Present — Flyby11-deprecated/, Flyoobe.ToolSpot-deprecated/. The repository contains multiple deprecated directories (Flyby11-deprecated, Flyoobe.ToolSpot-deprecated) with older .NET Framework code. These legacy components may contain unpatched security vulnerabilities and should not be included in production distributions. Fix: Remove deprecated directories from the repository entirely. If historical reference is needed, archive them separately. Ensure only actively maintained code is distributed to users.
• High · Potential Privilege Escalation Risk — Flyby11/CpuCheck.cpp, Flyby11/dllmain.cpp, Flyby11-deprecated/CpuCheckNative/. The codebase includes native C++ DLL projects (Flyby11/CpuCheck.cpp, Flyby11/dllmain.cpp) that appear to handle CPU checks and system-level operations. Native code execution combined with OOBE (Out-of-Box Experience) customization in a Windows setup context could potentially be exploited for privilege escalation. Fix: Implement comprehensive input validation and bounds checking in all native C++ code. Conduct thorough security code review and consider third-party security audit. Ensure proper error handling and avoid buffer overflows.
• High · PowerShell Script Execution Without Validation — Flyoobe.Extensions/*.ps1. The repository contains PowerShell scripts (Flyoobe.Extensions/*.ps1) that are described as 'scriptable setup extensions'. These scripts may execute system-level operations with elevated privileges during Windows setup, creating a vector for malicious script injection or tampering. Fix: Implement code signing for all PowerShell scripts. Validate script integrity before execution. Use AppLocker or Execution Policy to restrict script sources. Document exactly what each extension does and require user consent before execution.
• Medium · Missing Input Validation in Forms — Flyby11-deprecated/Flyby11/*.cs (Form classes). Multiple WinForms components (CanIUpgradeView.cs, CompatibilityForm.cs, MainForm.cs, ProblemsForm.cs) handle user input and system operations without visible input validation patterns in the file structure. Fix: Implement comprehensive input validation for all user-facing forms. Validate file paths, registry operations, and command executions. Use whitelisting rather than blacklisting for acceptable inputs.
• Medium · ISO Handler Without Visible Security Controls — Flyby11-deprecated/Flyby11/IsoHandler.cs. The IsoHandler.cs component manages ISO files during Windows setup but does not show visible integrity or signature verification mechanisms in the file structure. Fix: Implement cryptographic signature verification for ISO files. Validate file integrity using hashes. Restrict ISO sources to official Microsoft repositories. Implement secure temporary file handling.
• Medium · Logging Without Visible Sanitization — Flyby11-deprecated/Flyby11/Logger.cs. A Logger.cs component exists but without visible source code context, sensitive information (user paths, system details, credentials) may be logged insecurely. Fix: Ensure logging never captures sensitive data (passwords, tokens, PII). Implement log rotation and secure storage. Restrict log file access to authorized users. Sanitize user input before logging.
• Low · Multi-Language Resource Files Complexity — Flyby11-deprecated/Flyby11/Locales/. The application includes 14+ localization files (.resx) which increases attack surface and maintenance burden. Potential for localization-based injection attacks if not properly handled. Fix: Validate all resource strings at runtime. Implement proper escaping for display contexts. Use secure localization libraries. Review localization files for encoded payloads during updates.
• Low · Missing Security Headers and Manifest Issues — Flyby11-deprecated/Flyby11/app.manifest, Flyoobe.ToolSpot-deprecated/Flyoobe.ToolSpot/app.manifest. App.manifest files exist but security configuration details are not visible. Windows applications should explicitly define security contexts and privilege requirements. Fix: Explicitly declare privilege requirements (requestedExecutionLevel) in manifests. Request only

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.