Contributor guides
Start by building the checkout and selecting the Minecraft target you want to edit. Read the architecture before changing a compiler, native runtime or game boundary, then choose verification that exercises the affected behavior.
Work on the project
- Build and run Toolchains, Minecraft targets, and the standalone playground.
- All-addon dev stand Run Create, Sable, Propulsion, and Aeronautics together.
- Maintain addons Standalone builds, integration boundaries, and lifecycle tests.
- Publish releases Validate tagged artifacts and publish or recover a release.
- Verification Choose focused checks and understand release gates.
Understand the internals
- Architecture Compiler, native runtime, actor host, and ownership.
- Module and package guide Put changes in the layer that owns their behavior.
- Native test coverage Find evidence at Rust, FFI, JVM, and game boundaries.
Measure performance
- In-world VM benchmarks Profile the server cost of real and headless computers.
- Performance reports Recorded workloads, measurements, and optimization evidence.
Maintain the documentation
Player guides explain how to use the mod; developer topics own exact Guest language/library contracts and their evidence; architecture pages own implementation boundaries. Dated performance reports describe their recorded revisions and are not current support matrices. Update the owning page with a behavior change instead of copying its contract into several guides.
Wiki pages use layout: default, a descriptive title, and the appropriate section (players, developers or
contributors). Preserve existing permalink values so published links remain stable. Add discoverable guides to
docs/_data/navigation.yml and detailed reports to the performance index. Use relative Markdown links for source
pages and Liquid relative_url links for site routes; avoid hardcoding the deployed site address for internal links.
Keep code examples complete and distinguish development features from published releases through the changelog.
The Pages workflow builds
release and nightly documentation from separate revisions, including generated Guest API and IDE palette assets.
Run python3 -m unittest discover -s docs/_tools -p 'test_versioned_docs.py' after changing version composition.
Check local link targets and navigation against the source pages; these source checks and versioning tests do not
replace a Jekyll rendering check or establish that external sites are available.
Repository workflow
Follow the repository’s working guidelines. Use GitHub issues for reproducible bugs and architectural work. Include the relevant verification commands and results with a change; visible UI changes benefit from screenshots.