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/azerothcore/azerothcore-wotlk 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
• 12 active contributors
• Distributed ownership (top contributor 32% of recent commits)
• GPL-2.0 licensed
• CI configured
• Tests present
• ⚠ GPL-2.0 is copyleft — check downstream compatibility

_{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 azerothcore/azerothcore-wotlk repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/azerothcore/azerothcore-wotlk.

What it runs against: a local clone of azerothcore/azerothcore-wotlk — 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 azerothcore/azerothcore-wotlk | 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 ≤ 30 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "azerothcore/azerothcore-wotlk(\\.git)?\\b" \\
  && ok "origin remote is azerothcore/azerothcore-wotlk" \\
  || miss "origin remote is not azerothcore/azerothcore-wotlk (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 "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "acore.json" \\
  && ok "acore.json" \\
  || miss "missing critical file: acore.json"
test -f ".github/workflows/core-build-pch.yml" \\
  && ok ".github/workflows/core-build-pch.yml" \\
  || miss "missing critical file: .github/workflows/core-build-pch.yml"
test -f "apps/compiler/compiler.sh" \\
  && ok "apps/compiler/compiler.sh" \\
  || miss "missing critical file: apps/compiler/compiler.sh"
test -f ".github/CONTRIBUTING.md" \\
  && ok ".github/CONTRIBUTING.md" \\
  || miss "missing critical file: .github/CONTRIBUTING.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/azerothcore/azerothcore-wotlk"
  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).

AzerothCore is a complete open-source MMO server emulator and framework written in C++ that runs World of Warcraft: Wrath of the Lich King compatible game servers. It provides a fully modular C++ core engine, database schema, game logic, and scripting system to host private MMORPG servers with 26.7M lines of C++ codebase backed by CI/CD pipelines for Windows, macOS, Linux, and Docker. Core monolithic structure: root CMakeLists.txt orchestrates the build, .devcontainer/docker-compose.yml defines containerized dev environment, src/ holds the C++ engine (likely game world, network, database layers), modules/ directory (implied by core_modules_build.yml workflow) contains pluggable game systems, sql/ schema files manage database, and tools/ contains utility binaries. PreLoad.cmake and acore.sh suggest a custom build bootstrapper.

C++ game developers and server administrators who want to run self-hosted WoW:WotLK private servers or develop MMO server infrastructure; contributors interested in game engine architecture, network protocols, and database-driven game systems; and community members building game content (quests, dungeons, PvP systems) via the modular scripting system.

Actively developed with multiple passing CI workflows (core-build-nopch, core-build-pch, windows/macos/linux/docker builds all shown with badges), strong governance (CODEOWNERS, CODE_OF_CONDUCT.md, SECURITY.md), 2.1M+ commits visible, and organized issue templates for crash/game/BTA tracking. This is production-ready for private server operators but carries the legal/maintenance burden of game server emulation.

Large monolithic C++ codebase (26.7M lines) creates high maintenance surface area; requires careful database migrations and server compatibility testing across WoW patches; single core team dependency risk mitigated by community but still active governance needed; breaking changes to core APIs affect downstream modules and private server forks heavily.

CI/CD actively enforced across 8 parallel build workflows (nopch/pch variants, Windows, macOS, Linux, Docker, tools, modules, dashboard); codestyle checks via codestyle.yml workflow; SQL codestyle enforcement; module build testing; dashboard CI integration. GitHub Actions automation shows continuous integration discipline with PR labeling, project automation, and pending import workflows.

Clone: git clone https://github.com/azerothcore/azerothcore-wotlk.git && cd azerothcore-wotlk. Build: Run ./acore.sh (shell script in root) or use CMake directly: mkdir build && cd build && cmake .. && make. Dev container: code . in VSCode with devcontainer extension to spin up the docker-compose environment defined in .devcontainer/. See .vscode/tasks.json for configured build tasks.

Daily commands:

1. Execute ./acore.sh in repository root (shell bootstrap script). 2. Or manual CMake: mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Release .. && cmake --build . --config Release. 3. Database setup required (schema in sql/ directory—needs MySQL/MariaDB running). 4. Configure worldserver/authserver via config files (implied, typically in conf/ directory post-build). 5. Start: ./bin/worldserver and ./bin/authserver. Dev container: Open in VSCode with devcontainer extension for one-command setup.

• CMakeLists.txt — Root build configuration defining the entire C++ compilation pipeline, compiler flags, and dependency resolution for the MMO server core.
• acore.json — Central configuration manifest for the AzerothCore project, defining module structure, build parameters, and feature flags.
• .github/workflows/core-build-pch.yml — Primary CI/CD pipeline validating core compilation with precompiled headers on every commit; defines build standards.
• apps/compiler/compiler.sh — Main build orchestration script that handles configuration, compilation, and installation of the entire AzerothCore stack.
• .github/CONTRIBUTING.md — Developer onboarding guide documenting coding standards, PR workflow, and module architecture expectations.
• PreLoad.cmake — CMake initialization file that sets up the build environment, detects platform/compiler, and loads core dependencies before main compilation.

Add a New Module to the Build System

1. Register module in the central project manifest with build flags and dependencies (acore.json)
2. Create CMakeLists.txt in your module directory to define source files and compilation rules (CMakeLists.txt)
3. Update the global CMakeLists.txt to include your module's subdirectory via add_subdirectory() (CMakeLists.txt)
4. Add module-specific compiler flags or dependencies in PreLoad.cmake if needed (PreLoad.cmake)

Implement Database Schema Changes

1. Create migration SQL script in the appropriate database schema directory (apps/DatabaseSquash/DatabaseSquash.sh)
2. Update version metadata using VersionUpdater to track schema state (apps/DatabaseSquash/VersionUpdater/VersionUpdater.sh)
3. Configure database initialization in CI to apply migrations (apps/ci/ci-conf-db.sh)

Fix Code Style Issues and Prepare for Merge

1. Run C++ formatter validation to identify style violations (apps/codestyle/codestyle-cpp.py)
2. Apply autoformat rules and verify against .editorconfig standards (.editorconfig)
3. Verify no suppression rule violations in static analysis (.suppress.cppcheck)
4. Trigger codestyle CI workflow to validate before pushing (.github/workflows/codestyle.yml)

Set Up Local Development Environment

1. Open project in VS Code and use the dev container to initialize environment (.devcontainer/devcontainer.json)
2. Run acore.sh interactive menu to configure build options and install dependencies (acore.sh)
3. Execute compiler.sh to perform full build with selected options (apps/compiler/compiler.sh)
4. Review CONTRIBUTING.md for coding standards before making changes (.github/CONTRIBUTING.md)

• CMake (C++) — Cross-platform build abstraction for heterogeneous OS targets (Windows, macOS, Linux) with complex C++ compilation requirements
• GitHub Actions — Native CI/CD without external infrastructure; enables multi-platform matrix testing (Windows/macOS/Linux) in parallel
• Bash scripting (apps/compiler, apps/ci) — Portable automation for configuration, compilation orchestration, and environment setup across Unix-like systems
• Python utilities (codestyle, config-merger) — Cross-platform scripting for code validation, linting, and configuration merging without compiled dependencies
• Docker/Dev Containers — Reproducible development environment isolation eliminating 'works on my machine' issues across contributor systems

• CMake instead of direct compiler invocation

  • Why: Enables single source build definition for Windows/macOS/Linux with different compiler toolchains
  • Consequence: Adds configuration complexity; requires CMake knowledge from contributors; longer initial build setup

• Modular architecture with per-module CMakeLists.txt

  • Why: Allows selective compilation and independent module development; supports plugin-like architecture
  • Consequence: Distributed build configuration harder to debug; increased maintenance burden for consistency

• Precompiled headers (PCH) as optional build strategy

  • Why: Dramatically accelerates incremental builds for large codebases by caching common headers
  • Consequence: PCH introduces linker complexity and cache invalidation issues; requires two separate CI pipelines

• Bash-heavy automation over compiled tools

  • Why: Reduces build system dependencies; scripts are version-controllable and reviewable
  • Consequence: Shell scripts are harder to test, less performant, and platform-dependent (Unix-first)

• Does not provide cloud hosting or managed service deployment
• Does not include Web UI or REST API for server management (CLI-driven)
• Does not handle cross-version game client compatibility (WotLK expansion fixed)
• Does not provide automated game content generation or asset pipeline

Database dependency: worldserver/authserver require running MySQL/MariaDB instance with schema pre-applied from sql/ scripts—missing this causes immediate connection failures. Module loading: modules/ are CMake-configured at build time; adding a new module requires CMakeLists.txt edits and rebuild, not runtime injection. Precompiled headers (PCH): Two build variants exist (core-build-nopch vs core-build-pch)—PCH speeds builds but can cause stale cache issues if headers change; clean build may be needed. Configuration files: authserver.conf and worldserver.conf typically generated post-build in conf/ directory—paths are hardcoded; incorrect paths cause silent failures. Git hooks: .git_commit_template.txt suggests enforced commit message format—violating it may block commits. SQL migrations: sql/ changes require careful ordering; running migrations out of sequence breaks existing servers.

• Game Object Spawning & Respawn Timers — Core MMO mechanic: understanding how NPCs, items, and creatures are spawned in the world, managed in memory, and respawned on death is fundamental to modifying game behavior; AzerothCore uses database-driven spawn tables with in-memory caching.
• Realm vs Account Authentication Separation — WoW uses a split-server model: authserver validates credentials, worldserver manages gameplay. Developers must understand this boundary for account management, session tokens, and character transfers.
• Memory-Mapped Database Connection Pooling — With thousands of concurrent players, AzerothCore uses connection pools to reuse database sockets instead of creating new ones per query—critical for performance tuning and debugging deadlocks in SQL logs.
• Event-Driven Spell System — Spells, abilities, and item use flow through event hooks (SpellEffect, AuraApply, etc.) in modules; understanding the event dispatch order is essential for scripting combat without race conditions.
• Grid-Based World Partitioning — Azeroth world is divided into grids for culling and performance; objects only load/despawn when players cross grid boundaries. Critical for understanding player sync, NPC visibility, and lag.
• ScriptMgr Hook Registry Pattern — Modules register callbacks with ScriptMgr (likely a central event dispatcher) instead of modifying core files. This is the architectural pattern enabling modular game logic without monolithic entanglement.
• SQL Migration Versioning — sql/ directory uses timestamped migration files to evolve schema safely across server instances. Incorrect ordering or partial application breaks live servers; understanding the migration strategy is critical for database changes.

• MaNGOS/MaNGOS — Direct predecessor—AzerothCore is a fork of MaNGOS adding modular architecture, modern C++, and improved tooling for WoW emulation
• TrinityCore/TrinityCore — Alternative WoW server emulator using similar monolithic C++ approach but different architecture philosophy and active competing development
• azerothcore/azerothcore-modules — Official community module repository—separate org containing pre-built modules (transmog, eluna scripting, PvPMall) that extend core via plugin architecture
• azerothcore/azerothcore.github.io — Official documentation site—contains wiki, API docs, module development guides, and installation instructions referenced by README
• HerculesWS/Hercules — Alternative Ragnarok Online (not WoW) but same monolithic emulation architecture; useful for comparing game server design patterns

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 SQL code style validation to pre-commit hook workflow

The repo has .github/workflows/sql-codestyle.yml but no documented pre-commit hook setup in .git_commit_template.txt or pre-commit configuration. A new contributor could add a .pre-commit-config.yaml file that enforces SQL style checks locally before push, reducing CI failures and improving developer experience. This aligns with the existing sql-codestyle.yml workflow.

• [ ] Create .pre-commit-config.yaml at repo root with sql-codestyle hooks
• [ ] Add pre-commit installation instructions to .github/CONTRIBUTING.md
• [ ] Reference the hook setup in .git_commit_template.txt
• [ ] Test against existing SQL files in sql/ directory (if present)

Implement unit tests for apps/EnumUtils/enumutils_describe.py

The enumutils_describe.py tool exists but likely has no dedicated test coverage. This is a concrete utility with well-defined input/output that would benefit from pytest-based tests. This improves reliability of enum generation and prevents regressions in core build pipelines.

• [ ] Create tests/apps/EnumUtils/ directory with test_enumutils_describe.py
• [ ] Add unit tests covering enum parsing, description extraction, and output formatting
• [ ] Integrate test execution into .github/workflows/tools_build.yml
• [ ] Document test running in apps/EnumUtils/enumutils_describe.md

Add CMake configuration validation workflow for cross-platform builds

The repo has separate Windows, macOS, and Linux build workflows (.github/workflows/windows_build.yml, macos_build.yml, etc.) but no unified CMake configuration validation. A contributor could create a lightweight workflow that validates CMakeLists.txt syntax and checks for common cross-platform issues (missing dependencies, platform-specific flags) before running full builds, reducing CI time and catch errors early.

• [ ] Create .github/workflows/cmake-lint.yml using cmake --version and cmake --help-property-list validation
• [ ] Add cmakelint tool integration or manual checks for PreLoad.cmake and root CMakeLists.txt
• [ ] Reference specific CMake anti-patterns to check (hardcoded paths, missing EXPORT statements)
• [ ] Trigger on changes to CMakeLists.txt, PreLoad.cmake, and CMake-related dependencies

• Add unit tests for SQL migration validation: Create tests in a new tests/sql/ directory that verify all .sql files in sql/ parse correctly and migrations can be applied in sequence without conflicts—currently no validation visible.
• Document module creation template: Create a detailed example module in modules/mod_example_quest_giver/ with full scaffold (CMakeLists.txt, ScriptMgr hooks, SQL schema) and tutorial in wiki—onboarding friction is high for first-time module authors.
• Expand .vscode/launch.json with authserver debugging: Currently only worldserver is configured for debug; add separate launch configuration for authserver with proper breakpoints and variable inspection—enables debugging auth issues during local development.

AzerothCore shows moderate security concerns typical of large legacy game server projects. Key issues include potential SQL injection in database tools, shell script injection risks, missing SAST integration, and incomplete security documentation visibility. The CI/CD pipeline and Docker configurations require review. Positive aspects include: active maintenance, code style enforcement, community code of conduct, and defined issue templates. Immediate recommendations: enable automated dependency scanning, integrate SAST tools, audit database operations for SQL injection, review shell scripts for injection vulnerabilities, and document security policies comprehensively.

• High · Potential SQL Injection in Database Tools — apps/DatabaseSquash/DatabaseExporter/, apps/DatabaseSquash/VersionUpdater/. The presence of DatabaseSquash and VersionUpdater applications that handle SQL operations suggests potential SQL injection vectors. Shell scripts in apps/DatabaseSquash/ may construct SQL queries without proper parameterization. Fix: Review all SQL query construction in these tools. Implement parameterized queries and prepared statements. Avoid string concatenation for SQL commands. Add input validation and sanitization for all database operations.
• High · Shell Script Code Injection Risks — apps/bash_shared/, apps/ci/. Multiple bash scripts (common.sh, defines.sh, includes.sh, menu_system.sh) in apps/bash_shared/ and apps/ci/ execute system commands. These may be vulnerable to injection attacks if they accept user input without proper escaping. Fix: Implement strict input validation for all user-supplied variables. Use quoted variables consistently ("$var"). Avoid eval() and command substitution from untrusted input. Use shellcheck to validate bash scripts.
• High · Missing Security Policy Documentation — .github/SECURITY.md. While a SECURITY.md file exists, the content was not provided. Without visibility into the security policy, there may be gaps in vulnerability disclosure and incident response procedures. Fix: Ensure SECURITY.md contains: responsible disclosure procedures, supported versions for security updates, security contact information, and incident response timeline.
• Medium · Docker Configuration Without Security Review — .devcontainer/docker-compose.yml, .github/actions/docker-tag-and-build/. Docker configurations exist (.devcontainer/docker-compose.yml, .github/workflows/docker_build.yml) but their content was not provided. Docker containers may be running with excessive privileges or exposed ports. Fix: Review Docker configurations for: non-root user execution, minimal base images, exposed port restrictions, volume mount restrictions, and secret management practices.
• Medium · CI/CD Pipeline Security Exposure — .github/workflows/. Multiple GitHub Actions workflows handle compilation, building, and deployment. These workflows may expose secrets, build artifacts, or create supply chain attack vectors if not properly secured. Fix: Implement: branch protection rules, review requirements for CI changes, secret rotation policies, artifact retention policies, and signed commits for deployments.
• Medium · Missing Dependency Vulnerability Scanning — Project root configuration. No dependency scanning configuration (DEPENDABOT, Snyk, etc.) is visible in the file structure. For a large C++ project, this represents a gap in supply chain security. Fix: Enable GitHub's Dependabot or similar tools. Implement automated scanning of C++ dependencies, CMake files, and transitive dependencies. Review and update CMakeLists.txt dependencies regularly.
• Medium · Code Style Tools May Miss Security Issues — apps/codestyle/. Code style scripts (codestyle-cpp.py, codestyle-sql.py) focus on formatting rather than security. No static analysis security testing (SAST) tools are evident. Fix: Integrate SAST tools (clang-tidy, cppcheck with security rules, SonarQube). Run security analysis in CI/CD pipeline. Address all security warnings before merge.
• Low · Incomplete File Structure Analysis — src/, sql/, modules/. Core application code files were not provided in the partial file structure. This limits comprehensive security analysis of actual vulnerability patterns (SQL injection, buffer overflows, etc.). Fix: Perform detailed static code analysis on: database query construction, input validation, memory management, authentication/authorization logic, and cryptographic implementations.

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.