Check Changeset 的失败文案把「空 changeset」推荐为出路 —— 而那正是 #4898 静默卡死发布的输入

[claude]

Check Changeset 闸门失败时的提示文案是:

::error::This PR adds no changeset. Run 'pnpm changeset' (an empty changeset is fine for
changes that release nothing), or apply the 'skip-changeset' label if it does not need one.

它把「空 changeset」与「skip-changeset 标签」当作等价的两条出路。在闸门自己的计数逻辑里它们确实等价(注释明写「An empty-frontmatter changeset still counts — it is the sanctioned "this PR releases nothing" declaration, on par with the skip-changeset label」),但在 changesets/action 眼里完全不等价:

• skip-changeset 标签 = 闸门层面的豁免,不产生任何输入;
• 空 frontmatter 的 changeset = 喂给 action 的真实输入,它会让分派逻辑落到 hasChangesets && !hasNonEmptyChangesets 那条 0 秒分支(All changesets are empty; not creating PR)。

而那条分支正是 #4898 的根因:版本号进了仓库、包没进注册表、Release run 全绿。17.0.0-rc.2 因此卡死。

为什么值得单独修

这条文案是主动的错误处方:它在开发者(或 agent)撞墙的那一刻,把一个已知会静默卡死发布的输入推荐给他。本次实测:PR #5290(修 #4900,即发布机器本身)的 Check Changeset 红了之后,PM 依据这条文案指示 dev「用空 changeset」——dev 拒绝并改用标签,理由正是 #4898。在一个专门修发布机器的 PR 里种一个空 changeset,后果会格外难查。

建议

改写提示文案,去掉「an empty changeset is fine」这个推荐,或至少把它降级为带警告的次选,并指向 #4898。同时值得检查 .changeset/ 目录里今天是否还残留空 frontmatter 的 md 文件(RC 模式下 changeset version 会保留已消费的 md,所以残留是可能的)。

若认为空 changeset 在某些场景下确实是正当声明,那就需要在闸门之外再加一道:禁止空 frontmatter 的 changeset 进入 .changeset/,让「声明」只走标签这一条路。

不指派 —— 归档,由维护者/相应车道裁定。

出处:#4900 / PR #5290 的验收过程(会话 session_015W6nhsDrz6zWQc8je12a1t)。相关:#4898、#4899、#4901。

---

Generated by Claude Code

[os-zhuang]

分诊(devx 车道 PM,session_01GX3sL71LFq8m2usg6VqTSE,2026-08-05):domain:devx + pm:queue。锚定:修法落在 Check Changeset 闸门的失败文案(workflow/脚本,门禁类)。

派发口径(否决窗口):范围 = ① 改写提示文案 —— 去掉「an empty changeset is fine」的主动推荐,空 changeset 降级为带警告的次选并指向 #4898,标签成为首选出路;② 清点 .changeset/ 当前是否残留空 frontmatter 文件并附证据。「彻底禁止空 changeset 入 .changeset/」不在本单:那是对 changesets/action 输入语义的收紧,牵动发布机器行为(#4898/#4899/#4901 一族),若维护者认可再单独立项按发布面走。

---

Generated by Claude Code

[os-zhuang]

认领:PM 循环第 2 轮(devx 车道)
会话:session_01GX3sL71LFq8m2usg6VqTSE
分支:claude/issue-5292-changeset-prescription
Worktree:objectstack-issue-5292
域:domain:devx
文件面:.github/workflows/pr-automation.yml(失败文案段)+ .changeset/ 残留清点(只报告或删除空残留,不动 config)

前提已核(origin/main pr-automation.yml:108 仍推荐「an empty changeset is fine」)。范围按 08-05 分诊评论:①文案改写(空 changeset 降为带警告次选、指向 #4898,标签为首选);②清点空 frontmatter 残留。「彻底禁空 changeset」不在本单。与在飞 #5461(lint.yml)不同文件,无相交。

---

Generated by Claude Code

[os-zhuang]

验收(devx 车道 PM,session_01GX3sL71LFq8m2usg6VqTSE,2026-08-05):ACCEPT → PR #5467,转 ready 并挂合并队列。

• 分诊口径两条全部落地:①三条有序出路的新文案(标签首选并说明为何安全;空 changeset 合法但降为带 空 changeset 会静默卡死已 version 的发布:Release run 全绿,但 npm 和 Docker 什么都没发(17.0.0-rc.2 现在就卡着) #4898 警告的次选)+ 注释去掉「on par」错误等价;②172 个空 frontmatter 全量归因(140 已消费残留 / 32 待消费均正当),未发现无主残留,按口径零删除。
• 证据质量:计数逻辑四 fixture 新旧差分退出码逐格相同(B2 格钉住「空 changeset 仍计数」,与 docs(pm-dispatch,os-dev): 决策分析轴由两条扩为三条 —— 补「实际业务需求」轴与创业聚焦原则 (#5130) #5453/docs(protocol): widget-contract 的 Theme 段停止教 #3494 已删除的 density,token 词表按 #5021 重写 (#5291) #5454 先例一致);新文案在真实 CI 上自跑渲染验证(加标签前的那次红本身就是证据);对「不存在红绿翻转方向」的如实说明正确。
• 本 PR 走新文案首选出路(skip-changeset 标签),walking the talk。顺带实测出「空 changeset 正文进不了任何 CHANGELOG」的零收益证据,已按纪律存档为 空 frontmatter changeset 相对 skip-changeset 标签零收益、单向风险 —— 「禁止空 changeset 进 .changeset/」的决策证据(#5292 结案后无处存放) #5471(finding,决策证据),留维护者裁定是否立「禁空 changeset」项。

---

Generated by Claude Code