Repository navigation
[v3 migration 3/4] Decide #9208 — changesets/action v1 → v2 against release.yml's pinned rationale #9499
Description
Activity
Label corrected:
pm:blocked→needs-user-decision. TheBlocked-by: #9497line 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/actionis a compiled Action that cannot run outside GitHub Actions, and that repository is outside this session's authorised scope, so its bundled@changesets/readcould 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/actioninto 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.ymlstill pins@v1and works, and #9208 is held rather than dangling. This card simply sits in the decision inbox until answered.
Generated by Claude Code
- A — bring
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/publishinvocation 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
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/actionv1 → v2) is the epic PM's to make from evidence — #9497's U6 reading (delivered; #9497 closed completed 2026-08-18, report on #9465) againstrelease.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 perpm:epic).
Generated by Claude Code
Answered and closing. Maintainer decision on 2026-08-19, verbatim:
同意 9208
The decision this card existed to produce: do not upgrade
changesets/actionto v2. #9208 is closed with the full reasoning; the short version is thatrelease.yml's v1 pin encodes a safety property — nopublish:input meansrunPublishis unreachable — that was asserted against v1's source, and this repo has already paid once for that property's absence (rc.3andrc.4minted with no human). No feature of v2 is needed for the one job we use it for, so there was nothing on the other side of the scale.The scope question this card was blocked on is moot. It asked whether
changesets/actionshould enter this session's authorised repositories so U6 could be answered. That access is not needed to decline an upgrade nobody needs — it is needed only if and when there is a reason to take one. The requirement is now recorded where it will be read: #9916 puts both re-verification obligations beside the pin inrelease.yml— therunPublishreachability property, and (new since the v3 migration) the bundled@changesets/readseeing.changeset/pre/.So this closes as completed: it produced a decision with evidence and a durable record, which is what a decision card is for. It did not produce the answer to U6, and that is stated rather than papered over — U6 remains unmeasured, by choice, because measuring it costs repository access we do not need today.
Epic #9465 now has one card left: #9500, the RC-window verification, still on hold until the next pre-mode entry.
Generated by Claude Code
- added a commit that references this issue
on Sep 28, 2026
Sub-issue of #9465.
Blocked-by: #9497
release.ymlpinschangesets/action@v1and 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
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.changeset version/publishunder 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).Outcomes, both legitimate
Either way: no release is performed by this card, and
release.ymlis not edited outside the migration PR.Acceptance