bump-objectui.sh 的 pin changeset 只收 feat|fix 且静默截断到 40 条 —— 破坏性 refactor! 进不了前端发布记录

[os-zhuang]

未认领。 刷 #4665（objectui pin 7d9734d5e321 → 785b8a5d432c）时发现，与该单同源（#3340 的失效模式：前端改动没进平台发布记录），但修的是机制本身，所以另立，不在 #4665 的 PR 里顺手改。

现状

scripts/bump-objectui.sh 用提交标题猜"这条提交要不要写进 @objectstack/console 的 changeset"：

CHANGES="$(git -C "$OBJECTUI_ROOT" log --no-merges --format='- %s' "${OLD_SHA}..${NEW_SHA}" \
  | grep -iE '^- (feat|fix)' | head -40 || true)"

bump 类型也用同一套猜法（grep -ciE '^feat' 有命中就 minor，否则 patch）。

三个后果，都是这次刷新的实测

区间 7d9734d5e321..785b8a5d432c：53 个非 merge 提交，其中 feat|fix 34 条。

1. 带 ! 的破坏性 refactor 一条都进不去。 这次被过滤掉的就有 8 条 refactor(...)!，包括 refactor(layout)!: delete PageNodeRenderer, the unregistered page-node renderer (#3225) 和两批 burn ledger（objectui#3220 / feat(spec): compile-check skills/ TypeScript examples (anti-drift, #3094) #3224）。破坏性变更是最不该从发布记录里消失的那一类，而它恰好是唯一被类型过滤挡在门外的一类。chore(deps)! 同理（区间里的 chore(deps): lockstep the @objectstack family onto 17.0.0-rc.1 也没进）。
2. head -40 是静默截断。 没有 "…and N more" 的尾标记，读者无从知道清单是完整的还是被砍过的。这次 34/40 —— 用掉了 85%，下一次多攒两周就会开始悄悄掉最旧的几条，而"掉了"和"本来就没有"在成品里长得一模一样。
3. 反向也不准：不发版、不进包的提交被收了进来。 两条 fix(ci)（objectui#3198 never render a budget FAIL for a run that measured nothing、objectui#3186 hand the cross-repo token to github-script）按类型匹配进了清单，但它们在 objectui 侧连 changeset 都没有，也不在构建产物里。（跑 pnpm objectui:refresh 并落 console pin —— 2026-08-02 合并的 7 个 objectui PR 目前进不了 v17 #4665 的 PR 里我手工删掉了这两行，但下一次刷新会照样带回来。）

为什么值得修

bump-objectui.sh 写这个 changeset 的唯一理由就是补 #3340 那个洞：pin 一动、前端改动却在平台发布记录里查无此人。但它判断"这条提交算不算前端改动"用的是提交标题的 conventional-commit 类型，而不是"这条提交在 objectui 侧发不发版"。猜错的两个方向都已经在真实区间里出现了。

建议（按可持续性排序）

1. 读区间里新增的 .changeset/*.md 的 frontmatter，别猜 commit 类型。 objectui 每个发版 PR 都带一个 changeset，空 frontmatter = release-nothing。git diff --name-only --diff-filter=A OLD..NEW -- .changeset/ 就能拿到这批文件，有包名的才是"发版的前端改动"，级别（major/minor/patch）也是现成的 —— 连 bump 类型都不用再从 ^feat 猜。声明即依据，跟本仓 contract-first 的方向一致。
2. 过渡方案（若 1 太大）：把 ! 破坏性提交无条件收进清单（^- \w+(\(.*\))?!:），排除 scope 为 ci 的提交，并在截断处补 - …and N more commits (see the objectui range)。
3. 无论走哪条，截断必须出声：静默截断和没有截断在成品里不可区分，这正是这个脚本存在要防的那种沉默。

关联

• Release process: prevent frontend (objectui) changesets being missed when the console pin lags #3340 —— 本条要防的失效模式
• 跑 pnpm objectui:refresh 并落 console pin —— 2026-08-02 合并的 7 个 objectui PR 目前进不了 v17 #4665 —— 发现现场（pin 刷到 785b8a5d432c）

[xuyushun441-sys]

认领:PM 循环第 8 轮
会话:session_018iARDqtrhQgz6fVHDeDkbQ
分支:claude/issue-4731-objectui-pin-changeset-from-changesets
Worktree:objectstack-issue-4731

车道:domain:devx —— 维护者已指定本会话独占认领该标签,登记在 #4604。落点 scripts/bump-objectui.sh,与其它 PM 的文件车道无交叉。

前提复核(对最新 main):缺陷仍在,scripts/bump-objectui.sh:97 逐字如 issue 所述 ——

| grep -iE '^- (feat|fix)' | head -40 || true)"

类型过滤与 head -40 静默截断都在原处。

方向取建议 1(读 changeset frontmatter,不猜 commit 类型)

issue 按可持续性给了三档,取第 1 档。这属 PM 可自决范围(不改公开契约、不涉及存储迁移),理由:

• 它把判据从「猜」换成「声明」。脚本要回答的问题是「这条提交算不算发版的前端改动」,而 objectui 每个发版 PR 都带一个 changeset —— 有包名的才发版,空 frontmatter 就是 release-nothing。git diff --name-only --diff-filter=A OLD..NEW -- .changeset/ 直接拿到这批文件,级别(major/minor/patch)也是现成的,连 bump 类型都不用再从 ^feat 猜。与本仓 contract-first 的方向一致。
• 第 2 档(放行 ! 提交 + 排除 ci scope + 补截断尾标)是在猜法上打补丁:它能修掉这次实测到的三个后果,但下一种猜错的形态还会再来一次。issue 自己把它列为「若 1 太大」的过渡方案。
• 第 3 条不是可选项,无论走哪档都要做:截断必须出声。静默截断与没有截断在成品里不可区分 —— 而这个脚本存在的全部理由,正是防这种沉默。

派发时会明确:若实现中发现第 1 档确实做不动(例如 objectui 侧 changeset 与提交区间对不上),停下来报 needs_decision,不要自行降级到第 2 档 —— 降级是方向变更,该我来定。

---

Generated by Claude Code

[xuyushun441-sys]

PM 复核:通过(ACCEPT),含一项 PM 裁定;等 CI 全绿后进合并队列

PR:#4842(草稿,base main,body 首行 Fixes objectstack-ai/objectstack#4731)

文件面(5 个,packages/** 零改动,未碰在飞另两单的文件):scripts/objectui-changeset-digest.mjs(新,616 行,含 20 例 self-test)、scripts/bump-objectui.sh、lint.yml、package.json、changeset。

方案 1 落地,且对着真实区间验了

判据从「猜 commit 类型」换成「读区间内新增的 .changeset/*.md frontmatter」:包名决定收录,空 frontmatter = release-nothing,bump 级别直接取声明的最高级 —— grep -ciE '^feat' 整个删掉。截断无默认;若设了 CONSOLE_CHANGES_MAX 且触发,输出真实的「…and N more」;区间不可走(shallow clone / 首次 pin)时输出显式标注的 Degraded 列表而不是静默空清单。

真实区间证明(dev 主动 attach 并 unshallow 了 objectui 仓来跑,没有拿「环境里没有」当借口):7d9734d5e321..785b8a5d432c 上新逻辑产出 44 条 releasing changeset(4 breaking、4 release-nothing、7 无 changeset 提交计数在列),对照旧逻辑 34 行 + 静默截断 + bump 猜成 minor。旧过滤器错丢 13 条 releasing 提交(含 refactor(layout)! 删 PageNodeRenderer、两批 burn ledger、chore(deps) rc.1 lockstep)、错收 5 条 release-nothing 提交 —— 新输出 13 条全在、5 条全不在。

Ground truth 出入,dev 如实上报而非糊过去 —— 结论:issue 描述不精确,实现无错

我派发时给的验收是「8 条 refactor(...)! 必须进、2 条 fix(ci) 必须不进」,并要求对不上就查清是哪边错。dev 查了:

• 区间实际是 9 条 refactor,其中 6 条带 !(不是 8)—— issue 点名的两个例子(objectui#3225、The managedBy: 'system' bucket is overloaded (engine-only vs. admin-writable) — split the taxonomy; don't guard it wholesale #3220/feat(spec): compile-check skills/ TypeScript examples (anti-drift, #3094) #3224)都在其中,9 条全被旧过滤器丢掉,新实现 9 条全收;另有 5 条 feat!/fix! 本来就过旧过滤器,合计 11 条 ! 提交全部在列。
• objectui#3186 的 fix(ci) 其实带 changeset —— 空 frontmatter,即显式声明 release-nothing;docs(spec): document validation governance fields + cross_field/script overlap; tidy stale form mirror #3198 确实没有。这个细节反而加强了方案 1:空 frontmatter 是 objectui 在大声说「不发任何东西」,只有读声明的实现才听得见;按类型猜的旧逻辑对这句话是聋的。

PM 裁定:major 在 lockstep 组上的落法,采纳已实现的方案 A

dev 报了一个 issue 未预见的交互:@objectstack/console 在 changesets 的 fixed lockstep 组里(一个 major 抬升整列 ~70 包),而 scripts/check-changeset-no-major.mjs 在 RC pre-mode 之外拒绝 major。已实现的 A:pre-mode 内 major 原样通过(main 今天在 rc,故 issue 的区间产出 major,与验收一致);pre-mode 外声明的 major 记为 minor,但降级本身响亮(changeset 正文与 stderr 都写明降级及理由),breaking 条目永不从清单中移除。

这属 PM 可自决,不上报维护者,依据是判定标准里的「existing code norms determine the answer」:A 逐字镜像了 check-changeset-no-major.mjs 自己的豁免逻辑 —— 仓里已经决定了「pre-mode 外不许 major」,B(无条件放行 major)会让每次平常的 pin 刷新都撞红一条必过闸门、等人打 allow-major 标签,可靠地撞红 CI 的机械脚本会被绕过,而绕过正是发布记录静默的回归路径(本 issue 存在的全部理由)。A 不隐藏任何 breaking(条目在列、降级出声),是「响亮的强制」而非静默。维护者若倾向 B,删掉 objectui-changeset-digest.mjs 里那一个 inPreMode() 分支即可 —— 这是留给你的否决窗口。

衍生 #4843(同缺陷,隔壁脚本)

scripts/objectui-range.mjs(发布页的 Console 聚合器)默认仍是同一个 feat|fix 类型过滤 —— 同一真实区间上同样丢 13 收 5。落点 scripts/ = domain:devx,本车道,随后分诊入队。

诚实标注的未跑项:容器无);未跑 pnpm lint/test/typecheck(改动不触任何包源码,scripts/ 闸门的仓内惯例是 --self-test,20/20 绿且已接 CI)。合理。

---

Generated by Claude Code

[xuyushun441-sys]

结案 — PR #4842 已合入 main

采纳建议 1(读声明),放弃建议 2(在猜法上打补丁)。理由值得留档:脚本真正要回答的是「这条提交在 objectui 侧发不发版」,而 objectui 每个发版 PR 都已经声明了答案 —— .changeset/*.md 的 frontmatter 有包名才发版,空 frontmatter 是 changesets 自己的 release-nothing 写法,bump 级别也是现成的。从提交标题的 conventional-commit 类型去猜,是拿一个代理指标替代一个已经写下来的事实。建议 2 能修掉本次实测到的三个后果,但下一种猜错的形态还会再来;这与本仓 contract-first 的方向(Prime Directive #12)一致。

实测结果(7d9734d5e321..785b8a5d432c,53 个非 merge 提交):旧逻辑漏收 13 条发版提交(含全部 6 条破坏性 refactor(...)!)、误收 5 条不发版提交;新逻辑对这 18 条判断全部正确,且清单不再被 head -40 无声截断。

两处 ground truth 更正(核过原始 git 历史,是本 issue 的描述有偏差,不是实现偏差):

1. 我在 issue 里写「被过滤掉的有 8 条 refactor(...)!」。实际区间内是 9 条 refactor,其中带 ! 的 6 条;9 条全部被旧过滤器丢掉,点名的两个例子(objectui#3225、The managedBy: 'system' bucket is overloaded (engine-only vs. admin-writable) — split the taxonomy; don't guard it wholesale #3220/feat(spec): compile-check skills/ TypeScript examples (anti-drift, #3094) #3224)都在其中。
2. 我写两条 fix(ci)「连 changeset 都没有」。objectui#3198 确实没有;objectui#3186 有 changeset,但 frontmatter 是空的。结论相同(两条都该排除),但机制不同,而且这个差别正是本次改动的价值所在:空 frontmatter 是 objectui 明确说出的「不发版」,读声明连这一层都读得懂,类型猜测则两条都会误收。

一处需要维护者知情的判断:声明的 major 怎么落到 console 上。 @objectstack/console 在 changesets 的 fixed lockstep 组里,一个 major 会把整个 monorepo 顶上去,而 scripts/check-changeset-no-major.mjs 正是为此存在;objectui 例行把符号改名标成 major,机械透传会让每次常规 pin 刷新都撞门禁。实现照抄了那个门禁自己的判据:处于 changesets pre-release(RC)模式时 major 原样保留,不在 pre-mode 时降为 minor 并在产物正文里出声说明降级及原因,破坏性条目一条不删,CONSOLE_BUMP 仍可强制覆盖。若日后希望无条件透传 major(靠 allow-major label 放行),删掉 inPreMode() 那一个分支即可 —— 这是个可撤销的选择,不是被锁死的语义。

合入过程的一个教训:本 PR 先被合并队列以 MERGE_CONFLICT 踢出过一次,原因是同批次的 #4833 先落地,两者都往 .github/workflows/lint.yml 和根 package.json 追加行。这是我批次选择时的疏漏 —— 没把这两个共享文件当成碰撞面。已由原 agent 做并集合并(f3c2f3d6b)后重新进队。

后续 #4843 依赖本 PR 导出的 collectAddedChangesets() / parseChangeset(),现已解除阻塞。

---

Generated by Claude Code