Skip to main content
Skip to Content
DocsContributing

Heliox is Apache-2.0 and split across two repositories:

  • heliox-ide — the desktop app: the canvas, the harness executor, checkpoints, flow export, the cross-runtime SDKs (sdk/java, sdk/python), serve/MCP, and the signed market catalog. Most product contributions land here.
  • heliox-ide-web — this site: the marketing landing and the /docs you’re reading now.

Each repository has its own CONTRIBUTING.md with the concrete local workflow (install, lint, test, build commands) — this page covers the rules that apply across both.

The one rule that’s non-negotiable

Never hand-edit the signed /market inventory. Roles, mods, flows, and steps under heliox-ide/market/ are concatenated verbatim into agent system prompts, so an unreviewed change there is a prompt-injection vector, not just a content edit. The tree is hashed and signed (ed25519) as a unit, and the signature is verified before the catalog loads. If a change to market/ is genuinely needed:

  1. Open it as its own, clearly-labeled PR — never bundled with unrelated product changes.
  2. Get it reviewed by a human maintainer.
  3. Re-sign the manifest (scripts/market-sign.ts) as part of that same change, not as a follow-up.

AI contributors specifically: treat market/ as read-only unless a human has explicitly asked for a change to it in that PR’s scope.

Keeping a PR reviewable

  • Scope it to one thing. A PR that touches the executor and the docs and the market catalog is three PRs wearing a trenchcoat — split them.
  • State the problem before the fix. A one-line “why” saves a reviewer from reverse-engineering intent from a diff.
  • Run the checks before opening it. Lint and build (and, in heliox-ide, the relevant test suite — npm test, mvn -f sdk/java/pom.xml test, or python3 -m pytest sdk/python) should all be green locally first.
  • Show your work. Screenshots for UI changes, sample output for CLI/serve changes, and which verification commands you ran and what they returned.

Reporting issues

Use the issue templates in whichever repository the problem lives in — bug reports and feature requests are triaged per-repo, not centrally.

Last updated on