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/beeradmoore/dlss-swapper 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
• 17 active contributors
• GPL-3.0 licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 78% of recent commits
• ⚠ GPL-3.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 beeradmoore/dlss-swapper repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/beeradmoore/dlss-swapper.

What it runs against: a local clone of beeradmoore/dlss-swapper — 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 beeradmoore/dlss-swapper | 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 ≤ 49 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "beeradmoore/dlss-swapper(\\.git)?\\b" \\
  && ok "origin remote is beeradmoore/dlss-swapper" \\
  || miss "origin remote is not beeradmoore/dlss-swapper (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 "DLSS Swapper.sln" \\
  && ok "DLSS Swapper.sln" \\
  || miss "missing critical file: DLSS Swapper.sln"
test -f "src/.editorconfig" \\
  && ok "src/.editorconfig" \\
  || miss "missing critical file: src/.editorconfig"
test -f "global.json" \\
  && ok "global.json" \\
  || miss "missing critical file: global.json"
test -f "nuget.config" \\
  && ok "nuget.config" \\
  || miss "missing critical file: nuget.config"
test -f "package/build_all.cmd" \\
  && ok "package/build_all.cmd" \\
  || miss "missing critical file: package/build_all.cmd"

# 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/beeradmoore/dlss-swapper"
  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).

DLSS Swapper is a Windows desktop application (C# WPF) that lets gamers download, manage, and swap between different versions of DLSS, FSR, and XeSS shader upscaling DLLs across games without requiring game updates. It solves the problem of being locked to whatever upscaling technology version shipped with a game by enabling manual DLL injection and version management. Single Visual Studio solution (DLSS Swapper.sln) with primary C# codebase (~1.08M lines), complemented by build tooling in PowerShell/Batch/NSIS for installers. The extras/ folder contains EAAppGameListBuilder as a companion utility. GitHub Actions workflows handle automated builds for distribution. Documentation lives in docs/ (Jekyll site) with translator tooling for multi-language support.

PC gamers who want to upgrade or downgrade upscaling technology (DLSS/FSR/XeSS) in their games independently of game patches, and power users who need granular control over graphics library versions across Steam, Epic, GOG, Ubisoft Connect, Xbox App, and Battle.net libraries.

Actively maintained and production-ready. The repo shows recent activity with organized GitHub workflows (build-for-distribute.yml, winget-submission.yml), proper issue templates, multi-language support, and distribution through WinGet and official GitHub releases. Multiple game library integrations and community translations (Catalan, Spanish, Japanese, Portuguese, Turkish, Chinese variants) indicate stable, user-facing feature set.

Standard open source risks apply.

No specific PR or milestone data visible in the file structure provided, but the presence of build-for-distribute.yml and winget-submission.yml workflows suggests active release management and package distribution. Multiple language translations and game library integrations indicate ongoing feature expansion and community engagement.

Clone the repo with git clone https://github.com/beeradmoore/dlss-swapper.git, open DLSS Swapper.sln in Visual Studio (requires .NET Framework/Core for C# compilation), restore NuGet packages, then build the solution. For running: launch the compiled executable directly or use the NSIS installer in the release artifacts.

Daily commands: Open DLSS Swapper.sln in Visual Studio 2019+ with .NET Framework 4.7.2+ or .NET 6+ support. Build the solution (Ctrl+Shift+B). Run the compiled .exe from bin/Debug or bin/Release. For release builds, use the GitHub Actions workflow: push to main and the build-for-distribute.yml creates installer artifacts.

• DLSS Swapper.sln — Primary Visual Studio solution file that defines the entire project structure and dependencies—entry point for understanding the build system.
• src/.editorconfig — Defines code style and formatting standards that all contributors must follow to maintain consistency across the codebase.
• global.json — Specifies the .NET SDK version and global build settings required for all developers to build the project successfully.
• nuget.config — Configures NuGet package sources and restore behavior—critical for resolving dependencies like CommunityToolkit and AsyncAwaitBestPractices.
• package/build_all.cmd — Master build script orchestrating the entire packaging pipeline; essential for understanding the release and distribution workflow.
• package/NSIS/Installer.nsi — NSIS installer configuration that packages the application for Windows distribution—defines the user-facing installation experience.

Add Support for a New DLL Type (e.g., DLSS, FSR, XeSS variant)

1. Update the project model/service to recognize the new DLL format (src/Acknowledgements/Acknowledgement.cs (reference for data model patterns))
2. Add recognition logic in the core application DLL scanner (DLSS Swapper.sln (add new project if major subsystem))
3. Update the installer to handle the new DLL type (package/NSIS/Installer.nsi)
4. Document the new format in the how-it-works guide (docs/how-it-works/readme.md)
5. Add translations for UI strings related to the new type (docs/translator/index.html)

Add a New Language Translation

1. Create a new README translation file following the naming pattern (readmes/readme_[LANG].md (e.g., readme_de-DE.md for German))
2. Submit translation via the web translator interface (docs/translator/index.html)
3. Add translated strings to the UI translator tool (docs/translator/js/script.js)
4. Update the main documentation index to link the new translation (docs/index.html)

Create a Release Build and Distribute

1. Update version in global.json and any version files (global.json)
2. Run the full build pipeline to create both installer and portable versions (package/build_all.cmd)
3. NSIS will automatically package the installer with file associations (package/NSIS/Installer.nsi)
4. CI/CD automatically submits to Windows Package Manager on tag push (.github/workflows/winget-submission.yml)
5. Create release notes and upload to GitHub Releases (.github/workflows/build-for-distribute.yml)

• WinUI 3 (Community Toolkit) — Modern Windows UI framework providing native look-and-feel with reactive MVVM binding support for a responsive desktop application
• MVVM Community Toolkit — Simplifies view-model binding and async/await patterns, reducing boilerplate and improving code maintainability
• NSIS Installer — Lightweight, scriptable Windows installer format with registry/file association support—industry standard for desktop app distribution
• .NET (C#) — Cross-platform runtime with strong Windows Desktop support, async/await, and rich standard library for file/DLL operations
• GitHub Actions CI/CD — Integrated repository automation for building, testing, and publishing releases without external infrastructure

• Windows-only application (no Linux/macOS support visible)

  • Why: DLSS, FSR, and XeSS DLLs are Windows-specific; targeting Windows gaming ecosystem maximizes user base
  • Consequence: Cannot serve macOS/Linux gamers; maintenance burden lighter due to single platform

• Local file scanning + remote version repository

  • Why: Avoids cloud dependency and latency; users can work offline after initial version index download
  • Consequence: Must manually sync version index; no real-time tracking of game installations across devices

• Backup old DLL before swapping

  • Why: Allows rollback if new DLL causes issues; reduces risk of unrecoverable game breakage
  • Consequence: Doubles storage requirement; adds swap latency; requires cleanup mechanism for stale backups

• Community-driven translations via web UI

  • Why: Scales localization without relying on core team; leverages community expertise in diverse languages
  • Consequence: Quality and currency of translations varies; requires moderation and occasional cleanup of outdated strings

• Does not modify game executables or game engine code
• Does not provide online multiplayer anti-cheat compatibility verification (user responsibility)
• Does not support automatic game discovery via Steam API or Epic Games API (manual path selection only)
• Does not track version compatibility matrices per-game (community crowdsourced in external resources)
• Does not implement Linux or macOS support
• Does not manage shader cache or graphics settings—DLL swapping only

DLSS Swapper modifies game executable directories by injecting/replacing DLL files—requires admin privileges and may trigger antivirus false positives. WPF application requires Windows-specific runtime (.NET Framework or .NET Desktop Runtime). Game library detection depends on external APIs (Steam, Epic, GOG, etc.) which can break if those services change their installation registry keys or file paths. The NSIS installer uses custom signing (suggested by build-for-distribute.yml); unsigned versions may not install without user warnings on modern Windows. No NuGet dependencies visible in file list—verify actual dependency tree in .csproj files for any external security risks.

• DLL Injection / DLL Swapping — Core technique this tool uses to replace runtime graphics libraries; critical for understanding security implications and how Windows loader precedence works
• Windows Registry Game Detection — Game libraries (Steam, Epic, GOG) store installation paths in Windows Registry; DLSS Swapper queries these keys to auto-detect installed games
• NSIS (Nullsoft Scriptable Install System) — Build pipeline uses NSIS for creating Windows installers (.exe); understanding .nsi scripts is needed to modify installation behavior
• WPF (Windows Presentation Foundation) — UI framework for the desktop application; XAML-based declarative UI requires understanding WPF data binding and MVVM patterns for UI modifications
• Semantic Versioning & Compatibility Matrix — Tool must track DLSS/FSR/XeSS versions and determine which are compatible with which games; version comparison logic is non-trivial (3.x vs 2.x breaking changes)
• Game Library API Integration (Steam, Epic, GOG) — Each store has different mechanisms for game discovery (Registry, config files, REST APIs); DLSS Swapper abstracts these differences to support multiple libraries

• Kaldaien/Special-K — Similar DLL injection framework for graphics library hooking and replacement, shares the technical approach of runtime DLL swapping
• GPUOpen-Tools/Radeon-Software-Slimmer — Related tool for managing AMD driver components and library versions, addresses similar GPU software version management use case
• lutris/lutris — Cross-platform game manager supporting multiple libraries; complements DLSS Swapper by providing broader game library unification (though Lutris also runs on Linux/Mac)
• microsoft/winget-cli — Windows Package Manager that DLSS Swapper distributes through; understanding winget-submission.yml workflow requires familiarity with this ecosystem
• NVIDIA-DLSS/DLSS — Official NVIDIA DLSS GitHub (if public) provides reference implementation and version release notes; DLSS Swapper is built around automating adoption of these releases

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 EAAppGameListBuilder utility

The extras/EAAppGameListBuilder project appears to be a helper tool for parsing EA App game lists, but there are no visible test files. Adding unit tests would ensure the GameSearchResponse parsing logic is robust and prevent regressions when the EA App API changes.

• [ ] Create extras/EAAppGameListBuilder/EAAppGameListBuilder.Tests/EAAppGameListBuilder.Tests.csproj
• [ ] Add unit tests for GameSearchResponse.cs deserialization edge cases
• [ ] Add integration tests that validate against sample EA App responses in extras/EAAppGameListBuilder/EAAppGameListBuilder.Tests/Fixtures/
• [ ] Update the build workflow .github/workflows/build-for-distribute.yml to run tests

Add GitHub Action workflow to validate installer NSIS script syntax

The package/NSIS/Installer.nsi file is critical for distribution but there's no CI validation of NSIS syntax. A linting workflow would catch installer configuration errors before releases.

• [ ] Create .github/workflows/validate-nsis.yml workflow
• [ ] Add NSIS syntax validation step using a linter (e.g., nsis-lint or similar tool)
• [ ] Configure the workflow to run on: pull requests modifying package/NSIS/** files
• [ ] Link the workflow to the build-for-distribute.yml to ensure installer builds are validated

Document DLSS/FSR/XeSS DLL compatibility matrix and add validation tests

The project handles three different graphics upscaling technologies (DLSS, FSR, XeSS) but there's no documented compatibility matrix or validation of supported versions. This would help contributors understand version constraints and prevent broken releases.

• [ ] Create docs/compatibility-matrix.md documenting supported versions for each technology
• [ ] Add a compatibility validator tool in extras/ (similar to InNeedOfTranslationDetector) to test DLL versions
• [ ] Document the DLL format specifications in docs/how-it-works/dll-specifications.md
• [ ] Add integration tests that validate actual DLL files from known versions

• Add automated test coverage for game library detection logic (Steam, GOG, Epic paths)—currently no test files visible; create xUnit or NUnit tests for LibraryDetection or GamePath resolution modules.
• Improve documentation for the DLL version comparison and compatibility matrix—docs/how-it-works/readme.md exists but could detail which DLSS/FSR/XeSS versions are compatible with which games.
• Build a Linux/Proton compatibility guide or issue tracker since current codebase is Windows-only (WPF) but gaming on Proton is growing; could document workarounds or plan cross-platform architecture.

The DLSS Swapper project shows a reasonable security posture for an open-source tool managing game DLL files. Primary concerns are: (1) inclusion of pre-compiled binaries without visible verification mechanisms, (2) native C code requiring security review, and (3) missing responsible disclosure documentation. The project uses standard .NET and build tools but lacks explicit dependency lock files and security policies. No obvious hardcoded credentials, injection vulnerabilities, or critical misconfigurations were detected in the visible file structure. Recommended improvements focus on transparency, verification mechanisms, and establishing a security reporting process.

• Medium · Potential Insecure Binary Usage in NSIS Installer — package/NSIS/FindProcDLL.dll, package/NSIS/plugins/x86-ansi/FindProcDLL.dll, package/NSIS/plugins/x86-unicode/FindProcDLL.dll. The NSIS installer package includes pre-compiled DLL files (FindProcDLL.dll) without visible source code or verification checksums. These binaries could potentially be compromised or outdated, and there is no clear mechanism to verify their integrity. Fix: Verify the source and integrity of all third-party binaries. Consider: (1) Publishing checksums (SHA256) for all distributed binaries, (2) Rebuilding binaries from source when possible, (3) Adding binary verification steps to the build pipeline, (4) Documenting the origin and version of each binary.
• Medium · C Code Security Review Required — extras/RTSSHooksCompatibility/RTSSHooksCompatibility.c. The codebase includes native C code (RTSSHooksCompatibility.c) which is inherently more vulnerable to memory safety issues. Without visible review comments or security practices, there may be risks such as buffer overflows, memory leaks, or injection vulnerabilities. Fix: Conduct a thorough security review of the C code. Implement: (1) Static analysis tools (e.g., clang-analyzer, Coverity), (2) Memory safety checks, (3) Bounds checking on all buffer operations, (4) Input validation for any external data, (5) Consider using safer alternatives or wrapper functions.
• Low · Missing Security Policy Documentation — Repository root. No visible SECURITY.md or security policy file found in the repository. This makes it difficult for security researchers to responsibly report vulnerabilities. Fix: Create a SECURITY.md file documenting: (1) How to report security vulnerabilities responsibly, (2) Expected response timeframes, (3) Disclosure policy, (4) GPG key for encrypted communications (if applicable).
• Low · PowerShell Script Execution Risk — package/NSIS/create_nsh_file_list.ps1, extras/SortTranslations/sort.ps1. Build scripts use PowerShell (e.g., create_nsh_file_list.ps1, sort.ps1) without visible execution policy documentation. PowerShell scripts can be vulnerable to script injection if inputs are not properly validated. Fix: Review all PowerShell scripts for: (1) Input validation, (2) Use of -NoProfile and -ExecutionPolicy Restricted flags, (3) Removal of any dangerous cmdlets like Invoke-Expression, (4) Documentation of required execution policies.
• Low · Dependency Management Visibility — nuget.config, DLSS Swapper.sln. nuget.config is present but no clear lock file (packages.lock.json) or comprehensive dependencies listing is visible for the .NET projects. This makes supply chain security harder to track. Fix: Implement: (1) Commit lock files (packages.lock.json) to version control, (2) Enable package signature verification in nuget.config, (3) Use software composition analysis (SCA) tools in CI/CD, (4) Regularly scan for vulnerable dependencies using tools like OWASP Dependency-Check or Snyk.

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.