fix(text): no shipped text says the ownership ceremony is closed; an unmarked database is one 17.x or an 18.0 pre-release created

Text, pins and changesets only.

- The refusals #24710, #24709 and #24652 re-worded to "18.0 supports fresh
  installs only" name the ceremony again: LegacyOrganizationRowsUnreadable
  (metadata-core), the seed loader's unowned-holder refusal
  (metadata-protocol, now with the reviewed plan's --plan-file), the
  platform-admin WITHHELD warning and the unnamed-grant report line
  (plugin-security). Their pins assert the remedy and the absence of the
  closed-command sentence.
- The guard refusal, cli.mdx, tenancy-modes.mdx, webhooks.mdx, the
  migration.zod.ts generation note, the cli.json item and this PR's
  changeset no longer say "every 18.0 database": a database with no birth
  marker is one 17.x or an 18.0 pre-release (18.0.0-next.*) created; 18.0.0
  writes the marker itself.
- Pending changesets that announce a refusal no longer shipped are
  retired: 24651, 24710, 24709, 24652, 24637 and 15214 (whose walled bullets
  step 4 superseded). 24567 keeps only its surviving --json detail change.
- New gate check:closed-ceremony-text (lint.yml): no package source, docs
  page or pending changeset says "fresh installs only", "keep ... on a 17.x
  release", "the 18.x release that carries the upgrade path" or "the
  upgrade path arrives in a later 18.x release". Tests are out of its
  population. Ablation: #24710's sentence put back reds it (3 findings).

Co-authored-by: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014UATXWqAXqkaZkbG92ox6V

Author: claude

.changeset/15214-c11-fresh-install-messages.md

@@ -2,12 +2,10 @@
 '@objectstack/cli': patch
 ---
 
-fix(cli): `os migrate apply --allow-destructive`'s organization-ownership refusal says what 18.0 supports for a v17 database, and names no step of the command 18.0 refuses
+fix(cli): `os migrate apply --allow-destructive`'s organization-ownership refusal states the ceremony's record in its `--json` `detail`
 
 Clause-②: no
 
-- **`os migrate apply --allow-destructive` on a v17-shaped database.** When the run would drop `organization_id` from a table the organization-ownership ceremony owns, and the ceremony has not verified on the database, the refusal now says that 18.0 supports fresh installs only and does not upgrade a v17 database: keep a v17 database on a 17.x release until the 18.x release that carries the upgrade path, whose ceremony drops these columns itself. The v18 boot refusal and `os migrate organization-ownership`'s own refusal say the same. Before, it told the operator to run `os migrate organization-ownership --out PLAN` and then `--apply --plan-file PLAN`, which 18.0 refuses on every database (`NOT_IMPLEMENTED`). The `--json` refusal's `detail` no longer names that command either: it reads "No run of the organization-ownership ceremony is recorded on this database.", or names the last unverified run with its date and blocking count.
-- **`os migrate organization-ownership --help`** shows what the command answers in 18.0: exit `1` with `NOT_IMPLEMENTED`, nothing read or written, and the same refusal as JSON. Before, it showed six plan and apply examples that 18.0 refuses.
-- **`os dev` on a v17-shaped development database.** When it does not upgrade the database in place (the ceremony's plan is refused, or the database is not a local SQLite file), it now ends with the same position: keep a v17 development database on a 17.x release until the 18.x release that carries the upgrade path, and upgrade it there. Before, it told the developer to run `os migrate organization-ownership --dev` and then the same command with `--apply`.
+- **`os migrate apply --allow-destructive --json` on a database the organization-ownership ceremony has not verified.** When the run would drop `organization_id` from a table the ceremony owns, the refusal's `detail` reads "No run of the organization-ownership ceremony is recorded on this database.", or names the last unverified run with its date and blocking count. The human message names the ceremony's plan and apply, which drop these columns themselves.
 
-Nothing else changes. The refusals still hold back the whole run, and their message code (`refused_organization_ownership_unmigrated`), `tables`, `marker`, exit code `1` and every flag are as before.
+Nothing else changes. The refusal still holds back the whole run, and its message code (`refused_organization_ownership_unmigrated`), `tables`, `marker`, exit code `1` and every flag are as before.

.changeset/24567-drop-gate-refusal-18-0.md

@@ -10,20 +10,20 @@
 '@objectstack/service-settings': minor
 ---
 
-feat(cli,runtime)!: `os migrate organization-ownership` upgrades v17 and 18.0 databases; a server serves only a database it created or one the ceremony certified
+feat(cli,runtime)!: `os migrate organization-ownership` upgrades a database 17.x or an 18.0 pre-release created; a server serves only a database it created or one the ceremony certified
 
 Clause-②: yes (narrowing)
 
 <!-- adr-0087: not-required (no-migration-prescription) No key of any metadata schema is removed, renamed or re-shaped, so there is nothing for `objectstack migrate meta` to rewrite and no tombstone. The data migration this change prescribes is the operator's ceremony, `os migrate organization-ownership`, stated below; the boot refusal names it. -->
 
-**BREAKING** for a database an earlier release created, shipped as `minor` under the repo's launch-window convention for breaking changes (ADR-0131 D10).
+**BREAKING** for a database with no birth marker — one 17.x or an 18.0 pre-release (`18.0.0-next.*`) created — shipped as `minor` under the repo's launch-window convention for breaking changes (ADR-0131 D10).
 
-- **The ceremony is open.** `os migrate organization-ownership` runs again (18.0 refused it with `NOT_IMPLEMENTED`): a bare run writes the plan, and `--apply --plan-file PLAN --backup-taken` applies that reviewed plan. Its new steps carry what an 18.0 database still owes, each selected by the rows' shape, never by a NULL organization:
+- **The ceremony is open.** `os migrate organization-ownership` runs again (the 18.0 pre-releases refused it with `NOT_IMPLEMENTED`): a bare run writes the plan, and `--apply --plan-file PLAN --backup-taken` applies that reviewed plan. Its new steps carry what an 18.0 pre-release database still owes, each selected by the rows' shape, never by a NULL organization:
   - `sibling-moves`: the global settings-audit rows move to `sys_platform_setting_audit`, and identity mail (reset, verification, account invitation, change-email notice, magic link) to `sys_identity_email`, id for id. Their queued mail jobs and their activity rows follow them. The organization invitation stays in `sys_email`.
   - `declared-webhooks`: each `sys_webhook` copy a package's seeder wrote under a name a package still declares is settled. A pristine copy is deleted once its deliveries name the declaration (`declared:NAME`), with the cipher it referenced. A copy customized only in its switch becomes the declaration's activation row. Any other edit becomes the administrator's own webhook under a new name (`NAME_custom`), and the declaration is switched off.
   - `declared-rule-copies`: each stored sharing rule under a declared rule's name becomes a clone under a new name, its grants kept, and the declaration is switched off.
   - `not-null`: after the column drops, every table the post-step plan clears takes `organization_id` NOT NULL. The ceremony owns that nullability, so the schema differ no longer reports it as `relax_not_null` drift.
-- **The boot guard decides on a marker.** The first boot that creates a datastore from empty writes a birth marker (`sys_migration` row `adr-0131-organization-ownership`, `details.birth.shapeGeneration`). Every CLI data boot writes it too, so a fresh install whose first command is `os migrate apply` or `os seed` still boots. On the Turso remote face (`libsql://`), `getSchemaSyncStats` now answers what its schema doors created and found (it answered `{ created: 0, existing: 0 }` before), so a fresh remote database is observed as one and gets its marker. The ceremony's verified marker carries the same `shapeGeneration` (now `1`, `ORGANIZATION_OWNERSHIP_SHAPE_GENERATION` in `@objectstack/spec/system`). A server refuses a database with no marker (every 18.0 database), one certified at an older generation, or an uncertified one. The refusal names the command and no longer says to stay on 17.x. The v17-shape probe also reads `tenancy: { enabled: false }` and `systemFields: false`.
+- **The boot guard decides on a marker.** The first boot that creates a datastore from empty writes a birth marker (`sys_migration` row `adr-0131-organization-ownership`, `details.birth.shapeGeneration`). Every CLI data boot writes it too, so a fresh install whose first command is `os migrate apply` or `os seed` still boots. On the Turso remote face (`libsql://`), `getSchemaSyncStats` now answers what its schema doors created and found (it answered `{ created: 0, existing: 0 }` before), so a fresh remote database is observed as one and gets its marker. The ceremony's verified marker carries the same `shapeGeneration` (now `1`, `ORGANIZATION_OWNERSHIP_SHAPE_GENERATION` in `@objectstack/spec/system`). A server refuses a database with no marker (one 17.x or an 18.0 pre-release created), one certified at an older generation, or an uncertified one. The refusal names the command and no longer says to stay on 17.x. The v17-shape probe also reads `tenancy: { enabled: false }` and `systemFields: false`.
 - **`sys_secret` and `sys_flow_credential` are deployment-level** (`systemFields: { tenant: false }`). Their `organization_id` is dropped by the ceremony's column-drops step. The settings service no longer writes one, and `SettingsSecretStore.insert` no longer takes it.
 
-**What an operator does.** Before serving an 18.0 or v17 database with this release: take a backup, run `os migrate organization-ownership --out plan.json`, review the plan, then run `os migrate organization-ownership --apply --plan-file plan.json --backup-taken`, and start the server. `os dev` does this for a local SQLite development database. On a walled database, a customized copy of a declared webhook or sharing rule blocks its step, naming the row: rename it to a name no package declares, or delete it, then re-run.
+**What an operator does.** Before serving a database 17.x or an 18.0 pre-release created with this release: take a backup, run `os migrate organization-ownership --out plan.json`, review the plan, then run `os migrate organization-ownership --apply --plan-file plan.json --backup-taken`, and start the server. `os dev` does this for a local SQLite development database. On a walled database, a customized copy of a declared webhook or sharing rule blocks its step, naming the row: rename it to a name no package declares, or delete it, then re-run.

.changeset/24581-organization-ownership-ceremony-open.md

@@ -1081,6 +1081,18 @@ jobs:
         continue-on-error: true
         run: pnpm check:watch-hint-literal
 
+      # No shipped refusal, upgrade text or pending changeset says the
+      # organization-ownership ceremony is closed (#24581). The 18.0
+      # pre-releases refused the command and taught a family of surfaces to say
+      # "fresh installs only / keep it on 17.x"; the ceremony is open, and one
+      # such sentence left anywhere sends an operator away from the command
+      # that upgrades their database. Tests are out of the population (they
+      # spell the sentence to pin its absence). Repo-wide text sweep; ~1s.
+      - name: No shipped text says the ownership ceremony is closed
+        id: closed-ceremony-text
+        continue-on-error: true
+        run: pnpm check:closed-ceremony-text
+
       # ADR-0087 D4's per-release correctness gate (#17080). The REAL run needs
       # two published tarballs and npm, so it lives in the release lane and
       # cannot run on a PR; what runs here is its `--self-test`, which is