fix(pnpm-release-changeset): use changesets/action v2 input names, and put the shared workflows on tags

[unional]

Fixes the silently-broken changesets release path from #43, and puts this repo on tags so the next fix to a shared release path lands behind a version consumers opt into.

Two commits, two concerns.

1. fix(pnpm-release-changeset) — the #43 defect

The workflow pins changesets/action@v2.0.0 but passed v1 input names. Actions ignores unknown with: keys, so publish-script was never set: the action only ever opened a version PR, nothing was published to npm, and the job went green.

Before (v1)	After (v2)
version:	version-script:
publish:	publish-script:
commit:	commit-message:

Plus the two secondary defects the issue records: the custom token is now passed as the github-token input (v2 defaults push-with-git-cli: false, so it pushes commits and tags through the GitHub API using that input — the GITHUB_TOKEN env var is not read), and permissions is raised to contents: write, which that push requires. id-token: write is kept for npm OIDC.

What I verified, and how

• Input names — read from the action's own action.yml at the pinned tag, not from the issue: gh api "repos/changesets/action/contents/action.yml?ref=v2.0.0". All four of github-token, publish-script, version-script, commit-message exist as named; push-with-git-cli does default to false. Confirmed independently by the v2.0.0 release notes (Update to changesets v3 packages changesets/action#673, #674, #695).
• actionlint passes — but this is worth nothing as evidence, and I want to be explicit about that rather than let a green check imply verification. I ran it against the original broken file as a control and it passed that too, exit 0. actionlint does not validate third-party action input names. That is precisely why this bug survived review. The action.yml read is the only real check here.

What remains unproven

These workflows only execute on a real release, so I could not run this.

• The publish path end to end. Unproven until the next real release.
• CHANGESETS_OUTPUT plumbing. v2.0.0 (Expect publish output to be shared through a file changesets/action#678) replaced stdout parsing with a shared output file, and states the CHANGESETS_OUTPUT env var "should always be passed down to the Changesets CLI invocations" when using custom scripts. We use custom scripts (pnpm run version / pnpm run release). It should be inherited by the child process normally, but I have not proven it. If it is not, Allow custom publish scripts to complete without a Changesets output file changesets/action#697 says the publish still completes while GitHub releases and git tags are not created, and the published output this workflow exposes would be wrong — visual-testing's release.yml gates its docs job on exactly that output.
• The .npmrc heredoc is now dead code and slightly broken (no closing EOF, leading whitespace, and the step sets NPM_TOKEN: ''). Remove npm auth handling in favor of docs changesets/action#695 removed .npmrc handling entirely in favour of Trusted Publishing. Left alone — separate concern, but it should be cleaned up.

2. docs — the tagging scheme

Consumers pin @v1. Semver tags plus a moving major alias, re-pointed on each compatible release; v1.0.0 immutable. Rationale, the v0.x-vs-v1.0.0 call, what one tag covers, what counts as breaking, and the release procedure are all in the README.

The short version of the judgment calls:

• v1.0.0, not v0.x. The moving-major-alias convention is only coherent at >= 1 — under semver, 0.x minors may break, so a moving v0 would auto-deliver breaking changes, which is the exact failure being fixed.
• A moving v1 does give back some instant propagation. Accepted knowingly: @main propagates everything including unreviewed breaking changes; @v1 propagates only what a maintainer judged compatible. Repos wanting zero drift can pin @v1.0.0.
• One tag covers all eight workflows plus setup-playwright. A change to any one bumps the tag for everyone. That churn is noise, not risk.

Findings from verifying the scheme

The root cause is upstream of #43 and is still live. .mergify.yml auto-merges Renovate PRs. The v1→v2 major arrived as #42 on branch renovate/changesets-action-2.x and auto-merged at 00:58Z on 2026-08-12 — the Mergify guard head~=^(?!major-) expects a major- prefix that Renovate does not produce here, so a major merged like a patch and reached every consumer instantly. Tagging fixes the consumer half; the Mergify rule is a separate defect and should be fixed on its own.

Renovate will keep tag pins current. The org preset (unional/renovate-preset) is just config:base + :preserveSemverRanges — no enabledManagers, nothing disabling github-actions. So pins will not go stale. Note that a moving @v1 yields no update PRs by design; Renovate only opens one when v2 appears. Dependabot is not a factor — the two configs that exist are npm-only.

Known gap, documented not fixed: pnpm-verify.yml:43 and pnpm-release-changeset.yml:42 reference this repo's own setup-playwright@main. A reusable workflow cannot use a relative path (./ resolves against the caller's checkout), so these must be fully qualified — and a consumer pinned @v1 still picks that action up from main. Re-pointing them before v1 exists would break every current consumer, so the README records the remedy to apply when cutting the first tag.

Tag to cut after merge

Do not cut from this branch. After this merges to main:

v1.0.0  ->  the merge commit of this PR on main
v1      ->  the same commit

Exact commands are in the README's "Cutting a release". Per the known gap above, consider including the setup-playwright@main → @v1 edit in the tagged commit.

Before anyone pins the new tag — read this

The consumer list in circulation was incomplete, and no consumer can adopt this workflow yet.

A full org scan (raw grep of every workflow file in all 16 repos, not just code search) found a fourth consumer that was missed: repobuddy/jest-watch-toggle-config-2, which uses pnpm-release-changeset.yml and is therefore inside the #43 blast radius. repobuddy/visual-testing also has two more setup-playwright references than were listed (pull-request.yml, update-snapshot.yml).

All four consumers are on @changesets/cli v2:

Repo	@changesets/cli	Uses pnpm-release-changeset.yml
repobuddy/repobuddy	^2.26.0	yes
repobuddy/storybook	^2.29.7	yes
repobuddy/visual-testing	^2.29.8	yes
repobuddy/jest-watch-toggle-config-2	^2.25.2	yes

changesets/action@v2.0.0 hard-validates this — changesets/action#699 added a check that fails CLI v2 users and directs them to changesets/action@v1. So every one of the four must upgrade to @changesets/cli v3 before pinning v1 for the release workflow. repobuddy/repobuddy is doing so in repobuddy/repobuddy#581 (open; CI red only on a time-based pnpm minimumReleaseAge check that self-clears). The other three have no upgrade in flight.

To be clear about who broke what: this is not a regression introduced by pinning. main already carries changesets/action@v2, so all four are already mismatched today. Pinning does not create the problem; it stops the next one.

Migration issues with exact diffs and the CLI-v3 precondition are filed on each consumer repo.

One decision for the Council

I implemented #43 as specified — fix the v2 input names. But given that zero of four consumers can actually use the result, there is a defensible alternative worth an explicit decision rather than a silent default: revert this repo to changesets/action@v1, ship a v1.0.0 that every consumer can adopt immediately, and do the action v2 upgrade later as v2.0.0 once the consumers are on CLI v3 — which is exactly the opt-in boundary this tagging scheme exists to provide.

I did not do that, because it goes beyond what #43 and the mission asked for and is a direction change, not an implementation detail. Flagging it rather than deciding it. As it stands, v1.0.0's release workflow is correct but unusable until the consumers upgrade.

Refs #43

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[unional]

Superseded by #45, which carries this branch's input fix and README forward.

The correction: this PR applied the changesets/action@v2 input fix to main and put every consumer on @v1. But action v2 hard-rejects @changesets/cli v2, and four of the five consumers are still on it (storybook ^2.29.7, visual-testing ^2.29.8, rolldown-inline-type-exports ^2.29.8, jest-watch-toggle-config-2 ^2.25.2). A single v1 carrying action v2 would have left all four exactly as broken as they are today.

#45 splits the two instead — main/v1 on action v1 for the CLI-v2 repos, v2.x/v2 on action v2 for repobuddy/repobuddy (now on CLI v3) — and adds the secretless OIDC variant to both lines.

Your README is largely intact there; the changes are the pin-by-CLI-major table, the two-line branch layout, the OIDC section, and the release procedure covering both lines.