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/cabaletta/baritone 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 6w ago
• 8 active contributors
• Distributed ownership (top contributor 47% of recent commits)
• LGPL-3.0 licensed
• CI configured
• Tests present
• ⚠ LGPL-3.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 cabaletta/baritone repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/cabaletta/baritone.

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

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

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

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

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

# 4. Critical files exist
test -f "src/api/java/baritone/api/BaritoneAPI.java" \\
  && ok "src/api/java/baritone/api/BaritoneAPI.java" \\
  || miss "missing critical file: src/api/java/baritone/api/BaritoneAPI.java"
test -f "src/api/java/baritone/api/IBaritone.java" \\
  && ok "src/api/java/baritone/api/IBaritone.java" \\
  || miss "missing critical file: src/api/java/baritone/api/IBaritone.java"
test -f "src/api/java/baritone/api/behavior/IPathingBehavior.java" \\
  && ok "src/api/java/baritone/api/behavior/IPathingBehavior.java" \\
  || miss "missing critical file: src/api/java/baritone/api/behavior/IPathingBehavior.java"
test -f "src/api/java/baritone/api/cache/ICachedWorld.java" \\
  && ok "src/api/java/baritone/api/cache/ICachedWorld.java" \\
  || miss "missing critical file: src/api/java/baritone/api/cache/ICachedWorld.java"
test -f "forge/src/main/java/baritone/launch/BaritoneForgeModXD.java" \\
  && ok "forge/src/main/java/baritone/launch/BaritoneForgeModXD.java" \\
  || miss "missing critical file: forge/src/main/java/baritone/launch/BaritoneForgeModXD.java"

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

Baritone is a pathfinding and automation bot for Minecraft that acts as 'Google Maps for the block game'—it calculates efficient routes through complex terrain, manages inventory, and automates repetitive tasks like mining and building. It supports Minecraft versions 1.12.2 through 1.21.3 across both Forge and Fabric modloaders, with sophisticated A* pathfinding integrated directly into the client. Modular Gradle project with buildSrc/ containing custom Gradle tasks (CreateDistTask, ProguardTask) for distribution and obfuscation. Separate modules for forge/ and fabric/ implement mod entry points (BaritoneForgeModXD.java, fabric.mod.json). Core pathfinding logic resides in the implicit src/ tree; the build system auto-detects Minecraft versions via Unimined plugin. Source code split between API/core and version-specific adapters.

Minecraft players and modders who want autonomous navigation and task automation; speedrunners and vanilla survival players seeking efficiency without writing custom mods; mod developers integrating pathfinding into larger client-side utilities.

Production-ready and actively maintained. The project has substantial star count and maturity evidenced by support across 11 Minecraft versions, comprehensive CI/CD via GitHub Actions (gradle_build.yml, run_tests.yml), and a detailed FEATURES.md documentation. Code structure and multi-version support indicate years of development; the presence of Dockerfile, ProguardTask.java for obfuscation, and deterministic builds (Determinizer.java) shows production-grade tooling.

Low risk for core stability but moderate complexity: the codebase is 1.5M+ lines of Java with multi-version compatibility constraints (supporting 1.12.2 to 1.21.3 requires adapter code for breaking MC changes). Single primary maintainer pattern typical of hobbyist mods; LGPL-3.0 + 'anime exception' license is non-standard and may complicate commercial use. No evidence of supply-chain risk from external dependencies given the Gradle setup.

Active development with recent CI configuration (GitHub Actions workflows) and support for MC 1.21.3 (latest badge in README). The project maintains version detection from git tags and commits (gradle.properties reference to mod_version and automatic git describe versioning). No specific PR/issue data visible, but the presence of issue templates (bug.md, question.md, suggestion.md) and PR template indicates ongoing contributor engagement.

git clone https://github.com/cabaletta/baritone.git
cd baritone
./gradlew build

For development, use ./gradlew runClient (inferred from Gradle + Minecraft mod convention); consult SETUP.md and USAGE.md in the repo root for detailed instructions and configuration.

Daily commands:

./gradlew build          # Compile all versions
./gradlew forge:build    # Build Forge mod only
./gradlew fabric:build   # Build Fabric mod only
./gradlew runClient      # Run integrated client (requires Minecraft installation)

Built .jar files are output to build/libs/ in each module. Consult USAGE.md for in-game command syntax.

• src/api/java/baritone/api/BaritoneAPI.java — Main API entry point that all integrations depend on; defines how external code interfaces with Baritone's pathfinding and navigation system
• src/api/java/baritone/api/IBaritone.java — Core interface defining Baritone instance contract, including behaviors, settings, and world data access that every implementation must satisfy
• src/api/java/baritone/api/behavior/IPathingBehavior.java — Abstraction for the pathfinding algorithm—the heart of Baritone's navigation engine
• src/api/java/baritone/api/cache/ICachedWorld.java — World caching interface that stores and retrieves block data to enable efficient pathfinding across large areas
• forge/src/main/java/baritone/launch/BaritoneForgeModXD.java — Forge mod loader entry point; bootstraps Baritone into the Minecraft environment
• build.gradle — Multi-version Minecraft build configuration; defines how Baritone compiles against different MC versions and mod loaders
• src/api/java/baritone/api/Settings.java — Global configuration schema that controls all pathfinding parameters, goals, and behavioral tuning

Add a new pathfinding goal

1. Create a class implementing IGoal in the api/goal package (referenced by IPathingBehavior) (src/api/java/baritone/api/behavior/IPathingBehavior.java)
2. Register the goal type in the command system or Settings to make it accessible (src/api/java/baritone/api/Settings.java)
3. Implement goal heuristic and block matching logic in your IGoal subclass (src/api/java/baritone/api/behavior/IPathingBehavior.java)

Add a new chat command

1. Create a class extending Command in the impl/command package (src/api/java/baritone/api/command/Command.java)
2. Implement execute(), onLiteralCommandSyntaxException(), and argument consumption logic (src/api/java/baritone/api/command/argument/IArgConsumer.java)
3. Register command in ICommandSystem and define custom argument parsers if needed (src/api/java/baritone/api/command/ICommandSystem.java)

Add a new behavior

1. Create an interface extending IBehavior in src/api/java/baritone/api/behavior (src/api/java/baritone/api/behavior/IBehavior.java)
2. Implement onTick() to hook into the main game loop (src/api/java/baritone/api/behavior/IBehavior.java)
3. Register the behavior with IBaritone.getBehaviorStatus() and IBaritone.getBehaviors() (src/api/java/baritone/api/IBaritone.java)

Add caching for a new data type

1. Create an interface extending ICachedRegion to define the new cached data (src/api/java/baritone/api/cache/ICachedRegion.java)
2. Implement serialization/deserialization in the cache directory (src/api/java/baritone/api/cache/ICachedWorld.java)
3. Hook the data populator into IWorldScanner to scan and cache during world exploration (src/api/java/baritone/api/cache/IWorldScanner.java)

• Java with Gradle — Minecraft modding standard; Gradle enables multi-version and multi-loader builds (Forge, Fabric)
• Interface-based API (src/api/) — Decouples public contract from implementation; allows swapping pathfinding algorithms and loading Baritone into different Minecraft versions
• Cache-based world storage (ICachedWorld, ICachedRegion) — Minecraft worlds are too large to pathfind in real-time; caching enables instant lookups and long-distance navigation
• Chat command system (ICommandSystem) — Provides user-friendly in-game control without external GUIs or overlays

• Single API module split from implementation modules per loader

  • Why: Provides clear contract for end-users but increases maintenance burden (must sync API changes across implementations)
  • Consequence: Easier to understand the public API, harder to coordinate breaking changes

• Synchronous A pathfinding on main game thread*

  • Why: Simpler integration with Minecraft's tick system; avoids race conditions on world data
  • Consequence: Can cause frame stutters on long-distance pathfinding; limits CPU cores utilization

• Persistent disk-based cache for explored regions

  • Why: Enables resuming navigation across server restarts; reduces repeated scanning
  • Consequence: Disk I/O latency; cache invalidation issues if world changes

• Real-time multiplayer simulation or PvP anti-cheat evasion
• Automatic farm/base building (only navigation)
• GUI beyond in-game chat commands
• Support for modded blocks without manual datatype configuration

Version skew: the project requires Java toolchain matching sourceCompatibility (JavaLanguageVersion.of()); Unimined plugin auto-downloads Minecraft server JARs and mappings (can be slow on first build). Git tag versioning is mandatory—if git describe fails, it falls back to gradle.properties mod_version, which may cause version mismatches. ProGuard configuration is implicit and regenerated on each build; modifying Baritone's public API requires careful ProGuard rule updates. Minecraft's obfuscation changes between versions require version-specific adapter code not visible in this file list.

• A* Pathfinding Algorithm — Core to Baritone's pathfinding engine; understanding heuristic cost functions and open-set management is essential for optimizing movement in complex terrain
• Mixin Bytecode Injection — Baritone hooks into Minecraft client code via Mixins (evident from fabric.mod.json and Forge setup) to intercept player movement and render events without forking Minecraft itself
• Multi-Version Minecraft Compatibility — Supporting 11 MC versions (1.12.2–1.21.3) requires managing breaking API changes; the Unimined plugin handles this via version-specific source sets and remapping—critical for long-term maintenance
• ProGuard Obfuscation & Minification — Baritone uses ProGuard (ProguardTask.java) to shrink and obfuscate the compiled mod for distribution; understanding ProGuard rules is needed when adding new public APIs or dependencies
• Deterministic Builds — The Determinizer.java strips timestamps and other non-reproducible data from JARs; ensures distributed builds produce bit-identical artifacts for security and verification
• Gradle Multi-Module Projects — Baritone uses a root build.gradle with submodules (forge/, fabric/, buildSrc/) allowing shared configuration and independent version targeting; essential for understanding the build pipeline
• Behavior Trees (implicit in automation) — Baritone automates complex actions (mining, building, navigation chains) using composable task/behavior structures; understanding node-based task composition helps when extending bot capabilities

• MeteorDevelopment/meteor-client — Alternative Minecraft client-side utility framework with similar multi-version support and Fabric/Forge dual-loading; direct competitor for automation tasks
• PorkStudios/ExampleMod — Minimal Forge/Fabric template using Unimined (same build plugin as Baritone); useful reference for modloader integration patterns
• minecraft-dev/MinecraftDev — IntelliJ plugin for Minecraft development; most Baritone contributors use this for IDE setup and Mixin debugging
• FabricMC/fabric — Fabric modloader core; Baritone depends on Fabric API and mappings for fabric/ module builds
• MinecraftForge/MinecraftForge — Forge modloader core; provides the foundation for Baritone's forge/ module and bytecode transformation hooks

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 pathfinding core algorithms in src/main/java/baritone/pathing

Baritone is a pathfinding/navigation mod, but the .github/workflows/run_tests.yml workflow exists with no corresponding test suite visible in the file structure. The pathing logic is critical to the project's core functionality. Adding JUnit tests for pathfinding algorithms (cost calculations, block interactions, path validation) would catch regressions early and make contributions safer. This aligns with the existing CI/CD setup.

• [ ] Create src/test/java/baritone/pathing directory structure mirroring src/main
• [ ] Add JUnit 4 dependency to build.gradle if not present
• [ ] Write tests for BlockStateInterface, PathNode, and path cost calculations
• [ ] Ensure run_tests.yml GitHub Action executes these tests
• [ ] Document test execution in SETUP.md or CONTRIBUTING.md (if it exists)

Add behavior API documentation and examples for src/api/java/baritone/api/behavior

The file structure shows src/api/java/baritone/api/behavior exists, indicating Baritone has a plugin/behavior system. However, USAGE.md and FEATURES.md don't appear to document how to extend Baritone with custom behaviors. This is a high-value contribution for attracting plugin developers. The behavior API is the extension point for the entire ecosystem.

• [ ] Review existing behavior interfaces in src/api/java/baritone/api/behavior
• [ ] Create docs/BEHAVIOR_API.md documenting the behavior lifecycle and interfaces
• [ ] Add 2-3 concrete example behaviors (e.g., CustomMiningBehavior) in docs/examples/
• [ ] Link from USAGE.md and README.md to the new behavior documentation
• [ ] Include code snippets for registering and configuring custom behaviors

Implement Fabric and Forge build validation in GitHub Actions

The repo has both fabric/ and forge/ subdirectories with separate build.gradle files, but .github/workflows/gradle_build.yml likely only tests the main build. Multi-loader projects need validation that both loader implementations compile and pass tests independently. This prevents silent breakage in either loader branch and improves contributor confidence.

• [ ] Inspect current .github/workflows/gradle_build.yml to confirm it skips fabric/forge
• [ ] Add matrix strategy to gradle_build.yml with jobs for :fabric:build and :forge:build
• [ ] Ensure both jobs run against multiple Java versions from gradle.properties
• [ ] Add separate test steps for each loader (e.g., :fabric:test, :forge:test)
• [ ] Document loader-specific build instructions in SETUP.md

• Add unit tests for the A* pathfinding algorithm (currently no test files visible in buildSrc or forge/fabric modules); create src/test/java/baritone/pathfinding/AStarTest.java with test cases for open-terrain, obstacle avoidance, and cost heuristics.
• Document the Gradle build system setup in SETUP.md—specifically how to configure ProGuard rules for custom commands and how the Determinizer.java ensures reproducible builds; many contributors are confused by the buildSrc/ custom tasks.
• Add examples/ directory with sample Baritone scripts (e.g., automated mining, base building, navigation chains) and corresponding CLI command documentation; currently USAGE.md exists but lacks runnable examples.

The Baritone codebase shows reasonable security posture for an open-source Minecraft mod project. Key concerns are: incomplete Gradle configuration syntax, lack of version pinning in Docker/dependencies, execution of unverified scripts (gradlew), and absence of explicit security policies. The project uses HTTPS for repositories and includes proper licensing. No evidence of hardcoded secrets, SQL injection, or XSS vulnerabilities in the provided file structure. Recommended improvements focus on build process hardening, dependency management, and establishing security disclosure procedures.

• Medium · Incomplete Repository URL in Gradle Configuration — build.gradle (lines 45-47). The Maven repository configuration in build.gradle is incomplete. The 'impactdevelopment-repo' URL declaration is missing the closing brace, which could lead to build failures or unexpected dependency resolution behavior. Fix: Complete the repository configuration by adding the missing closing brace: '}'.
• Medium · Insecure HTTP Repository URLs — build.gradle (repository definitions). The Gradle build configuration uses HTTP URLs for Maven repositories (e.g., 'https://impactdevelopment.github.io/maven/'). While HTTPS is used here, ensure all repository URLs consistently use HTTPS to prevent man-in-the-middle attacks during dependency downloads. Fix: Verify all Maven repository URLs use HTTPS. Consider implementing repository pinning and checksum verification for critical dependencies.
• Low · Git Command Execution in Build Script — build.gradle (lines 26-31). The build.gradle file executes git commands directly ('git describe --always --tags --first-parent --dirty'.execute()) without input validation or error handling. This could be exploited if the repository is compromised. Fix: Add proper exception handling, validate command output, and consider using the gradle-git-version plugin instead of executing shell commands directly.
• Low · Permissive Java Version Configuration — build.gradle (lines 33-39). The Gradle build uses dynamic Java version detection and toolchain configuration. While flexible, this could lead to unexpected behavior if the build environment changes without explicit version pinning. Fix: Consider explicitly pinning the Java version required for this project rather than relying on dynamic detection.
• Medium · Dockerfile Using Non-LTS Ubuntu Base Image — Dockerfile (lines 1-6). The Dockerfile uses 'ubuntu:focal' (20.04) which is not an LTS release for extended support. Additionally, it performs an unattended apt update without pinning package versions, which could introduce unexpected changes. Fix: Use 'ubuntu:jammy' (22.04) or newer LTS image. Pin specific package versions: 'apt install openjdk-17-jdk=17.*...' and add 'apt clean' to reduce image size.
• Medium · Unrestricted Build Execution — Dockerfile (line 15). The Dockerfile executes './gradlew build' without any verification of the gradlew script integrity. The gradlew wrapper could be compromised to execute malicious code. Fix: Verify the gradlew script checksum before execution. Consider regenerating the wrapper with a known-good version: 'gradle wrapper --gradle-version X.Y.Z'. Alternatively, use system gradle if available.
• Low · Missing .gitignore Review — .gitignore (file not shown). While a .gitignore file exists, without visibility into its contents, there's a risk that sensitive files (keys, credentials, configuration) could be committed. Fix: Review .gitignore to ensure it excludes: *.key, *.pem, *.env, *.local, gradle.properties (if containing secrets), and IDE-specific sensitive files.
• Low · Public Repository without Security Policy — Repository root. While a CODE_OF_CONDUCT.md exists, there's no visible SECURITY.md or security disclosure policy for reporting vulnerabilities responsibly. Fix: Create a SECURITY.md file documenting how security vulnerabilities should be reported privately (e.g., via email) before public disclosure.

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.