@foir/sdk 0.23.0 → 0.24.0

package/CHANGELOG.md

@@ -108,6 +108,33 @@ nobody asking for `@foir/sdk` gets it early. The push that carries the commit to
 
 Changes on `dev` that have not been published to npm.
 
+## [0.24.0] — 2026-10-18
+
+### Changed
+
+- **`joinWaitlist` resolves `true` for every address** (`@foir/sdk/auth`). It
+  used to resolve the waitlist entry, whose status told anyone who asked
+  whether an address had been approved. The server now answers every address
+  alike, whether it was queued, was already let in, or already has an account,
+  and what differs is only the email the address is sent. Migration: stop
+  reading `id`, `email` or `status` from the result; a resolved call means the
+  address was not refused.
+- **`myProviderToken` and `logout` act for one sign-in** (`@foir/sdk/auth`). A
+  provider's token belongs to the sign-in that obtained it, so `logout` ends
+  this device's and no other device's, and a sign-in with nothing kept for it
+  resolves `linked: false` with `reauthenticate: true`. Migration: where
+  `reauthenticate` is true, show the user the way to sign in through the
+  provider again rather than an empty or failed page.
+
+### Removed
+
+- **`WaitlistJoinResult`** (`@foir/sdk/auth`, type). `joinWaitlist` resolves a
+  boolean.
+- **`verifyEmail`** (`@foir/sdk/auth`). It redeemed verification tokens that
+  only the console's own sign-up minted, and that lane is gone. An address is
+  proven by the code it is sent: `requestOTP`, then `loginWithOTP`, which marks
+  the address proven and lets in a person who was waiting to prove it.
+
 ## [0.23.0] — 2026-10-16
 
 ### Added
@@ -186,23 +213,23 @@ Changes on `dev` that have not been published to npm.
 
 ### Changed
 
-- **Breaking: everyone who signs in is a user, and nothing says customer or
-  admin as a kind.** It needs the platform release that serves the same
+- **Breaking: everyone who signs in is a user, and no name says what kind
+  of person somebody is.** It needs the platform release that serves the same
   names; an earlier platform refuses every call below by name.
   - `@foir/sdk/auth`: the raw calls take the server's op names: `login`,
     `register`, `requestOTP`, `loginWithOTP`, `refreshTokens` (the
     `refreshToken` op), `logout`, `joinWaitlist`, `signupContext`,
     `requestPasswordReset`, `resetPassword`, `updatePassword`, `verifyEmail`,
-    `loginWithProvider`, `providerCallback`, `providerVerifyOTP` (were
-    `customerLogin` and the rest), and `registerOrganization` founds an
-    organization over the `registerOrganization` op (was
-    `registerOperatorOrganization`). The helpers that save a session are
+    `loginWithProvider`, `providerCallback`, `providerVerifyOTP`, each
+    renamed from a name that said what kind of person called it, and
+    `registerOrganization` founds an organization over the
+    `registerOrganization` op. The helpers that save a session are
     `signInWithPassword`, `signUpWithPassword` and `signInWithOTP` (were
     `loginWithPassword`, `registerWithPassword`, `loginWithOTP`), beside
-    `signOut`. `getSessionCustomer` is `getSessionUser`, `customerAccess` is
-    `userAccess`, `CustomerAuthResult` is `AuthResult` and carries `userId`,
-    `FoirCustomer` is `FoirUser` (`{ id, email }`), and `FoirAccess.customerId`
-    is `userId`. A session is stored under `foir:userId`, so one saved by an
+    `signOut`. The session, access and result helpers are `getSessionUser`,
+    `userAccess` and `AuthResult` (which carries `userId`), the signed-in
+    person is `FoirUser` (`{ id, email }`), and `FoirAccess` names them as
+    `userId`. A session is stored under `foir:userId`, so one saved by an
     earlier version reads as signed out once.
   - `@foir/sdk/auth`: a provider sign-in that names an address somebody
     already holds waits for the code sent to it: `providerSignInRefusalOf`
@@ -211,23 +238,23 @@ Changes on `dev` that have not been published to npm.
   - `@foir/sdk/auth`: the hosted session answers `userId`
     (`HostedSession.userId`, `FoirSessionUser.userId`), from the platform's
     `user_id`, and its cookie is `foir_session`.
-  - `@foir/sdk/react`: `useFoirSession()` answers `user` (was `customer`).
-  - `@foir/sdk/app`: `records.user` and `users` (were `records.customer` and
-    `customers`), over the platform's `saveUserRecord`, `userRecordByIdentity`,
+  - `@foir/sdk/react`: `useFoirSession()` answers `user`.
+  - `@foir/sdk/app`: `records.user` and `users`, over the platform's
+    `saveUserRecord`, `userRecordByIdentity`,
     `eraseUserRecord`, `createUser`, `user`, `users`, `userByIdentity` and
     `userIdentitiesById`. `users.list()` answers `{ users }`. `AppUser`,
     `AppUserList`, `AppUserSaveResult` (`userCreated`), `AppUserEraseResult`
     (`userDeleted`, `userKeptBecause`), `AppUserEmailUnavailableReason`,
-    `appUserUnlinkedOf` and `appUserEmailUnavailableOf` replace the
-    `AppCustomer` names. A notification, a consent change and an
+    `appUserUnlinkedOf` and `appUserEmailUnavailableOf` are the app client's
+    names for the people it reads. A notification, a consent change and an
     organization's first member name `userId`.
   - `@foir/sdk/server`: an operation's context names who started the run as
-    `actorId` and the user it acts for as `userId` (was `userId` and
-    `customerId`). `ScopedTokenIngress.userId` was `customerId`.
+    `actorId` and the user it acts for as `userId` (`userId` used to name
+    who started it). `ScopedTokenIngress` names the user as `userId`.
   - `@foir/sdk/data`: `FoirGranteeKind` is `'USER'`, a note's subject may be
-    `'user'`, `FoirUserNote` and `FoirUserNoteAttachment` replace the
-    `FoirCustomerNote` names, and `FoirAuthDowngrade.userToken` was
-    `customerToken`.
+    `'user'`, a note of a user's is `FoirUserNote` with
+    `FoirUserNoteAttachment`, and `FoirAuthDowngrade` names the dropped
+    token `userToken`.
 
 ### Removed
 
@@ -235,8 +262,9 @@ Changes on `dev` that have not been published to npm.
   (`@foir/sdk/auth`). Nothing stores where a user stands: a request names the
   organization it acts in (`orgId` or `orgUrl`), and the platform checks they
   stand there on that request. `myOrganizations` still lists where they may.
-- **Breaking: `requireAdmin` and `RequireAdminOptions`, and `isAdmin` on
-  `FoirUser`** (`@foir/sdk/auth`). What a user may do is a role or a scope:
+- **Breaking: the helpers that guarded on a person being of the managing
+  kind, and the flag on `FoirUser` that said so** (`@foir/sdk/auth`). What a
+  user may do is a role or a scope:
   guard on it with `requireRole` or `requireScope`. `requireAuth` takes the
   type `resolveUser` answers, for a project that reads its own profile.
 
@@ -246,7 +274,7 @@ Changes on `dev` that have not been published to npm.
 
 - **An operation provisions an organization** (`@foir/sdk/app`).
   `organizations.provision({ provisionId, name, parentId?, settings?, firstMember? })`
-  makes an organization with a customer as its first member, in the role the
+  makes an organization with a user as its first member, in the role the
   project names for a founder, and answers `{ organizationId }`. It needs
   `organizations:create`. With `settings: { modelKey, data }` it writes the
   organization's settings record too and answers `settingsRecordId`; that
@@ -261,7 +289,7 @@ Changes on `dev` that have not been published to npm.
   needs the platform release that carries `scheduleOrganizationDeletion`.
 - **`FoirWriteNoteArgs`** (`@foir/sdk/data`): the arguments of
   `foir.ns.notes.writeNote`, the one field that writes a note for a signed-in
-  customer and for a visitor. It asks `notes:create` and needs the platform
+  user and for a visitor. It asks `notes:create` and needs the platform
   release that carries `writeNote`. `foir.ns.notes` answers any field the
   platform serves, so the call itself needs no new SDK.
 
@@ -288,7 +316,7 @@ Changes on `dev` that have not been published to npm.
   itself uses `createServerClient` from `@foir/sdk/server`. A key minted
   before a key had a kind (`sk_`) is not refused here.
 - **A key's kind is read from its prefix in one place.** A key is publishable
-  (`foir_pub_`), server (`foir_srv_`) or admin (`foir_adm_`), and a key minted
+  (`foir_pub_`), server (`foir_srv_`) or the console (`foir_adm_`), and a key minted
   earlier is `pk_`, `sk_` or `tc_`. Only a publishable key, in either format,
   is named in a URL and takes the shared cache lane. Earlier versions looked
   for the letters `pk_` alone, so a `foir_pub_` key was sent to the origin and
@@ -352,7 +380,7 @@ to this version then.
   reads it as what those were worth, exactly as the platform does.
 
   A record grant reaches the operation's own records: the project's, or those
-  of the customer a run acts for. `records:read.all:<model>`, and the write,
+  of the user a run acts for. `records:read.all:<model>`, and the write,
   delete and publish forms like it, reach every owner's records of the model.
   An older token's write of a model was every owner's, so it is read as
   `records:write.all:<model>` and `records:create:<model>`, and takes that
@@ -381,19 +409,19 @@ to this version then.
   platform holds a running install's setting to a category the project has.
 
 - **An app can say what connecting changes** (`@foir/sdk/app/contract`).
-  `Credentials.connectNotice` is the app's own words, shown to the operator
+  `Credentials.connectNotice` is the app's own words, shown to the user
   beside the step that connects their account and, for an install the vendor
   started, before the install is confirmed. A vendor that keeps one live
   connection per account (Shopify, per store) says here that connecting moves
   it from any other project. Empty when there is nothing to say.
 
-- **The roles a signed-in customer holds, and what they may do**
-  (`@foir/sdk/auth`, `@foir/sdk/react`). A storefront can now ask which customer
-  roles the signed-in customer holds and show the page to match, where before
+- **The roles a signed-in user holds, and what they may do**
+  (`@foir/sdk/auth`, `@foir/sdk/react`). A storefront can now ask which user
+  roles the signed-in user holds and show the page to match, where before
   it had to treat one of a role's permissions as a stand-in for the role.
 
-  - `getSessionAccess(adapter, env)` and `customerAccess(env, { bearerToken })`
-    return a `FoirAccess`: the customer's id, the keys of the roles they hold
+  - `getSessionAccess(adapter, env)` and `userAccess(env, { bearerToken })`
+    return a `FoirAccess`: the user's id, the keys of the roles they hold
     (`roles`), and everything they may do through the key (`scopes`). Plain
     data, so a loader can return it. `null` when nobody is signed in.
   - `hasRole(access, key)` and `hasScope(access, scope)` read it. `hasScope`
@@ -412,7 +440,7 @@ to this version then.
   and a role taken away is gone the next time it is asked.
 
   `roles` is `null`, not an empty list, when the platform did not say which
-  roles the customer holds. `hasRole` answers false for it and `requireRole`
+  roles the user holds. `hasRole` answers false for it and `requireRole`
   refuses with `roles_unknown`, so an outage is never read as "not staff". A
   platform that does not serve the field yet reads the same way: the role
   helpers need the platform release that carries it.
@@ -424,7 +452,7 @@ to this version then.
   `accessStatus`, `loadAccess` and `ensureAccess`.
 
 - **A save says when it made a record the operation may not read**
-  (`@foir/sdk/app`). `records.upsert` and `records.customer.save` answer
+  (`@foir/sdk/app`). `records.upsert` and `records.user.save` answer
   `fieldsWithheld`. It is true when the operation declared the create of a
   model and not the read: the save made the record, and `record` carries its
   `id` and `modelKey` and nothing else. The record is not empty.
@@ -440,13 +468,13 @@ to this version then.
   app's operations are given the one they could use, so an installed app keeps
   running; a manifest served from then on says it.
 
-- **Breaking, with the platform release that carries it: erasing a customer
-  takes `identities:delete`** (`@foir/sdk/app`). `records.customer.erase` needed
+- **Breaking, with the platform release that carries it: erasing a user
+  takes `identities:delete`** (`@foir/sdk/app`). `records.user.erase` needed
   `users:create` beside the delete and the read of the model, and now needs
   `identities:delete` there. `APP_GRANTS` carries it, with `files:delete`,
   `notifications:read` and every owner's files (`files:read.all`,
   `files:write.all`, `files:delete.all`), which a manifest may now declare.
-  `verifyScopedToken` reads a token minted before, that carried the customer
+  `verifyScopedToken` reads a token minted before, that carried the user
   create beside the delete of a model, as holding `identities:delete`, as the
   platform does.
 
@@ -464,17 +492,14 @@ to this version then.
   | `config:read` | `appconfig:read` |
   | `secrets:read.app`, `secrets:put.app`, `secrets:list.app`, `secrets:delete.app` | `appsecrets:read`, `appsecrets:put`, `appsecrets:list`, `appsecrets:delete` |
   | `files:list` | `files:read` |
-  | `customers:write` | `users:create` |
-  | `customers:read` | `users:read.all` |
-  | `customers:read:named` | `users:read.named` |
-  | `customers:read:identity` | `identities:read` |
+  | The names for writing and reading a project's users | `users:create`, `users:read.all`, `users:read.named`, `identities:read` |
   | `notifications:write` | `notifications:write.named` |
   | `records:write:<model>` | `records:write:<model>` and `records:create:<model>` |
 
   The last row is a change in what the name means. `records:write:<model>`
   changes a record that is there, and making one is `records:create:<model>`.
   An operation that does both declares both. `records.upsert` and
-  `records.customer.save` are let through on either, and the platform asks for
+  `records.user.save` are let through on either, and the platform asks for
   the one the save turns out to need.
 
 - **Breaking, with the platform release that carries it: a full-page placement
@@ -487,7 +512,7 @@ to this version then.
   things change in what a placement writes:
 
   - **Every owner's records are written `.all`.** `records:read:order` was
-    every order and is now the operator's own. Declare
+    every order and is now the user's own. Declare
     `records:read.all:order`.
   - **A write no longer includes its read.** `records:write:order` also read
     and created, and `apps:write` also read apps. Declare each one the page
@@ -496,8 +521,8 @@ to this version then.
   - **A wildcard and a permission that gives others are refused**, as `*`
     always was.
 
-  The token then carries what the placement declares and the operator holds,
-  permission by permission. An operator who holds part of a declared grant is
+  The token then carries what the placement declares and the user holds,
+  permission by permission. A user who holds part of a declared grant is
   given that part, where before the whole name was withheld.
 
 - **`session.can` answers by what the token covers** (`@foir/sdk/placement`).
@@ -538,11 +563,11 @@ to this version then.
     `records:read` for the model beside their own permission.
   - An operation that declares the create of a model and not the read
     (`@foir/sdk/app`) still makes its records. `records.upsert` landing on a
-    record already there, `records.customer.save` likewise, `records.delete`,
+    record already there, `records.user.save` likewise, `records.delete`,
     `records.refresh`, `records.rename` and `records.updateMany` are refused
     until it declares the read too.
 
-- **Breaking, with the platform release that carries it: `records.customer.erase`
+- **Breaking, with the platform release that carries it: `records.user.erase`
   needs the delete of the model** (`@foir/sdk/app`). An erase removes a record,
   so the operation declares `records:delete` and `records:read` for the model,
   and `users:create`. Until now the grant to save the record was enough. An
@@ -554,14 +579,14 @@ to this version then.
   `MyOrganizationRole.permissions` is gone and `MyOrganizationRole.grants`
   takes its place: what the role gives, in the permission catalogue's names. A
   grant stands for itself, so changing a record and creating one are two
-  names (`records:write`, `records:create`), reading every customer's records
+  names (`records:write`, `records:create`), reading every user's records
   is `records:read.all`, and staffing an organization is `members:read` and
   `members:write`. Code that looked for `organizations:staff` or
   `records:list.all` in a role's list looks for the new names.
 
-- **Breaking, with the platform release that carries it: `customers.byIdentity`
-  and `customers.identities` need `identities:read`, declared by name**
-  (`@foir/sdk/app`). The read of every customer, `users:read.all`, no longer
+- **Breaking, with the platform release that carries it: `users.byIdentity`
+  and `users.identities` need `identities:read`, declared by name**
+  (`@foir/sdk/app`). The read of every user, `users:read.all`, no longer
   includes them.
 
 ### Removed
@@ -632,29 +657,29 @@ the next promotion; `latest` moves to this version then.
   (`@foir/sdk/data`). Code that reads a drift is unaffected. Code that builds
   one by hand, for example to test a handler given to `onSchemaDrift` or made by
   `createFoirDriftHandler`, must add `incompatible: []`.
-- **Breaking (types): `AppConsentChange` names its customer one way**
-  (`@foir/sdk/app`). It was an interface with a required `customerId`. It is
-  now a type that holds a `customerId` or an `email`, never both. A change
-  written as `{ customerId, ... }` is unaffected. An interface that extended
+- **Breaking (types): `AppConsentChange` names its user one way**
+  (`@foir/sdk/app`). It was an interface with a required `userId`. It is
+  now a type that holds a `userId` or an `email`, never both. A change
+  written as `{ userId, ... }` is unaffected. An interface that extended
   `AppConsentChange` no longer compiles: intersect with it instead.
 
 ### Added
 
-- `notifications.setConsent` takes `email` in place of `customerId`
-  (`@foir/sdk/app`), for an opt-in from somebody who may have no customer yet,
-  such as a sign-up form. The platform finds the customer holding the address
+- `notifications.setConsent` takes `email` in place of `userId`
+  (`@foir/sdk/app`), for an opt-in from somebody who may have no user yet,
+  such as a sign-up form. The platform finds the user holding the address
   at the install's level, or makes one, together with the change, so a change
   it refuses (a category the project does not have, a confirmation email the
-  project cannot send) leaves no customer behind. Finding or making the
-  customer first with `customers.ensure` did. The operation must declare
-  `customers:write` as well as `notifications:consent`. `AppConsentSubject` is
+  project cannot send) leaves no user behind. Finding or making the
+  user first with `users.ensure` did. The operation must declare
+  `users:create` as well as `notifications:consent`. `AppConsentSubject` is
   exported.
 
 - `FoirSchemaDrift.incompatible`: what the generated module describes that the
   server no longer serves that way, as sorted paths into the manifest
   (`models.order.selection.status`, `models.order.ops.update`,
   `namespaces.search.ops.searchRecords.args.query`,
-  `models.order.relations.customer`, `selectionUnions.Block.HeroBlock.title`).
+  `models.order.relations.buyer`, `selectionUnions.Block.HeroBlock.title`).
   Empty when the surface has only grown. `changed` keeps its meaning: what
   moved, not what broke.
 
@@ -665,26 +690,26 @@ platform serves from the next promotion; `latest` moves to it then.
 
 ### Changed
 
-- **Breaking: an app finds a customer by identity through its install, not
-  through a model** (`@foir/sdk/app`). The customer sign-in an app's customers
+- **Breaking: an app finds a user by identity through its install, not
+  through a model** (`@foir/sdk/app`). The user sign-in an app's users
   come through is paired with the install as a whole, so the two reads that
-  walk it no longer name a model and have moved beside the other customer
+  walk it no longer name a model and have moved beside the other user
   reads:
-  - `records.customer.identities(model, customerId)` is now
-    `customers.identities(customerId)`.
-  - `customers.byIdentity(identity)` is new: the id of the customer who holds
+  - `records.user.identities(model, userId)` is now
+    `users.identities(userId)`.
+  - `users.byIdentity(identity)` is new: the id of the user who holds
     an identity at the app's own system, or `null`. It replaces reading a
-    customer's record for its owner.
+    user's record for its owner.
 
-  Both need the new capability `customers:read:identity` (or `customers:read`),
+  Both need the new capability `identities:read` (or `users:read.all`),
   declared by the operation, and are refused at an install that pairs no
   sign-in. Reading or writing a model is no longer what admits them.
-- `install.config()` asks the platform for `customerSignIn`, a field a platform
+- `install.config()` asks the platform for `userSignIn`, a field a platform
   older than this release does not have.
 
 ### Added
 
-- `install.config()` answers `customerSignIn`: the key of the customer sign-in
+- `install.config()` answers `userSignIn`: the key of the user sign-in
   the install pairs, or `null` when it pairs none.
 
 ## [0.17.0] — 2026-10-02
@@ -694,19 +719,19 @@ platform serves from the next promotion; `latest` moves to it then.
 
 ### Added
 
-- **An app is told when a project cannot email its customers**
+- **An app is told when a project cannot email its users**
   (`@foir/sdk/app`). A project with no App base URL used to accept a
   notification's email and drop it. The platform now refuses a notification
   that carries an email, and an opt-in to a category confirmed by email, with
-  the reason as data. `appCustomerEmailUnavailableOf(error)` reads it:
+  the reason as data. `appUserEmailUnavailableOf(error)` reads it:
   `{ reason: 'NO_APP_BASE_URL' }`, or `null` for any other failure.
-- `install.config()` answers `customerEmailUnavailable`: the same reason ahead
-  of time, or `null` when the project can send. `AppCustomerEmailUnavailableReason`
+- `install.config()` answers `userEmailUnavailable`: the same reason ahead
+  of time, or `null` when the project can send. `AppUserEmailUnavailableReason`
   is the type.
 
 ### Changed
 
-- `install.config()` asks the platform for `customerEmailUnavailable`, a field
+- `install.config()` asks the platform for `userEmailUnavailable`, a field
   a platform older than this release does not have.
 
 ## [0.16.0] — 2026-10-02
@@ -717,11 +742,11 @@ it at the next promotion.
 ### Added
 
 - **An embedded page is told how the console looks** (`@foir/sdk/placement`).
-  The console's theme is the operator's own setting, which a framed page cannot
+  The console's theme is the user's own setting, which a framed page cannot
   see, so a page that followed the system's preference could sit dark inside a
   light console. `connectPlacement` takes `onAppearance`, called with
   `{ theme: 'light' | 'dark' }` as soon as the console says (before the token
-  arrives) and again whenever the operator changes it; `session.appearance`
+  arrives) and again whenever the user changes it; `session.appearance`
   holds the current one. `PlacementAppearance` is the type, and
   `PLACEMENT_MESSAGE.appearance` the message.
 - A console older than this says nothing: `onAppearance` is not called and
@@ -739,7 +764,7 @@ then.
 - **`notifications.setConsent` answers `confirmationPending`**, and takes
   `givenElsewhere` and `locale` (`@foir/sdk/app`). A project can ask that an
   opt-in an app collects in a category is confirmed by email before it counts.
-  In such a category an opt-in writes nothing: the platform sends the customer
+  In such a category an opt-in writes nothing: the platform sends the user
   one confirmation email, in the page's `locale` when they have stated no
   language of their own, and the answer says `confirmationPending`. The
   preference turns on when they follow the link. Everywhere else an opt-in is
@@ -760,17 +785,17 @@ then.
 
 ### Added
 
-- **`customers.get`, `customers.byEmail` and `customers.list`** on the app
-  client (`@foir/sdk/app`): an operation reads the customers its work is about.
-  `get(id)` and `byEmail(email)` answer one customer or null, and need
-  `customers:read:named`: the customer the operation names, by id or by their
+- **`users.get`, `users.byEmail` and `users.list`** on the app
+  client (`@foir/sdk/app`): an operation reads the users its work is about.
+  `get(id)` and `byEmail(email)` answer one user or null, and need
+  `users:read.named`: the user the operation names, by id or by their
   exact email address at the install's level, and nothing wider. `list` pages
-  through the customers at the install's level and needs `customers:read`,
+  through the users at the install's level and needs `users:read.all`,
   which covers the two lookups as well. An operation declaring only the named
-  read is refused the list. `AppCustomer` and `AppCustomerList` are their types.
-- **`customers.ensure` answers `verified`**: whether the customer it found or
-  made has proved the address is theirs. It finds the customer holding the
-  email either way, so one shopper asking twice is one customer; a caller with
+  read is refused the list. `AppUser` and `AppUserList` are their types.
+- **`users.ensure` answers `verified`**: whether the user it found or
+  made has proved the address is theirs. It finds the user holding the
+  email either way, so one shopper asking twice is one user; a caller with
   something that should wait for proof asks the flag first.
 
 ## [0.13.0] — 2026-10-01
@@ -797,7 +822,7 @@ then.
   order, at most `first` of them, with `hasMore` saying the filter matched more.
   For work an app hands out in turn, such as the next ten people waiting: list
   them, then update the ones listed by id. A model's list is named by its
-  plural, which its operator may set, so the first list a client makes reads
+  plural, which its user may set, so the first list a client makes reads
   the data API's surface descriptor (`GET /v1/manifest`) as the same token,
   once. `AppRecordList` is its query's type.
 
@@ -822,12 +847,12 @@ production serves from the next promotion; `latest` moves to it then.
     `whoami`, `install.config`, `install.credentials`,
     `install.writeCredentials`, `install.reportStatus`, `records.upsert`,
     `read`, `delete`, `refresh`, `rename`, `updateMany` and `aggregate`,
-    `records.customer.save`, `read`, `erase` and `identities`,
-    `customers.ensure`, `notifications.send` and `notifications.setConsent`, and
+    `records.user.save`, `read`, `erase` and `identities`,
+    `users.ensure`, `notifications.send` and `notifications.setConsent`, and
     `request` for a document of your own. Nothing is checked before a call: what
     the token may do is the platform's to hold it to, and a refusal is a
     `FoirRequestError` carrying the platform's answer.
-  - `appLookupConflictOf`, `appCustomerUnlinkedOf` and `isAppFieldWithheld` read
+  - `appLookupConflictOf`, `appUserUnlinkedOf` and `isAppFieldWithheld` read
     the refusals an app acts on, as data.
   - `readAppDispatch` and `readCredentialProbe` read the two bodies the platform
     posts to an app, and `redeemExchangeTicket` trades an OAuth exchange ticket
@@ -855,7 +880,7 @@ production serves from the next promotion; `latest` moves to it then.
   what it throws when it has no keys to judge a token by.
 - **`requireScopedToken` answers more about who is calling.** The ingress it
   resolves with gains `orgId` (the organisation level the token was minted at,
-  `null` when it states none), `customerId`, `expiresAt` and `tokenId`.
+  `null` when it states none), `userId`, `expiresAt` and `tokenId`.
   `ScopedTokenError` gains `reason` (`missing`, `invalid`, `forbidden` or
   `unavailable`), and its `status` may now be 503: keys that cannot be fetched
   are this service's outage, which the platform retries, and not a verdict on
@@ -867,7 +892,7 @@ production serves from the next promotion; `latest` moves to it then.
   passed. It takes `apiUrl`, used when a dispatch names no address to report
   to, `retry`, and `signal`. A call the platform did not answer, or answered
   with a 5xx or a 429, is tried again, with the same signed bytes.
-- **`@foir/sdk/placement`**, a new subpath for an app's own admin console shown
+- **`@foir/sdk/placement`**, a new subpath for an app's own console shown
   inside Foir's as a full-page placement. `connectPlacement` tells the console
   the page is ready, takes the token it posts into the frame (only from the
   consoles you list), keeps it fresh, and gives you `request`, `can` and
@@ -926,8 +951,8 @@ production serves from the next promotion; `latest` moves to it then.
     once and asks again, failing with `FoirSessionExpiredError` when the session
     is over.
   - A request that sent no bearer is untouched.
-- **A refresh that names no customer keeps the session's identity.**
-  `saveSession` used to write the customer id and email unconditionally, so a
+- **A refresh that names no user keeps the session's identity.**
+  `saveSession` used to write the user id and email unconditionally, so a
   refresh answered without them left a valid token beside an empty identity, and
   `requireAuth` turned the session away. Given `env`, `requireAuth` now reads a
   missing identity once from `currentUser` rather than failing.
@@ -985,10 +1010,10 @@ surface version instead of the schema counter.
   credential.
 
   Two things a dispatch client does not do. It does not subscribe: the
-  subscription socket authenticates a key, an admin token or a customer bearer
+  subscription socket authenticates a key, a console user token or a user bearer
   and has no path for a dispatch token, so `onChange` and friends throw, naming
   why. And it takes no key-side option (`apiKey`, `bearerToken`, `orgId`,
-  `channel`, the socket options), because the token carries its own customer,
+  `channel`, the socket options), because the token carries its own user,
   organization and channel; each is a compile error and a runtime refusal.
 
 - `readDispatch(request)` and `OperationPayloadError` on `@foir/sdk/server`.
@@ -1015,7 +1040,7 @@ surface version instead of the schema counter.
 
 - `FoirRecordOwner` on `@foir/sdk/data`: `{ id, ownerId, ownerKind }`, what
   `setOwner` answers with. An operation that declares `records:attribute:<model>`
-  hands a record to another customer with `foir.<model>.setOwner({ id, ownerId })`,
+  hands a record to another user with `foir.<model>.setOwner({ id, ownerId })`,
   and names the owner of a record it creates with `create({ input, ownerId })`.
   The answer carries the owner and not the record, because an operation acting
   for the previous holder may no longer read it.
@@ -1259,14 +1284,14 @@ returns a result object rather than `HostedSession | null`, and
   silent wrong answer for a thrown one that discards the answer. Nothing changes
   for a caller that does not pass it.
 
-- `registerOrganization(env, { key, name }, { bearerToken })` on `@foir/sdk/auth`: a customer founds an organization of their own and becomes its first member, holding the role the project's `organizationSignupRole` setting names. Returns the same `MyOrganization` entry `myOrganizations` lists. Present on the wire only while the project's `organizationSignupEnabled` setting is on.
-- **The operator's organization context, on `@foir/sdk/auth`** — `myOrganizations`
+- `registerOrganization(env, { key, name }, { bearerToken })` on `@foir/sdk/auth`: a user founds an organization of their own and becomes its first member, holding the role the project's `organizationSignupRole` setting names. Returns the same `MyOrganization` entry `myOrganizations` lists. Present on the wire only while the project's `organizationSignupEnabled` setting is on.
+- **The user's organization context, on `@foir/sdk/auth`** — `myOrganizations`
   and `selectOrganization`, plus the types `MyOrganization` and
   `SelectedOrganization`, and two entries on `AUTH_OPS`.
 
   A Fóir project can be partitioned into organizations, one per tenant of a SaaS
-  built on Fóir. An *operator* is a customer who runs one or more of them.
-  `myOrganizations()` answers which ones this customer may stand in — from their
+  built on Fóir. An *user* is a user who runs one or more of them.
+  `myOrganizations()` answers which ones this user may stand in — from their
   own membership rows, so it is not the project's inventory and cannot be used as
   one — and `selectOrganization({ orgId })` says which. An empty `orgId` clears
   the selection.
@@ -1276,7 +1301,7 @@ returns a result object rather than `HostedSession | null`, and
   caller's membership on every request. An application therefore cannot forget
   to send it, cannot send another organization's, and cannot be made to cross
   the boundary by a query it built wrong. These two functions are the entire
-  per-customer surface; everything downstream names no organization at all.
+  per-user surface; everything downstream names no organization at all.
   (The project credential's side of the same boundary is the client-level
   `orgId` option below — a property of the client, still never of a call.)
 
@@ -1390,7 +1415,7 @@ returns a result object rather than `HostedSession | null`, and
   Schema drift is a different problem with the same remedy. A deploy that
   renames a field leaves every cached entry perfectly current and quietly wrong:
   no record changed, nothing is out of order, and the bytes describe a schema
-  that no longer exists — until the tab is reloaded, which on a long admin
+  that no longer exists — until the tab is reloaded, which on a long console
   session can be days. `createFoirDriftHandler` wires the `FoirSchemaDrift` the
   data client already reports to a full clear.
 
@@ -1511,7 +1536,7 @@ returns a result object rather than `HostedSession | null`, and
   credential and the bearer is re-exchanged when it dies. A consumer that cannot
   see the lifetime has to hardcode the platform's (coupling itself to a server
   constant it cannot observe) or decode `exp` off the JWT — or, as happened,
-  treat a 15-minute bearer as good forever and have customers appear signed out
+  treat a 15-minute bearer as good forever and have users appear signed out
   mid-session. `createFoirSessionClient` on the SPA path has read `expires_in`
   and scheduled a proactive refresh all along; this closes the asymmetry.
 
@@ -1521,10 +1546,10 @@ returns a result object rather than `HostedSession | null`, and
 - **`HostedSessionResult`** exported from `./auth`.
 
 - **`FoirAuthDowngrade`** on `./data` and `./server`, plus `extensions` on the
-  response envelope — Foir now reports when it DISCARDED a customer token you
+  response envelope — Foir now reports when it DISCARDED a user token you
   sent, and the SDK stops dropping that report on the floor.
 
-  A customer JWT is optional: one that fails to verify is not refused, the read
+  A user JWT is optional: one that fails to verify is not refused, the read
   is served anonymously and returns `200`. So a lapsed token and a genuinely
   anonymous request were indistinguishable — nothing threw, no refresh armed,
   and auth-targeted content quietly resolved to its anonymous variant. The
@@ -1533,7 +1558,7 @@ returns a result object rather than `HostedSession | null`, and
   ```json
   { "data": { "…": "…" },
     "extensions": { "auth": {
-      "customerToken": "rejected", "reason": "expired", "servedAs": "anonymous"
+      "userToken": "rejected", "reason": "expired", "servedAs": "anonymous"
     } } }
   ```
 
@@ -1553,7 +1578,7 @@ returns a result object rather than `HostedSession | null`, and
 
   The GraphQL `events` subscription has been live on the public schema since the
   events spine shipped, with no client able to reach it. It is an `sk_`-only
-  operator surface, so it lives on `./server` beside the rest of the events
+  console surface, so it lives on `./server` beside the rest of the events
   client and inherits its `pk_` and `Authorization` refusals unchanged.
 
   New exports: `FoirEventsSubscribeParams`, plus `FoirSubscription` and
@@ -1575,7 +1600,7 @@ returns a result object rather than `HostedSession | null`, and
   It collapsed every failure to `null`: no cookie, a `401`, a `502`, a rate
   limit, a DNS failure. Consumers have to act on that `null`, and the only
   safe-looking action is to clear the session and redirect to the front door —
-  so one blip on `/session/token` signed out a customer whose 30-day cookie was
+  so one blip on `/session/token` signed out a user whose 30-day cookie was
   perfectly valid, and nothing recorded that it had happened. The route's own
   rate limiter is deliberately fail-open for the opposite reason.
 
@@ -1594,7 +1619,7 @@ returns a result object rather than `HostedSession | null`, and
   `outcome` says what to DO; `reason` says what happened. Only `401` and a
   missing cookie are `signed-out`. A `403` reports as `unavailable` with reason
   `forbidden` — it means the CSRF header did not arrive, which is a
-  misconfiguration rather than a blip, but signing the customer out over it
+  misconfiguration rather than a blip, but signing the user out over it
   would still be wrong.
 
 - **`foir.ns.operations.onExecution` delivers `status` as the
@@ -1634,14 +1659,14 @@ Everything additive, so a MINOR either way under the pre-1.0 note.
 ### Added
 
 - **`hostedLogoutUrl(config, clientId, returnTo?)` on `./auth`** — the mirror of
-  `hostedLoginUrl`, and the only thing that actually signs a customer out on the
+  `hostedLoginUrl`, and the only thing that actually signs a user out on the
   hosted-cookie flow.
 
   Login on that flow is symmetric across browser and server; logout was not.
-  The apex `foir_customer_session` cookie is the durable credential, and
+  The apex `foir_session` cookie is the durable credential, and
   disposing of a bearer, clearing a local session, or calling the
-  `customerLogout` mutation all leave it in place — the next request
-  re-establishes the customer from it. The only surface that ended a session was
+  `logout` mutation all leave it in place — the next request
+  re-establishes the user from it. The only surface that ended a session was
   `POST /session/logout`, cookie-authenticated and CSRF-header-gated, which only
   a browser sending `credentials: 'include'` can reach.
 
@@ -2013,7 +2038,7 @@ note above.
 
   Reads take the shared, cacheable lane where they can:
   `GET /cdn/graphql?key=pk_…` with the persisted-query hash in the URL when the
-  call is a query, on a `pk_` key, with no customer bearer, on the published
+  call is a query, on a `pk_` key, with no user bearer, on the published
   channel — and `POST /graphql` otherwise. The server's gate refuses on five
   conditions and the client decides all five before the request: the fifth,
   "the credential is in the URL", it satisfies by construction. The server is
@@ -2035,7 +2060,7 @@ note above.
   hand-written document may legitimately have several. As a document it reaches
   everything the credential can reach — including the two dozen root fields no
   model and no namespace claims (`designTokens`, `record`, `locales`, the
-  customer-auth mutations), which is the point of an escape hatch and is more
+  user-auth mutations), which is the point of an escape hatch and is more
   than the old shape could address.
 
 - **Every op prints, and there is one wire format rather than two.** The
@@ -2098,19 +2123,19 @@ note above.
   schema knowledge the client is not allowed to hold. The manifest publishes
   each op's result shape, so the table has nothing left to answer. Neither
   symbol has appeared in a published release.
-- **`customerResendVerificationEmail` from `@foir/sdk/auth`** — and the
-  `AUTH_OPS.customerResendVerificationEmail` entry with it. **It never sent an
-  email.** The resolver behind it checked that the request carried a customer id,
-  returned `true`, and called no RPC; there is no customer verification-code
-  column and no customer verification email in the action catalogue for it to
+- **`resendVerificationEmail` from `@foir/sdk/auth`** — and the
+  `AUTH_OPS.resendVerificationEmail` entry with it. **It never sent an
+  email.** The resolver behind it checked that the request carried a user id,
+  returned `true`, and called no RPC; there is no user verification-code
+  column and no user verification email in the action catalogue for it to
   have used. A caller got a success response every time and nothing was
   delivered, which is worse than an error, because there is no signal to act on.
 
-  **Use the OTP flow for mailbox proof:** `customerRequestOTP(env, email)` emails
-  a code, and `customerLoginOTP(env, { email, otp })` redeems it — activating a
+  **Use the OTP flow for mailbox proof:** `requestOTP(env, email)` emails
+  a code, and `loginWithOTP(env, { email, otp })` redeems it — activating a
   pending account on redemption and returning a session, so possession of the
-  mailbox is proven by the same call that signs the customer in. That is a live,
-  delivered path today; `customerVerifyEmail` remains for redeeming a token that
+  mailbox is proven by the same call that signs the user in. That is a live,
+  delivered path today; `verifyEmail` remains for redeeming a token that
   arrived by some other route.
 
   Like the two entries above, this symbol has not appeared in a published
@@ -2143,11 +2168,11 @@ note above.
   id are what the note is filed against and never appear on screen.
 
   Opening the panel reads `noteConfig`, which the API charges `notes:write` and
-  refuses to a caller with no customer session, so one probe settles whether the
+  refuses to a caller with no session, so one probe settles whether the
   visitor is signed in, whether their role may write notes, and whether
   screenshot capture may be offered. A missing scope reads like a bad API key and
-  is not one, so it is reported as what it is: the signed-in customer's ROLE is
-  short `notes:write`, which a new project's default customer role does not
+  is not one, so it is reported as what it is: the signed-in user's ROLE is
+  short `notes:write`, which a new project's default user role does not
   carry.
 
   Screenshot capture is offered only when the project allows it and the browser
@@ -2177,11 +2202,11 @@ note above.
   New exports on `./media`: `captureFoirScreen`, `isFoirScreenCaptureSupported`,
   `FoirScreenCapture`, `FoirScreenCaptureOptions`.
 
-- **Note attachments and note config on `./data`.** `FoirCustomerNote` gains
+- **Note attachments and note config on `./data`.** `FoirUserNote` gains
   `attachments`, `FoirCreateMyNoteArgs` gains an optional `attachmentFileIds`,
   and `FoirNoteConfig` is the shape `foir.ns.notes.noteConfig()` answers with.
 
-  New exports on `./data`: `FoirCustomerNoteAttachment`, `FoirNoteConfig`.
+  New exports on `./data`: `FoirUserNoteAttachment`, `FoirNoteConfig`.
 
 - **A subject registry — the records a client fetched, so an annotation can
   anchor to the record instead of to a URL.** `createFoirSubjectRegistry()`
@@ -2225,11 +2250,11 @@ note above.
   `FoirSubject`, `FoirSubjectEntry`, `FoirSubjectOptions`, `FoirSubjectOrigin`,
   `FoirSubjectRegistry`, `FoirRecordPath`.
 
-- **Types for the customer notes surface.** `foir.ns.notes.myNotes()` and
+- **Types for the user notes surface.** `foir.ns.notes.myNotes()` and
   `foir.ns.notes.createMyNote()` already worked — `notes` is a namespace the
   manifest publishes like any other — but their shapes had to be written out by
   hand at each call site. They are platform-owned and identical in every project,
-  so they now ship: `FoirCustomerNote`, `FoirMyNotesArgs`, `FoirMyNotesResult`,
+  so they now ship: `FoirUserNote`, `FoirMyNotesArgs`, `FoirMyNotesResult`,
   `FoirCreateMyNoteArgs`, `FoirNoteSubjectType`.
 
   ```ts
@@ -2237,7 +2262,7 @@ note above.
   ```
 
   `FoirNoteSubjectType` is the closed set the platform's write path enforces
-  (`record`, `file`, `model`, `operation`, `schedule`, `customer`) and is never a
+  (`record`, `file`, `model`, `operation`, `schedule`, `user`) and is never a
   model key — a note on a record is `'record'` plus the key on
   `subjectModelKey`. Like every mirrored platform table in `builtins.ts`, a kind
   added upstream widens this union in a minor release.
@@ -2394,12 +2419,12 @@ note above.
   `FoirEventsClientConfig`, `FoirEventsListParams`, `FoirEventsStreamParams`.
 
   **On `@foir/sdk/server` and no other subpath, deliberately.** The event log is
-  an OPERATOR surface (DECIDED 2026-08-04): reachable by an `sk_` key or
-  an admin session, never by a customer token, and `events:list.project` is not
+  an USER surface (DECIDED 2026-08-04): reachable by an `sk_` key or
+  a console session, never by a user token, and `events:list.project` is not
   mintable on a `pk_` key at all. `events.view` is plain tenant+project
   containment while `record.view` carries owner/grantee/borrow terms on top, so a
   containment-only read over the log describes rows whose records the same caller
-  could not read — and each row's `actor` names which *other* customer acted.
+  could not read — and each row's `actor` names which *other* user acted.
   `createEventsClient` therefore throws on a `pk_` key and on an `Authorization`
   header rather than letting either reach the wire, and an import-graph test
   fails if the module becomes reachable from a subpath that ships to a browser.
@@ -2420,12 +2445,12 @@ note above.
   is the entire cost of GraphQL paid for one screen. Ten root fields closed:
 
   `getAuthConfig`, `getDefaultAuthProvider`, `currentUser`, `myProviderToken`,
-  `customerLogout`, `customerRequestPasswordReset`, `customerResetPassword`,
-  `customerUpdatePassword`, `customerVerifyEmail`, `deleteMyAccount`.
+  `logout`, `requestPasswordReset`, `resetPassword`,
+  `updatePassword`, `verifyEmail`, `deleteMyAccount`.
 
   Plus the session-layer pairings for the flows that need one:
   `resetPasswordAndSignIn` (redeem the emailed token and persist the session it
-  mints — the peer of `loginWithPassword` for the branch where the customer
+  mints — the peer of `loginWithPassword` for the branch where the user
   cannot log in), `signOut` (revoke server-side, then clear locally, and clear
   locally even if the revoke fails), and `authedOp` (`authedRequest`'s twin for
   auth ops: refresh once, retry once, on a 401-shaped failure).
@@ -2442,10 +2467,10 @@ note above.
 ### Removed
 
 - **The nine auth operation documents on `@foir/sdk/auth`** —
-  `CustomerLoginDocument`, `CustomerRegisterDocument`,
-  `CustomerRefreshTokenDocument`, `CustomerRequestOTPDocument`,
-  `CustomerLoginOTPDocument`, `CustomerLoginWithProviderDocument`,
-  `CustomerProviderCallbackDocument`, `CustomerProviderVerifyOTPDocument`,
+  `UserLoginDocument`, `UserRegisterDocument`,
+  `UserRefreshTokenDocument`, `UserRequestOTPDocument`,
+  `UserLoginOTPDocument`, `UserLoginWithProviderDocument`,
+  `UserProviderCallbackDocument`, `UserProviderVerifyOTPDocument`,
   `AuthProvidersDocument`.
 
   **Breaking, so the next release is a MINOR** per the pre-1.0 note above.
@@ -2457,15 +2482,15 @@ note above.
   eleven were unreachable. The flows now address the server's generated `auth`
   namespace, so `@foir/sdk/auth` carries no transport of its own.
 
-  *Migration.* Nothing that called a FUNCTION changes: `customerLogin(env, …)`,
+  *Migration.* Nothing that called a FUNCTION changes: `login(env, …)`,
   `getAuthProviders(env)`, `loginWithPassword(adapter, env, …)`, `refreshSession`,
   `requireAuth`, `authedRequest` and every React hook in `@foir/sdk/react` keep
   their exact signatures. Only code importing a `*Document` const is affected,
   and only if it was executing the document itself through its own GraphQL
   client. Two options:
 
-  - call the SDK function instead (`customerLogin(env, vars)` rather than running
-    `CustomerLoginDocument` through Apollo/urql), which is what the exports were
+  - call the SDK function instead (`login(env, vars)` rather than running
+    `UserLoginDocument` through Apollo/urql), which is what the exports were
     for; or
   - keep your own client and write the document in your own codebase — these are
     fixed-shape platform operations, so the text does not vary by project.
@@ -2529,7 +2554,7 @@ actually happened.
 
   Purely additive: `./auth` keeps exporting all four, unchanged, and nothing is
   moved or renamed. What changes is the cost of reaching them. `./auth` also
-  exports the customer-auth GraphQL documents, which build their
+  exports the user-auth GraphQL documents, which build their
   TypedDocumentNodes with a top-level `parse()` that no bundler can treat as
   pure — so a browser app importing only `createFoirSessionClient` was shipping
   the whole `graphql` package to get it. `src/auth/session-client.ts` imports
@@ -2590,7 +2615,7 @@ on its own, which is the intended behaviour for a release that adds exports.
 
 ### Added
 
-- `@foir/sdk/auth`: `customerSignupContext` and `customerJoinWaitlist`, plus the
+- `@foir/sdk/auth`: `signupContext` and `joinWaitlist`, plus the
   `SignupContext`, `SignupMode` and `WaitlistJoinResult` types — waitlist and
   restricted-signup flows for projects that are not open-registration.
 - A pinned public-export surface: `public-exports.snapshot.json` plus
@@ -2617,7 +2642,7 @@ on its own, which is the intended behaviour for a release that adds exports.
 
 ### Added
 
-- `@foir/sdk/client`: `createFoirContentClient` — forwards the customer bearer
+- `@foir/sdk/client`: `createFoirContentClient` — forwards the user bearer
   token on content reads, so authenticated and segment-targeted content works
   without hand-rolling the header.
 
@@ -2634,7 +2659,7 @@ on its own, which is the intended behaviour for a release that adds exports.
 
 ### Added
 
-- **New subpath `@foir/sdk/react`** — drop-in React customer auth: `FoirProvider`,
+- **New subpath `@foir/sdk/react`** — drop-in React user auth: `FoirProvider`,
   `SignIn`, `OAuthButtons`, `UserButton`, `useFoirAuth`, `useFoirSession`,
   `useFoirUser`.
 - **New subpath `@foir/sdk/next`** — Next.js App Router BFF auth adapter: cookie
@@ -2662,7 +2687,7 @@ First public release. Ten subpaths:
 - `@foir/sdk/media` — progressive media components and adapters.
 - `@foir/sdk/content` — `createContentRenderer` and `RichTextRenderer` with
   injected typography tokens.
-- `@foir/sdk/auth` — customer auth flows, token lifecycle, hosted-login bridge.
+- `@foir/sdk/auth` — user auth flows, token lifecycle, hosted-login bridge.
 - `@foir/sdk/realtime` — `createCollabSession`, a thin y-websocket helper.
 - `@foir/sdk/codegen`, `@foir/sdk/codegen/block-registry`,
   `@foir/sdk/codegen/block-scaffold` — the `foirCodegen` preset and the