ci(release): add beta prerelease workflow

[clay-good]

What was missing: Fixes merged to main sit unreleased until the next stable cut — there's no way for users to opt into them earlier.

What it does: Adds a manually-dispatched beta job to the existing release workflow (release-prepare.yml) that cuts a beta prerelease from main:

• Version is the next stable version per pending changesets with a -beta.N suffix — today it would cut v1.6.0-beta.1, and N auto-increments on each cut.
• Publishes to npm under the beta dist-tag, so @latest is untouched and users opt in with npm install -g @fission-ai/openspec@beta.
• Tags the commit and creates a prerelease-flagged GitHub Release with auto-generated notes.
• Changesets are left unconsumed, and the stable prepare job is untouched apart from an event guard — the two flows can't trigger each other (prepare runs only on push, beta only on workflow_dispatch).

Why one workflow file: npm trusted publishing authorizes a single workflow file per package, and release-prepare.yml is already the registered publisher — so the beta job lives there and no npm settings change is needed. (Workflow display name is now Release since it does more than prepare; npm binds to the filename, which is unchanged.)

Proof it works: The version computation was dry-run locally against main's pending changesets (changeset status → 1.6.0 → v1.6.0-beta.1); the workflow YAML is validated. The publish step itself can only be proven by dispatching the workflow after merge.

Notes: Manual dispatch only for now — a nightly cron can be added later with a schedule trigger on the same job.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Added a manual beta release path that generates the next beta version, publishes prerelease builds with a beta dist-tag, and creates GitHub prereleases with updated installation notes.
• Chores
  • Updated release automation to use a simplified “Release” workflow, running on pushes to the main branch and supporting manual triggering.
• Bug Fixes
  • Tightened conditions so the standard release preparation step no longer runs during manual beta releases, avoiding duplicate release actions.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: d0d25dc7-2823-449c-9daa-fd775f8ffad7

📥 Commits

Reviewing files that changed from the base of the PR and between a2b42fc and 97b3599.

📒 Files selected for processing (1)

• .github/workflows/release-prepare.yml

🚧 Files skipped from review as they are similar to previous changes (1)

• .github/workflows/release-prepare.yml

---

📝 Walkthrough

Walkthrough

The release workflow is renamed and now runs on pushes to main plus manual dispatch. The prepare job is limited to push events, and a new beta job computes an unused beta version, publishes it to npm, tags it, and creates a GitHub prerelease.

Changes

Beta Release Workflow

Layer / File(s)	Summary
Workflow trigger rename and prepare job gating .github/workflows/release-prepare.yml	Workflow renamed and given push (main) plus workflow_dispatch triggers; prepare job condition now requires both repository match and push event.
Beta version computation, npm publish, and prerelease .github/workflows/release-prepare.yml	New beta job for workflow_dispatch checks out the repo, sets up Node/pnpm, derives the next beta version from Changesets status and existing -beta.N tags/releases, bumps version without git tagging, publishes to npm with beta dist-tag, then tags/pushes and creates a GitHub prerelease.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Workflow as Release workflow
  participant Changesets as changeset status
  participant npm as npm registry
  participant GitHub as Git tags and releases

  Workflow->>Changesets: read next stable version
  Workflow->>GitHub: probe existing beta tags and releases
  Workflow->>npm: check existing package versions
  Workflow->>npm: npm version --no-git-tag-version
  Workflow->>npm: npm publish --tag beta
  Workflow->>GitHub: create or skip v{version}-beta.N tag
  Workflow->>GitHub: create or skip prerelease

Loading

Possibly related PRs

• Fission-AI/OpenSpec#474: Both PRs modify .github/workflows/release-prepare.yml and affect release/versioning automation around Changesets-generated versions.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly matches the main change: adding a beta prerelease workflow to release automation.
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.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[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 @.github/workflows/release-beta.yml:
- Around line 60-61: The Set package version step is still interpolating
steps.version.outputs.version directly inside the shell command, which should be
hardened to match the later tagging step. Update the release-beta workflow so
this step receives the version through env as VERSION and then uses that
variable in the npm version command, keeping the shell parse phase free of
inline ${{ }} expansion. Use the existing Set package version and
steps.version.outputs.version references to locate the change and mirror the
env-based pattern already used by the tagging step.
- Around line 65-79: Make the beta publish workflow idempotent in
release-beta.yml: the current publish step in the beta release job can rerun
after a failed git tag push and then fail on an already-published npm version.
Update the publish flow around the npm publish and tag/create prerelease steps
to detect whether the computed VERSION from steps.version.outputs.version is
already present on npm (or otherwise recover from a partial prior run) and
skip/reuse the publish when appropriate. Keep the fix localized to the beta
release job so reruns can safely continue even if git push origin "v${VERSION}"
previously failed.

🪄 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: CHILL

Plan: Pro

Run ID: 2635b2db-a00c-4fa8-8cdd-571f98b4f73e

📥 Commits

Reviewing files that changed from the base of the PR and between 296ecbc and 3a3b83f.

📒 Files selected for processing (1)

• .github/workflows/release-beta.yml

[coderabbitai]

🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win

Pass the version via env instead of inline ${{ }} expansion.

Line 61 interpolates steps.version.outputs.version directly into the run shell, which is the template-injection pattern flagged by static analysis. The tagging step (Line 71) already does this correctly via env: VERSION; mirror that here for consistency and to keep the value out of the shell parse phase. Exploitability is low today (the value is semver-derived), but the env form is the idiomatic hardening.

🔒️ Proposed fix

       - name: Set package version
-        run: npm version "${{ steps.version.outputs.version }}" --no-git-tag-version
+        env:
+          VERSION: ${{ steps.version.outputs.version }}
+        run: npm version "$VERSION" --no-git-tag-version

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	- name: Set package version
	run: npm version "${{ steps.version.outputs.version }}" --no-git-tag-version
	- name: Set package version
	env:
	VERSION: ${{ steps.version.outputs.version }}
	run: npm version "$VERSION" --no-git-tag-version

🧰 Tools

🪛 zizmor (1.26.1)

[info] 61-61: code injection via template expansion (template-injection): may expand into attacker-controllable code

(template-injection)

🤖 Prompt for 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.

In @.github/workflows/release-beta.yml around lines 60 - 61, The Set package
version step is still interpolating steps.version.outputs.version directly
inside the shell command, which should be hardened to match the later tagging
step. Update the release-beta workflow so this step receives the version through
env as VERSION and then uses that variable in the npm version command, keeping
the shell parse phase free of inline ${{ }} expansion. Use the existing Set
package version and steps.version.outputs.version references to locate the
change and mirror the env-based pattern already used by the tagging step.

Source: Linters/SAST tools

[coderabbitai]

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Inspect the workflow around the referenced lines
sed -n '1,220p' .github/workflows/release-beta.yml

# Find where VERSION / beta versioning is computed elsewhere in the workflow
rg -n "steps\.version|beta|git tag|npm publish|release-beta|version" .github/workflows/release-beta.yml

# Search for any logic that checks for existing npm versions or tags before publishing
rg -n "npm view|npm info|npm publish|git ls-remote|gh release create|tag exists|already exists|dist-tag" .github/workflows

Repository: Fission-AI/OpenSpec

Length of output: 4583

---

Make beta publishing idempotent across reruns. If npm publish succeeds but the tag push fails, the next run recomputes the same vX-beta.N from git tags and then hits an “already published” npm error. Add an existence check or other recovery path before publishing so a partial failure can be retried safely.

🤖 Prompt for 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.

In @.github/workflows/release-beta.yml around lines 65 - 79, Make the beta
publish workflow idempotent in release-beta.yml: the current publish step in the
beta release job can rerun after a failed git tag push and then fail on an
already-published npm version. Update the publish flow around the npm publish
and tag/create prerelease steps to detect whether the computed VERSION from
steps.version.outputs.version is already present on npm (or otherwise recover
from a partial prior run) and skip/reuse the publish when appropriate. Keep the
fix localized to the beta release job so reruns can safely continue even if git
push origin "v${VERSION}" previously failed.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

.github/workflows/release-prepare.yml (1)

106-107: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win

Avoid inlining ${{ … }} into the run: script; pass via env.

Expanding the step output directly into the shell command is the template-injection anti-pattern flagged by static analysis. The final step (Lines 114-125) already uses the safer env/$VERSION pattern; mirror it here for consistency and hygiene.

🔒 Proposed fix

       - name: Set package version
-        run: npm version "${{ steps.version.outputs.version }}" --no-git-tag-version
+        env:
+          VERSION: ${{ steps.version.outputs.version }}
+        run: npm version "$VERSION" --no-git-tag-version

🤖 Prompt for 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.

In @.github/workflows/release-prepare.yml around lines 106 - 107, The Set
package version step is inlining a GitHub Actions expression directly into the
shell command, which should be avoided. Update the step to pass the version from
steps.version.outputs.version through env and reference it via a shell variable
in the run script, following the same pattern used by the final release step for
consistency and safer templating.

Source: Linters/SAST tools

🤖 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 @.github/workflows/release-prepare.yml:
- Around line 111-120: The beta release flow in the publish/tag steps is not
retry-safe because `npm publish --tag beta` can succeed before the `git
tag`/`git push` in the prerelease step fails, causing the next run to reuse the
same `beta.N` version and hit an npm publish rejection. Update the release
sequence around the `Publish to npm under the beta dist-tag` and `Tag and create
GitHub prerelease` steps so the git tag/push happens before publishing, or add
logic in the version selection path to verify the npm registry and advance
`beta.N` when the version already exists. Keep the retry behavior anchored to
the existing `steps.version.outputs.version` and prerelease tagging flow.

---

Nitpick comments:
In @.github/workflows/release-prepare.yml:
- Around line 106-107: The Set package version step is inlining a GitHub Actions
expression directly into the shell command, which should be avoided. Update the
step to pass the version from steps.version.outputs.version through env and
reference it via a shell variable in the run script, following the same pattern
used by the final release step for consistency and safer templating.

🪄 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: CHILL

Plan: Pro

Run ID: c5ab7490-c6ed-45a4-b3d2-8182568af5fc

📥 Commits

Reviewing files that changed from the base of the PR and between 0eb9f15 and a2b42fc.

📒 Files selected for processing (1)

• .github/workflows/release-prepare.yml

[alfred-openspec]

Post-merge sanity review: looks good. I checked the final workflow against the release path and the first manual beta run succeeded on main (v1.6.0-beta.1 is published under the npm beta tag and the GitHub prerelease/tag exists). The hardening commit addressed the retry/idempotency and expression-injection concerns I would have raised.

One small future edge case to keep in mind: if an old beta tag exists without a GitHub release and points at a prior commit, the resume path will select it and then fail rather than advancing to the next beta number. That is acceptable for now since it is a manual recovery case, not a blocker.