Measured while implementing #8917 (v16 content gaps) and deliberately not fixed there: #8917 is completeness-only and its maintainer ruling pins the surface to 16.1.0 plus the two GA-cut changesets. This is a factual correction on a release-owned page, which is the other lane. Filed unassigned.
What the page says
content/docs/releases/v16.mdx names af1b0db as the Console pin the 16.0.0-rc.1 cut landed on, in four places:
| line | text |
|---|
| 572 | "The rc.0 bundle pins 94d4876; the pin advanced to af1b0db before the 16.0.0-rc.1 cut" |
| 704 | "the console pin advanced 94d4876 → af1b0db, released as @objectstack/console 16.0.0-rc.1" |
| 713 | "Console from the objectui pin advancing 94d4876 → af1b0db (objectui #2706–#2736), bundled as @objectstack/console 16.0.0-rc.1" |
| 802 | heading: "New in Console (objectui, now bundled 94d4876 → af1b0db)" |
(Line numbers as of 422f086c2 on the #8917 branch; on main before that commit they are 535, 666, 676, 765.)
What the changelog says
packages/console/CHANGELOG.md's ## 16.0.0-rc.1 section contains four pin bumps, and each entry states its own objectui range, so they chain deterministically:
| changeset | refreshed to | stated range |
|---|
a276969 | 0318118e02fd | 94d4876df090...0318118e02fd |
bfa3c3f | 3b2e4d98d904 | 0318118e02fd...3b2e4d98d904 |
1965549 | af1b0db96e44 | 3b2e4d98d904...af1b0db96e44 |
a791200 | 69fa5d163a97 | af1b0db96e44...69fa5d163a97 |
So af1b0db is an intermediate pin inside rc.1, not the cut's endpoint. The rc.1 endpoint is 69fa5d163a97.
Independent corroboration from the other side of the boundary: the GA-cut changeset db34d54 states its range as 69fa5d163a97...9a5f016f7d5c — it starts where rc.1 actually ended.
Consequence: one Console change is documented nowhere
The window af1b0db96e44...69fa5d163a97 (a791200) carries one frontend change:
fix(app-shell): mark notifications read via the REST surface, not direct receipt writes (objectui#2743)
That is the Console half of the mark-as-read fix whose framework half (#3354) the page does document, under Landed since 16.0.0-rc.0 → New capabilities (backend). Grepping v16.mdx for 2743 returns nothing. Related closed card for the same defect: #3362.
The other two windows are fine content-wise — a276969 (objectui#2707) and bfa3c3f (objectui#2706 / #2701 / #2708) are all described on the page; only the pin arithmetic in the four lines above is wrong for them.
Suggested fix
Dedicated docs-only PR (release pages are never a rider on code — repo CLAUDE.md): correct the four pin statements to 94d4876 → 69fa5d163a97, and add objectui#2743 to the New in Console (objectui …) bullet list. The objectui issue-number range in line 713 ("objectui #2706–#2736") would want re-deriving too, since #2743 falls outside it.
⛔ Not to be conflated with #8916 (v9/v12/v14 status lines) or #8917 (v16 completeness) — both are separate surfaces, deliberately.
Provenance
Derived from packages/console/CHANGELOG.md on origin/main at 6468df115, by chaining each rc.1 entry's own objectui range line. Dedupe search run before filing (keyword + path, open issues): no open card covers it; #6115 is the closed v17.mdx analogue of exactly this defect class, which doubles as a positive control that the search instrument was live.
Measured while implementing #8917 (v16 content gaps) and deliberately not fixed there: #8917 is completeness-only and its maintainer ruling pins the surface to 16.1.0 plus the two GA-cut changesets. This is a factual correction on a release-owned page, which is the other lane. Filed unassigned.
What the page says
content/docs/releases/v16.mdxnamesaf1b0dbas the Console pin the16.0.0-rc.1cut landed on, in four places:rc.0bundle pins94d4876; the pin advanced toaf1b0dbbefore the16.0.0-rc.1cut"94d4876 → af1b0db, released as@objectstack/console16.0.0-rc.1"94d4876 → af1b0db(objectui #2706–#2736), bundled as@objectstack/console16.0.0-rc.1"94d4876 → af1b0db)"(Line numbers as of
422f086c2on the #8917 branch; onmainbefore that commit they are 535, 666, 676, 765.)What the changelog says
packages/console/CHANGELOG.md's## 16.0.0-rc.1section contains four pin bumps, and each entry states its ownobjectui range, so they chain deterministically:a2769690318118e02fd94d4876df090...0318118e02fdbfa3c3f3b2e4d98d9040318118e02fd...3b2e4d98d9041965549af1b0db96e443b2e4d98d904...af1b0db96e44a79120069fa5d163a97af1b0db96e44...69fa5d163a97So
af1b0dbis an intermediate pin inside rc.1, not the cut's endpoint. The rc.1 endpoint is69fa5d163a97.Independent corroboration from the other side of the boundary: the GA-cut changeset
db34d54states its range as69fa5d163a97...9a5f016f7d5c— it starts where rc.1 actually ended.Consequence: one Console change is documented nowhere
The window
af1b0db96e44...69fa5d163a97(a791200) carries one frontend change:fix(app-shell): mark notifications read via the REST surface, not direct receipt writes(objectui#2743)That is the Console half of the mark-as-read fix whose framework half (#3354) the page does document, under Landed since 16.0.0-rc.0 → New capabilities (backend). Grepping
v16.mdxfor2743returns nothing. Related closed card for the same defect: #3362.The other two windows are fine content-wise —
a276969(objectui#2707) andbfa3c3f(objectui#2706 / #2701 / #2708) are all described on the page; only the pin arithmetic in the four lines above is wrong for them.Suggested fix
Dedicated docs-only PR (release pages are never a rider on code — repo
CLAUDE.md): correct the four pin statements to94d4876 → 69fa5d163a97, and add objectui#2743 to the New in Console (objectui …) bullet list. The objectui issue-number range in line 713 ("objectui #2706–#2736") would want re-deriving too, since #2743 falls outside it.⛔ Not to be conflated with #8916 (v9/v12/v14 status lines) or #8917 (v16 completeness) — both are separate surfaces, deliberately.
Provenance
Derived from
packages/console/CHANGELOG.mdonorigin/mainat6468df115, by chaining each rc.1 entry's ownobjectui rangeline. Dedupe search run before filing (keyword + path, open issues): no open card covers it; #6115 is the closed v17.mdx analogue of exactly this defect class, which doubles as a positive control that the search instrument was live.