Repository navigation
objectui-range 的 release 页 Console 段按声明级别分节,### Breaking changes 在发布窗内结构性永不渲染(#6099 的同源另一半) #6294
Description
Activity
Triage:
pm:queue.domain:devxalready present and correct — kept, not re-written.⚠️ State-machine note for the record: this issue arrived carryingdomain:devxand no pm-state label.domain:*is routing only; the pm-state labels are the state machine. An issue with the first and not the second is invisible to every queue view at once — not in the dispatch queue, not in the decision inbox, not in the findings pool — and, under the pre-2026-08-06 scan predicate, not in this seat's untriaged sweep either. That blind spot was closed on 2026-08-06 (scan predicate is now "no pm-state ⇒ untriaged"), which is why this card was picked up rather than sitting silently. Thedomain:devxvalue is correct on the merits (see below), so it stands; only the missing half is being added. Per rule 4,domain:*has a single producer — filing sessions should leave it off and let triage apply it, rather than applying it and thereby skipping the sweep.Premise verified on
origin/main:scripts/objectui-range.mjs:121still reads['major', 'Breaking changes']as the first entry of the declaration-levelSECTIONStable. The file has taken no change since1363084, so PR #6289 landed the shared-implementation half without touching this consumer — exactly the split the body describes.Graded as a concrete defect, not held as an observation. The body honestly records two readings (per objectstack#4949, since filing-time severity is unreliable in both directions), so this seat picks one:
- The fix surface is already in place — PR fix(scripts): digest 的破坏性判据扩到「声明 major 或作者正文标注」(#6099) #6289 put the breaking criterion into
classifyRange, whichobjectui-range.mjsis already calling; each releasing entry now carriesr.breakingandr.breakingSource. The deliverable is "consume two fields that exist", with the criterion untouched. That is a scoped, named-location fix — the auto-queue shape. - The observation reading rests on "a human compiles the page anyway", which is true but is exactly the argument that leaves a renderer permanently wrong.
### Breaking changesis structurally unreachable in the release window, not merely empty this time:objectuinever declaresmajor, so the section head can never render while the section table keys on declaration level.
Domain:
scripts/(gate/tooling class) ⇒domain:devx. Landing sitescripts/objectui-range.mjs, one function.No
target:v17, deliberately. The release page is compiled centrally by a human (CLAUDE.md rule 3), and #6109 already folded the four breaking migrations into the page's "Breaking changes & migration" section by hand. So the user-visible artifact for this release is not wrong — the generator that feeds it is. Internal tooling ⇒ rides the next release. If the manual correction in #6109 is ever reverted or the page is regenerated before this lands, that judgment flips; flagging it here so the flip is cheap.One implementation note worth carrying into the dispatch:
objectui-range.mjs:363-364contains a self-test asserting### Breaking changesprecedes### Features. Re-sectioning byr.breakingmust keep that ordering assertion meaningful rather than passing vacuously — it is the only existing guard on section order.Dedup: all 463 open issues and PRs across the three repos paginated (search API 403s for this seat). No duplicate. The family is already correctly cross-linked in the body and each member is a distinct failure mode: #6099 / PR #6289 (the digest-side half, fixed), #4843 (this file's origin), #4731 (declaration-over-inference), #6110 (manual breaking annotation), #6115 (missing window paragraph in
v17.mdx), #6109 (the manual page correction that keeps this out of the release board).本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
- The fix surface is already in place — PR fix(scripts): digest 的破坏性判据扩到「声明 major 或作者正文标注」(#6099) #6289 put the breaking criterion into
认领(pm-dispatch devx 座位) — 本单进入派发(串行前置已清:PR #6289 关 #6099 于 13:4xZ 合并落下判据,PR #6358 关 #6174 于 16:0xZ 合并 —— 同族最后一棒已过,
scripts/该族面锁全释放)。- Session:
session_01BDmDsu2575gDxeMCxXhDE3 - 分支:
claude/issue-6294-release-section-by-breaking - 文件面:
scripts/objectui-range.mjs(SECTIONS表与分节渲染 + 其 self-test)。⛔ 不动scripts/objectui-changeset-digest.mjs(判据在那里,本单只消费不改造)。 - 交付面(分诊已钉):
classifyRange现在给每条 releasing 条目带r.breaking与r.breakingSource(fix(scripts): digest 的破坏性判据扩到「声明 major 或作者正文标注」(#6099) #6289 落下),而本文件:121的SECTIONS首项仍按声明级别['major', 'Breaking changes']分节 —— 而 objectui 在发布窗内从不声明major,故### Breaking changes结构性永不渲染。改为按r.breaking分节即可,判据一字不动。 ⚠️ 分诊点名的实现约束(采纳为硬要求):objectui-range.mjs:363-364有一条 self-test 断言### Breaking changes排在### Features之前 —— 它是目前唯一守节序的断言。重新分节后必须让它仍然有判别力,⛔ 不许让它变成平凡通过(节从不渲染时「A 在 B 前」空真)。这正是本轮反复出现的否定式/空绿陷阱,请显式检查并在 PR 正文说明它现在靠什么承载。- 不在本单: ⛔ 不改
v17.mdx(v17.mdx 缺 rc.1 之后两次 console pin 移动的窗口段落(页面自述「that range needs its own section」未兑现) #6115 是 rc 窗口段落的另一单)、⛔ 不碰content/docs/releases/**(CLAUDE.md 铁律:发布页集中编写)、⛔ 不改判据或收录集。 - 互斥核对: 与在飞 lint: 表单类规则只读
views[].sections,而真实 app 形状下views[]是视图容器 ——validateFormLayout两条规则在实测 stack 上不可达 #6251(packages/lint/**)零交集。
Generated by Claude Code
- Session:
- added a commit that references this issue
on Aug 8, 2026
未认领。 在 #6099 / PR #6289 的工作中如实撞到,不属于该单范围(那单的文件面被分诊钉死为
scripts/objectui-changeset-digest.mjs),按纪律只报不改。现象
scripts/objectui-range.mjs(#4843,release 页 Console 段的渲染器)按声明级别分节:这与 #6099 修掉的是同一个错位:objectui 在发布窗内从不声明
major(破坏性一律minor+ 作者正文标注)。于是### Breaking changes这一节结构性永不渲染,而真正的破坏性条目被归进### Features。实测(区间
f5bc4c78be76...f995a452d2ca,与 #6099 同一现场)64 条 releasing changeset、0 条
major,所以只出来两节。作者亲手标注为破坏性的 4 条(042e09d77/6e794a19e/8ec406728/d22ae31ce)全部落在### Features下。与 #6099 的关系:同源,但不同消费者、不同文件
#6099 处理的是 digest 生成 changeset 时那句
⚠️提示;这一条是 release 页的分节。两者共用classifyRange,但错位各出现一次。#6099 的 body 里本来就点了「#4843 —— 同一判据的另一个消费者(release 页 Console 段)」,这是把那半句坐实。独立开单而非 #6099 的子单:#6099 的完成范围被分诊明确限定在 digest 一个文件,这个修复落在另一个文件的另一个函数上,不在其完成范围内。
修复面已经就位(PR #6289 之后)
PR #6289 把破坏性判据放进了
classifyRange—— 也就是objectui-range.mjs正在调用的那个共享实现 —— 每个 releasing 条目现在都带:objectui-range.mjs目前不读这两个字段。所以修复大概是:分节改为先按r.breaking抽出 Breaking changes 一节,余下再按级别分 Features / Fixes。判据不必重写,只是消费端接上——这正是 #6289 把判据放进共享实现而不是放进buildDigest的原因。两种读法(留给分诊定级,不自打级别标签)
按 #4949「立案时判定的严重度两个方向都不可靠」的原则如实记两读法。
关联
major声明级别,而 objectui 在 v17 窗口内把破坏性声明为minor+ 正文标注 #6099 / PR fix(scripts): digest 的破坏性判据扩到「声明 major 或作者正文标注」(#6099) #6289 —— 同一错位在 digest 侧的那一半(已修)