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/lostindark/DriverStoreExplorer 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 — Mixed signals — read the receipts

• Last commit 3w ago
• 13 active contributors
• GPL-2.0 licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 76% of recent commits
• ⚠ GPL-2.0 is copyleft — check downstream compatibility
• ⚠ 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 lostindark/DriverStoreExplorer repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/lostindark/DriverStoreExplorer.

What it runs against: a local clone of lostindark/DriverStoreExplorer — 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 lostindark/DriverStoreExplorer | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 49 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-2.0" \\
  || miss "license drift — was GPL-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Rapr/DSEForm.cs" \\
  && ok "Rapr/DSEForm.cs" \\
  || miss "missing critical file: Rapr/DSEForm.cs"
test -f "Rapr/Utils/IDriverStore.cs" \\
  && ok "Rapr/Utils/IDriverStore.cs" \\
  || miss "missing critical file: Rapr/Utils/IDriverStore.cs"
test -f "Rapr/Utils/DriverStoreFactory.cs" \\
  && ok "Rapr/Utils/DriverStoreFactory.cs" \\
  || miss "missing critical file: Rapr/Utils/DriverStoreFactory.cs"
test -f "Rapr/Utils/NativeDriverStore.cs" \\
  && ok "Rapr/Utils/NativeDriverStore.cs" \\
  || miss "missing critical file: Rapr/Utils/NativeDriverStore.cs"
test -f "Rapr/Program.cs" \\
  && ok "Rapr/Program.cs" \\
  || miss "missing critical file: Rapr/Program.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 49 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~19d)"
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/lostindark/DriverStoreExplorer"
  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).

Driver Store Explorer (RAPR) is a Windows desktop application (C# WinForms) that provides a GUI for browsing, managing, and cleaning the Windows DriverStore—the system directory where Windows stores device driver packages. It supports multiple backend APIs (native Windows API, DISM, PnPUtil) and enables bulk deletion, export, and intelligent cleanup of driver packages, with particular emphasis on identifying and removing old/duplicate driver versions. Monolithic WinForms application. Main UI entry point is DSEForm.cs with helper logic in DSEFormHelper.cs. Language/localization strings live in Rapr/Lang/ (Resource files for 20+ cultures). Custom controls in Rapr/Controls/. Backend abstraction via DriverStoreType.cs likely switches between API implementations. Exports handled by CSVExporter.cs and IExport.cs interface. Single Rapr.sln project structure.

Windows system administrators and advanced users who need to manage driver bloat, troubleshoot driver conflicts, or maintain offline Windows images. Also useful for IT professionals performing large-scale device deployments or imaging who need to export/backup drivers before removal.

Actively maintained and production-ready. The project has CI/CD pipelines (GitHub Actions in .github/workflows/ci.yml, release.yml, winget.yml), multi-language support (20+ locales in Rapr/Lang/), and release automation. However, it appears to be a single-maintainer project (lostindark) with no visible test files in the repo snapshot, which is a maturity concern for a system-critical tool.

High risk due to the nature of what it does—improper driver deletion can render Windows unbootable. The codebase has no visible automated tests (.csproj or test folders not shown), making regression detection difficult. Single maintainer (lostindark) means bus factor is 1. The tool directly modifies critical Windows system state, so any bug can have severe consequences. No visible issue tracker or recent activity timestamp provided, so maintenance velocity is unclear.

Based on visible workflows: Active CI/CD with automated builds (ci.yml), release automation (release.yml), and WinGet package distribution (winget.yml). The presence of release-highlights.md and release-highlights.lock.yml suggests recent release tooling updates. No PR or issue data visible in file list, so specific work-in-progress items cannot be determined from this snapshot.

Clone and open the solution: git clone https://github.com/lostindark/DriverStoreExplorer.git && cd DriverStoreExplorer && start Rapr.sln (opens in Visual Studio). Requires .NET Framework (inferred from .sln and .Designer.cs files). No package.json visible, so NuGet restore happens automatically in VS. Build via Visual Studio or msbuild Rapr.sln.

Daily commands: Open Rapr.sln in Visual Studio 2015+ and press F5 to debug, or Build → Build Solution then run Rapr.exe from bin folder. The app must run with Administrator privileges to access the DriverStore. No startup scripts or npm install needed—pure .NET desktop app.

• Rapr/DSEForm.cs — Main UI form and primary entry point for the application—orchestrates all driver store operations and user interactions.
• Rapr/Utils/IDriverStore.cs — Core abstraction defining the driver store interface; all driver management operations depend on implementations of this contract.
• Rapr/Utils/DriverStoreFactory.cs — Factory pattern implementation that creates appropriate driver store instances; critical for supporting multiple driver store backends.
• Rapr/Utils/NativeDriverStore.cs — Primary implementation of IDriverStore using native Windows APIs; handles deletion, enumeration, and low-level driver store operations.
• Rapr/Program.cs — Application entry point; initializes the UI, logging, and permission checks before launching the main form.
• Rapr/Utils/DeviceHelper.cs — Interacts with Windows device manager and PnP utilities; essential for enumerating and managing physical devices.
• Rapr/SafeNativeMethods.cs — P/Invoke declarations for Windows native APIs (SetupAPI, DISM); all system-level driver operations depend on these definitions.

Add Support for a New Driver Store Type

1. Create a new class implementing IDriverStore interface in Rapr/Utils/ (e.g., CustomDriverStore.cs). Implement Enumerate(), Delete(), and other required methods. (Rapr/Utils/IDriverStore.cs)
2. Register the new implementation in DriverStoreFactory.GetInstance() method to detect and instantiate your store type. (Rapr/Utils/DriverStoreFactory.cs)
3. If the new type requires native API calls, add P/Invoke declarations to SafeNativeMethods.cs. (Rapr/SafeNativeMethods.cs)
4. Update the driver store selection dialog (ChooseDriverStore.cs) if manual selection is needed. (Rapr/ChooseDriverStore.cs)
5. Add unit tests to RaprTests/RaprTests.cs validating Enumerate() and Delete() operations. (RaprTests/RaprTests.cs)

Add a New Export Format

1. Create a new class implementing IExport interface (e.g., JSONExporter.cs in Rapr/). (Rapr/IExport.cs)
2. Implement the Export() method to serialize DriverStoreEntry collection to your target format. (Rapr/CSVExporter.cs)
3. Register the exporter in DSEForm.cs menu or toolbar, adding a handler that instantiates and calls your Export() method. (Rapr/DSEForm.cs)
4. Add localization strings for the new export format in Language.resx. (Rapr/Lang/Language.resx)

Add a New UI Control or Feature to the Main Form

1. Define the control layout in DSEForm.Designer.cs or manually add to the form's InitializeComponent() method. (Rapr/DSEForm.Designer.cs)
2. Implement the event handlers and logic in DSEForm.cs to respond to user interactions and update driver list/state. (Rapr/DSEForm.cs)
3. If the control requires helper functionality, add methods to DSEFormHelper.cs. (Rapr/DSEFormHelper.cs)
4. Add any required localization strings to Language.resx and all language-specific resource files. (Rapr/Lang/Language.resx)

Integrate a New Windows API or System Utility

1. Declare P/Invoke signatures for the new API in SafeNativeMethods.cs with proper DllImport attributes. (Rapr/SafeNativeMethods.cs)
2. Create a wrapper class (e.g., NewUtilityHelper.cs) in Rapr/Utils/ that encapsulates the P/Invoke calls with error handling. (Rapr/Utils/DeviceHelper.cs)
3. Call the wrapper from the appropriate driver store implementation or helper class depending on the feature scope. (Rapr/Utils/NativeDriverStore.cs)
4. Add unit tests verifying the wrapper's behavior in RaprTests/. (RaprTests/RaprTests.cs)

• Windows Forms (WinForms) — Native Windows desktop UI framework with direct access to Win32 APIs; appropriate for system administration tool requiring tight OS integration.
• P/Invoke & SafeNativeMethods — Required to call unmanaged Windows APIs (SetupAPI, DISM) for low-level driver store and device management operations not exposed by .NET Framework.
• C# — Strong type safety, .NET Framework interop capabilities, and access to Windows-specific libraries; suits administrative tool development.
• Factory & Repository Patterns — Allows abstraction of multiple driver store backends (Native, DISM, PnPUtil

Must run as Administrator—app will fail silently without elevated privileges. DriverStore is Windows-only; this tool will not compile/run on other platforms. No visible app.config or settings file in snapshot, so hardcoded paths or API choices may exist. P/Invoke calls to unmanaged Windows APIs are brittle across OS versions (Vista through Win11)—version-specific behavior may exist but not be documented. Deleting drivers modifies actual system state immediately with no rollback; test on a VM first.

• Windows DriverStore — The central repository this tool manages; understanding its structure and purpose is essential to avoid breaking Windows device functionality
• P/Invoke (Platform Invoke) — RAPR calls native Windows APIs for driver operations; understanding P/Invoke signatures, marshaling, and version compatibility is critical for modifying backend logic
• DISM (Deployment Image Servicing and Management) — One of three backend APIs this tool can use to manage offline/online driver stores; knowing DISM command syntax helps understand DriverStoreType abstraction
• PnPUtil (Plug and Play Utility) — Second backend API for Windows 10+ driver enumeration and deletion; understanding its limitations vs. native API affects feature decisions
• WinForms Designer Pattern — The codebase uses .Designer.cs files (auto-generated by Visual Studio); understanding this separation between designer code and logic is essential for safe UI modifications
• Resource-based Localization (.resx files) — Multi-language support via .resx files in Rapr/Lang/; adding new UI strings or languages requires understanding this mechanism
• Batch/Bulk Operations with Progress Tracking — The tool performs multi-select driver deletion; understanding threading, cancellation tokens, and UI update synchronization prevents race conditions on large bulk operations

• microsoft/Windows-driver-samples — Official Microsoft samples for Windows driver development; relevant for understanding driver package structure and Windows APIs this tool uses
• jaykul/ChocoLatier — PowerShell-based Windows package management; alternative programmatic approach to driver installation and management
• abbodi1406/WHD — Windows Hardening script project; related tool used alongside Driver Store Explorer for system maintenance and cleanup
• Ralim/IronOS — Not directly related but represents firmware/driver-level system tooling; context for understanding system-critical nature of driver management

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 DriverStoreType.cs and SafeNativeMethods.cs

The repo lacks visible test projects despite being a critical system utility that modifies Windows driver store. SafeNativeMethods.cs contains P/Invoke declarations for native Windows APIs, and DriverStoreType.cs likely contains driver enumeration logic. These are high-risk components that should have comprehensive unit tests to prevent regressions and validate driver detection/deletion operations.

• [ ] Create a new test project (e.g., Rapr.Tests) in Rapr.sln
• [ ] Add unit tests for SafeNativeMethods.cs covering native API calls and error handling
• [ ] Add unit tests for DriverStoreType.cs covering driver enumeration, filtering, and deletion logic
• [ ] Integrate test execution into .github/workflows/ci.yml (add dotnet test step)
• [ ] Ensure >80% code coverage for these critical modules

Extract CSV and export logic into a testable abstraction layer (IExport implementation)

CSVExporter.cs exists but IExport.cs interface is present, suggesting incomplete abstraction. The export functionality (CSV, and potentially other formats) should be fully decoupled from the main UI logic (DSEForm.cs and DSEFormHelper.cs). This enables easier testing, format extensibility, and follows the existing interface pattern.

• [ ] Create concrete implementations of IExport.cs for CSV and other formats (e.g., JsonExporter.cs, TsvExporter.cs)
• [ ] Refactor CSVExporter.cs to properly implement IExport interface with dependency injection
• [ ] Update DSEFormHelper.cs to use IExport abstraction instead of direct CSVExporter calls
• [ ] Add unit tests in Rapr.Tests for each exporter implementation
• [ ] Update UI to support format selection via IExport factory pattern

Add GitHub Actions workflow for automated localization validation

The repo supports 19 languages (Language.*.resx files) but lacks CI validation that all language files are synchronized. Missing keys or mismatched translation files could break non-English UIs. A workflow should validate RESX consistency across all Lang/ files before merging.

• [ ] Create .github/workflows/localization-check.yml
• [ ] Write or use a tool to parse Language.resx and all Language.*.resx files
• [ ] Validate that all keys in Language.resx exist in all language variants
• [ ] Check that language file structure matches (no orphaned keys)
• [ ] Report warnings/errors for missing translations in PR comments
• [ ] Run on every push to Rapr/Lang/ directory

• Add unit tests for CSVExporter.cs and DSEFormHelper.cs—currently no test files visible in repo, and a system-critical tool like this should have at least basic logic coverage to catch regressions.
• Improve EnhancedSearchTextBox.cs with substring/wildcard filtering or regex support—currently appears to be basic text matching; admin users would benefit from advanced query patterns.
• Add a dry-run mode flag to DSEFormHelper.cs driver deletion logic—show what would be deleted before actual removal, reducing accidental corruption risk for new users.

Failed to generate security analysis.

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.