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/cemu-project/Cemu 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.

GO — Healthy across the board

• Last commit today
• 19 active contributors
• Distributed ownership (top contributor 38% of recent commits)
• MPL-2.0 licensed
• CI configured
• ⚠ 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 cemu-project/Cemu repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/cemu-project/Cemu.

What it runs against: a local clone of cemu-project/Cemu — 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 cemu-project/Cemu | Confirms the artifact applies here, not a fork | | 2 | License is still MPL-2.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 ≤ 30 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MPL-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MPL-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is MPL-2.0" \\
  || miss "license drift — was MPL-2.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 "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "BUILD.md" \\
  && ok "BUILD.md" \\
  || miss "missing critical file: BUILD.md"
test -f "CODING_STYLE.md" \\
  && ok "CODING_STYLE.md" \\
  || miss "missing critical file: CODING_STYLE.md"
test -f ".github/workflows/build.yml" \\
  && ok ".github/workflows/build.yml" \\
  || miss "missing critical file: .github/workflows/build.yml"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

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

Cemu is a Wii U emulator written in C/C++ that reproduces the hardware behavior of Nintendo's Wii U console, enabling users to run most Wii U games and homebrew on Windows, Linux, and macOS. It's an actively maintained open-source project focused on accuracy and performance, with support for game-specific profiles stored in bin/gameProfiles/default/ (e.g., 0005000010101a00.ini for individual titles). Monolithic C++ application: core emulation logic resides in the root source tree, game profiles are data-driven via INI files in bin/gameProfiles/default/ keyed by game Title ID (hex format 000500...), and the build system uses CMake (CMakeLists.txt, CMakeSettings.json for MSVC). GitHub Actions workflows in .github/workflows/ handle CI/deployment; language strings are managed separately in a sister repo.

Game enthusiasts and developers who want to play Wii U titles on modern hardware; Linux/macOS users seeking cross-platform gaming support; emulation researchers and contributors interested in CPU/GPU cycle-accurate simulation; compatibility testers who file issues against the 300+ game profiles in the repo.

Production-ready for most games with active development: the project has open CI/CD workflows (build.yml, deploy_release.yml), a structured issue template system (emulation_bug_report.yaml, feature_report.yaml), and releases published to GitHub. The codebase is 12M+ lines of C++ with a CODING_STYLE.md enforced via .clang-format, suggesting established practices. However, macOS support is marked 'experimental' in the README with known MoltenVK/Rosetta performance issues.

Primary risk: heavy monolithic C++ codebase (11.9M lines) with complex hardware simulation makes refactoring and onboarding difficult. Secondary risks include reliance on third-party graphics packs (cemu_graphic_packs repo) for visual accuracy, language localization dependency (Cemu-Language repo), and potential single-maintainer bottleneck for a project of this scope. No visible test suite metrics in the file list, which is unusual for emulation code.

Active CI/CD with multiple workflows: build.yml runs on every commit, deploy_release.yml handles releases, and generate_pot.yml manages i18n. The project accepts pull requests and has a Discord/Matrix community for real-time developer coordination. Specific recent work is not visible in the file list, but the presence of organized issue templates (emulation_bug_report.yaml, feature_report.yaml) and a mature .clang-format config suggests ongoing quality control.

Clone the repo: git clone https://github.com/cemu-project/Cemu.git && cd Cemu. Read BUILD.md for platform-specific instructions (Windows/Linux/macOS differ significantly). Use CMake: mkdir build && cd build && cmake .. && cmake --build . (exact flags vary; see BUILD.md). No package.json present—this is pure CMake/C++, no npm/yarn.

Daily commands: No traditional 'dev server.' Instead: (1) cmake --build . --config Debug to build the emulator binary, (2) run ./Cemu or equivalent binary, (3) point the UI to a Wii U game ROM file. See BUILD.md for platform-specific binary locations and UI setup.

• CMakeLists.txt — Primary build configuration defining compilation targets, dependencies, and platform-specific settings for Windows, Linux, and macOS.
• BUILD.md — Essential documentation for building Cemu from source; every contributor must understand the build process before modifying core code.
• CODING_STYLE.md — Establishes code conventions and style guidelines that all contributors must follow to maintain consistency across the 600-file codebase.
• .github/workflows/build.yml — CI/CD pipeline that validates all commits; understanding this is critical for ensuring changes pass automated checks before merge.
• README.md — Primary entry point documenting Cemu's purpose as a Wii U emulator, supported platforms, and links to essential resources.

• CMake Build System (CMake 3.x, C/C++, platform-specific compilers) — Defines compilation targets, platform detection, dependency resolution, and optimization flags for cross-platform builds.
  • Failure mode: Build fails if dependencies are missing, incompatible flags used, or platform-specific code contains syntax errors.
• CPU Emulation Core (C/C++, JIT compilation, instruction translation) — Emulates PowerPC instruction set of Wii U CPU; translates/interprets guest instructions for host execution.
  • Failure mode: Game crashes or hangs if instruction semantics are incorrect or timing assumptions violated.
• GPU Emulation & Rendering (C/C++, Vulkan/DirectX/OpenGL, graphics shader compilation) — Translates Wii U GPU commands to host graphics APIs; handles texture formats, shaders, framebuffer operations.
  • Failure mode: Graphical artifacts, texture corruption, or rendering hangs if GPU command translation is incomplete or incorrect.
• Game Profile System (.ini file parsing, in-memory configuration storage) — Loads per-game .ini configuration files and applies emulation settings (CPU/GPU clocks, rendering options, workarounds).
  • Failure mode: Game runs with default settings if profile not found; incorrect profile may cause incompatibility or poor performance.
• System Integration Layer (C/C++, platform APIs (Windows, Linux, macOS), standard library) — Maps Wii U OS calls (file I/O, networking, controller input) to host system equivalents; abstracts platform differences.
  • Failure mode: Game I/O fails or controller input unresponsive if OS call mapping is missing or broken for specific platform.

• User → Cemu Launcher — User selects a Wii U game file (.wud, .wux, or decrypted image) and clicks 'Play'
• Cemu Launcher → Game Profile System — Launcher identifies game by title ID and loads matching .ini profile from bin/gameProfiles/default/
• Game Profile System → CPU/GPU Emulation Core — Profile settings (clock multipliers, rendering mode) are applied to emulation configuration
• Cemu → Wii U Game Executable — CPU emulator begins executing PowerPC instructions from game binary; GPU emulator translates graphics

Add Game-Specific Emulation Profile

1. Create a new .ini file in bin/gameProfiles/default/ named with the game's title ID (e.g., 000500001010ac00.ini) (bin/gameProfiles/default/)
2. Define game-specific settings such as rendering options, CPU/GPU clock adjustments, and workarounds for emulation quirks (bin/gameProfiles/default/0005000010101a00.ini)
3. Test the profile by loading the game in Cemu and verify settings are applied correctly (bin/gameProfiles/default/)

Modify Build Configuration

1. Edit CMakeLists.txt to add new source files, dependencies, or compilation flags for your platform (CMakeLists.txt)
2. Update .github/workflows/build.yml if your changes require new build steps or dependencies (.github/workflows/build.yml)
3. Test locally by running cmake configure and build, then validate in CI pipeline (CMakeLists.txt)

Add New Localization Strings

1. Add strings to the source code using the project's i18n API (.github/workflows/generate_pot.yml)
2. Run generate_pot.yml workflow to extract all translatable strings into .pot template (.github/workflows/generate_pot.yml)
3. Translators can then work with the generated template to provide localizations (.github/workflows/generate_pot.yml)

• C/C++ — High-performance language required for real-time CPU and GPU emulation of the Wii U with minimal overhead.
• CMake — Cross-platform build system enabling single codebase to compile on Windows, Linux, and macOS with platform-specific optimizations.
• GitHub Actions — Integrated CI/CD platform for automated multi-platform builds, testing, and release deployment on every commit.

• Single C/C++ codebase for Windows, Linux, and macOS

  • Why: Maximizes code reuse and maintainability across three platforms while minimizing duplication.
  • Consequence: Requires careful platform abstraction layers; platform-specific bugs may be harder to detect early.

• Game-specific .ini profiles instead of universal heuristics

  • Why: Allows fine-grained per-game tuning for compatibility and performance without affecting other titles.
  • Consequence: Requires manual profile creation for each game; does not scale automatically to unknown titles.

• Open-source codebase with community contributions

  • Why: Accelerates development and enables transparency; aligns with emulation community values.
  • Consequence: Requires robust code review, testing, and documentation to maintain quality and security.

• Does not emulate original Wii hardware; focuses exclusively on Wii U.
• Does not provide a graphical game installer; expects users to source games legally.
• Does not include proprietary Wii U firmware or bootloader; relies on user-provided system files.
• Not a real-time debugger; does not provide interactive runtime inspection of emulated CPU/GPU state.
• Not a compatibility layer for running unmodified Wii U executables on native systems; only emulation.

(1) Game profiles are stored by hex Title ID (e.g., 0005000010101a00.ini)—you must know a game's exact ID to create/modify its profile or changes won't apply. (2) macOS builds use MoltenVK (Vulkan→Metal translation) with documented performance degradation; ARM Mac (Rosetta 2) support is incomplete. (3) Build prerequisites vary by platform (see BUILD.md); missing a dependency silently fails CMake. (4) PR review requires understanding of game-specific behavior—just passing CI is insufficient; test against actual games. (5) Localization changes require updates to the separate Cemu-Language repo, not this one.

• PowerPC JIT Compilation — Cemu must translate Wii U PowerPC instructions to x86-64 at runtime for playable performance; understanding JIT caching and code invalidation is critical for CPU emulation work.
• Game Title ID (16-char hex identifier) — Cemu uses Title IDs (e.g., 0005000010101a00) as the unique key for per-game profile configuration in bin/gameProfiles/default/; you must know this format to work with game-specific fixes.
• Vulkan Graphics API with MoltenVK Translation Layer — Cemu uses Vulkan for GPU emulation on Windows/Linux and MoltenVK (Vulkan-to-Metal bridge) on macOS; understanding this abstraction is essential for graphics-related bugs and platform-specific issues.
• Cycle-Accurate Hardware Simulation — Cemu aims for accurate timing and behavior of Wii U CPU/GPU cycles to handle timing-sensitive games; this requires detailed knowledge of the actual Wii U hardware and can cause subtle bugs if approximated.
• Memory-Mapped I/O and Hardware Registers — Wii U peripherals (controllers, GPU, CPU) communicate via memory-mapped registers at fixed addresses; emulating this correctly is crucial for game compatibility.
• Cross-Platform Build Abstraction (CMake) — Cemu targets Windows, Linux, and macOS with platform-specific graphics APIs and dependencies; CMakeLists.txt and CMakeSettings.json abstract these differences—understand this to add features.
• Shader Compilation and GPU Driver Workarounds — Game profiles (*.ini files) contain GPU-specific flags and shader tweaks for driver compatibility; these workarounds are often game-specific due to differences in GPU architecture and driver bugs.

• cemu-project/cemu_graphic_packs — Official repository of GPU-level graphics enhancements (shaders, texture packs, resolution patches) that users pair with Cemu binaries to improve visual fidelity.
• cemu-project/Cemu-Language — Sister repository managing UI translations and localization strings via POT files generated by generate_pot.yml workflow; modify this to add language support.
• yuzu-emu/yuzu — Alternative Nintendo Switch emulator using similar C++ architecture and game profile system; relevant for learning emulation patterns and cross-referencing hardware simulation approaches.
• dolphin-emu/dolphin — Established GameCube/Wii emulator predecessor to Cemu concepts; codebase demonstrates mature CPU/GPU abstraction layers for console emulation in C++.
• RPCS3/rpcs3 — PlayStation 3 emulator using similar JIT-compilation and game-profile architecture; relevant for understanding how to handle complex console hardware in C++.

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 a game profiles validation and documentation system

The bin/gameProfiles/default/ directory contains 60+ .ini configuration files for individual games, but there's no documentation on the schema, valid options, or validation tooling. A new contributor could create a JSON schema file defining the .ini format, add a CI workflow to validate all existing profiles against this schema, and generate documentation for game profile configuration options. This would prevent profile corruption and help contributors add new profiles correctly.

• [ ] Create bin/gameProfiles/schema.json defining all valid .ini options and their types
• [ ] Add a Python/C++ validation script in a new tools/ directory to lint all .ini files
• [ ] Add a GitHub Action in .github/workflows/ to run profile validation on every PR
• [ ] Document the schema in a new bin/gameProfiles/README.md with examples

Add platform-specific build verification workflow

The repo supports Windows, Linux, and macOS, but the existing .github/workflows/build_check.yml likely doesn't comprehensively test all three platforms or all CMake configurations. A contributor could expand the CI to verify builds on all three platforms with different compiler versions (MSVC, GCC, Clang) and CMake configurations (Debug/Release), catching platform-specific compilation issues early.

• [ ] Examine current .github/workflows/build_check.yml and .github/workflows/build.yml to identify coverage gaps
• [ ] Create or expand .github/workflows/build_check.yml with a matrix strategy for [Windows/Linux/macOS] × [Debug/Release] × [compiler versions]
• [ ] Add platform-specific build flags from CMakeLists.txt to the workflow matrix
• [ ] Document build requirements per-platform in BUILD.md if missing

Implement clang-format enforcement in CI

The repo has .clang-format and CODING_STYLE.md, but no CI enforcement. A contributor could add a GitHub Action to check code formatting on all PRs, preventing style inconsistencies from merging. This is low-effort, high-value for maintainer quality-of-life.

• [ ] Add a new GitHub Action workflow .github/workflows/clang_format_check.yml
• [ ] Use clang-format to check all .cpp, .h, .c files against the existing .clang-format config
• [ ] Fail the check if formatting violations are detected and provide a helpful error message
• [ ] Add optional step to auto-fix formatting for contributor convenience (or document manual fixes in CODING_STYLE.md)

• Add unit tests for game profile INI parser: bin/gameProfiles/default/*.ini files lack visible test coverage—write a test suite in a new tests/gameProfiles/ directory that validates parsing logic for Title IDs, shader flags, and GPU workarounds.
• Expand gameProfiles documentation: create a bin/gameProfiles/README.md explaining the INI schema (what keys are valid, which games need which flags, how to add a new profile) since currently only example .ini files exist with no spec.
• Add GitHub Actions workflow for profile validation: create a .github/workflows/validate_profiles.yml that lints all .ini files in bin/gameProfiles/default/ for malformed entries (duplicate Title IDs, invalid hex, missing required keys)—currently no automated check exists.

Cemu is an established Wii U emulator project with active development (GitHub Actions CI/CD visible). Static analysis of the file structure reveals no hardcoded secrets, exposed credentials, or obvious misconfigurations. However, several security concerns warrant attention: (1) Lack of dependency vulnerability details prevents assessment of third-party risks; (2) Game profile configuration files lack apparent integrity validation; (3) Without source code review, memory safety and injection vulnerabilities in C/C++ code cannot be assessed; (4) No formal security policy/disclosure guidelines are evident. Recommendations include conducting comprehensive static code analysis, establishing a formal security disclosure process, implementing dependency scanning, and performing fuzzing tests on game file parsing. The moderate security score reflects the inability to fully assess critical areas due to incomplete information provided.

• Medium · Game Profile Configuration Files Without Integrity Validation — bin/gameProfiles/default/*.ini files. The repository contains numerous game profile configuration files (.ini) in bin/gameProfiles/default/. These files could potentially be modified to alter emulator behavior or inject malicious settings. No apparent integrity checking or code signing is visible in the file structure. Fix: Implement integrity verification (checksums/signatures) for game profile files. Consider loading profiles from read-only directories or with hash verification at runtime.
• Medium · Insufficient Visibility on Dependency Management — Dependencies management (CMakeLists.txt, .gitmodules). The .gitmodules file indicates submodule usage, but no detailed dependency file (package.json, requirements.txt, vcpkg.json, conanfile.txt) was provided for analysis. This makes it impossible to assess whether third-party dependencies contain known vulnerabilities. Fix: Provide comprehensive dependency inventory. Use automated tools like OWASP Dependency-Check or Snyk to scan for known vulnerabilities in all third-party libraries. Maintain an SBOM (Software Bill of Materials).
• Low · Limited Code Review Information — Source code files (not provided in analysis). While the file structure shows CI/CD workflows (.github/workflows/), without access to actual source code, injection vulnerabilities (SQLi, XSS, command injection), buffer overflows, and unsafe memory operations in C/C++ cannot be fully assessed. Fix: Perform static analysis using tools like: Clang Static Analyzer, SonarQube, Cppcheck, or AddressSanitizer. Implement mandatory code review processes focusing on security.
• Low · No Evidence of Security Policy or Disclosure Guidelines — Repository root. No SECURITY.md or security policy file is visible in the repository structure, which would typically outline vulnerability reporting procedures. Fix: Create a SECURITY.md file with responsible disclosure guidelines and a security contact email (security@cemu.info or similar).
• Low · Potential Game File Handling Risks — Source code handling game file parsing (not visible). As an emulator handling game files from untrusted sources, there may be risks from malformed game ROMs/images causing crashes or exploits. File format parsing vulnerabilities are common in emulators. Fix: Implement robust input validation for all game file formats. Use fuzzing (AFL, libFuzzer) to test file parsing with malformed inputs. Sandbox game file processing where possible.

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.