@antelopejs/interface-dms 0.10.4 → 0.13.0

package/docs/1.core/6.invites.md

@@ -1,19 +1,18 @@
 ---
 title: "Invites"
-description: "An invite brings a person into a tenant by email."
+description: "Invite functions, the UserInvite table and model, invite extensions, durable invite resolution, and invite availability."
+mode: reference
 ---
 
-# Invites
-
 ## Overview
 
-An invite brings a person into a tenant by email. `inviteUserToTenant` is the entry point: when the email already belongs to a user it grants them membership directly, and otherwise it creates a token-bearing invite row the person redeems later. The two outcomes are distinguished by the `kind` field of the result.
+An invite brings a person into a tenant by email. `inviteUserToTenant` is the entry point. When the email already belongs to a user, it grants them membership directly. Otherwise it creates an invite row with a token, which the person redeems later. The `kind` field of the result tells the two outcomes apart.
 
-The functions live in `@antelopejs/interface-dms/invites`; the `UserInvite` table and its model live in `@antelopejs/interface-dms/db`.
+The functions live in `@antelopejs/interface-dms/invites`. The `UserInvite` table and its model live in `@antelopejs/interface-dms/db`.
 
-## Invite a User
+## Invite a user
 
-```typescript
+```typescript fragment
 import { inviteUserToTenant } from "@antelopejs/interface-dms/invites";
 
 const result = await inviteUserToTenant({
@@ -38,17 +37,17 @@ return { inviteId: result.inviteId, token: result.token };
 | Option | Type | Description |
 | ------ | ---- | ----------- |
 | `tenantId` | `string` | Tenant the person is invited into. Required. |
-| `email` | `string` | Email to look up and, failing that, to invite. Required. |
+| `email` | `string` | Email to look up, and to invite when no account has it. Required. |
 | `firstname` | `string \| null` | Invitee's first name, stored on the invite row and used to address the email. Defaults to `null`. |
 | `lastname` | `string \| null` | Invitee's last name. Defaults to `null`. |
 | `language` | `string` | Language stored on the invite row. Defaults to `"en"`. |
 | `roleIds` | `string[]` | Roles granted on join. Defaults to `[]`. |
 | `asTenantOwner` | `boolean` | Grant tenant ownership on join. Defaults to `false`. |
-| `sendEmail` | `boolean` | Dispatch the admin invite email after the row is created. Defaults to `false`. |
-| `awaitEmailDelivery` | `boolean` | With `sendEmail`, wait for the email and report its outcome as `emailDelivery` instead of sending it in the background. Defaults to `false`. |
-| `inviterName` | `string` | Name of the sender shown in the invitation email. |
+| `sendEmail` | `boolean` | Send the invitation email through `sendAdminInviteEmail` after the row is created. Defaults to `false`. |
+| `awaitEmailDelivery` | `boolean` | With `sendEmail`, wait for the email and report its outcome as `emailDelivery`, instead of sending it in the background. Defaults to `false`. |
+| `inviterName` | `string` | Name of the sender, shown in the invitation email. |
 | `invitedBy` | `string \| null` | Id of the inviting user, stored on the invitation. |
-| `extensions` | `InviteExtensionPayloads` | Payloads keyed by registered invite extension key. |
+| `extensions` | `InviteExtensionPayloads` | Payloads keyed by the key of a registered invite extension. |
 
 ### `InviteUserToTenantResult`
 
@@ -67,11 +66,15 @@ interface InvitedUserResult {
 }
 ```
 
-The `"added"` branch runs `applyTenantOwnership` with `roleIds` and `asTenantOwner` ([Tenancy](/docs/interfaces/core/tenancy)), so the member hooks fire and no token is generated. The `"invited"` branch creates the invite row through `createUserInviteToken`, then dispatches the email when `sendEmail` is set. By default that is fire-and-forget: the call does not wait on delivery and does not fail when delivery does.
+The whole call goes through [`changeTenantMembers`](/docs/interfaces/core/tenancy#changetenantmembers), so it respects tenant lifecycle admission.
 
-Pass `awaitEmailDelivery: true` when someone is waiting on the answer and has to learn that the email did not leave. The call then waits for the email and sets `emailDelivery` to `"sent"` or `"failed"`. It still does not throw: the invitation is kept either way, so the caller can offer to resend it. The failure's details (the provider's error) go to the server log only; tell the user something generic. The DMS members **Invite** form and the pending invitations' **Resend** action both work this way.
+The `"added"` branch writes the membership the way `applyTenantOwnership` does, with `roleIds` and `asTenantOwner` ([Tenancy](/docs/interfaces/core/tenancy)). The member hooks fire and no token is generated. The branch then delivers the `extensions` payloads to their extensions at once, because no invitation exists to wait on. A delivery failure at that point is logged and not raised, since the user is already a member.
 
-```typescript
+The `"invited"` branch creates the invite row the way `createUserInviteToken` does, then sends the email when `sendEmail` is set. By default the email goes out in the background. The call does not wait for delivery and does not fail when delivery fails.
+
+Pass `awaitEmailDelivery: true` when someone waits for the answer and must learn that the email did not leave. The call then waits for the email and sets `emailDelivery` to `"sent"` or `"failed"`. It still does not throw. The invitation is kept either way, so the caller can offer to resend it. The details of the failure, such as the provider's error, go to the server log only, so show the user a generic message. The DMS members **Invite** form and the **Resend** action on pending invitations both work this way.
+
+```typescript fragment
 const result = await inviteUserToTenant({
   tenantId,
   email: "alice@example.com",
@@ -84,13 +87,13 @@ if (result.kind === "invited" && result.emailDelivery === "failed") {
 }
 ```
 
-The function is deliberately side-effect-light: it does not throw on duplicates and performs no context-specific pre-checks. Decide in the caller what "already a member" should answer.
+`inviteUserToTenant` does not throw on duplicates and runs no checks specific to a context. Decide in the caller what to answer when the person is already a member.
 
-## Create an Invite Token Directly
+## Create an invite token directly
 
-`createUserInviteToken` is the lower-level half — it always creates a row and never touches memberships or email.
+`createUserInviteToken` is the lower-level function. It always creates a row, and it never touches memberships or email.
 
-```typescript
+```typescript fragment
 import { createUserInviteToken } from "@antelopejs/interface-dms/invites";
 
 const { inviteId, token } = await createUserInviteToken({
@@ -102,15 +105,28 @@ const { inviteId, token } = await createUserInviteToken({
 });
 ```
 
-`CreateUserInviteTokenOptions` requires `tenantId`, `email`, `language`, `roleIds` and `asTenantOwner`; `firstname` and `lastname` are optional and default to `null`. Optional `invitedBy` records the sender and `extensions` carries `InviteExtensionPayloads`. `replacementReason` selects `"replaced"` (default) or `"resent"` when retiring an existing invitation. `CreateUserInviteTokenResult` is `{ inviteId: string; token: string }`.
+`CreateUserInviteTokenOptions` has these fields:
 
-Optional `replacesInvite: UserInvite` identifies the exact incarnation being replaced, including a retained snapshot during a retry.
+| Option | Type | Description |
+| ------ | ---- | ----------- |
+| `tenantId` | `string` | Required. |
+| `email` | `string` | Required. Stored trimmed and lowercased. |
+| `language` | `string` | Required. |
+| `roleIds` | `string[]` | Required. |
+| `asTenantOwner` | `boolean` | Required. |
+| `firstname`, `lastname` | `string \| null` | Optional. Default to `null`. |
+| `invitedBy` | `string \| null` | Optional. Records the sender. `null` when nobody signed in sent it. |
+| `extensions` | `InviteExtensionPayloads` | Optional. |
+| `replacementReason` | `"replaced" \| "resent"` | How to report the retirement of an invitation this one displaces. Defaults to `"replaced"`. A resend passes `"resent"`, which reissues the same invitation, so contributors do not undo what it carries. |
+| `replacesInvite` | `UserInvite` | The exact incarnation to replace, including a retained snapshot during a retry. |
+
+`CreateUserInviteTokenResult` is `{ inviteId: string; token: string }`.
 
-`inviteeDisplayName(firstname?, lastname?)` joins the two into the name the invite email addresses the person by, and returns `undefined` when the invite carries neither. `inviteUserToTenant` calls it for you; call it yourself when you render your own invite surface from a stored row, so the fallback for a nameless invite matches what the email does.
+An existing invite for the same email in the same tenant is retired through a durable decision. Completion invokes `Hook.INVITE_DELETED` for the old invitation, creates the replacement through `Hook.INVITE_BEING_CREATED` and `Hook.INVITE_CREATED`, and removes the old row. A failed completion can replay hooks with the same delivery identity. See [Durable invite resolution](#durable-invite-resolution) and [Hooks](/docs/interfaces/core/hooks).
 
-An existing invite for the same email in the same tenant is retired through a durable decision. Completion invokes `Hook.INVITE_DELETED` for the old invitation, then creates the replacement through `Hook.INVITE_BEING_CREATED` and `Hook.INVITE_CREATED`, and removes the old row. Failed completion can replay hooks with the same delivery identity; see [durable invite resolution](#durable-invite-resolution) and [Hooks](/docs/interfaces/core/hooks).
+`inviteeDisplayName(firstname?, lastname?)` joins the two names into the name the invite email uses, and returns `undefined` when the invite carries neither. `inviteUserToTenant` calls it for you. Call it yourself when you render your own invite screen from a stored row, so a nameless invite falls back the same way the email does.
 
-## Token Constants
+## Token constants
 
 | Constant | Value | Meaning |
 | -------- | ----- | ------- |
@@ -124,24 +140,27 @@ import {
 } from "@antelopejs/interface-dms/invites";
 ```
 
-## The `UserInvite` Table
+## The `UserInvite` table
 
-Table `user_invites` in the `dms-tenant` schema, so invites are per-tenant like memberships. The table-name constant `USER_INVITES_TABLE_NAME` is exported next to it.
+Table `user_invites` in the `dms-tenant` schema, so invites are per tenant, like memberships. The table-name constant `USER_INVITES_TABLE_NAME` is exported next to it.
 
 | Field | Type | Notes |
 | ----- | ---- | ----- |
-| `_id` | `string` | Invite id — the `inviteId` the create functions return. |
-| `createdAt` | `Date` | Creation time, indexed. |
-| `email` | `string` | Indexed. |
+| `_id` | `string` | Invite id. The create functions return it as `inviteId`. |
+| `createdAt` | `Date` | Creation time. Indexed across tenant instances. |
+| `email` | `string` | Stored trimmed and lowercased. Indexed across tenant instances. |
 | `firstname` | `string \| null` | Invitee's first name, when the invite carried one. |
 | `lastname` | `string \| null` | Invitee's last name, when the invite carried one. |
 | `roles_ids` | `string[]` | Related to `Role`, many. Roles to grant on redemption. |
 | `language` | `string` | Language the invite was issued in. |
-| `token` | `string` | Indexed. The secret handed to the invitee. |
+| `token` | `string` | The secret handed to the invitee. Indexed across tenant instances. |
 | `asTenantOwner` | `boolean` | Grant tenant ownership on redemption. |
-| `expiresAt` | `Date` | Indexed. `INVITE_EXPIRY_DAYS` after creation. |
+| `expiresAt` | `Date` | `INVITE_EXPIRY_DAYS` after creation. Indexed across tenant instances. |
+| `creationResolutionId` | `string`, optional | Set on a replacement. The replacement is actionable only after the resolution that created it completes. |
+| `invitedBy` | `string \| null`, optional | Id of the user who sent the invitation or last resent it. `null` for an invitation created outside a signed-in request, such as an import or a module. |
+| `extensions` | `InviteExtensionPayloads \| null` | Payloads attached through `RegisterInviteExtension`, keyed by extension key. Delivered when the invitee joins, and deleted with the row when they do not. |
 
-Note the field is `roles_ids`, not `roleIds` — the membership field of that name lives on `TenantMember` ([Tenancy](/docs/interfaces/core/tenancy)).
+The field is `roles_ids`, not `roleIds`. The membership field `roleIds` lives on `TenantMember` ([Tenancy](/docs/interfaces/core/tenancy)).
 
 ## `UserInviteModel`
 
@@ -152,9 +171,9 @@ Note the field is `roles_ids`, not `roleIds` — the membership field of that na
 | `getByEmail(email)` | `Promise<UserInvite \| undefined>` |
 | `getByToken(token)` | `Promise<UserInvite \| undefined>` |
 | `getByTokenWithTenant(token)` | `Promise<{ invite: UserInvite; tenantId: string } \| undefined>` |
-| `deleteByToken(token)` | Deletes every row carrying the token |
+| `deleteByToken(token)` | Deletes every row that carries the token. |
 
-Invitations are stored with their e-mail trimmed and lowercased, and `getByEmail` normalizes its argument the same way, so the casing a caller passes does not matter.
+`getByEmail` trims and lowercases its argument the same way the stored email is, so the casing a caller passes does not matter.
 
 ```ts docs-check
 import { GetModel } from "@antelopejs/interface-database-decorators";
@@ -166,28 +185,28 @@ export async function hasExpiredInvite(tenantId: string, email: string): Promise
 }
 ```
 
-`getByTokenWithTenant` reports the tenant the row came from, which is what a redemption flow needs: the person following an invite link is not authenticated yet, so there is no tenant claim to bind the handle to.
+`getByTokenWithTenant` reports the tenant the row came from. A redemption flow needs it, because the person who follows an invite link is not authenticated yet, so no tenant claim exists to bind the handle to.
 
-Raw deletion, including `deleteByToken`, does not coordinate durable decisions or extension cleanup. Use the invite-resolution contract below for terminal actions, not direct model writes.
+Raw deletion, `deleteByToken` included, does not coordinate durable decisions or extension cleanup. For terminal actions, use the invite resolution contract below instead of direct model writes.
 
 ## `RegisterInviteExtension`
 
-`RegisterInviteExtension<T>(options: InviteExtensionOptions<T>): () => void`, from `@antelopejs/interface-dms/invite-extensions`, contributes fields to the members invite form. Registration belongs to the module and is removed when it stops; the returned function removes it earlier.
+`RegisterInviteExtension<T>(options: InviteExtensionOptions<T>): () => void`, from `@antelopejs/interface-dms/invite-extensions`, adds fields to the members invite form. The registration belongs to the module and is removed when the module stops. The returned function removes it earlier.
 
 | Option | Type | Contract |
 | --- | --- | --- |
-| `key` | `string` | Required non-empty namespace. Must not contain `__`, the field-id separator. |
-| `component` | `FormBuilder` | Required form whose fields join the invite modal. |
-| `schema` | `ZodType<T, ZodTypeDef, unknown>` | Required validator at submission and delivery. Uses unprefixed field ids; callbacks receive parsed output `T`. |
-| `onAccept` | `InviteAcceptHandler<T>` | Required callback after membership exists. |
-| `onCleanup` | `InviteCleanupHandler<T>` | Optional cleanup on cancellation, replacement, expiry or member removal, never acceptance. |
-| `editable` | `boolean` | Defaults to `true`. `false` makes fields read-only on the pending-invitation edit form. |
-| `onUpdate` | `InviteUpdateHandler<T>` | Called after a changed pending payload is stored. Failure is logged, not raised to the caller. |
-| `label` | `string` | Heading, defaulting to the form's title. |
+| `key` | `string` | Required, non-empty namespace. It must not contain `__`, the separator between the key and a field id. Registration throws otherwise. |
+| `component` | `FormBuilder` | Required. The form whose fields join the invite modal. |
+| `schema` | `ZodType<T, ZodTypeDef, unknown>` | Required. Validates the payload at submission and again at delivery. Its keys are the field ids of `component`, without the prefix. Callbacks receive the parsed output `T`. |
+| `onAccept` | `InviteAcceptHandler<T>` | Required. Called after the membership exists. |
+| `onCleanup` | `InviteCleanupHandler<T>` | Optional. Called on cancellation, replacement, expiry, or member removal, and never on acceptance. |
+| `editable` | `boolean` | Defaults to `true`. `false` shows the fields read-only on the edit form of a pending invitation. |
+| `onUpdate` | `InviteUpdateHandler<T>` | Called after a changed payload on a pending invitation is stored. A failure is logged and not raised to the caller. |
+| `label` | `string` | Heading of the contributed block. Defaults to the title of the form. |
 | `description` | `string` | Description of the contribution. |
-| `placement` | `InviteExtensionPlacement` | Optional `side` (`"before"`, `"after"`, `"end"`), `anchorField`, and numeric `order`. Defaults to end, order 0. |
+| `placement` | `InviteExtensionPlacement` | Optional `side` (`"before"`, `"after"`, `"end"`), `anchorField`, and numeric `order`. Defaults to the end, order 0. |
 
-`anchorField` names a top-level field or group of the invite form. Without an anchor, `before` places the contribution first; `after` and `end` append it. Lower orders come first, with extension keys breaking ties. Form field ids are namespaced by `key`; stored `InviteExtensionPayloads` is `Record<string, unknown>`, keyed by extension.
+`anchorField` names a top-level field or field group of the invite form. Without an anchor, `before` places the contribution first, and `after` and `end` append it. Lower orders come first, and extension keys break ties. The key namespaces the form field ids. The stored `InviteExtensionPayloads` type is `Record<string, InviteExtensionJson>`, keyed by extension, where `InviteExtensionJson` is a JSON value that may be read-only.
 
 ### Callback contracts
 
@@ -197,32 +216,38 @@ Raw deletion, including `deleteByToken`, does not coordinate durable decisions o
 | `InviteUpdateHandler<T>` | `(payload: T, previous: T \| undefined, context: InviteExtensionContext)` | `MaybePromise<void>` |
 | `InviteCleanupHandler<T>` | `(payload: T \| undefined, context: InviteCleanupContext)` | `MaybePromise<void>` |
 
-`InviteExtensionContext` has `tenantId`, `email`, and optional `deliveryId` and `inviteId`. Direct addition of an existing account calls `onAccept` without an `inviteId`. `previous` is undefined when no old payload exists or it no longer validates.
+`InviteExtensionContext` has `tenantId`, `email`, and optional `deliveryId` and `inviteId`. When an existing account is added directly, `onAccept` runs without an `inviteId`. `previous` is `undefined` when no old payload exists or the old payload no longer validates.
+
+`InviteCleanupContext` has `tenantId`, `reason: "invite-deleted" | "member-removed"`, and optional `deliveryId`, `inviteId`, `email` and `userId`. Invite cleanup sets `inviteId`. Member cleanup sets `userId`. Durable delivery may replay concurrently with the same `deliveryId`, so deduplicate external effects and scope the cleanup of invite resources to `inviteId`. The [durable delivery guidance](/docs/building/backend-services#extension-and-hook-delivery) lists the operational obligations.
 
-`InviteCleanupContext` has `tenantId`, `reason: "invite-deleted" | "member-removed"`, and optional `deliveryId`, `inviteId`, `email`, and `userId`. Invite cleanup identifies the invitation; member cleanup identifies the user. Durable delivery may replay concurrently with the same `deliveryId`: deduplicate external effects and scope invite resource cleanup to `inviteId`. See [durable delivery guidance](/docs/building/backend-services#extension-and-hook-delivery) for operational obligations.
+## Durable invite resolution
 
-## Durable Invite Resolution
+The functions in `@antelopejs/interface-dms/invite-resolution` coordinate competing terminal actions. They do not authorize the caller. Prefer the higher-level invitation entry points, unless you implement a terminal action yourself.
 
-The functions in `@antelopejs/interface-dms/invite-resolution` coordinate competing terminal actions. They do not authorize the caller. Prefer the higher-level invitation entry points unless implementing a terminal action yourself.
+| Function | Signature | Result |
+| --- | --- | --- |
+| `loadInviteForAction` | `(tenantId: string, inviteId: string) => Promise<UserInvite \| undefined>` | Loads the exact invitation, or its durable snapshot after the live row is gone. |
+| `assertInviteReady` | `(tenantId: string, invite: UserInvite) => Promise<void>` | Rejects with HTTP 409 (`Invitation creation is still pending`) while the creation of a replacement is incomplete. |
+| `decideInvite` | `(input: ResolveInviteInput) => Promise<InviteResolution>` | Records one permanent terminal outcome before any effect. A conflicting reason or user rejects with HTTP 409, and so does conflicting replacement content. A new acceptance of an expired invitation also rejects with 409. |
+| `completeInviteResolution` | `(resolution: InviteResolution) => Promise<void>` | Enters tenant lifecycle admission through `changeTenantMembers` and replays the effects. A callback failure retains the snapshot for a retry. |
 
-| Function | Signature and result |
-| --- | --- |
-| `loadInviteForAction` | `(tenantId: string, inviteId: string) => Promise<UserInvite \| undefined>` — loads the exact invitation or its durable snapshot after the live row is gone. |
-| `assertInviteReady` | `(tenantId: string, invite: UserInvite) => Promise<void>` — rejects with HTTP 409 while a replacement's creation is incomplete. |
-| `decideInvite` | `(input: ResolveInviteInput) => Promise<InviteResolution>` — records one permanent terminal outcome before effects. Conflicting reason, user or replacement content rejects with HTTP 409. A new acceptance of an expired invitation also rejects. |
-| `completeInviteResolution` | `(resolution: InviteResolution) => Promise<void>` — enters tenant lifecycle admission and replays effects; callback failures retain the snapshot for retry. |
+`ResolveInviteInput` contains `tenantId`, `invite: UserInvite`, `reason: InviteResolutionReason`, and optional `userId` and `replacement: UserInvite`. `InviteResolutionReason` is `"accepted" | "cancelled" | "replaced" | "resent" | "expired"`. The API captures the extension keys itself, so callers do not supply them.
 
-`ResolveInviteInput` contains `tenantId`, `invite: UserInvite`, `reason: InviteResolutionReason`, and optional `userId` and `replacement: UserInvite`. `InviteResolutionReason` is `"accepted" | "cancelled" | "replaced" | "resent" | "expired"`. The API captures extension keys itself; callers do not supply them.
+`InviteResolution`, from `@antelopejs/interface-dms/db`, is the stored decision and retry snapshot. Its fields are `_id`, `tenantId`, `reason`, nullable `userId`, `invite`, optional `inviteToken`, nullable `replacement`, `extensionKeys`, `revision`, `membershipPhase`, `replacementPhase`, `completed` and `decidedAt`. Both phase fields use `InviteMembershipPhase` (`"pending" | "applying" | "applied"`). Treat a resolution as a read-only result and pass it back to completion. Do not change the model to advance phases.
 
-`InviteResolution` (from `/db/tables/inviteResolutions.table`) is the stored decision and retry snapshot: `_id`, `tenantId`, `reason`, nullable `userId`, `invite`, optional `inviteToken`, nullable `replacement`, `extensionKeys`, `revision`, `membershipPhase`, `replacementPhase`, `completed`, and `decidedAt`. Both phase fields use `InviteMembershipPhase` (`"pending" | "applying" | "applied"`). Treat these as read-only results and pass the decision back to completion; do not mutate the model to advance phases.
+Custom producers of memberships or invitations must follow [tenant lifecycle admission](/docs/interfaces/core/tenancy#tenant-lifecycle-admission). Every competing terminal path must decide before it produces effects. A durable decision does not make external effects exactly-once, so callback implementations still own their idempotency.
 
-Custom membership/invite producers must follow [tenant lifecycle admission](/docs/interfaces/core/tenancy#tenant-lifecycle-admission), and all competing terminal paths must decide before producing effects. A durable decision does not make external effects exactly-once; callback implementations still own idempotency.
+## Mark the invite action unavailable
 
-## Mark the Invite Action Unavailable
+`RegisterInviteAvailability`, from `@antelopejs/interface-dms/invite-extensions`, lets a module disable the **Invite** button of the members page while one of its conditions holds, such as a plan whose seats are all taken. The resolver is an `InviteAvailabilityResolver`. It runs once per request while the page layout is built, with a `ComponentFilterContext` that carries `tenantId` and `user`. It returns one of three values:
 
-`RegisterInviteAvailability`, from `@antelopejs/interface-dms/invite-extensions`, lets a module disable the members page's **Invite** button while one of its conditions holds — a plan whose seats are all taken, say. The resolver runs per request while the page layout is built, with `{ tenantId, user }`; returning `{ reason }` disables the button and shows the reason next to it, `undefined` leaves it enabled. The first resolver to refuse wins, and one that throws is logged and ignored.
+- `{ reason }` disables the button and shows the reason next to it. A `$`-prefixed reason resolves as an i18n key.
+- `{ hidden: true }` hides the button.
+- `undefined` leaves the button enabled.
 
-```typescript
+Resolvers run in registration order, and the first one that refuses wins. A resolver that throws is logged and ignored.
+
+```typescript fragment
 import { RegisterInviteAvailability } from "@antelopejs/interface-dms/invite-extensions";
 
 RegisterInviteAvailability(async ({ tenantId }) =>
@@ -232,8 +257,8 @@ RegisterInviteAvailability(async ({ tenantId }) =>
 );
 ```
 
-It only shapes the UI. A module that must refuse the invitation itself does so from `Hook.INVITE_BEING_CREATED` and `Hook.MEMBER_BEING_ADDED`. The registration is lifted when the registering module stops; the returned function removes it earlier.
+The resolver only shapes the UI. A module that must refuse the invitation itself does so from `Hook.INVITE_BEING_CREATED` and `Hook.MEMBER_BEING_ADDED`. The registration is lifted when the registering module stops, and the returned function removes it earlier.
 
-## Next Steps
+## Next steps
 
 [Hooks](/docs/interfaces/core/hooks) covers the invite and membership events these functions fire, and how to react to them.