@@ -0,0 +1,19 @@
+---
+'@objectstack/cli': patch
+---
+
+fix(cli)!: a production `os serve` whose `@objectstack/plugin-auth` fails to load is refused, naming the load error, instead of booting with no organization object
+
+Clause-②: yes (narrowing)
+Metadata-protocol: none
+
+<!-- adr-0087: not-required (no-migration-prescription) A boot-time refusal in `os serve`: 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. No export, type, flag or error code is removed or renamed. The remedy is a deployment one (repair the install), stated below. The other categories are closed on facts: the package publishes (not unpublished); no ADR-0087 id covers this boot (not registered or already-registered); and nothing exported is removed or narrowed (not runtime-interface-only, type-surface-only or runtime-export-retired). -->
+
+**BREAKING** boot-refusal narrowing (ADR-0131 D9), the third composition beside the two the previous change refused. It changes which production boots start, not what a metadata author can write, so it ships as `patch` with this banner.
+
+- FROM: a production `os serve` or `os start` (no `--dev`) whose stack enables the `auth` tier and resolves an auth secret, but whose `@objectstack/plugin-auth` fails to load — a missing install (silently) or a broken one (one `⚠ AuthPlugin failed to load: …` warning) — booted with no `AuthPlugin`. It composed no organization object, so every row the boot wrote landed with no organization: stored ownerless on an 18.0.0-born store (nullable columns, MongoDB), refused at NOT NULL on a fresh SQL table.
+- TO: that boot is refused before any plugin starts, with or without `--server`, and the database is never opened. The refusal names the load error. The same holds when the AuthPlugin construction itself throws before it is mounted.
+
+**Unchanged:** `os dev` and `--dev` (a development boot keeps the warning and boots without auth); the cloud runtime's host kernel (`ObjectOSEnvironmentPlugin`), whose auth is each project's; a production boot with no auth secret or with no auth at all, which is still refused by the existing refusals; and an embedded kernel, which never runs this command.
+
+**The remedy.** Repair the install the error names: `@objectstack/plugin-auth` is a dependency of `@objectstack/cli`, so reinstall the deployment's dependencies (e.g. `npm ci` or `pnpm install --frozen-lockfile`). Running kernel-only (`--no-server`) does not avoid the refusal.
@@ -402,7 +402,9 @@ The `auth` tier requires `OS_AUTH_SECRET` in production: without it the boot
 is refused before any plugin starts, with or without `--server`, because a boot
 with no `AuthPlugin` has no organization and every row it wrote would have no
 owner. A production boot whose tiers leave `auth` out (`--preset minimal`
-included) is refused the same way unless the stack mounts `AuthPlugin` itself.
+included) is refused the same way unless the stack mounts `AuthPlugin` itself,
+and so is one whose `@objectstack/plugin-auth` fails to load (a missing or broken
+install): the refusal names the load error instead of booting without auth.
 In `--dev` mode the CLI falls back to an insecure local secret, so login works
 out of the box. (The cloud runtime's host kernel, where auth is each project's,
 only warns.) To take full control, set `tiers` on the stack config:
 
@@ -417,18 +417,22 @@ one it is refused: `✖ FATAL: tenancy posture 'group' is walled, but this deplo
 refused before any plugin starts, so set the secret before you start such a
 deployment on 18.0. A production boot whose stack mounts no auth at all (the
 `auth` tier off and no `AuthPlugin` of its own) is refused the same way: enable
-auth and set the secret. Either boot has no organization, so every row it wrote
-would have no owner.
-
-`--no-server` does not avoid either refusal: a kernel-only boot runs the same
+auth and set the secret. So is a production boot that has the secret but whose
+`@objectstack/plugin-auth` fails to load (a missing or broken install), `os start`
+included: earlier 18 releases booted it without auth, silently or with one
+`⚠ AuthPlugin failed to load` warning, and the refusal now names the load error —
+reinstall the deployment's dependencies. Each of these boots has no
+organization, so every row it wrote would have no owner.
+
+`--no-server` does not avoid any of these refusals: a kernel-only boot runs the same
 seed and would write the same ownerless rows. Earlier 18 releases let a
 `--no-server` boot through, and their refusal text offered `--no-server` as a
 remedy; it is not one. The same holds for a migrate-and-exit job
 (`OS_MIGRATE_AND_EXIT=1`): give it `OS_AUTH_SECRET` too. A development boot
 (`os dev`, `--dev`) and an embedded kernel are not affected, and neither is the
 cloud runtime's host kernel, whose auth is each project's. `os start` is not
-affected: it generates an auth secret on its first run and persists it to
-`<home>/auth-secret`.
+affected by the missing-secret refusal: it generates an auth secret on its first
+run and persists it to `<home>/auth-secret`.
 
 What the plan lists, how a blocked row is resolved, and every flag are in the
 command's reference: