@@ -0,0 +1,36 @@
+---
+'@objectstack/plugin-auth': patch
+'@objectstack/spec': minor
+'@objectstack/client': patch
+'@objectstack/cli': patch
+'@objectstack/verify': patch
+'@object-ui/auth': patch
+'@object-ui/console': patch
+---
+
+fix(plugin-auth)!: under invite_only, a self-serve sign-up is admitted only by the invitation it presents
+
+Clause-②: yes (narrowing) — under the `invite_only` audience posture an email-and-password sign-up for an invited address is admitted only when it presents that invitation's id as `invitationId`, and the address alone is refused `SELF_REGISTRATION_CLOSED`; a social OAuth creation is admitted by an invitation only when its identity provider verified the address. The sign-up request widens: `RegisterRequestSchema` and `RegisterRequest` gain `invitationId`, `SignUpData`, `RegisterForm` and the auth context's `signUp` gain it, and `os register` gains `--invitation`.
+Metadata-protocol: added — RegisterRequest gains the optional invitationId key (packages/spec/authorable-surface/api.json)
+
+<!-- adr-0087: not-required (no-migration-prescription) No key is removed, renamed or re-shaped and no stored row is rewritten: RegisterRequest gains an optional key, and a sign-up under invite_only that does not present its invitation is refused with the posture's existing code and message. -->
+
+**BREAKING** accept-set narrowing at the email-and-password sign-up door (`@objectstack/plugin-auth`), under the `invite_only` audience posture, the default.
+
+A sign-up under `invite_only` presents the invitation it is admitted by: the invitation's id, the last segment of the `/accept-invitation/` link the invitation mail carries, sent in the `/sign-up/email` body as `invitationId` beside `email`, `password` and `name`. The invitation must be pending, unexpired and addressed to that email. Anything else is refused `403 SELF_REGISTRATION_CLOSED` with the same message an uninvited sign-up gets, and nothing is written.
+
+**Upgrading.** A client that signs an invitee up sends `invitationId` beside the `email`, `password` and `name` it already sends. The one-line fix: send the id the invitation link carries as `invitationId`.
+
+**Who moves.** Nothing in this repository: the Console, the SDK, the CLI, the `@objectstack/verify` harness and the test fixtures all present the id; a client outside it that signs invitees up under `invite_only`, such as a custom front-end or a script, sends the accept link's last path segment as `invitationId`.
+
+**Operators.** Deploy the Console bundle together with the server; on a deployment with no mail transport, hand the invitee the link with the invitation's **Copy Invite Link** action; give an out-of-band recovery invitation row an `id` of your own, which the sign-up sends; and review accounts created before the upgrade that are unverified and hold or accepted an invitation.
+
+- **Unchanged:** the first account of a new deployment, and the operator's own provisioning (admin create, SCIM, the boot command's seed), need no invitation. The `open` and `email_domain` postures match an invitation by address as before. A magic-link or email-OTP creation, whose own flow answers from the mailbox, matches by address; an SSO provider's creation is unchanged.
+- **Social OAuth under `invite_only`:** a creation through a social provider is admitted by an invitation only when the provider verified the address; otherwise it is refused with the same code as an uninvited sign-up.
+- **No mail transport:** hand the invitee the link with the invitation's **Copy Invite Link** action; it carries the id.
+- `@objectstack/spec`: `RegisterRequestSchema` declares the optional `invitationId`.
+- `@objectstack/client`: `auth.register()` sends it through, typed by the widened `RegisterRequest`.
+- `@objectstack/cli`: `os register --invitation ID`.
+- `@objectstack/verify`: the harness's `signUp` presents the invitation it seeds.
+- `@object-ui/auth`: `SignUpData.invitationId`, `RegisterForm`'s `invitationId` prop and the sixth argument of the context's `signUp` send it.
+- `@object-ui/console`: `/register` opened from an invitation link sends that link's id with the sign-up; so does `@object-ui/app-shell`'s `DefaultRegisterPage`, whose package now also exports `invitationIdOf`.
@@ -613,12 +613,15 @@ dead end this section describes.
 
 **The recovery is out of band, and it is one row.** Write a pending invitation
 directly against the store the deployment reads, then have that person register
-through the ordinary sign-up endpoint — the invitation carve-out admits that
-one creation under every posture, so the `invite_only` default stays where it
-is. One `sys_invitation` row:
+through the ordinary sign-up endpoint, sending the row's `id` as `invitationId`
+beside the email — under `invite_only` a sign-up is admitted only by the
+invitation it presents. The invitation carve-out admits that one creation under
+every posture, so the `invite_only` default stays where it is. One
+`sys_invitation` row:
 
 | Column | Value |
 |:---|:---|
+| `id` | a long random value of your own: it is what the sign-up presents |
 | `email` | the address you intend to administer — one the directory does **not** already hold |
 | `status` | `pending` |
 | `expires_at` | any future timestamp |
@@ -700,6 +703,16 @@ a populated deployment, posting to `/api/v1/auth/sign-up/email`:
 | `email_domain` | **Only inside a domain you allowlisted.** Any address outside the list answers `403 EMAIL_DOMAIN_NOT_ALLOWED`, registered or not, so a caller must already hold an address on an allowlisted domain before they learn anything. |
 | `open` | **Nothing, while the mail transport is live.** A registered address gets the same answer as a new sign-up, nothing is written, and the address's holder is mailed that it already has an account. Without a live transport, or with email verification declared off and auto sign-in left on, a registered address is refused explicitly, so the answer tells a caller that the address is registered. |
 
+**Under `invite_only`, a sign-up is admitted only by the invitation it
+presents.** The sign-up sends the invitation's `id`, the last segment of its
+`/accept-invitation/` link, as `invitationId` beside the email: the Console's
+register page does this for an invitee who arrived from the link, and
+`os register --invitation` does it from a terminal. An address alone gets the
+same `403 SELF_REGISTRATION_CLOSED` as an address nobody invited. The link
+reaches the invitee in the invitation mail; on a deployment with no mail
+transport, an administrator hands it over with the invitation's **Copy Invite
+Link** action. The first account of a new deployment needs no invitation.
+
 **What decides it on `open` and `email_domain`.** A sign-up for an address that
 already has an account gets the same answer as a successful new sign-up, and
 writes nothing, when all three of these hold:
 
@@ -214,6 +214,7 @@ This schema accepts one of the following structures:
 | **password** | `string` | ✅ |  |
 | **name** | `string` | ✅ |  |
 | **image** | `string` | optional |  |
+| **invitationId** | `string` | optional | The id of the invitation this sign-up presents: the last path segment of its /accept-invitation/ link. Under the invite_only audience posture a sign-up is admitted only by the invitation it presents, pending, unexpired and addressed to this email; an address alone is refused SELF_REGISTRATION_CLOSED. The first account of a new deployment needs none, and the other postures do not read it. |
 
 
 ---
 
@@ -504,14 +504,18 @@ contradicts it, and correct it here when it does.
   `invite_only` default (`packages/plugins/plugin-auth/src/audience-posture.ts`:
   `resolveAudience` — undeclared ⇒ `invite_only`; the migration entry
   `audience-posture-default-invite-only` records the flip), and
-  `POST /api/v1/auth/sign-up/email` for an address holding no pending invitation answers
-  **`403 SELF_REGISTRATION_CLOSED`** (`decideAudienceAdmission` in the same file; the code
+  `POST /api/v1/auth/sign-up/email` that presents no pending invitation — an address alone
+  included — answers **`403 SELF_REGISTRATION_CLOSED`** (`decideAudienceAdmission` in the same file; the code
   is in the ADR-0112 ledger, `error-code-ledger.zod.ts`). QA run #21056 met it on every
   member persona it needed. Two doors mint one instead:
-  1. **Invite, then sign up.** As admin, `POST /api/v1/auth/organization/invite-member`
-     with `{"email": "EMAIL", "role": "member"}`; a pending, unexpired `sys_invitation`
-     row for that address is what admits the following `sign-up/email`
-     (`packages/plugins/plugin-auth/src/auth-manager.ts`, `hasPendingInvitationFor`).
+  1. **Invite, then sign up presenting the invitation.** As admin,
+     `POST /api/v1/auth/organization/invite-member` with `{"email": "EMAIL", "role": "member"}`,
+     and keep the `id` it answers: the following `sign-up/email` sends it as `invitationId`
+     beside the email (`{"email": "EMAIL", "password": "…", "name": "…", "invitationId": "ID"}`).
+     Under `invite_only` a sign-up is admitted only by the invitation it presents, pending,
+     unexpired and addressed to that email
+     (`packages/plugins/plugin-auth/src/presented-invitation.ts`); the address alone answers
+     the same 403.
      ⚠️ **The sign-up does not apply the invitation's role.** It binds the new user to the
      Default Organization as `member` whatever role was invited, and leaves the invitation
      `pending` (`reconcileMembership` in