docs(releases): the v16 line has two content gaps — 16.1.0 is documented on no page at all, and two changesets released at the 16.0.0 GA cut appear nowhere

[os-project-manager]

Filed by the domain:devx seat (#6023) from measurements made while landing #8886 / PR #8912. Unassigned. ⛔ No domain:* set — triage's field.

Both gaps were found by the dev on #8886 and deliberately not fixed there: the card's surface was the status line and the index entry, and writing missing release notes on a release-owned page is a different act with a different owner. PR #8912 is careful to leave the page not false about either — it names 16.1.0 as the line's final release and says plainly that the minor is not covered there.

Gap 1 — 16.1.0's content is documented on no release page

16.1.0 shipped 8 changesets (5 minor, 3 patch). The headline is #3366 — the CLI/spec preflight that every requires capability has an installable provider in the current edition.

v16.mdx documents the 16.0.0 content and does not mention 16.1 anywhere. There is no v16.1 page. So a released minor with a real user-facing feature has no release notes at all.

⚠️ This is a policy question before it is a docs task, which is why it is filed rather than fixed: does a minor get folded into its major's page (the shape v15 used — "15.1 adds …" in its index entry), or does it not get documented, deliberately? The v15 precedent says folded. ⛔ Whoever takes this should settle that first, because the answer decides whether this is a paragraph or a section.

Gap 2 — two changesets released at the 16.0.0 GA cut appear nowhere on the page

Measured as the changeset-id set present in the ## 16.0.0 changelog sections but absent from both ## 16.0.0-rc.0 and ## 16.0.0-rc.1:

changeset	content
db34d54	Console refreshed to 9a5f016f7d5c — a further pin move past af1b0db
8ff9210	spec: enforce the ViewFilterRule operator enum, with legacy-alias handling

⚠️ 8ff9210 is the more interesting one: enforcing an operator enum is an accept-set narrowing on a published surface, which is the class this repo treats most carefully, and it shipped in a GA with no release-note line.

⛔ The page is not made false by these omissions — PR #8912's closed window opener makes no claim either way about them, deliberately. This is a completeness gap, not a factual error, and it should not be conflated with #8916 (which is factual staleness).

Constraints for whoever takes this

• content/docs/releases/ is release-owned: release notes are written centrally at release time. ⇒ a dedicated docs-only PR, ⛔ never a rider on code. docs(releases): record the 16.0.0 GA cut and the closed v16 line #8912 is the worked precedent for shape.
• ⚠️ Adding content to a release page is closer to writing release notes than to correcting a fact. It may warrant the maintainer's call on whether an AI seat should author it at all — flagging that rather than assuming either way.
• Related but distinct: docs(releases): v9, v12 and v14 status lines are stale against their own last tags — three more instances of the class #8892 is about to gate #8916 (v9/v12/v14 status lines factually stale, and a prerequisite question for the gate: nothing fails when a GA'd major's release page still describes itself as a pre-release — the gap that let v17 and v16 both ship with stale status #8892 gate). ⛔ Do not merge these two cards — one is completeness, the other is correctness.

Provenance

Both measured by the dev on #8886 via changeset-id set arithmetic across the package changelogs' ## 16.0.0* sections; reported to this seat rather than filed by the dev, per that dispatch's (mistaken — see #8886 thread) instruction. Dedupe: reported unfiled with a positive control confirming the search instrument was live.

[os-project-manager]

Triage: escalated to the decision inbox (needs-user-decision, domain:devx). Why it clears the escalation bar rather than the repair lane: retroactively adding content to a release page is authoring release notes on a release-owned surface (content/docs/releases/ is written centrally at release time), and whether an AI seat may author that at all is the maintainer's call — the card itself flags exactly this. Prisms split (④ against, ①/② for), so not auto-adjudicable.

Four-prism block:

• Platform long-term coherence: a released minor with a real user-facing feature (16.1.0 / Preflight that required capabilities have an installable provider in the current edition #3366) documented nowhere is a standing incoherence; v15 set the precedent that a minor folds into its major's page.
• Measured business pull: modest but real — 16.x users have no notes for a shipped feature, and changeset 8ff9210 narrowed an accept set (ViewFilterRule operator enum) in a GA with no release-note line, which is apology-class content.
• AI-agent error-resistance: the content would be strictly changeset-derived (verifiable against the changelogs), but AI-authored prose on release-owned pages is precedent-setting in either direction.
• Startup scope discipline: paragraph-scale one-time work if held to changeset facts; the risk is silent expansion into "write missing release notes generally" — the card already warns against it.

Recommendation: approve a strictly changeset-derived fold — a short 16.1.0 section (or index-entry sentence, v15 house style) in v16.mdx naming #3366's capability preflight, plus two line items for db34d54 / 8ff9210 in the 16.0.0 section, with 8ff9210 explicitly labeled an accept-set narrowing; dedicated docs-only PR; nothing beyond what the changesets state. Alternative if you prefer human authorship of release prose: rule "maintainer authors, seats only file the gaps" — then this card closes into a one-line policy note and #8916-class cards stay the only seat-fixable kind.

⛔ Not dispatchable while needs-user-decision is on. Related but deliberately separate: #8916 (factual staleness, already queued).

Triage: this comment is from the triage seat (scheduled run) — no claim.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling (2026-08-16, recorded by PM session session_01NYgmGheCzM6NrHZN436Cxf). The maintainer approved the report's recommendation for this card (「主线1 3 4：同意」).

Ruled: the strictly changeset-derived fold is approved — an AI seat may author this one.

Scope pins (from the triage recommendation, now binding):

• A short 16.1.0 section or index-entry sentence in v16.mdx per the v15 house style, naming Preflight that required capabilities have an installable provider in the current edition #3366's capability preflight.
• Two line items for db34d54 / 8ff9210 in the 16.0.0 section, with 8ff9210 explicitly labeled an accept-set narrowing (ViewFilterRule operator enum).
• Nothing beyond what the changesets state — content must be verifiable against the package changelogs.
• Dedicated docs-only PR (release pages are never a rider on code); docs(releases): record the 16.0.0 GA cut and the closed v16 line #8912 is the shape precedent.

Policy boundary, on the record: this approval is per-card, not a general license — release prose otherwise remains centrally written at release time; future gaps of this class still come through the inbox. ⛔ Keep #8916 (factual staleness) separate, as filed.

Label flipped needs-user-decision → pm:queue in the same stroke.

---

Generated by Claude Code