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/luanti-org/luanti 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
• 46+ active contributors
• Distributed ownership (top contributor 16% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

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

What it runs against: a local clone of luanti-org/luanti — 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 luanti-org/luanti | Confirms the artifact applies here, not a fork | | 2 | License is still Other | 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 luanti-org/luanti. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/luanti-org/luanti.git
#   cd luanti
#
# 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 luanti-org/luanti and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other 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 ".github/workflows/linux.yml" \\
  && ok ".github/workflows/linux.yml" \\
  || miss "missing critical file: .github/workflows/linux.yml"
test -f "android/app/build.gradle" \\
  && ok "android/app/build.gradle" \\
  || miss "missing critical file: android/app/build.gradle"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
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/luanti-org/luanti"
  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).

Luanti (formerly Minetest) is an open-source voxel game engine and mod platform written primarily in C++ (9.3MB) with embedded Lua scripting (1.1MB). It enables users to create and play sandbox voxel games with easy modding through a Lua API, shipping with a builtin mod system and client/server architecture that supports multiplayer gameplay. Monolithic engine structure: C++ core engine lives at root src/ level; Lua scripting embedded via C++/Lua bindings; builtin/ contains core game logic and libraries in Lua; client/shaders/ holds GLSL rendering code; android/ is a separate Gradle project for mobile; documentation in doc/ and .github/. Assets (textures, fonts) in textures/ and fonts/; modding documentation at docs.luanti.org referenced from README.

Game developers and modders who want to create voxel-based games without licensing constraints; server operators hosting community game instances; and players seeking Minecraft-like experiences with full mod support and source code access. Contributors range from C++ engine developers to Lua scripters authoring game mechanics.

Luanti is production-ready and actively maintained. The project has 9+ years of history (copyright 2010–2026), comprehensive CI/CD across 7+ platforms (.github/workflows/: linux.yml, windows.yml, macos.yml, android.yml, docker_image.yml), established governance (.github/CONTRIBUTING.md, SECURITY.md), and multiple build targets (CMake-based, Docker support via Dockerfile). Recent activity is strong with continuous commits and platform coverage.

Risk is moderate: the C++ core (9.3MB) is complex and architecture-critical, making large refactors difficult; Android support (Java layer in android/app/src/main/java/net/minetest) adds multi-platform maintenance burden. The Lua API surface is extensive, creating compatibility concerns for mods across versions. No obvious single-maintainer bottleneck visible in the structure, but large C++ codebase means contributions require significant expertise.

The project recently renamed from 'Minetest' to 'Luanti' (visible in .github, README.md references). Active CI workflows show ongoing work across Android (android.yml), C++ linting (.clang-tidy, cpp_lint.yml), Lua validation (lua.yml, .luacheckrc), PNG asset checks, and Docker image generation. Multiple platform targets (Linux, Windows, macOS, Android) indicate parallel development.

Clone and build: git clone https://github.com/luanti-org/luanti.git && cd luanti && mkdir build && cd build && cmake .. && make -j$(nproc). Requires C++17 compiler, CMake 3.13+. For Android: use Gradle in android/ folder with NDK setup (see android/app/build.gradle). For server-only: CMake without GUI dependencies.

Daily commands: Desktop (Linux/macOS): cd build && cmake .. && make && ./minetest or cpack for installer. Windows: cmake -G "Visual Studio 16 2019" .. && cmake --build .. Android: cd android && ./gradlew assembleDebug (outputs APK in android/app/build/outputs/apk/). Server-only: ./minetest --server.

• CMakeLists.txt — Master build configuration for the entire C++ codebase across all platforms (Linux, Windows, macOS, Android); defines compilation flags, dependencies, and module structure
• .github/workflows/linux.yml — Primary CI/CD pipeline for Linux builds; validates compilation and test suite on the default platform
• android/app/build.gradle — Android NDK/Gradle build configuration; integrates C++ engine with Android SDK and manages native library compilation
• README.md — Authoritative documentation covering compilation, configuration, and version scheme; required reading for all contributors
• .github/CONTRIBUTING.md — Contributor guidelines defining code standards, PR expectations, and community norms

• CMakeLists.txt (Build Orchestrator) (CMake 3.x, compiler toolchains (GCC/Clang/MSVC)) — Detects OS/compiler, configures compiler flags, links dependencies (SDL2, OpenGL, Zlib, etc.), generates platform-specific build files
  • Failure mode: Missing dependency or toolchain detected during config; build fails before compilation starts
• C++ Game Engine (Core Loop) — undefined

Add support for a new platform (e.g., WebAssembly, iOS)

1. Add new CMake build configuration for the target platform in CMakeLists.txt (e.g., iOS toolchain, Emscripten settings) (CMakeLists.txt)
2. Create a new GitHub Actions workflow file following the pattern of .github/workflows/linux.yml for CI/CD on the new platform (.github/workflows/new_platform.yml)
3. For mobile platforms, create platform-specific Java/Kotlin activity and SDL bridge similar to android/app/src/main/java/net/minetest/minetest/GameActivity.java (android/app/src/main/java/net/minetest/minetest/GameActivity.java)
4. Add platform-specific build documentation to README.md under the Compiling section (README.md)

Add a new static analysis or code quality check to the CI pipeline

1. Define linter rules or configuration (e.g., .clang-tidy for C++ or .luacheckrc for Lua) (.clang-tidy)
2. Create or update a GitHub Actions workflow to run the linter on every push and PR (.github/workflows/cpp_lint.yml)
3. Document the new check in CONTRIBUTING.md so developers understand the requirement (.github/CONTRIBUTING.md)

Add support for a new locale/language translation

1. Add a new locale-specific strings.xml file in android/app/src/main/res/values-XX/ (where XX is the language code) (android/app/src/main/res/values-fr/strings.xml)
2. Register the locale in the Weblate translation platform (referenced in README.md translation badge) (README.md)
3. Update GitHub Actions workflows if needed to test the new locale in android.yml (.github/workflows/android.yml)

• C++ (CMake build system) — Core engine requires high performance for voxel rendering, physics, and networking; cross-platform portability across desktop and mobile
• Lua scripting (mods and games) — Mod API allows game creators and players to extend/customize without recompiling engine; interpreted language lowers barrier to entry
• SDL2 (cross-platform I/O) — Abstracts windowing, input, and rendering across Linux, Windows, macOS, Android with single codebase
• Android NDK + Gradle — Bridges Java/Kotlin Android framework to native C++ engine for mobile ports; manages native library linking and APK packaging
• GitHub Actions + CMake presets — Automated multi-platform CI/CD ensures code quality and binary availability; CMake presets provide reproducible builds

• Lua mod API over C++ plugins

  • Why: Reduces compilation friction and improves accessibility for game creators
  • Consequence: Some mod performance-critical code may run slower than native C++; mod incompatibility during engine updates possible

• Single CMake build vs. separate per-platform build systems

  • Why: Reduces maintenance burden and ensures feature parity across platforms
  • Consequence: CMake complexity grows; platform-specific optimizations (e.g., Metal on macOS) must fit into unified system

• Android via SDL2 + JNI vs. full Kotlin rewrite

  • Why: Reuses desktop C++ codebase; minimal Android-specific code
  • Consequence: SDL2 abstractions may lose platform-specific optimizations; JNI overhead for frequent Java callbacks

• Not a real-time multiplayer MMO platform (server architecture is optional, not built-in)
• Not a graphics engine for film/VFX (voxel rendering prioritizes gameplay over cinematic quality)
• Not a Windows-only or single-platform application (supports Linux, Windows, macOS, Android, WebAssembly)

Android NDK version: build.gradle pins ndkVersion via properties; local.properties must exist with correct keystore paths for release builds. Lua version: Minetest uses Lua 5.1, not 5.3+; some modern Lua features unavailable. Asset paths: prepareAssets task in build.gradle copies files from projRoot (parent directory) into Android assets; build fails silently if files missing. Unsupported languages: android/build.gradle filters translations via unsupported_language_list.txt to reduce APK size. Shader compatibility: Irrlicht shaders in irr/media/Shaders/ must be compatible with older GLSL versions; modern features may break on older devices. CMake presets: CMakePresets.json defines default configurations; users unfamiliar with CMake presets may bypass them and hit unexpected defaults.

• Voxel chunk system — The engine's core data structure — chunks divide infinite voxel space into manageable blocks for rendering, physics, and serialization; understanding chunk boundaries, LOD, and network streaming is critical for engine and mod development
• Lua C API and bindings — Luanti's mod system and game logic are written in Lua but executed via C++ bindings; understanding stack-based Lua C API calls (lua_push*, lua_to*) is essential for extending engine functionality or debugging mod/engine mismatches
• Client-server architecture with custom protocol — Luanti uses a bespoke binary protocol (not HTTP/WebSocket) for multiplayer communication between game clients and servers; understanding packet structure, ordering guarantees, and bandwidth optimization is needed for network code and mod interaction
• GLSL shader pipeline with Irrlicht abstraction — Graphics are controlled via GLSL shaders (client/shaders/), but abstracted through Irrlicht's material system; rendering customization requires knowledge of both shader code and Irrlicht's driver API
• Android JNI (Java Native Interface) bridge — Mobile builds wrap the C++ engine in Java via JNI (android/app/src/main/java/net/minetest/minetest/GameActivity.java); platform-specific features like input handling, lifecycle management, and permissions require understanding this bridge
• Content registration and mods loader — Games and mods register content (blocks, items, entities, crafting recipes) via Lua during initialization; the mod discovery, load order, and registration API (in builtin/) directly affects what content is available at runtime and how mods interact
• CMake multi-target build system with presets — The build spans 4+ platforms (Linux, Windows, macOS, Android) with different dependency trees and output formats (executables, installers, APKs); CMake presets (CMakePresets.json) and platform-specific logic in CMakeLists.txt are critical for understanding how to add new build targets or dependencies

• valvesoftware/source-engine — Source engine is a predecessor voxel-agnostic game engine; Luanti evolved as an open alternative with a focus on voxel-based sandbox gameplay
• VoxelEngine/VoxelEngine — Competing voxel game engine using similar C++ architecture; useful for comparing rendering and mod API design approaches
• dcongnd/minetest-docker — Community Docker setup for Luanti/Minetest servers; directly relevant for cloud deployment of this engine
• lua/lua — Official Lua repository; Luanti embeds Lua 5.1 and all script APIs depend on core Lua interpreter and C API
• irrlicht-engine/irrlicht — Irrlicht is the rendering backend used by Luanti (irr/media/Shaders/); understanding its texture formats and shader pipeline is essential for graphics work

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 GitHub Actions workflow for Android APK validation and security scanning

The repo has android.yml workflow but it lacks post-build validation steps. Currently there's no automated scanning for APK signing issues, duplicate classes, or missing native libs before release. This prevents catching build problems early and ensures release artifacts are valid before distribution.

• [ ] Create .github/workflows/android_apk_validation.yml that runs after android.yml completes
• [ ] Add steps to validate APK signatures using apksigner (Android SDK tool)
• [ ] Add MobSF scanning or bundletool analysis to detect common APK issues (missing ABIs, version mismatches)
• [ ] Add artifact hash generation and verification to prevent tampering
• [ ] Reference the new workflow in existing android.yml via workflow_run trigger
• [ ] Document the validation process in .github/CONTRIBUTING.md

Add unit tests for Lua API bindings validation in src/lua_api/

The repo has .luacheckrc for linting and lua.yml CI workflow, but there's no automated testing suite for validating that Lua API bindings (e.g., core functions exposed to mods) maintain backward compatibility across versions. This is critical since mod developers depend on stable APIs.

• [ ] Create src/lua_api/tests/ directory with CMake test integration
• [ ] Add test cases for all public Lua API functions documented in doc/lua_api.txt
• [ ] Test function signatures, return values, and error handling for core functions (minetest.register_node, minetest.add_entity, etc.)
• [ ] Add regression tests for previously-fixed API bugs
• [ ] Integrate tests into CMakeLists.txt and add to lua.yml CI workflow
• [ ] Document API testing process in CONTRIBUTING.md

Add PNG integrity validation workflow for texture asset files

The repo has png_file_checks.yml workflow but it only does whitespace/metadata checks. Given the large texture asset base in textures/ and Android asset preparation in android/app/src/main/res/drawable/, there's no automated validation for PNG corruption, dimension consistency, or metadata bloat that could inflate APK size or cause rendering issues.

• [ ] Extend .github/workflows/png_file_checks.yml to validate PNG integrity using tools like pngcheck or ImageMagick
• [ ] Add checks for unexpected PNG color modes (should be RGBA for game textures) or bit depths
• [ ] Add dimension validation rules (e.g., all node textures should be 16x16, 32x32, etc.) in textures/ directory
• [ ] Add metadata stripping verification to prevent bloated files in APK asset preparation
• [ ] Add size regression detection to fail if texture changes inflate asset bundle by >5%
• [ ] Document texture submission guidelines in CONTRIBUTING.md with specific format requirements

• Add unit tests for the Lua C++ bindings in src/script/lua_api/ — the codebase has extensive Lua integration but minimal test coverage visible in the file list; start with testing a single API function like lua_register_*
• Document the voxel coordinate system and chunk format in doc/developing/ — the core rendering and physics depend on voxel space transformations but docs are sparse; write a guide with examples covering block positions, chunk boundaries, and face indices
• Improve Android build error messages in android/app/build.gradle — the prepareAssets task silently fails if source files are missing; add validation with clear error messages pointing to missing builtin/, shaders/, or fonts/ directories

The Luanti codebase shows moderate security posture with several concerning issues. The primary vulnerabilities relate to insecure credential handling in build configuration, lack of integrity verification for external dependencies, and outdated Android API targets. The Dockerfile's unrestr

• High · Insecure Credential Storage in Gradle Build File — android/app/build.gradle. The Android build configuration loads keystore credentials from local.properties file which may be committed to version control or exposed. Passwords are stored in plain text in properties files, creating a credential exposure risk. Fix: Use Android Keystore system or environment variables for sensitive credentials. Never commit local.properties to version control. Add to .gitignore and use secure credential management systems (e.g., GitHub Secrets, Gradle properties encryption).
• High · Unrestricted External URL Fetching in Dockerfile — Dockerfile - Lines with ADD https://github.com/. The Dockerfile uses ADD with raw git URLs without hash verification or pinning. This allows potential man-in-the-middle attacks or injection of malicious code from external repositories (prometheus-cpp, libspatialindex, luajit). Fix: Use COPY with pre-verified source code or pin to specific git commit hashes. Implement checksum verification for downloaded dependencies. Use git@github.com: SSH URLs with known hosts verification instead of HTTPS for better authentication.
• Medium · Missing Build Integrity Verification — Dockerfile - ADD commands and subsequent RUN build commands. External dependencies (prometheus-cpp, libspatialindex, luajit) are downloaded and built without signature verification or checksums. No integrity checks are performed on the downloaded source code. Fix: Implement GPG signature verification for downloaded repositories. Pin to specific commit hashes. Use checksums (SHA256) to verify downloaded files. Consider using a private package repository or vendoring dependencies.
• Medium · Outdated Android SDK Compilation Target — android/app/build.gradle - compileSdk and targetSdkVersion settings. The build configuration uses compileSdk 34 with targetSdkVersion 35. While these are relatively recent, regular updates are needed to address security patches and API deprecations. Fix: Keep compileSdk and targetSdkVersion updated with the latest Android API levels. Monitor Android Security & Privacy Year in Review for required security updates.
• Medium · Minimal SDK Version at 21 May Expose to Vulnerabilities — android/app/build.gradle - minSdkVersion setting. minSdkVersion 21 (Android 5.0.1) is significantly outdated and lacks many security features available in newer Android versions, including hardened memory allocator, CFI, and other exploit mitigations. Fix: Increase minSdkVersion to at least 24 (Android 7.0) or higher. This removes support for devices lacking modern security features and reduces the attack surface.
• Medium · Missing Security Hardening in Docker Base Image — Dockerfile - ARG DOCKER_IMAGE=alpine:3.23. Alpine 3.23 base image may contain unpatched vulnerabilities. No explicit security scanning or hardening is applied to the base image before building dependencies. Fix: Use specific Alpine version tags (not just 3.23). Implement regular security scanning with tools like Trivy or Grype. Add security.txt and vulnerability disclosure policy. Consider using slim or distroless images where possible.
• Low · Missing HTTPS Verification in Asset Preparation — android/app/build.gradle - prepareAssets() task. The prepareAssets task reads files from disk without explicit permission checking. If the build environment is compromised, asset files could be modified. Fix: Implement file integrity checks (checksums) for copied assets. Use read-only file permissions where applicable. Add signature verification for critical asset files.
• Low · Insufficient Logging and Monitoring Configuration — Dockerfile and build.gradle. No explicit security event logging or monitoring configuration visible in the build scripts. Build artifacts and intermediate files are not explicitly secured. Fix: Implement build audit logging. Use docker BuildKit security scanning. Add integrity verification for all build outputs. Implement container image scanning in CI/CD pipeline.

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.