Build from source

Meridian’s source repository is private during early development. The workflow below records what public source users should expect after release; it is not available to anonymous users today.

Before the source release

The engine, integrated creator application, named subsystem details, current maturity, and architecture remain documented on this site. Cloning, building, and contributing begin when the repository opens under MIT or Apache-2.0.

After release, you will need Git, Rustup, the repository’s pinned Rust toolchain, and the native build tools expected by your platform.

Planned clone step

git clone <public Meridian repository URL>
cd meridian

When source access opens, Project Meridian will not be part of the checkout. The ignored game/ path is a boundary for a separate private repository, not a missing public submodule.

Confirm the workspace

cargo metadata --locked
cargo run -p meridian-spec -- check

The metadata command confirms that Cargo can resolve the pinned workspace. The specification check validates governance records and links that code changes are expected to respect.

Run the core gates

cargo fmt --all -- --check
cargo test --workspace
cargo clippy --workspace --all-targets -- -D warnings

These commands can take time. Start with the package you changed, then run broader gates before claiming repository-wide compatibility.

Try bounded smokes

The repository readme lists current smoke commands. They exercise different boundaries; a headless run, a native window, and an offscreen capture do not prove the same thing. Read the command’s evidence contract before treating a pass as visual or platform qualification.

If a command fails

Record the exact command, source revision, platform, toolchain, and first real failure. Do not replace an unavailable native surface with a silent skip. Unsupported or unavailable is useful evidence when it is reported precisely.