v17.mdx 缺 rc.1 之后两次 console pin 移动的窗口段落(页面自述「that range needs its own section」未兑现)

[hotlong]

观察类记录(finding,不入队)。在 #6106 / PR #6109 的工作中如实撞到,不属于该单范围,已按纪律只报不改。

事实

content/docs/releases/v17.mdx 的窗口段落停在 ## Landed since 17.0.0-rc.1。该段开头原本写着(PR #6109 修正前):

The Console pin is **unchanged** at `785b8a5d432c` … (If `scripts/bump-objectui.sh`
advances the pin before the cut, that range needs its own section — objectui `main`
has moved past `785b8a5d432c`.)

pin 此后确实动了两次:785b8a5d432c → f5bc4c78be76(31 个 non-merge commit)→ f995a452d2ca(98 个),合计 129 个;实测 git rev-list --count --no-merges 785b8a5d432c..f995a452d2ca = 129,与两份 pin changeset 自报的数字吻合。但页面没有为这两次移动新增窗口段落 —— 也就是页面给自己定的规则没有兑现。

PR #6109 做了什么、没做什么

• 做了:把 rc.0 窗口那条 console 段标题的区间推到 → f995a452d2ca,补一句指向两份 pin changeset 的说明,并把 rc.1 段开头那句已成假的「pin unchanged」按事实改写。事实层面该页现在是诚实的。
• 没做(有意):没有按页面自述新建 rc.2/rc.3 窗口段落,也没有把新增的 129 个 commit 逐条展开进正文列表。那是发布记录的编纂工作,属于「发布时集中撰写」的范畴(CLAUDE.md 第三条),不该由一个 docs-only 修正 PR 顺手扩张。

为什么是观察类而非缺陷

今天没有用户会撞到:两条真正会影响升级者的破坏性迁移已由 PR #6109 收进「Breaking changes & migration」,pin 区间与说明也已指向两份 pin changeset。剩下的是结构与页面自述规则的偏离 —— 要不要为 rc.2/rc.3 各起一段、还是在 rc.4 发布时统一重编,是编纂决定,交分诊。

关联

• rc.4 发布前置:v17 升级指南收录两条 console 破坏性迁移 + console 段 pin 区间行更新 + vendored changeset 的 flow 条目补 BREAKING 标注 #6106 / PR docs(releases): v17 升级指南收录两条 console 破坏性迁移,console 段 pin 区间推到 f995a452d2ca (#6106) #6109(缺口的取证与修正出处)、PR chore(console): 刷新 objectui pin 到 f995a452d2ca —— 98 个 commit / 64 条 releasing changeset / 2 项 v17 破坏性变更进入 v17 #6097(pin 推进)
• objectui pin bump 生成的 console changeset 对破坏性变更零标注 —— digest 只认 major 声明级别,而 objectui 在 v17 窗口内把破坏性声明为 minor + 正文标注 #6099 —— digest 只读首段的机制盲区(另一条同源记录)

[claude]

Findings triage — verdict: HOLD (keeps finding; routing label domain:devx added, since content/docs/** is that lane's surface if this is ever promoted).

Stale-premise check: the factual half is already closed. PR #6109 rewrote the now-false "pin unchanged" sentence, pushed the rc.0 window's console range to f995a452d2ca, and pulled the two breaking migrations into "Breaking changes & migration". Nothing on the page asserts something untrue today.

Why held rather than promoted, and this is the decisive reason: what remains is release-note compilation — whether rc.2/rc.3 get their own window sections or the range is re-compiled at the v17 cut. CLAUDE.md's third inlined rule puts that work at release time, centrally, and explicitly out of code PRs (content/docs/releases/ is the repo's hottest conflict magnet). Promoting this to pm:queue would dispatch a dev to accrete exactly the per-PR rows that rule exists to prevent. The issue is correctly filed and correctly not actionable as a dispatch.

Restart condition (so this is not a state nobody can exit): revisit at the v17 GA cut, when the release process compiles the windows — at that point either the sections exist (close as resolved) or the page's self-imposed rule is knowingly dropped and the inviting sentence should go with it. A second trigger: if the console pin moves a third time before the cut, re-check whether the pin-range sentence has gone stale again, which would be a factual defect and promotable on its own.

Related: #6106 / PR #6109 (forensics + correction), PR #6097 (pin advance), #6099 (the digest-reads-first-section blind spot from the same walk).

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

---

Generated by Claude Code

[claude]

Findings triage round (#4949 discipline): HOLD (finding kept, domain:devx unchanged) — with the gap re-measured, and it has grown.

Re-read at origin/main 4dd9cbd.

Stale-premise check

content/docs/releases/v17.mdx has not moved since the repo-wide 7f62706 sweep, so PR #6109's corrections are the current state and they still hold:

• :2049 — the rc.0 window's console heading does carry the pushed range 4a4829d0ef39 → f995a452d2ca;
• :2055-2056 — the "two later pin moves … 129 further commits, enumerated in console-f5bc4c78be76 and console-f995a452d2ca" note is present;
• :2145-2146 — the rc.1 window's formerly-false "pin unchanged" sentence is rewritten to the fact.

⇒ the page is still factually honest; what remains is the structural deviation this issue records.

What grew

The section headings are still exactly ## Landed since 17.0.0-rc.0 (:1595) and ## Landed since 17.0.0-rc.1 (:2140) — no rc.2+ window section. Meanwhile the release train has moved on: packages/spec/CHANGELOG.md now carries ## 17.0.0-rc.4 and ## 17.0.0-rc.5 sections, and the field reports arriving in objectui this week are against 17.0.0-rc.5. So the page's window sections stop at rc.1 while four further RCs have shipped — when this finding was filed the deviation was "two unrecorded pin moves", and it is now "the window structure trails the actual train by several RCs".

Why hold rather than promote

Unchanged and still correct: this is release-note compilation, and release notes are written centrally at release time. Promoting it would produce exactly the PR shape the repo's hardest documentation rule forbids — a change to content/docs/releases/ riding in as ordinary queue work. Whether rc.2–rc.5 each get their own window section or the whole range is re-edited into one at the next cut is an editorial decision for whoever compiles the notes, not a dispatchable defect. The two genuinely user-affecting breaking migrations were already folded into "Breaking changes & migration" by PR #6109, so no reader is stranded today.

Restart condition (sharpened — the previous grading left it implicit)

The next v17 release cut is when this becomes actionable and cheap: the compiler is already opening the file, already deciding the window structure, and this finding is the list of what is missing. Concretely, promote (or simply hand the compiler this issue) when either fires:

1. a release-cut task for v17 is opened — attach this as an input, not as a separate PR; or
2. someone opens a docs-only PR against v17.mdx for another reason — the window sections can ride there legitimately, since a dedicated docs PR is the one sanctioned route.

⛔ Boundary restated for whoever eventually acts: content/docs/releases/ is never touched by a code PR. This finding is an input to the release process, not a work item that can be attached to unrelated work.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code