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

[os-project-manager]

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

⚠️ Read this before #8892 is dispatched. It changes that card's shape.

The measurement (origin/main @ 85f5e78, 2026-08-15T16:29Z)

Each page's status line vs. the last @objectstack/spec tag of its own major:

page	says	last tag	verdict
v9.mdx:6	"All @objectstack/* packages are published at 9.0.0"	9.11.0	❌ stale, 11 minors behind
v12.mdx:6	"All @objectstack/* packages are published at 12.0.0"	12.6.0	❌ stale
v13.mdx:6	"…published at 13.0.0"	13.0.0	✅ accurate
v14.mdx:6	"Released July 2026 — current: 14.5.0 (July 13, 2026)"	14.8.0	❌ stale, and index.mdx already says (final release: 14.8.0) — page and index disagree
v15.mdx	(no status line at all)	15.1.1	➖ n/a

⚠️ v14 is the sharpest: it is stale and internally inconsistent with the index entry, and it still uses the current-series phrasing for a long-closed line.

⛔ Why this is a blocker for #8892, not a sibling of it

#8892 is the gate for exactly this defect class ("nothing fails when a GA'd major's release page still describes itself as a pre-release"). The sequencing plan on this seat was: land the instance (#8886/#8912), then land the gate.

That plan was wrong, and this measurement is why. v16 was not the only instance — it was the only one anybody had noticed. So:

Merging #8912 does not make main safe for #8892. Unless that gate scopes itself to the current / most-recent series, it goes red on v14, v12 and v9 the day it lands — a red main is shared damage every lane pays for.

⇒ #8892 must do one of these, decided as part of its own design:

• A — scope the gate to the current (and possibly most-recent-closed) series, and say in the gate's own text why older pages are out of scope; or
• B — treat this card as a hard prerequisite: fix v9/v12/v14 first, then land an all-majors gate; or
• C — land the gate with an explicit, enumerated baseline for the three known-stale pages, in the repo's shrink-only style, so they are recorded rather than silently tolerated.

⛔ Do not land #8892 without picking one deliberately. ⚠️ C is the option most likely to be reached for and least likely to be right by default — a baseline that starts with three entries on a brand-new gate is a gate that ships pre-compromised; it is only defensible if someone states why those three should stay stale.

Scope of a fix, if B is chosen

Docs-only, and content/docs/releases/ is release-owned — so the sanctioned route is a dedicated docs-only PR, ⛔ never a rider on code. #8912 is the worked precedent for the shape (status line rewritten as shipped, index entry moved to the (final release: X) house style used by v15/v14).

⚠️ Note from #8912's dev, worth carrying: fixing a status line honestly may surface that a minor's content is documented nowhere. Deciding how much to document is a scope question for whoever takes it — ⛔ do not let it silently expand into writing missing release notes.

Provenance and dedupe

Measured by the dev on #8886 while sweeping its own page for other pre-mode framing (a Zone-2 instruction), then re-verified independently by this seat against git tag --list before filing — the numbers above are mine, not inherited.

Dedupe: the dev reported no open issue matches, with a positive control confirming its search instrument was live (a control query returned #8886). ⛔ A zero-hit without a positive control would not have been accepted.

[os-project-manager]

Triage: routed domain:devx, queued (Task, docs-only). Fix surface is content/docs/releases/ status lines for v9/v12/v14 — release-owned, so a dedicated docs-only PR, ⛔ never a rider on code. Worked precedent for the shape: PR #8912.

Sequencing note for the devx seat: this card is an input to #8892's design (the A/B/C fork recorded on this card). ⛔ Do not dispatch #8892 without its dispatch prompt naming this card. No pm:blocked in either direction — the A/B/C choice belongs to #8892's own design, and this card is dispatchable independently.

Scope guard from the card, worth repeating in the dispatch: fixing a status line may surface undocumented minor content — that is #8917's (decision-gated) territory, ⛔ not silent expansion here.

Size/model suggestion: S mechanical, sonnet.

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

---

Generated by Claude Code

[os-project-manager]

✅ Maintainer ruling — scope settled, this card narrows to v14 only

Maintainer, 2026-08-15, verbatim, untranslated:

v14 之前的版本都不用管

⇒ Versions before v14 are out of scope. v9 and v12 are not to be fixed, and their staleness is now an accepted state, not an open defect.

Reading of the boundary, stated so it can be corrected in one word

I read 「v14 之前」 as v13 and earlier — v14 itself remains in scope. Two reasons, and the second is why I did not resolve the ambiguity toward the cheaper option:

1. v14 is the only page in this set that is internally contradictory: v14.mdx:6 says current: 14.5.0, while index.mdx already says (final release: 14.8.0). A reader sees both claims on the same site, and one of them is wrong regardless of whether anyone runs v14.
2. It still uses the current-series phrasing for a long-closed line — the exact defect class docs(releases): the v16 page and its index entry still say the train is published as 16.0.0-rc.0 — 16.0.0 and 16.1.0 shipped #8886/docs(releases): record the 16.0.0 GA cut and the closed v16 line #8912 just fixed for v16.

⚠️ If the intent was "v14 and earlier", this is a one-line correction and the card closes not planned instead. ⛔ I have not assumed that reading, because it is the one that produces no work, and picking the no-work reading of an ambiguous instruction is how scope quietly disappears.

What this card now is

page	says	last tag	disposition
v9.mdx:6	published at 9.0.0	9.11.0	⛔ out of scope — maintainer ruling
v12.mdx:6	published at 12.0.0	12.6.0	⛔ out of scope — maintainer ruling
v13.mdx:6	published at 13.0.0	13.0.0	✅ accurate anyway
v14.mdx:6	current: 14.5.0	14.8.0	⇒ the only work left on this card

Fix shape: docs-only, and content/docs/releases/ is release-owned ⇒ a dedicated docs-only PR, ⛔ never a rider on code. PR #8912 is the worked precedent — status line rewritten as shipped, index entry already correct here so likely untouched.

⚠️ Carry the trap #8912 hit: fixing a status line honestly can surface that a minor's content is documented nowhere (that is #8917 for the v16 line). ⛔ Do not let "correct the status line" silently become "write the missing release notes" — report it if you find it.

Consequence for #8892 — the gate can now be scoped

This ruling is what that card was blocked on. Recorded there; summary: the gate covers v14 and later, the cutoff is stated in the gate's own failure text, and this card's v14 fix lands before the gate so main never goes red on it.

---

Generated by Claude Code

[os-project-manager]

⛔ SUPERSEDES my comment above (5305269360) — closing not planned

Maintainer, 2026-08-15, verbatim, untranslated — this is the operative ruling:

只负责 v16 以后的，需要的话之前的版本删除也可以的

⇒ Only v16 onward is maintained. Everything this card is about — v9, v12, and v14 — is out of scope.

⚠️ My comment above read the earlier 「v14 之前的版本都不用管」 as leaving v14 in scope, and argued for fixing it because the page contradicts its own index entry. That reading is now moot. The cutoff is v16, not v14. ⛔ Do not implement anything from that comment — it is superseded in full, and I am leaving it visible rather than editing it so the correction is legible.

Disposition

Closed not planned. The staleness of v9.mdx, v12.mdx and v14.mdx is now an accepted state, ⛔ not an open defect and ⛔ not a baselined one. Nobody is expected to fix them, and no gate should complain about them.

⚠️ The deletion option is recorded, not taken

The ruling also permits deleting the pre-v16 pages (「需要的话之前的版本删除也可以的」). ⛔ Not exercised here, deliberately, and this is the part worth writing down for whoever revisits it:

• Deletion is not a one-line docs change. pnpm check:release-notes asserts "every released major has a curated, navigable page" — deleting v9–v15 would make that gate red unless the gate is updated in the same breath. A "just delete them" PR discovers this the hard way.
• The pages are public URLs. Removing them breaks inbound links for anyone still on those lines.
• content/docs/releases/ is release-owned ⇒ any deletion is a dedicated docs-only PR, ⛔ never a rider on code.

⇒ Deletion is a real option with a real cost, and it is permitted rather than requested. If someone wants it, it is a fresh card that must name the check:release-notes coupling in its scope. ⛔ It should not be smuggled in as cleanup on some other card.

What this unblocks

#8892 is now dispatchable with no prerequisite at all. Its gate scopes to v16+, and both in-scope pages are already correct — v16 by PR #8912 and v17 by PR #8882, both merged today. Recorded there.

---

Generated by Claude Code