ci: require human signoff before a major release

[Kyleasmth]

Closes YPE-2523 — pending a scope correction, see below.

Ports the Swift SDK's major-release signoff gate (YPE-2521) to this repo. A PR that declares a breaking change cannot merge until a write-access collaborator other than the author confirms it, by name, with the exact version and a 🚀.

The ticket's stated mechanism does not exist here

YPE-2523 says "semantic-release (current branch) detects a breaking change". This repo has no semantic-release: releases run on Changesets, and the bump level is declared in .changeset/*.md frontmatter rather than inferred from commit footers.

That is not a new discovery. docs/release-hardening-decisions.md (Decision 1, jhampton 2026-07-01) already records it:

In the Swift SDK, conventional commits drive changelog + version math. This repo does not work that way … Version bump = the level declared in each changeset … No semantic-release / conventional-changelog tooling.

So the gate is the same; only the detector changes. scripts/preview-release.mjs keeps the Swift name and output contract, but asks changeset status instead of @semantic-release/commit-analyzer.

One deliberate difference from Swift

Swift gates on "this release is a major". Here that would be wrong. Changesets accumulates changesets until the Version Packages PR ships them, so a major pending on main would make every unrelated PR report major and get blocked until the release went out.

The script therefore reports two separate things, and only the second gates:

Field	Means
is_major	the pending release would be a major (informational)
introduced_major	this PR added a changeset declaring major (gates)

Verified behaviour

Run against real commits on this branch, not reasoned about:

Scenario	Gate	next	is_major	introduced_major
CI-only PR (empty changeset)	pass	—	false	false
Adds a patch changeset	pass	2.12.2	false	false
Adds a major changeset	BLOCKS	3.0.0	true	true
Unrelated patch, major already pending	pass	3.0.0	true	false

The last row is the one a straight port would get wrong.

Also confirmed: the three packages are a fixed group in .changeset/config.json, so one major changeset bumps all three to the same 3.0.0. That keeps Swift's single-version signoff format valid — worth knowing, because if fixed were ever removed the signoff comment would become ambiguous about which version is approved. The script fails loudly rather than picking one if it sees more than one version.

Carried over from Swift unchanged

The parts that are release-tool-agnostic and were the hard-won bits there:

• Rejects bot comments and the PR author, so an author with write access cannot self-clear the gate.
• Verifies write/maintain/admin permission, with a per-login cache.
• Re-runs on comment deleted, so a cached success cannot outlive its evidence.
• Normalises > quote markers and whitespace, so GitHub's "Quote reply" matches.
• Upserts one blocking comment rather than posting a new one per push.
• Fails loudly if a major is detected but no version could be computed, rather than letting a degenerate regex pass the gate.

Not done, needs someone with admin

The workflow only blocks if major-release-signoff is added as a required status check on main. I cannot read branch protection (404 without admin). This is what actually made the Swift gate bite, so it should not be skipped.

Scope

Asking on the ticket for the description to be corrected before this merges, since it currently specifies a mechanism this repo does not have.

[changeset-bot]

🦋 Changeset detected

Latest commit: 4e13206

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 0 packages

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR