chore: align release branching and nightly tagging flow

[willkill07]

Overview

Align the release branching workflow, nightly alpha tagging, and version bump tooling so release branches can keep receiving nightly tags while main moves forward.

• I confirm this contribution is my own work, or I have the right to submit it under this project's license.
• I searched existing issues and open pull requests, and this does not duplicate existing work.

Details

• Add .github/nightly-alpha-branches.yaml as the configured source for branches that receive nightly alpha tags.
• Update .github/workflows/nightly-alpha-tag.yaml to fan out over the configured branches, check out each branch, derive the nightly tag version from that branch's own Cargo.toml, and tag that branch HEAD.
• Update just set-version so release version bumps include both Node npm packages: nemo-flow-node and nemo-flow-openclaw, plus their package-lock.json workspace entries.
• Update RELEASING.md with code-freeze steps, release-branch PR targeting guidance, release-tag branch guidance, nightly-tag cleanup guidance, and OpenClaw npm release surface details.
• Add the prepare-code-freeze repo-local skill and update update-project-version skill guidance so future agents follow the same code-freeze and package-versioning process.

Where should the reviewer start?

Start with RELEASING.md for the intended release process, then review .github/workflows/nightly-alpha-tag.yaml and justfile for the behavior that implements the process.

Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)

• Relates to: none

Summary by CodeRabbit

• Documentation
  • Added code-freeze and release-branch workflows, clarified release commit/tagging steps, and expanded release playbook to include OpenClaw as a published surface with packaging/publishing guidance.
• Chores
  • Made nightly-alpha tagging branch-aware with remote tag verification and matrixed tagging.
  • Ensured release tooling updates npm package versioning across relevant package surfaces for consistent releases.

[coderabbitai]

Walkthrough

Extends the release infrastructure to version and publish the OpenClaw npm package (nemo-flow-openclaw) as a first-class artifact. Adds multi-branch nightly alpha tagging, updates the release playbook with a code freeze workflow, and documents the versioning process through skill documentation.

Changes

Release Infrastructure and Automation

Layer / File(s)	Summary
Dual-package npm version tooling justfile	set_node_package_versions helper applies npm version updates to both crates/node and integrations/openclaw; set_project_version now calls this helper.
Multi-branch nightly alpha tagging .github/nightly-alpha-branches.yaml, .github/workflows/nightly-alpha-tag.yaml	Adds a branches config file; workflow loads branches and runs the tag job as a matrix, injects NEMO_FLOW_NIGHTLY_BRANCH, computes target_sha, verifies remote tag state, and pushes branch-specific nightly-alpha tags.
Release playbook expansion RELEASING.md	Adds nemo-flow-openclaw to published surfaces, requires OpenClaw manifest alignment with release versions, adds a Code Freeze section and release-branch tagging guidance, and extends packaging/publishing/verification steps to include OpenClaw.
Code freeze automation skill .agents/skills/prepare-code-freeze/SKILL.md	New skill documents end-to-end code-freeze preparation: determine release version/branch, create/push release/<x.y>, prepare PR branch, update nightly-alpha config, bump versions with just set-version, validate, and open a PR targeting main with guardrails.
Project version skill update .agents/skills/update-project-version/SKILL.md	Updates skill docs to include integrations/openclaw/package.json in source-of-truth guidance, extend just set-version targets, reference set_node_package_versions, and include OpenClaw in validation searches and references.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	Title follows Conventional Commits format with 'chore' type and provides a concise, imperative summary under 72 characters.
Description check	✅ Passed	Description includes all required template sections: Overview with checklist confirmation, Details of changes, reviewer start guidance, and Related Issues reference.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[dagardner-nv]

Overall good, just questions about the git remote names

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.agents/skills/prepare-code-freeze/SKILL.md:
- Around line 1-7: Add an SPDX HTML comment header to the top of this Markdown
file (SKILL.md / name: prepare-code-freeze) per the repo guideline for
HTML/Markdown files; insert an HTML comment block as the very first lines
containing the SPDX license tag (e.g., "SPDX-License-Identifier: Apache-2.0")
and any required copyright/holder text so the file includes the required SPDX
header in HTML comment syntax.

In `@RELEASING.md`:
- Around line 140-165: After running the version helper (just set-version
<release-version>) ensure the release-prep steps explicitly include refreshing
Cargo.lock and regenerating attribution files: run cargo check --workspace to
update Cargo.lock after workspace version changes and then run the
scripts/generate_attributions.sh rust and scripts/generate_attributions.sh node
to regenerate ATTRIBUTIONS-Rust.md and ATTRIBUTIONS-Node.md when Cargo metadata
or package-lock.json changed so the release PR includes updated lockfile and
attribution outputs.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: 50a3e805-ac98-4f37-9d9a-2abce366a389

📥 Commits

Reviewing files that changed from the base of the PR and between f8fa218 and 823abfd.

📒 Files selected for processing (2)

• .agents/skills/prepare-code-freeze/SKILL.md
• RELEASING.md

📜 Review details

🧰 Additional context used

📓 Path-based instructions (15)

**/*.{md,rst,html,txt}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-brand-terminology.md)

**/*.{md,rst,html,txt}: Always spell NVIDIA in all caps. Do not use Nvidia, nvidia, nVidia, nVIDIA, or NV.
Use an NVIDIA before a noun because the name starts with an 'en' sound.
Do not add a registered trademark symbol after NVIDIA when referring to the company.
Use trademark symbols with product names only when the document type or legal guidance requires them.
Verify official capitalization, spacing, and hyphenation for product names.
Precede NVIDIA product names with NVIDIA on first mention when it is natural and accurate.
Do not rewrite product names for grammar or title-case rules.
Preserve third-party product names according to the owner's spelling.
Include the company name and full model qualifier on first use when it helps identify the model.
Preserve the official capitalization and punctuation of model names.
Use shorter family names only after the full name is established.
Spell out a term on first use and put the acronym in parentheses unless the acronym is widely understood by the intended audience.
Use the acronym on later mentions after it has been defined.
For long documents, reintroduce the full term if readers might lose context.
Form plurals of acronyms with s, not an apostrophe, such as GPUs.
In headings, common acronyms can remain abbreviated. Spell out the term in the first or second sentence of the body.
Common terms such as CPU, GPU, PC, API, and UI usually do not need to be spelled out for developer audiences.

Files:

• RELEASING.md

**/*.{md,rst,html}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-brand-terminology.md)

Link the first mention of a product name when the destination helps the reader.

Files:

• RELEASING.md

**/*.{md,rst,txt}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)

**/*.{md,rst,txt}: Spell NVIDIA in all caps. Do not use Nvidia, nvidia, or NV.
Format commands, code elements, expressions, package names, file names, and paths as inline code.
Use descriptive link text. Avoid raw URLs and weak anchors such as 'here' or 'read more.'
Use title case consistently for technical documentation headings.
Introduce code blocks, lists, tables, and images with complete sentences.
Write procedures as imperative steps. Keep steps parallel and split long procedures into smaller tasks.
Prefer active voice, present tense, short sentences, contractions, and plain English.
Use can for possibility and reserve may for permission.
Use after for temporal relationships instead of once.
Prefer refer to over see when the wording points readers to another resource.
Avoid culture-specific idioms, unnecessary Latinisms, jokes, and marketing exaggeration in technical documentation.
Spell out months in body text, avoid ordinal dates, and use clear time zones.
Spell out whole numbers from zero through nine unless they are technical values, parameters, versions, or UI values.
Use numerals for 10 or greater and include commas in thousands.
Do not add trademark symbols to learning-oriented documentation unless the source, platform, or legal guidance explicitly requires them.
Do not add trademark symbols to NeMo Flow learning documentation by default.
Do not rewrite API names, package names, command flags, or code literals for style reasons.

Files:

• RELEASING.md

**/*.{md,markdown,rst}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-technical-docs.md)

**/*.{md,markdown,rst}: Use title case consistently in technical documentation headings
Avoid quotation marks, ampersands, and exclamation marks in headings
Keep product, event, research, and whitepaper names in their official title case
Use title case for table headers
Do not force social-media sentence case into technical docs
Use monospace formatting for code elements, commands, parameters, package names, and expressions
Use monospace formatting for directories, file names, and paths
Use angle brackets inside monospace for variables inside paths, such as /home/<username>/.login
Use quotation marks for error messages and strings in documentation
Use bold formatting for UI buttons, menus, fields, and labels in documentation
Use angle brackets between UI labels for menu paths, such as File > Save As
Use italics for new terms on first use in documentation
Use italics for publication titles in documentation
Use plain text formatting for keyboard shortcuts in documentation
Prefer [NVIDIA/NeMo](link) format for GitHub repository references over generic phrases like 'the GitHub repo'
Introduce every code block with a complete sentence
Do not make a code block complete the grammar of the previous sentence
Do not continue a sentence after a code block
Use syntax highlighting when the format supports it for code blocks
Avoid the word 'snippet' unless the surrounding docs already use it as a term of art
Keep inline method, function, and class references consistent with nearby docs, omitting empty parentheses for prose readability when no call is shown
Use descriptive anchor text that matches the destination title when possible for links
Avoid raw URLs in running text in documentation
Avoid generic link anchors such as 'here,' 'this page,' and 'read more' in documentation
Include the acronym in link text if a linked term includes an acronym
Do not link long sentences or multiple sentences in documentation
Avoid links that pull readers away from a procedure unles...

Files:

• RELEASING.md

**/*.{html,md}

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Include SPDX license headers in HTML and Markdown files using HTML comment syntax

Files:

• RELEASING.md

**/*.md

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Run Markdown link checking via lychee for README.md, CONTRIBUTING.md, and docs/ through pre-commit hooks

Files:

• RELEASING.md

**/*.{md,markdown,py,sh,bash,js,ts,java,cpp,go,rust}

📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)

Keep package names, repo references, and build commands current in documentation

Files:

• RELEASING.md

{RELEASING.md,CHANGELOG.md,docs/**/*.md}

📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)

Keep release-process and release-notes guidance in repo-maintainer docs such as RELEASING.md, not as user-facing docs pages or CHANGELOG.md

Files:

• RELEASING.md

**/*.{md,markdown,py,sh,bash}

📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)

Keep stable user-facing wrappers at scripts/ root in docs and examples; only point at namespaced helper paths when documenting internal maintenance work

Files:

• RELEASING.md

**/*.{md,markdown,py,sh,bash,js,ts,example}

📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)

Example commands must match current package names and paths

Files:

• RELEASING.md

{README*,CHANGELOG*,docs/**/*.{md,rst,txt},examples/**/*,*.md}

📄 CodeRabbit inference engine (.agents/skills/rename-surfaces/SKILL.md)

Update documentation, examples, and getting-started guides with new package/module/crate names after rename operations

Files:

• RELEASING.md

**/*.{md,txt,rst}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)

**/*.{md,txt,rst}: Ensure commands, package names, file paths, and APIs in documentation are correct and not stale; flag incorrect or outdated information as blocking issues
Ensure examples and procedures in documentation will execute successfully with current APIs and commands
Use consistent user-facing terminology throughout documentation that matches current repo terminology
Capitalize NVIDIA correctly in all documentation and public-facing text
Format code, commands, paths, and filenames as inline code (monospace) in documentation
Use descriptive anchor text for links instead of bare URLs or weak labels like 'here' in documentation
Prefer active voice, present tense, short sentences, and plain English in documentation
Structure documentation procedures as imperative steps that are easy to scan and not too long for a single sequence
Prefer 'after' instead of 'once' for temporal references in documentation
Use 'can' instead of 'may' when describing possibility (rather than permission) in documentation
Avoid ambiguous numeric dates and ordinal dates in documentation body text

Files:

• RELEASING.md

{RELEASING.md,CHANGELOG.md,docs/releases/**/*}

📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)

Reflect public packaging changes in release-facing documentation

Files:

• RELEASING.md

**/*.{py,js,ts,tsx,go,rs,md}

📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)

Format changed files with the language-native formatter before the final lint/test pass

Files:

• RELEASING.md

{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}

⚙️ CodeRabbit configuration file

{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}: Review documentation for technical accuracy against the current API, command correctness, and consistency across language bindings.
Flag stale examples, missing SPDX headers where required, and instructions that no longer match CI or pre-commit behavior.

Files:

• RELEASING.md

🧠 Learnings (1)

📓 Common learnings

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:18.987Z
Learning: Assume `upstream` is the NVIDIA repository remote (`NVIDIA/NeMo-Flow`) and `origin` remote can be a maintainer's personal fork

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:18.987Z
Learning: Run `just set-version <next-version>` to bump all release-versioned package surfaces on `main`

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:18.987Z
Learning: Do not create release tags during code freeze - only create the branch and the main PR

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:18.987Z
Learning: Do not target the code-freeze PR at the release branch - it must target `main`

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:18.987Z
Learning: Do not leave uncommitted user changes mixed into the code-freeze PR branch

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:33.366Z
Learning: Run `just set-version <version>` to update all release-version source files simultaneously: `Cargo.toml` workspace version, workspace dependency versions, `crates/node/package.json`, `integrations/openclaw/package.json`, and `package-lock.json` entries

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:33.366Z
Learning: When editing version helper code, keep `set_project_version`, `set_cargo_workspace_version`, and `set_node_package_versions` helper functions aligned with the version update fields, maintaining `set_node_package_version` as a compatibility alias and `set_npm_package_version` as a reusable npm JSON helper

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:33.366Z
Learning: Refresh `Cargo.lock` by running `cargo check --workspace` after making workspace package version changes

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:33.366Z
Learning: Regenerate `ATTRIBUTIONS-Rust.md` using `./scripts/generate_attributions.sh rust` when Cargo metadata changes and committed attribution files must stay fresh

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:33.366Z
Learning: Regenerate `ATTRIBUTIONS-Node.md` using `./scripts/generate_attributions.sh node` when `package-lock.json` changes

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:33.366Z
Learning: Rebuild the generated WebAssembly package with `just build-wasm` or `NEMO_FLOW_WASM_RELEASE=1 npm run build:pkg --workspace=nemo-flow-wasm` when the change needs WebAssembly publish validation, and inspect the generated `crates/wasm/pkg/package.json` rather than `crates/wasm/package.json`

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:33.366Z
Learning: Use ripgrep to audit remaining references to the old version in `Cargo.toml` with patterns `^version =|nemo-flow = \{ version =|nemo-flow-adaptive = \{ version =`, and separate true version pins from examples, generated attribution files, and unrelated third-party versions

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:33.366Z
Learning: Do not update only `Cargo.toml` or only Node package metadata; ensure version changes span all configured release surfaces

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:33.366Z
Learning: Do not assume `crates/wasm/package.json` is the published npm manifest for WebAssembly packages

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:33.366Z
Learning: Do not forget to update `Cargo.lock`, `ATTRIBUTIONS-Rust.md`, and `ATTRIBUTIONS-Node.md` after changing versioned inputs that feed them

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:33.366Z
Learning: Avoid doing blind repository-wide search/replace across docs, patches, and generated attribution files when updating versions

Learnt from: CR
Repo: NVIDIA/NeMo-Flow

Timestamp: 2026-05-13T18:05:33.366Z
Learning: Do not commit temporary non-release version suffixes set by `just package-node`, `just package-python`, and `just package-wasm` as the canonical project version unless the release process requires that exact string

🪛 LanguageTool

.agents/skills/prepare-code-freeze/SKILL.md

[uncategorized] ~39-~39: The official name of this software platform is spelled with a capital “H”.
Context: ...code-freeze-.. 5. Update .github/nightly-alpha-branches.yaml` to include...

(GITHUB)

---

[uncategorized] ~51-~51: The official name of this software platform is spelled with a capital “H”.
Context: ...`` 8. Open a PR targeting main using `.github/pull_request_template.md`. The PR mu...

(GITHUB)

🔇 Additional comments (2)

.agents/skills/prepare-code-freeze/SKILL.md (1)

20-63: LGTM!

RELEASING.md (1)

35-117: LGTM!

Also applies to: 123-124, 189-190, 205-210, 216-217, 233-235, 244-245, 266-267, 298-299

[willkill07]

/merge