@@ -0,0 +1,21 @@
+---
+'@objectstack/platform-objects': minor
+---
+
+fix(platform-objects)!: `sys_organization` no longer declares `change_slug`, whose door only the cloud orchestrator mounts (#24318)
+
+Clause-②: no (narrowing) (a platform object stops declaring an action whose door exists only in cloud; owes a `CONTRACT_REVIEW_TIER` review on the narrowing face before the queue, and the `repo:cloud#2` seat's pointer before landing)
+
+`sys_organization` declared a `change_slug` action ("Change Slug") at `record_header`, gated on `multiOrgEnabled`, whose target, `/api/v1/cloud/organizations/{id}/change-slug`, no package in this repository serves. So on every open-source composition with multi-organization on, the organization record page offered Change Slug in its `⋯` overflow, and the click answered `404 ENDPOINT_NOT_FOUND`. Measured on a booted multi-organization showcase.
+
+The action now belongs to the composition that serves its route. That composition declares `change_slug` as a top-level action bound by `objectName: 'sys_organization'`, and the registry attaches such an action to the served object, whichever package registers first.
+
+**BREAKING — what moves for consumers.** A declared action leaves a published platform object, shipped as `minor` under the launch-window convention for breaking changes (pre mode was exited at `c46b5f14cf`, so the launch-window guard is armed and a breaking change ships as `minor`).
+
+- FROM: `GET /api/v1/meta/object/sys_organization` served `change_slug` on every composition, and the four generated locale bundles carried its `label`, `description` and `successMessage`.
+- TO: the object serves it only where a composition binds it. The open-source record header offers Invite User, Set Active and Rename Organization inline, and Leave Organization in the overflow; each of them is a better-auth door this composition mounts.
+- Fix: cloud declares its own `change_slug`, the same declaration bound by `objectName: 'sys_organization'`, with its own translations. An open-source composition changes an organization's slug through `update_organization` (better-auth's `organization/update`, list row), as before.
+
+**Unchanged.** `rename_organization` (name and logo, no slug) and `update_organization` (name, slug and logo, list row only) keep their declarations, gates and order. No stored row moves.
+
+<!-- adr-0087: not-required (no-migration-prescription) a platform object stops declaring one action whose door exists only in another composition: no authorable spec key, spelling, export or stored shape moves, and no stored row is read, rewritten or converted. The repair is the serving composition's own declaration of the action, which no ledger entry can derive. The other categories are closed on facts: the package publishes (not unpublished); no ADR-0087 id covers this declaration (not already-registered); and the change is an object's declared action, not a runtime interface, a type surface or an export (not runtime-interface-only, type-surface-only or runtime-export-retired). -->
@@ -0,0 +1,19 @@
+---
+'@objectstack/spec': minor
+---
+
+fix(spec)!: `PUBLIC_AUTH_FEATURES.multiOrgEnabled.gatedInputs` no longer lists `sys_organization.actions.change_slug` (#24318)
+
+Clause-②: no (narrowing) (a platform object stops declaring an action whose door exists only in cloud; owes a `CONTRACT_REVIEW_TIER` review on the narrowing face before the queue, and the `repo:cloud#2` seat's pointer before landing)
+
+`gatedInputs` is the census of platform-object inputs gated on a public auth feature, which the platform objects' completeness guard holds equal to their declarations in both directions. `sys_organization` no longer declares `change_slug` (its door is the cloud orchestrator's, and the composition that serves it declares the action), so its row leaves the census.
+
+**BREAKING — what moves for consumers.** One string leaves a published constant, shipped as `minor` under the launch-window convention for breaking changes.
+
+- FROM: `PUBLIC_AUTH_FEATURES.multiOrgEnabled.gatedInputs` listed seven `sys_organization` actions, `'sys_organization.actions.change_slug'` among them.
+- TO: it lists six: `create_organization`, `update_organization`, `rename_organization`, `delete_organization`, `set_active_organization` and `leave_organization`.
+- Fix: none for an action declared outside the platform objects. The census is not a gate on other packages: a top-level action bound to `sys_organization` that declares `requiresFeature: 'multiOrgEnabled'` is lowered to the same `features.multiOrgEnabled != false` predicate and served with it, measured on a booted composition.
+
+**Unchanged.** The `multiOrgEnabled` key, its surface (`crud`) and its semantics (`default-on`); every other feature's row. The constant is declared `as const`, so its literal type loses the one tuple member too.
+
+<!-- adr-0087: not-required (no-migration-prescription) one path string leaves a published census constant that only the platform objects' own completeness guard reads: no authorable spec key, spelling, export or stored shape moves, and no stored row is read, rewritten or converted. The other categories are closed on facts: the package publishes (not unpublished); no ADR-0087 id covers this row (not already-registered); and the export stays, its declared entry type unchanged; the `as const` literal tuple loses one member, which nothing in this repository names (not runtime-interface-only, type-surface-only or runtime-export-retired). -->
@@ -0,0 +1,15 @@
+---
+'@objectstack/plugin-audit': patch
+---
+
+fix(plugin-audit): an object definition changed through the metadata door takes effect in the audit writers at once, with no restart
+
+Clause-②: no
+
+The audit writers kept each object's first definition for the life of the process. They now read the registered definition on every call. The registry already holds the merged definition behind its own invalidation points, so the read is two map lookups.
+
+- **Attachments follow `enable.files`.** An object whose `enable.files` was switched on through `PUT /api/v1/meta/object/:name` kept refusing `sys_attachment` writes with 403 `FILES_DISABLED` until the server restarted, although the metadata read-back already showed `enable.files: true`. The same attachment is now admitted at once, and switching the flag off refuses it again. `enable.feeds` on comments follows the same read.
+- **The ledger copy follows field changes.** A `password` field added through the door to an already-audited object is masked on the ledger copy from the moment it is added, as on every other read exit. The same read decides the mask for `secret` fields and the omission of `internal` ones.
+- **The activity row follows the object.** `enable.activities`, `activityMilestones`, the title field and the object label are read from the current definition too.
+
+What the metadata door accepts is unchanged.
@@ -0,0 +1,11 @@
+---
+'@objectstack/plugin-security': patch
+---
+
+fix(plugin-security): the boot report's unnamed-grant line says what 18.0 supports for a v17 database, not a command 18.0 refuses
+
+Clause-②: no
+
+- **The error line for `sys_user_permission_set` grants whose `permission_set` is empty** used to end with a fix: plan with `os migrate organization-ownership --out plan.json`, then run `os migrate organization-ownership --apply --backup-taken --plan-file plan.json`, restart, with a warning that granting the set again by name before it runs leaves a second grant for the ceremony to report. 18.0 refuses that command on every database, so the operator was sent to a refusal. The line now ends with the sentence the drop-gate refusal of `os migrate apply --allow-destructive` carries: "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."
+- **Unchanged:** the count, the "permission_set is empty" fact, the ADR-0131 D4 reason ("each confers nothing"), "Nothing was changed.", the structured meta, the log level and the report's result. Such a grant still confers nothing and is still listed.
+- **Removed from the line:** the two command steps and the restart step, and the advice about granting the set again by name. They described the 18.x upgrade ceremony, which 18.0 does not carry.
@@ -106,7 +106,7 @@ later ships. See [ADR-0070](https://github.com/objectstack-ai/objectstack/blob/m
 
 **Most metadata types must not be overlaid by an environment** — overlaying a packaged item would break the physical schema or the behaviour its package ships. The whitelist lives in **one** place: `MetadataTypeRegistryEntry.allowEnvironmentOverlay` in `packages/spec/src/kernel/metadata-plugin.zod.ts` (spelled `allowOrgOverride` before protocol 18; `GET /api/v1/meta/types` serves it per entry as `allowEnvironmentOverlay`).
 
-> **ADR-0131 D6 — the per-organization overlay axis is retired.** The `/meta` doors (REST and the runtime dispatcher) carry no organization into a metadata write or read: a Studio or `PUT /api/v1/meta/...` write of the five ✅ types below lands **environment-wide** (since ADR-0131 D7 the `sys_metadata` family declares no organization column) and is served to every organization, and an organization admin holding only the retired `manage_org_presentation` capability is refused (`403`). The protocol itself refuses every organization-scoped write, and every read — item, list, layers, cached, history, diff, audit, drafts and the commit timeline — is environment → code, whatever organization a caller names. An overlay row an earlier release stored under an organization — under the `single` posture, every Studio save of these types, filed under the Default Organization — is served by no read, and an 18.x `os serve` refuses to start on a database still holding one until the v18 migration ceremony (ADR-0131 C7: `os migrate organization-ownership --out PLAN`, then `--apply --plan-file PLAN`) has carried it to the environment layer and dropped the column; nothing deletes or rewrites it before then. The anonymous form doors read the environment alone too: the ceremony carries every organization-layer public-form withdrawal onto the environment, fail-closed. The table still records which types take an overlay of a shipped item.
+> **ADR-0131 D6 — the per-organization overlay axis is retired.** The `/meta` doors (REST and the runtime dispatcher) carry no organization into a metadata write or read: a Studio or `PUT /api/v1/meta/...` write of the five ✅ types below lands **environment-wide** (since ADR-0131 D7 the `sys_metadata` family declares no organization column) and is served to every organization, and an organization admin holding only the retired `manage_org_presentation` capability is refused (`403`). The protocol itself refuses every organization-scoped write, and every read — item, list, layers, cached, history, diff, audit, drafts and the commit timeline — is environment → code, whatever organization a caller names. An overlay row an earlier release stored under an organization — under the `single` posture, every Studio save of these types, filed under the Default Organization — is served by no read, and on a SQL database (SQLite, PostgreSQL, MySQL) still holding one a v18 `os serve` refuses to start. 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. In that release, the v18 migration ceremony (ADR-0131 C7: `os migrate organization-ownership --out PLAN`, then `--apply --plan-file PLAN`) carries such a row to the environment layer and drops the column; nothing deletes or rewrites it before then. The anonymous form doors read the environment alone too: in that release the ceremony carries every organization-layer public-form withdrawal onto the environment, fail-closed. The table still records which types take an overlay of a shipped item.
 
 | Type | `allowEnvironmentOverlay` | Rationale |
 | :--- | :---: | :--- |
 
@@ -196,31 +196,40 @@ os dev --database file:./data/test.db --auth-secret $(openssl rand -hex 32)
 | `--seed-admin` / `--no-seed-admin` | — | Seed a dev admin (`admin@objectos.ai` / `admin123`) on an empty DB — default on; override with `--admin-email` / `--admin-password` |
 | `-v, --verbose` | — | Verbose output |
 
-##### A 17.x development database is upgraded in place
+##### A 17.x development database
 
 A v18 server refuses to start on a database still in the v17
 organization-ownership shape until the [ownership ceremony](#os-migrate-organization-ownership)
-has run on it. `os dev` runs that ceremony for you when the database is a local
-SQLite file:
+has run on it.
 
 <Callout type="warn">
 18.0 supports fresh `single` installs; upgrades and walled postures arrive in 18.x. In 18.0 the ceremony refuses, so `os dev` stops at step 2 with its
 refusal and changes nothing.
+18.0 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. For a local SQLite file,
+`os dev` in 18.0 still takes step 1's copy first and prints where it is,
+beside the ceremony's `NOT_IMPLEMENTED` refusal; any other database gets no
+copy and the same answer.
 </Callout>
 
+In the 18.x release that carries the upgrade path, `os dev` runs that ceremony
+for you when the database is a local SQLite file:
+
 1. It copies the database file and its `telemetry` sibling (each with its
    `-wal` / `-shm`) into `<data dir>/backups/organization-ownership-<timestamp>/`.
 2. It runs `os migrate organization-ownership --dev` (the plan), then applies
    that plan. The plan, the apply report and the ceremony's log are kept
    beside the copy.
 3. It prints the ceremony's warnings and starts the server again.
 
-If a step blocks, or the post-check still holds rows (a row whose owner cannot
+In that release, if a step blocks, or the post-check still holds rows (a row whose owner cannot
 be derived, named per table with its remedy), `os dev` stops and prints what
 holds it, where the copy is, and the command that resumes the run. It tries once per session. A database that is
 not a local SQLite file (PostgreSQL, a remote libSQL, `:memory:`) is not
-upgraded in place: run the ceremony yourself. `os serve` and `os start` never run
-it; they refuse and name the command.
+upgraded in place: run the ceremony yourself.
+
+`os serve` and `os start` never run the ceremony: they refuse to start, and on
+a v17 database their 18.0 refusal says that 18.0 does not upgrade it.
 
 ##### Serving dev over https
 
@@ -1025,13 +1034,18 @@ safe. No flag skips these refusals:
 - `sys_account.issuer` is dropped only when its retirement pre-flight reads the
   table clean (`os migrate account-issuer` reports the colliding rows).
 - `sys_comment.reactions` waits for a verified `os migrate comment-reactions --apply` run.
-- `organization_id` on any table the organization-ownership ceremony covers
-  waits for a verified `os migrate organization-ownership --apply --plan-file FILE`
-  run. These tables are the ADR-0131 D7 tables and the `sys_metadata` family.
-  The ceremony drops those columns itself, in its column-drops step, before it
-  records the run verified. Dropping one first would turn every legacy
+- `organization_id` waits for a verified run of the organization-ownership
+  ceremony, on every table the drift offers to drop it from: the ceremony plans
+  every table that still carries the column, the ADR-0131 D7 tables and the
+  `sys_metadata` family among them. Dropping one first would turn every legacy
   organization row into an environment row. Under `--json` the refusal answers
   `message: 'refused_organization_ownership_unmigrated'` and lists the `tables`.
+  18.0 itself never records a verified run, so on a v17 database this refusal
+  holds on every run. 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. In that release, the ceremony's
+  `os migrate organization-ownership --apply --plan-file FILE` run drops these
+  columns itself, in its column-drops step, before it records the run verified.
 
 Each refusal holds the whole `--allow-destructive` run: nothing in it is
 created, applied or dropped, the run's other changes included. A run without
@@ -1478,14 +1492,15 @@ reports the failed read and exits `1`. A failed read or write exits `1`.
 
 The v18 ownership ceremony (ADR-0131 D10). A v18 `os serve` / `os start` refuses
 to start on a database still in the v17 organization-ownership shape until this
-has run. Under `os dev` it runs on its own for a local SQLite database (see
-[`os dev`](#os-dev)).
+has run. In the 18.x release that carries the upgrade path, `os dev` runs it on
+its own for a local SQLite database (see [`os dev`](#os-dev)).
 
 <Callout type="warn">
 18.0 supports fresh `single` installs; upgrades and walled postures arrive in 18.x. In 18.0 this command refuses, plan and apply alike: it exits `1` with
 `NOT_IMPLEMENTED` (under `--json`, `code` beside `error`) and reads and
 writes nothing. Keep a v17 database on a 17.x release until the 18.x release
-that carries the upgrade path.
+that carries the upgrade path. The invocations below, and what the list after
+them says the ceremony does, are that 18.x release's.
 </Callout>
 
 ```bash
 
@@ -412,11 +412,16 @@ overlay axis is retired: the doors carry no organization, so the overlay is
 column, ADR-0131 D7) and served to every organization
 of the deployment, whatever the author's active organization. Every protocol
 read is environment → code, whatever organization a caller names. An overlay
-row an earlier release stored under an organization is served by no read, and
-an 18.x `os serve` refuses to start on a database still holding one until the
-v18 migration ceremony (ADR-0131 C7) has carried it to the environment layer. The anonymous form doors read the environment alone too: the ceremony carries
-every organization-layer public-form withdrawal onto the environment,
-fail-closed. The per-user,
+row an earlier release stored under an organization is served by no read. On a
+SQL database (SQLite, PostgreSQL, MySQL) still holding one, a v18 `os serve`
+refuses to start, because the `sys_metadata` family there still carries its
+`organization_id` column. 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. In that release, the v18 migration
+ceremony (ADR-0131 C7) carries such a row to the environment layer. The
+anonymous form doors read the environment alone too; in that release the
+ceremony carries every organization-layer public-form withdrawal onto the
+environment, fail-closed. The per-user,
 per-field patch overlay a previous revision of this page taught here was
 removed in #13135 — it was never served by any route.
 
 
@@ -217,8 +217,11 @@ and resource `requiredPermissions` match capability names **as strings**. The
 boot writes no row for a capability, declared or curated: both are served by
 the registry. The `sys_capability` object itself is retired and no longer
 registered (ADR-0131 D3): a row an older database still holds is served by no
-route and read by nothing, and `os migrate organization-ownership --apply`
-reports the authored rows and deletes the seeded copies (ADR-0131 D10).
+route and read by nothing. In the 18.x release that carries the upgrade path
+(18.0 does not upgrade a v17 database: see
+[`os migrate organization-ownership`](/docs/deployment/cli#os-migrate-organization-ownership)),
+`os migrate organization-ownership --apply` reports the authored rows and
+deletes the seeded copies (ADR-0131 D10).
 Withdraw a capability by withdrawing the **grant**.
 </Callout>