[finding] The changeset release PR runs no CI at all — every ci.yml run on `changeset-release/main` is `action_required`, so the release commit reaches `main` unvalidated

[os-support-ai]

Filed unassigned while implementing #5394 (PR #5396). Not caused by that card and not fixed by it — #5394's fix closes one instance (the QUICK_REFERENCE.md drift) by moving the doc inside changeset:version; this issue is the channel that let the instance reach main in the first place, and it is wide open for anything else the release path produces.

Measured, not inferred

GET /repos/objectstack-ai/objectui/actions/workflows/ci.yml/runs?branch=changeset-release/main — 736 runs, and every one of the 30 most recent looks like this:

"conclusion": "action_required",
"created_at": "2026-08-20T09:17:34Z",
"run_started_at": "2026-08-20T09:17:34Z",
"updated_at": "2026-08-20T09:17:34Z",
"triggering_actor": "github-actions[bot]"

created_at == run_started_at == updated_at, zero elapsed: the workflow was created and immediately parked. Nothing executed.

On the 17.6.0 release PR (#4655, head 46a7740a1, merged 2026-08-20T09:58:21Z) the check-runs endpoint returns total_count: 1 — a single Close issues referenced in other repositories run that started at 09:58:28Z, 7 seconds after the merge. So the PR that rewrites 371 files and publishes 39 packages was merged with no test, no lint, no type-check having run against it.

Mechanism

changeset-release.yml uses changesets/action@v1 with GITHUB_TOKEN. GitHub does not start workflow runs from events raised by GITHUB_TOKEN, so the release PR gets no pull_request build. The bot force-pushes changeset-release/main on every push to main, so there is also no stable head for a human to re-run checks against.

Why it matters beyond #5394

The release commit is the single largest diff that lands on main in any given week, it is machine-generated, and it is the only commit that reaches main without passing the merge queue's validation. #5394 happened to cash this in three times through one doc row; the exposure is not limited to that row — any check that the version step can break lands red on main and is first seen by the push build (run 32356587040 took 39 min 26 s to report it).

This is the same shape as #4973 (--auto merging before the slow shard reported) one channel over: there, merges did not wait for the gates; here, the gates never run.

Directions (no choice made — this is a CI policy call for the maintainer)

1. Run the version step's validation inside changeset-release.yml before the action opens/updates the PR (it already runs pnpm test and pnpm build earlier in that job — but on the pre-version tree, which is precisely the tree that is not at risk).
2. Give the release PR real checks by having the action author it with a PAT / GitHub App token instead of GITHUB_TOKEN, so pull_request builds start.
3. Accept the exposure and mechanically guarantee the version step's outputs instead — which is what PR fix(release): carry QUICK_REFERENCE's Current Release block in changeset:version #5396 does for the one row that had actually drifted, and does not generalise.

I lean 1 (cheap, no token surface, validates exactly the tree that lands), but the trade-offs here are the maintainer's.

[os-zhuang]

<!-- os-decision-facets -->
Triage:定级 needs-user-decision · Bug(CI/发布通道策略 + 潜在 token 信任面,人工地板,超出代裁边界)。四维分析:

① 项目长远合理性:release 提交是每周落上 main 的最大单笔 diff(371 文件 / 39 包),且是唯一绕过合并队列验证的通道 —— 修通道优于逐产物打补丁。选项 A(在 changeset-release.yml 里对 version 之后的树跑验证)把验证放在恰好要落地的那棵树上,零新增信任面;选项 B(PAT/GitHub App token 让 release PR 跑真 checks)扩大供应链信任面并新增 token 生命周期义务;选项 C(接受现状 + 逐产物机械保证)不可泛化 —— PR #5396 只救了一行。
② 实际业务拉动:已三次真实付账(#5394 的同一文档行三次漂移上 main);客户可感知后果是 release 提交把 main 弄红后,首个报信的是 ~39 分钟的 push build,期间全部车道的合并队列压在红 main 上 —— 一次事故 ≈ 全团队小时级停摆。
③ 防 AI 犯错:371 文件的机器生成 diff 免验落 main,恰是「机器产出需响亮门禁」的教科书场景;A 在生成点验证,结构性堵住,而非依赖人看 push build。
④ 创业阶段不扩散:A 复用既有 job 与既有 test/build 命令,零新基础设施;B 引入需轮换、可泄漏的凭据。

推荐:A(version 步之后、action 开/更新 PR 之前,对 post-version 树跑验证)。选项:A 如上 / B PAT/App token 换真 PR checks / C 接受现状,逐产物机械保证。

本分析看不见什么:A 的真实价格未测 —— changesets/action 在每次 push to main 时都会刷新 release PR,post-version 全量 test+build(本仓 ~40 分钟)是否要为每次 main push 付一遍?若是,A 需要一个「仅 release PR 内容变化时才验证」的缓存/条件层,其复杂度本分析未定价。另:objectstack / cloud / objectos 是否同病(同一 action + GITHUB_TOKEN 形态)未审计 —— 裁决若采 A,应顺带普查四仓。

---

Generated by Claude Code

[huangyiirene]

Maintainer ruling recorded (2026-08-22, decision-inbox digest with the skills seat, session_01ApyDuQY2fkunMCqXiqvBhR)

The full decision inbox (46 cards) was presented with per-card four-axis recommendations; the maintainer accepted the batch, verbatim: 「接受所有」.

Ruled: Option A — run the version step's validation inside changeset-release.yml, on the post-version tree, after the version step and before changesets/action opens/updates the release PR. This validates exactly the tree that lands on main with zero new token/trust surface (rejecting B's PAT/App-token route and C's per-artifact mechanical guarantees). Attached condition, per the recommendation's stated blind spot: price/measure the cost first — determine whether the post-version full test+build (~40 min) would be paid on every push to main that refreshes the release PR, and whether a validate-only-when-release-PR-content-changes conditional/cache layer is needed, before committing to the implementation shape.

State: needs-user-decision removed → pm:queue (ready for dispatch).

---

Generated by Claude Code

[os-zhuang]

Triage: domain:devx. The fix lands in the CI configuration governing the changeset-release/main branch — a workflow-trigger/permission change, not a package change.

objectui three-stream split (maintainer 2026-08-21): domain:devx engineering surface · domain:spec contract surface · domain:ui everything else.

⚠️ Serial note for the devx seat: this card, #5442 (releases that never reached npm) and #5571 (Version Packages refresh cadence) are three readings of the same release pipeline and will contend for .github/workflows/. Fold-or-serial is a required answer before dispatching any of them.

Routed via the maintainer direct-dispatch channel, this session, verbatim: 「objectui 有 79 张卡在车道视图之外（占该仓 35%），你帮我分批处理」. PM session session_0124Qg8rLvpXnQDwCmpKUmaJ. Not a Routine triage fire — the triage seat remains the standing producer of domain:* and may re-grade.

⛔ pm-state, assignee and scope untouched.

---

Generated by Claude Code