Contributions are welcome.
Install the rum developer CLI once:
cargo run --bin rum -- repo cli installThat installs rum, installs shell completions for the detected shell, and uses your cargo bin directory, usually ~/.cargo/bin.
If that directory is not already on PATH, rum will print shell-specific fixups.
If you want rum to write the persistent PATH update for you:
cargo run --bin rum -- repo cli install --pathThen install the repo hooks:
rum repo hooks installThe canonical top-level command groups are:
rum verify fullfor the full GitHub CI verification suiterum verify ...for local and CI verification gatesrum vscode ...for VS Code extension workflowsrum wasm ...for wasm editor workflowsrum python ...for Python binding workflowsrum coverage ...for coverage generation, reporting, and gatingrum repo ...for hooks, completions, releases, graphs, policy helpers, and MSL reference-data maintenance
Typical local verification:
rum verify full
rum verify lint
rum verify workspace
rum verify quick
rum verify template-runtimesrum verify quick runs the same verification surface as GitHub CI except for
the slow 180-model MSL parity job. rum verify full includes that parity run.
Because those commands include coverage, VS Code, and wasm gates, they expect
the same local prerequisites that CI installs: cargo-llvm-cov, Node/npm, and
the wasm Rust target/tooling.
rum verify template-runtimes is for ignored example-template execution checks
that require optional runtimes such as Python with SymPy.
Editor validation:
rum vscode test
rum wasm testExtension packaging:
rum vscode build
rum vscode package --target linux-x64MSL/reference maintenance:
rum verify msl-parity
rum repo msl omc-reference
rum repo msl flamegraph --model Modelica.Electrical.Digital.Examples.DFFREG --mode compile
rum repo msl promote-quality-baselineCommand discovery:
rum help
rum help verify
rum help repo msl
rum help repo cli installFor compiler-affecting changes, follow:
spec/SPEC_0025_PR_REVIEW_PROCESS.mdspec/README.md
Project specifications live under spec/.
- Run the smallest verification gate that actually covers your change.
- Prefer
rumcommands over ad hoc local scripts so local and CI workflows stay aligned. - Keep contributor-facing command examples in docs synchronized with the actual CLI.
- Include a PR size budget in the pull-request body:
- production lines added/deleted,
- test lines added/deleted,
- net lines and file count,
- public API item delta.
- If the PR has positive net lines, include a short cleanup/compression pass plan and explicit rationale for every new abstraction.