[v3 migration 3/4] Decide #9208 — `changesets/action` v1 → v2 against release.yml's pinned rationale

[os-project-manager]

Sub-issue of #9465.

Blocked-by: #9497

release.yml pins changesets/action@v1 and records a rationale for the pin (#6170). Dependabot's #9208 proposes v2. That bump and the CLI major (#9217) drive one machine, so deciding them independently means the failure only shows at the next release.

This card produces a decision with evidence, and then either folds the action bump into the migration PR (#9498) or closes #9208 with the reason recorded on it.

What has to be established

• What release.yml's v1 pin is actually protecting — read release workflow: publish pushes tags + npm but its version commit never reaches main — twice now (rc.3 c6a52d3, rc.4 a10cbc77); landing the commit must be part of the publish lane #6170 and the workflow's own comments rather than assuming the pin is inertia.
• Whether v2 changes any of that behaviour, in particular anything touching how the action invokes changeset version/publish under v3's exit-1-on-no-op (this is the seam where the two bumps interact; U6 on [v3 migration 1/4] Rehearse @changesets/cli v3 in a throwaway clone and answer U1–U6 with measurements — no repo changes #9497 supplies the reading).
• Whether v2 requires inputs or permissions the current job does not grant.

Outcomes, both legitimate

• Fold in. The action bump joins [v3 migration 2/4] Land the v3 migration as one atomic PR — bump, gates, workflows and config together #9498's PR, with the argument for why v2 does not violate the pinned rationale written in that PR's body.
• Defer. chore(ci)(deps): Bump changesets/action from 1 to 2 #9208 stays open or is closed with a comment stating what would have to change for v2 to be safe. A deferral is a real answer here; "we bumped it because Dependabot offered" is not.

Either way: no release is performed by this card, and release.yml is not edited outside the migration PR.

Acceptance

• A decision comment on chore(ci)(deps): Bump changesets/action from 1 to 2 #9208 stating the outcome, the evidence, and what was read (release workflow: publish pushes tags + npm but its version commit never reaches main — twice now (rc.3 c6a52d3, rc.4 a10cbc77); landing the commit must be part of the publish lane #6170, the workflow comments, v2's changelog).
• If folded: [v3 migration 2/4] Land the v3 migration as one atomic PR — bump, gates, workflows and config together #9498's PR carries the change and this card links to it. If deferred: chore(ci)(deps): Bump changesets/action from 1 to 2 #9208 carries the reason, and this card records it on Migrate the release toolchain to @changesets/cli v3 — one atomic PR carrying the bump, the pre-mode restructure, and the gates that model v2's semantics #9465 so the next Dependabot re-offer meets an existing answer instead of a fresh debate.

[os-project-manager]

Label corrected: pm:blocked → needs-user-decision. The Blocked-by: #9497 line in the body is stale — #9497 closed hours ago, so the unlock sweep would have put this card back in the queue as dispatchable, which it is not.

What actually holds it is an input only the maintainer can give. #9497 measured U6 as not answerable from here: changesets/action is a compiled Action that cannot run outside GitHub Actions, and that repository is outside this session's authorised scope, so its bundled @changesets/read could not be read either. The decisive library-level fact was measured — after a v3 cut the CLI sees the full stock while a v2-era non-recursive reader sees only the unconsumed residue — but which generation each action version bundles is unknown.

So the question is one of these two, and it is not a technical judgment I can make for you:

• A — bring changesets/action into this session's repository scope (or paste v1's and v2's reader), and this card answers chore(ci)(deps): Bump changesets/action from 1 to 2 #9208 properly.
• B — dispatch it now for the half that is answerable: read release.yml's pin rationale (release workflow: publish pushes tags + npm but its version commit never reaches main — twice now (rc.3 c6a52d3, rc.4 a10cbc77); landing the commit must be part of the publish lane #6170), state what v2 would have to preserve, and record an explicit deferral on chore(ci)(deps): Bump changesets/action from 1 to 2 #9208 rather than a decision.

Recommendation unchanged from #9497's: A, because B pays for the missing half later, and the failure mode it guards against is the version PR quietly ceasing to refresh mid-window — invisible until a cut is dispatched against a stale number, which is the exact shape of #4898.

Not urgent, and nothing else in the epic waits on it: release.yml still pins @v1 and works, and #9208 is held rather than dangling. This card simply sits in the decision inbox until answered.

---

Generated by Claude Code

[os-support-ai]

Triage note recording maintainer guidance (2026-08-18, live PM chat with the triage seat, session session_01EUZUjvnLsqwHVkXkTv8TKQ; verbatim: 「其他接受你的建议」, applying the recommendation delivered for this card).

Accepted posture: the default answer is DEFER. The #6170 pin has a recorded rationale; "Dependabot offered v2" is not a reason. The epic side (#9465) produces the evidence per this card's own procedure — what the v1 pin protects, whether v2 changes the version/publish invocation under v3's exit-1-on-no-op (U6 on #9497), and any new inputs/permissions — and the maintainer nods on the resulting fold-in/defer proposal only if the evidence argues for v2. No maintainer action is due now; the card stays in the inbox as the epic's decision-procedure card. This comment exists so the next Dependabot re-offer meets a recorded default instead of a fresh debate.

---

Generated by Claude Code

[os-support-ai]

Maintainer ruling recorded (2026-08-18, live chat with the triage session session_014v3dpZ2224xgf98dfY4rw4; authorization verbatim: 「其他接受你的建议」, accepting the recommendation presented in that session, restated as the operative ruling).

Ruling: delegated to the epic PM. The fold-in vs defer decision on #9208 (changesets/action v1 → v2) is the epic PM's to make from evidence — #9497's U6 reading (delivered; #9497 closed completed 2026-08-18, report on #9465) against release.yml's pinned rationale (#6170) — without a separate maintainer round-trip. Recorded lean: defer, unless U6 shows v2 is either required by the v3 toolchain or demonstrably harmless against the pin's rationale; "Dependabot offered" remains insufficient per this card's own text. The human gate stays where it already is structurally: the release.yml migration PR (#9498) is human-merged, so any fold-in passes the maintainer's hands regardless.

Blocked-by discharged: #9497 closed completed 06:52Z with the U1–U6 report. Label: needs-user-decision → pm:queue (epic #9465 subtree — the epic PM sequences it; other seats keep skipping the subtree per pm:epic).

---

Generated by Claude Code