Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
106 lines (72 loc) · 2.75 KB

CONTRIBUTING.md

File metadata and controls

106 lines (72 loc) · 2.75 KB
Raw

Contributing to Omni

Before you start

Omni is an open source runtime under active debugging. Please do not assume a path is healthy only because it returns a response. A useful contribution is one that improves clarity, reproducibility, observability, or reliability.

Local setup

Prerequisites

  • Python 3.11+
  • Node.js >=24.15 <25
  • Rust toolchain

Install dependencies

npm install

Optional subproject installs:

pip install -r backend/python/requirements.txt
pip install -r omni-training/requirements.txt

Running locally

Run the Node-side tests:

npm run test:node

Run the Python-side tests:

npm run test:python

Run everything:

npm test

Run the Python entrypoint:

python backend/python/main.py

Run the Rust API:

cargo run --manifest-path backend/rust/Cargo.toml

Opening a pull request

Please keep PRs small and focused. Use the following branch naming convention:

  • feat/p5e-* — new features or phase items
  • fix/p5e-* — bug fixes
  • refactor/p5e-* — refactoring without feature changes
  • chore/p5e-* — CI, tooling, documentation

Never push directly to main. Always open a pull request and wait for CI to pass.

Recommended flow:

  1. Create a branch for one problem only.
  2. Add or update tests when behavior changes.
  3. Update documentation when the runtime behavior, contract, or repo structure changes.
  4. Explain what evidence you used to justify the change.

Contribution rules

  • Do not commit secrets, credentials, or local .env values.
  • Do not remove failing tests just to make CI green.
  • Do not hide degraded behavior behind vague success messaging.
  • Do not rewrite large runtime subsystems without evidence and scoped tests.
  • Prefer additive changes over breaking public contracts.
  • If a change affects Rust/Python/Node boundaries, mention that explicitly in the PR.

What areas need help

  • Rust/Python/Node runtime boundary debugging
  • execution-lane reliability
  • observability truthfulness
  • test coverage around real runtime paths
  • contributor onboarding and developer setup clarity
  • documentation cleanup and public-facing explanations

Good entry points

Expectations for tests

If you change behavior, run the most relevant tests you can locally and mention what you ran in the PR. If you cannot run a full validation, say what was skipped and why.