fix(release): dry-run synthetic candidates on next

[marcusrbrown]

Summary

• push the synthetic release candidate to disposable next before running semantic-release in the prepare workflow
• run semantic-release dry-runs against next in both prepare and CI so protected release is no longer treated as the synthetic branch
• keep the merged next -> release publish path unchanged

[fro-bot]

Verdict: PASS

The PR correctly moves semantic-release dry-runs from the protected release branch to the disposable next branch, ensuring branch protection is never violated during release preparation.

---

Blocking issues

None. The implementation is sound and aligns with the architecture plan.

---

Non-blocking concerns

1. .releaserc.yaml branch configuration mismatch

The .releaserc.yaml only defines branches: [release]. When running --branches next, semantic-release won't find a matching branch config and will use defaults. This works for dry-run mode, but consider documenting this behavior.

Recommendation: Add a comment to .releaserc.yaml explaining that next is used for dry-run staging and intentionally not configured for actual releases:

branches:
  - release
  # Note: 'next' branch is used for dry-run staging only (ci.yaml, prepare-release-pr.yaml)
  # and is not configured for actual releases per docs/plans/2026-03-22-auto-release-no-force-push-plan.md

2. GITHUB_EVENT_NAME=push addition not documented in PR description

Both workflow files now set GITHUB_EVENT_NAME=push. This ensures semantic-release treats the dry-run as a push event (vs merge_group or pull_request), which affects its behavior. Consider updating the PR description to mention this change.

---

Missing tests

None identified. The workflow changes are difficult to unit test without mocking the entire GitHub Actions environment.

---

Risk assessment: LOW

Why LOW:

• Changes are narrowly scoped to dry-run execution paths
• The next branch is already designed to be disposable (cleared on no-release, deleted post-publish)
• Real release publishing on release branch (auto-release.yaml) is unchanged
• The architecture plan explicitly documents this approach

Potential regression:

• If semantic-release version or behavior changes, the --branches next workaround might need adjustment
• Mitigation: Document the expected semantic-release behavior in comments

---

Code Quality

Positive patterns:

• Clear, single-purpose changes
• Consistent approach across both workflows (ci.yaml and prepare-release-pr.yaml)
• Proper ordering: push to next BEFORE running semantic-release (so commits are visible)
• Idempotent cleanup: || true on branch deletion prevents failures

Follows existing patterns:

• Uses same --force-with-lease pattern for safe pushes
• Maintains same git push --force-with-lease origin HEAD:next pattern
• Preserves --dry-run true --ci false flags

---

Implementation Details Verified

Aspect	Status
Push to next before dry-run	✅ Correct ordering
--branches next flag	✅ Valid semantic-release workaround
GITHUB_REF env var	✅ Points to next
GITHUB_EVENT_NAME=push	✅ Simulates push event
Branch protection untouched	✅ release remains protected
Post-publish cleanup unchanged	✅ auto-release.yaml still deletes next

---

Run Summary

Field	Value
Event	pull_request
Repository	fro-bot/agent
Run ID	23406884924
Cache	hit
Session	ses_2e9b6b7c7ffeDSpcDu9dT3uXmO

[fro-bot]

Verdict: PASS ✅

The implementation correctly moves semantic-release dry-runs from the protected release branch to the disposable next branch, eliminating force-push violations against branch protection rules.

---

Architecture Alignment

This PR correctly implements the plan from docs/plans/2026-03-22-auto-release-no-force-push-plan.md:

Workflow	Branch	Purpose
prepare-release-pr.yaml	next	Synthesize & dry-run before PR
ci.yaml (DRY_RUN=true)	Local next	PR analysis without remote push
ci.yaml (DRY_RUN=false)	Pushed next	Main branch release prep
auto-release.yaml	release	Actual publish (unchanged)

---

Implementation Correctness

Aspect	Status
Push to next before dry-run	✅ Correct ordering in both workflows
--branches next CLI override	✅ Bypasses .releaserc.yaml correctly
Local isolation for DRY_RUN	✅ --repository-url . avoids remote calls
Event simulation	✅ GITHUB_EVENT_NAME=push ensures correct behavior
Plugin filtering	✅ DRY_RUN limits to analysis/exec plugins
Branch protection	✅ release never touched during dry-runs

---

Code Quality

Positive patterns:

• Clear separation between prepare (dry-run) and publish (auto-release) workflows
• Consistent approach across both workflows with GITHUB_REF=refs/heads/next
• Proper ordering: push to next → build → semantic-release (prepare workflow)
• Local branch creation for DRY_RUN avoids unnecessary remote operations

One minor suggestion (optional):

Consider adding a comment to .releaserc.yaml documenting the next branch usage:

branches:
  - release
  # Note: 'next' is used for dry-run staging (ci.yaml, prepare-release-pr.yaml)
  # Actual releases occur on 'release' via auto-release.yaml

---

Risk Assessment: LOW

Why LOW:

• Changes are narrowly scoped to dry-run execution paths
• release branch protection is never violated
• Real publishing on auto-release.yaml is unchanged
• next branch is designed to be disposable (cleared on no-release, deleted post-publish)

---

Run Summary

Field	Value
Event	pull_request
Repository	fro-bot/agent
Run ID	23408727465
Cache	hit
Session	ses_2e95b75d1ffeRLw7M7c9cIpNyL

[marcusrbrown]

Superseded by new PR using release preview script instead of semantic-release branch emulation