[marchtian]

Requested by 田騏 · project thread

Clause-②: no
Metadata-protocol: none

A docs-only PR (content/docs/** plus the docs-audit list). It publishes nothing from any released package, so it carries no changeset. It does not touch the Version Packages PR #24876, and it performs no release act.

Why

I audited the 18.0 and 18.1 release docs against what shipped and what is pending:

• 18.0.0. releases/v18/18-0.mdx is still accurate. npm view on 2026-10-23 reads latest = 18.0.0 and next = 18.0.0-next.5. Two pages around it had drifted:
  • Upgrading → "Upgrading to 18.0" describes three behaviours that only exist on main and gives them no version: fix(cli)!: refuse a production os serve that composes no organization object, --server or not #25155 (--no-server is no longer a way round the auth refusal), fix(cli)!: refuse a production os serve whose @objectstack/plugin-auth fails to load, naming the load error #25231 (a plugin-auth load failure is refused) and feat(cli): os migrate plan lists the tenant columns still nullable, naming the voluntary ownership ceremony; the ceremony reports a NOT NULL shard truthfully #25179 (os migrate plan lists nullable tenant columns). A reader on 18.0.0 is told about refusals that 18.0.0 does not make.
  • Versioning policy. Backward Compatibility says "the window closes at GA, and strict SemVer resumes from that point", and that a PATCH has "no behavior changes". The releases index says "A patch release fixes bugs." Ruling A (changeset levels: minor only when the metadata protocol changes (added / narrowed / semantic), patch otherwise; release notes grouped by what the reader must do (maintainer ruling A, 2026-10-21) #25105, 2026-10-21) keeps the no-major guard and grades by the metadata protocol, so after 18.0.0 a non-protocol breaking change ships as patch. 18.1.0 is a minor that carries 82 changesets declared breaking, 37 of them graded patch, fix(plugin-auth)!: a cloud-managed environment refuses local self-registration, invitations (resends included), user creation and import, and sets passwords only on local accounts #25399 among them. A ^18.0.0 range takes it unattended.
• 18.1.0. No page existed. I rehearsed pnpm run version in a throwaway clone of main (2581efb). It produces 18.1.0 across 73 packages with 227 distinct CHANGELOG entries. Every content gate the publish lane runs is green on that tree. The one exception is check-release-section-coverage, which is advisory: "NO heading on this page names the 18.1 series".
• ADR-0087. The registry is complete. check-adr-0087-registration --list shows 82 declared-breaking changesets, all 82 with a disposition and 0 residue: 9 registered, 7 already-registered, 61 no-migration-prescription, 4 runtime-export-retired and 1 runtime-interface-only. check:upgrade-guide and check:spec-changes both generate cleanly.

What changes

• releases/v18/18-1.mdx (new). The 18.1.0 notes, compiled from the changesets, with the entries grouped by classifyReleaseBullet as the GitHub Release body groups them:
  • 73 entries need action from the reader, 9 are converted, 41 are new capabilities, 0 are semantic and 104 are fixes.
  • The page adds a Console section (pin 616df6598b42 → 1d178e06ac5e, six refreshes, 91 objectui entries) and an upgrade checklist from 18.0.0.
  • Two callouts say the page was compiled before the cut and has not been walked.
  • The cloud-managed break (fix(plugin-auth)!: a cloud-managed environment refuses local self-registration, invitations (resends included), user creation and import, and sets passwords only on local accounts #25399) gets its own section, which says self-hosted deployments are unchanged.
• upgrading.mdx.
  • The three post-18.0.0 behaviours now say "from 18.1.0".
  • The per-release table gains a 18.1.0 row.
  • The sentence "a minor has nothing for os migrate meta to replay" now notes the nine step-18 conversions that 18.1.0 adds.
• protocol/backward-compatibility.mdx, releases/index.mdx, releases/v18/index.mdx. These now state the post-GA level rule. The v18 index also links 18.1.0 and notes the 18.1.0 tightening of the auth-secret refusal.
• releases/v18/18-0.mdx. It now says that a caret range takes later 18.x releases, which can break, and section 4 points at the 18.1.0 notes.
• scripts/docs-audit/handwritten-docs.json. This regenerates with --write for the new page.

The "current series" field on the releases index is left to sync-release-index-currency.mjs. On the rehearsed post-version tree it stamps 18.1.0, and check:release-notes, check:release-page-status, check:doc-anchors and the section-coverage check are all green.

Follow-up after the publish

These are not in this PR:

• A "Release facts, as measured" section, filled in with npm view after the publish.
• A walked 18.0.0 → 18.1.0 checklist, which replaces the "not walked" callouts.

Verified locally

• check:doc-anchors, check:docs-single-h1, check:docs-redirects, check:docs-audit-scope, check:release-notes, check:release-page-status, check:release-index-currency-sync, check:published-readme-links and check:nul-bytes are all green.
• An MDX 3 + GFM compile of the six edited pages passes.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json b2c075290092603aa4cf11948989f452059e9195 → packageMentionDocs.