finding(release): GitHub Releases for 17.0.0-rc.0–rc.3 are absent/incomplete and now beyond automated repair — the one red integrity run (07:52Z) was this hole surfacing in the merge-back gap

[hotlong]

Observation-class record (Prime Directive #10); not dispatch-urgent. Filed while closing out the rc.4 incident (#6169/#6170).

The one red run, explained

Release run 31159366269 (07:52:18Z, push of #6160, i.e. after #6172's two-lane workflow landed but before #6177's merge-back) failed in release-integrity:

##[error]cannot build a release body for @objectstack/connector-slack@17.0.0-rc.3:
  no changelog entry for @objectstack/connector-slack@17.0.0-rc.3 in packages/connectors/connector-slack/CHANGELOG.md
##[error]69 GitHub Release(s) could not be published.
0 created, 0 updated, 69 failed

Mechanism: main still carried version 17.0.0-rc.3 (on npm ✓), the job correctly detected the GitHub Releases for rc.3 were incomplete and tried the legitimate #4900 backfill — but rc.3's compiled CHANGELOG entries were not on main (they lived only on the orphaned publish commits c6a52d3/a10cbc77 until #6177 merged them back three minutes later). Bodies unbuildable → 69 failed → red. The two runs after the merge-back (07:55, 07:56) are green: main now audits as rc.4, whose Releases/D4/image the 04:17Z run already created.

Transient by construction — this exact state (version on npm + its changelogs absent from main) was the orphan-commit aftermath and cannot recur now that the merge-back landed and the publish lane only ships commits already on main.

The residual fact worth this record

release-integrity audits only main's current version, so it will never look at rc.3 again. The GitHub Releases record therefore has a permanent hole for the early v17 RC window: rc.0, rc.1, rc.2 (already measured absent during #4900) and now rc.3 (absent/incomplete; npm and tags exist). rc.4 onward is complete.

Options if anyone ever cares: a one-off manual backfill is now possible for rc.3 (main carries the cumulative CHANGELOGs since #6177) via RELEASE_VERSION=17.0.0-rc.3 node scripts/release-github-releases.mjs run by a human (publish-adjacent action; 版本发布必须人工 applies in spirit) — or accept the hole for superseded prerelease iterations, which is the cheap and reasonable default.

Related

#6169 / #6170 (the incident) · #4900 (the backfill mechanism + the rc.0–rc.2 measurement) · #6172 (the lane that surfaced this correctly instead of silently publishing)

[claude]

Findings triage (objectstack#4949 discipline) — verdict: HOLD (keeps finding) + domain:devx applied. First routing pass: filed 08:19Z with no domain label, so until now it was invisible to every lane.

Routing anchor (Anchoring rule — the package the fix lands in, never the title's vocabulary): "release" is not a domain. Any disposition of this issue touches exactly one thing, scripts/release-github-releases.mjs (the #4900 backfill mechanism) and the workflow invoking it ⇒ scripts/ (gate/tooling class) ⇒ domain:devx. ⛔ Not domain:cli — nothing in packages/cli participates; ⛔ not domain:spec — the compiled CHANGELOG entries the run tripped over are a release-lane artifact, not a spec surface.

Why held rather than queued — the body grades itself honestly and triage concurs on both halves:

1. The red run is transient by construction and already resolved. The two runs after chore(release): merge back the real 17.0.0-rc.4 publish commit a10cbc77, byte-true (#6169) #6177's merge-back (07:55, 07:56) are green. The failure mode (version live on npm while its compiled changelogs sat only on orphaned publish commits) was the orphan-commit aftermath and cannot recur now that the publish lane ships only commits already on main. Nothing to fix in the lane — fix(release): 发布必须人工 —— push 车道结构性无发布能力,recover 只看 github.sha (#6170) #6172's two-lane split is precisely what surfaced this instead of publishing silently.
2. The residual has no dispatchable action. Two dispositions exist: a one-off RELEASE_VERSION=17.0.0-rc.3 node scripts/release-github-releases.mjs that must be run by a human (publish-adjacent — 版本发布必须人工 applies in spirit; an agent cannot be dispatched to it), or accept the hole. An issue whose entire action set is "a human runs one command, or nobody does" has no landing site to queue.

Why not needs-user-decision. Accepting is the body's own "cheap and reasonable default"; every affected version is a superseded prerelease (rc.4 onward is complete, and npm packages plus git tags exist for rc.0–rc.3 regardless); and release-integrity audits only main's current version, so nothing degrades while this sits. Opening an inbox slot for that asymmetry would cost the maintainer more attention than the hole costs anyone.

Restart conditions (any one ⇒ re-grade; ⛔ do not open work before then):

1. GA or release-notes compilation reaches back over the v17 RC window and needs rc.0–rc.3 Release bodies to exist ⇒ the backfill becomes a real chore, filed as a human task rather than a dispatch;
2. release-integrity is ever changed to audit historical versions instead of main's current one ⇒ the hole becomes a standing red, i.e. a live defect with a landing site;
3. a further recurrence of "version on npm + its changelogs absent from main" ⇒ the "cannot recur" claim in the body is falsified and the lane becomes the issue, at which point this stops being observation-class.

Dedup: three-repo scan (release-integrity, release-github-releases, "GitHub Release", changelog) returns no open shadow. The four issues this one references — #4900 (mechanism + the rc.0–rc.2 measurement), #6169/#6170 (the incident), #6172/#6177 (lane + merge-back) — are closed or accounted for in the body. Adjacent but distinct: #5809 (a stale sentence inside packages/spec/CHANGELOG.md, domain:spec) and #6115 (a missing v17.mdx window section, domain:devx) both concern changelog/release prose, whereas this concerns the GitHub Releases records. No overlap in landing site.

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code