Testing and Documentation

This page describes the validation and documentation checks expected for repository changes.

Testing Rule

Run tests for every language affected by your change. If you touch the core runtime, the expectation is broader because the bindings sit on top of the same behavior.

Run the affected targets directly:

$
just test-rust
$
$
# Run Rust tests with code coverage reporting, requires installing cargo-llvm-cov with `cargo install cargo-llvm-cov`
$
just ci=true test-rust
$
$
just test-python
$
just test-go
$
just test-node
$
just test-openclaw
$
just test-wasm

Use the matching build recipes when you need explicit build-only passes:

$
just build-rust
$
just build-python
$
just build-go
$
just build-node
$
just build-wasm

Common Commands

These commands cover the most common language-specific validation loops.

Rust

Run the Rust validation loop when a change touches the core runtime or Rust-facing API surface.

$
cargo test --workspace

Python

Run the Python validation loop when a change touches the wrapper package, tests, or docs tooling.

$
uv sync
$
uv run pytest

Node.js

Run the Node.js validation loop when a change touches the NAPI binding or JavaScript package surface. Run the OpenClaw target when Node changes can affect the OpenClaw plugin or when touching integrations/openclaw.

$
npm install --ignore-scripts
$
npm test --workspace=nemo-relay-node
$
just test-openclaw

Documentation Checklist

If your change affects public behavior, bindings, examples, or workspace structure, update the corresponding docs in the same branch.

Before opening a PR, confirm:

1. README.md still matches the repo structure
2. Relevant reference docs are updated for public API changes.
3. Relevant package or crate READMEs are updated when needed.
4. Examples and snippets stay aligned with supported bindings.
5. Docs build cleanly.

Docs Verification

Use these commands to validate the Fern documentation site after docs changes. They regenerate the ignored Python, Node.js, and Rust API reference pages before checking the Fern site, including links and navigation.

$
just docs-linkcheck
$
just docs

Fern Publishing

NeMo Relay uses a dual-branch Fern publishing model. Authors edit documentation on main in docs/ and fern/. The generated Fern content on docs-website is managed by CI and must not be edited by hand. The branch root .gitignore, README.md, and .github/workflows/publish-fern-docs.yml are branch-local maintenance files and can be updated directly on docs-website.

The Fern workflow uses the FERN_TOKEN GitHub environment secret from the fern environment. Pull-request branches under pull-request/** get Fern previews when docs change, and merged pull requests clean up their preview deployment. Pushes to main sync the generated fern/pages-dev/ layout to docs-website and publish the dev docs. Raw SemVer tags such as 0.1.0, 0.1.0-beta.1, and 0.1.0-rc.1 create public docs versions displayed with a leading v. Prerelease indicators are stripped from the public docs version path, so 0.1.0-beta.1, 0.1.0-rc.1, and 0.1.0 all target v0.1.0. Stable tags use availability: stable and update the default Latest version. Beta and release-candidate tags use availability: beta, replace the same base version snapshot, and do not update Latest. Alpha tags are not published.

The branch sync and version snapshot logic lives in scripts/docs/sync_fern_docs_branch.py.

Licensing and Headers

All source files must include SPDX headers and remain under Apache 2.0 expectations. Reviewers check this during normal review even when hooks do not enforce it automatically.