release: 17.0.0-rc.4 published from a10cbc77 but the version commit never landed on main — 2026-08-03 shape repeated; merge it back before ANY further release action

[hotlong]

Facts (all measured 2026-08-07 ~05:30Z)

• The publish is real: 69 tags *@17.0.0-rc.4 (138 ls-remote lines incl. peeled), ALL pointing at one commit a10cbc77a1e83a382d4a190879b39d588435a04d — chore: version packages (rc), github-actions[bot], 2026-08-07 04:17:39Z. npm confirms: npm view @objectstack/spec@17.0.0-rc.4 version → 17.0.0-rc.4; dist-tags.rc → 17.0.0-rc.4.
• Cut from 36fc938 (fix(cli): dev watcher 重建后不再无声——重建成功后自动重启 serve 子进程(默认开,--no-restart 可退) (#5148) #6150) — i.e. it contains chore(release): 发版状态对账 —— main 版本对齐 2026-08-03 已发布的 17.0.0-rc.3 #6149's version reconciliation and everything merged up to 04:1xZ (incl. refactor(spec)!: 按 ADR-0049 退役 FieldMapping.transform 与整个 FieldMappingTransform 联合 —— 五成员零执行者 (#5552) #6078 / fix(plugin-auth): break-glass 守卫扩到 sys_permission_set,并把「零管理员」从引导期豁免里分辨出来 (#6084) #6107 / fix(drivers): undefined 比较数一律拒收 —— 闸落在任何发射器/守卫之前,两个毛病同闸消灭 (#6050) #6142), so the computed rc.4 numbers are correct. Commits after 36fc938 (fix(service-automation): runAs:'system' 的 create_record 按 ADR-0118 染全三列——组织、属主、创建者禁 NULL (#5494) #6153, refactor(client)!: subscribeMetadata 的 type 收窄为 MetadataEventSubject，订阅无合同类型改为编译报错 (#4627) #6156, ci(dx): DEBT/TEST_DEBT 台账数字改为每次重测的真棘轮 —— 实测 > 记录即红 (#5278) #5827, feat(objectql,cli): os migrate 新增 summary count/sum 存量 NULL 回填迁移 (#6063) #6158, feat(spec): strictness 台账新增第九判定词 covered(#5249 裁 A) #6154, docs(ci): 控制字节集合的最后两处散文手抄改为引用门禁脚本头 (#5681) #6166…) ride the next rc.
• Not an ancestor of main: absent from the last 60 main commits; merge-base with main is its parent 36fc938. Same failure shape as 2026-08-03 (发版状态对账:main 的 fixed 组版本(rc.2)落后 npm 已发布的 rc.3 —— 版本 PR 因此计算出已占用的版本号,直合会静默丢失一次发布 #6135, rc.3 / c6a52d3), one version later.
• What the orphaned commit carries: 153 files, +33604/−79 — the rc.4 package.json bumps, the compiled CHANGELOGs, and the .changeset/pre.json bookkeeping. Zero .changeset/*.md deletions (prerelease mode consumes via pre.json, not file deletion).
• The bypass also skipped the release gates: .objectui-sha in the published tree is f995a452 — the stale pin. The 7 releasing objectui changesets (chore(console): bump objectui pin f995a452 → a4cff5b (17 commits / 7 releasing changesets) — required before cutting rc.4 #6159) are absent from rc.4's record; check:objectui-pin-fresh (required on chore: version packages (rc) #4935) never ran because the lane didn't go through chore: version packages (rc) #4935. That is the v16 loss shape recurring — second occurrence evidence for the root-cause issue.

Why this must be fixed before anything else in the release lane

main's package.json still say 17.0.0-rc.3, so every regeneration of changeset-release/main computes rc.4 again — a version npm now already has. The branch has in fact regenerated after the publish (head a1e65f22 ≠ a10cbc77), so ⚠️ merging #4935 as it stands is the collision trap, not the fix. Do not merge #4935 and do not run the publish lane again until this issue closes.

Remedy (measured, clean)

git merge-tree --write-tree origin/main a10cbc77 → exit 0, no conflicts. So:

1. Push the published commit as a branch: git push origin a10cbc77a1e83a382d4a190879b39d588435a04d:refs/heads/release/rc4-merge-back
2. Open a PR (base main), label skip-changeset (release bookkeeping; .changeset/** must not be touched beyond what the commit itself carries), land it through the merge queue.
3. After it lands, changeset-release/main regenerates from rc.4 state → chore: version packages (rc) #4935 becomes the rc.5 PR, and the dry-run check is simply "does chore: version packages (rc) #4935 now propose rc.5?".

Ordering vs #6159 (console bump): independent — its changeset is a new file, no conflict either way; it now targets rc.5 (see note there).

Related

#6135 / #6149 (rc.3 instance + field-level reconciliation) · root-cause issue: see the companion issue filed together with this one · #6159 (missed window) · #3340 (the gate the bypass skipped) · #4935

[hotlong]

⛔ Ordering flip — do NOT execute the merge-back until the Release workflow is contained.

Root cause is now confirmed on #6170 (with evidence): release.yml runs on every push to main, and its recover-publish step publishes whenever the computed next version is absent from npm — the workspace it reads is the one the changesets action just moved to the freshly versioned state. Nobody clicked anything for rc.3 or rc.4.

Consequence for this issue: merging a10cbc77 back sets main's versions to rc.4, so the very next push to main would compute rc.5 → absent from npm → auto-publish rc.5, repeating the incident one version later.

Revised sequence:

1. Containment first: maintainer disables the Release workflow (one click), or 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's workflow fix lands;
2. Then this merge-back (still clean per merge-tree);
3. changeset-release/main regenerates as the rc.5 PR. Per the maintainer's ruling recorded on 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 (版本发布必须人工), merging that PR — i.e. releasing — is a human-only action; no AI seat performs it.

The body's "do not merge #4935 / do not run the publish lane" instruction stands, with the sharper reason: the lane runs itself on every merge — refraining from running it is not enough; it must be disabled or fixed.

---

Generated by Claude Code

[hotlong]

Claim: PM session (sequence step ② of the maintainer-approved plan; unblocked by #6172 merging — the push lane is now structurally unable to publish, so landing this merge-back can no longer auto-mint rc.5)
Session: session_01BickTBKm2JYSNnrtPT8ysa
Branch: claude/issue-6169-rc4-merge-back (will point at a10cbc77 verbatim — byte-true merge-back, no authored changes)
Worktree: objectstack-issue-6169
Domain: release bookkeeping (the publish commit's own file set) — maintainer-directed sequence from chat
File surface: exactly what a10cbc77 carries — 68 package.json version fields, compiled CHANGELOGs, .changeset/pre.json (153 files). ⛔ no hand edits on top.
Container judgment: S (pushing an existing commit + read-only verification) → mode:subagent, shared container
Serial constraints cleared: in-flight #6173 (#6159 pin bump) touches .objectui-sha + one NEW .changeset/*.md — disjoint from this commit's set (pre.json is a different file; CHANGELOGs are untouched by #6173). #6172 (merged) touched .github/workflows/ only — merge cleanliness re-verified at execution. skip-changeset applies at review (release bookkeeping; the commit carries its own pre.json update, no new changeset by design).

---

Generated by Claude Code

[hotlong]

Review: ACCEPT → PR #6177, flipped ready and queued.

• Byte-true property verified end to end: remote branch sha == PR head sha == a10cbc77a1e83a382d4a190879b39d588435a04d == the single distinct peeled target of all 69 *@17.0.0-rc.4 tags. One commit, zero authored changes. This matches my own independent measurement from the incident investigation.
• Content taxonomy has zero outliers: 76 package.json (68 own-version bumps rc.3→rc.4 + 8 private workspaces' dep ranges), 76 CHANGELOG.md, 1 .changeset/pre.json (parses; mode=pre, tag=rc, 1269 consumed ids). No .changeset/*.md deletions (correct for pre mode); content/docs/releases/ confirmed untouched.
• Premises re-verified against current main (b9ebb929, i.e. after docs(pm-dispatch): steward pin-watch mechanical output + Guardrails「版本发布必须人工」(#6162, #6170) #6164/fix(release): 发布必须人工 —— push 车道结构性无发布能力,recover 只看 github.sha (#6170) #6172): main still rc.3; merge-tree still conflict-free re-run immediately before push; no competing PR (CI's duplicate-claim gate green).
• Safety precondition held: fix(release): 发布必须人工 —— push 车道结构性无发布能力,recover 只看 github.sha (#6170) #6172's two-lane release.yml is on main — the push run after this merges can only regenerate the version PR (as rc.5) and audit; publishing requires a human dispatch + environment.
• CI converged green (TypeScript 07:35:30Z incl. every generated-artifact gate; ESLint 07:23:27Z; Test Core 1–3; Dogfood gates; Temporal Conformance; lockfile byte-identical under --frozen-lockfile). The one red Check Changeset run is the documented label race, superseded by the post-label runs reporting skipped (the exempt path — skip-changeset correctly applied: this commit carries its own pre.json bookkeeping; a new changeset would be wrong by design).
• Nothing was published, no tags pushed, no workflow dispatched — per the 版本发布必须人工 guardrail.

Acceptance signal after merge (will verify and confirm here): #4935 regenerates as the rc.5 proposal, and the first push run's release-integrity stays quiet (main = rc.4, already on npm). Merging #4935 — i.e. releasing rc.5 — remains a human-only action.

---

Generated by Claude Code

[hotlong]

Acceptance signal verified — incident closed. Post-merge measurements (2026-08-07 ~08:18Z, artifacts first, run conclusions second):

• main (bd19133 = chore(release): merge back the real 17.0.0-rc.4 publish commit a10cbc77, byte-true (#6169) #6177's queue merge) carries 17.0.0-rc.4 (cli + spec verified) with the full compiled CHANGELOGs and pre.json bookkeeping — code now matches npm.
• changeset-release/main regenerated (0a22ac1): chore: version packages (rc) #4935 now proposes 17.0.0-rc.5 (cli + spec verified in the branch tree). The collision trap is gone.
• Nothing was minted: zero rc.5 tags on the remote; @objectstack/cli@17.0.0-rc.5 absent from npm; dist-tags.rc still 17.0.0-rc.4. The push run for the merge-back (31159559325) concluded success with release-integrity on the quiet path.
• One earlier red run (07:52Z, in the 3-minute window between fix(release): 发布必须人工 —— push 车道结构性无发布能力,recover 只看 github.sha (#6170) #6172 and chore(release): merge back the real 17.0.0-rc.4 publish commit a10cbc77, byte-true (#6169) #6177) is explained and recorded as a finding: the integrity job correctly surfaced the rc.3 GitHub-Releases hole while main still lacked rc.3's changelogs — transient by construction, cannot recur. See the finding issue filed alongside this comment.

Per the ruling on #6170: releasing rc.5 (merging #4935 / dispatching the publish lane / approving the release environment) is human-only from here.

---

Generated by Claude Code