docs(plugin-auth): re-measure the better-auth version attestations on 1.7.12

Every live reading that named 1.7.3 was re-measured against the installed
1.7.12 dist or by the test that pins it, and restamped with the date and
the card. Facts about the 1.7.3 release itself stay as written. The
internal-field-readback census is scoped to its 1.7.3 trace and flagged
instead of restamped: sso's verify-domain reads the verification
identifier back off the row, which the census says no flow does.

The pnpm-workspace.yaml family note states the new target and what the
lift moved.

Claude-Session: https://claude.ai/code/session_011TdZ8GjixNZFLz1xJD9zzK
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

packages/plugins/plugin-auth/src/account-invitation-marker.ts

@@ -11,7 +11,8 @@
  * is what creates the row's credential on first set. But better-auth hands the
  * resulting link only to `sendResetPassword({ user, url, token }, ctx.request)`;
  * `requestPasswordReset` itself answers `{ status, message }` and nothing else
- * (installed better-auth 1.7.3, `dist/api/routes/password.mjs`). So the import
+ * (better-auth 1.7.12, `dist/api/routes/password.mjs`, re-measured 2026-10-21
+ * for #25096). So the import
  * never holds the link, and the template choice can only be made inside
  * `sendResetPassword` (`auth-manager.ts`). Without a marker that callback
  * cannot tell an administrator's invitation from a user who forgot their
@@ -65,8 +66,8 @@
  *
  * better-auth runs `sendResetPassword` through `runInBackgroundOrAwait`, which
  * CATCHES and logs whatever the send throws, and `requestPasswordReset` still
- * answers `{ status: true }` (installed 1.7.3, `dist/context/create-context.mjs`
- * and `dist/api/routes/password.mjs`). That is right for the public door — the
+ * answers `{ status: true }` (better-auth 1.7.12, `dist/context/create-context.mjs`
+ * and `dist/api/routes/password.mjs`, re-measured 2026-10-21 for #25096). That is right for the public door — the
  * answer must not say whether an address exists or whether its mail went out —
  * and it means a throw inside the send can never reach the import. No
  * better-auth option makes the call rethrow: `advanced.backgroundTasks.handler`

packages/plugins/plugin-auth/src/admin-import-users-invite-delivery-failure.test.ts

@@ -6,7 +6,8 @@
  * The import invites an email row by asking better-auth for a password reset,
  * and better-auth runs `sendResetPassword` through `runInBackgroundOrAwait`,
  * which catches and logs whatever the send throws and still answers
- * `{ status: true }` (installed 1.7.3, `dist/context/create-context.mjs`). So a
+ * `{ status: true }` (better-auth 1.7.12, `dist/context/create-context.mjs`,
+ * re-measured 2026-10-21 for #25096). So a
  * throw inside the send can never reach the import. `sendResetPassword` now
  * settles a delivery receipt the import's own request carries
  * (`account-invitation-marker.ts`), and the import reads it after the request

packages/plugins/plugin-auth/src/auth-email-locale.test.ts

@@ -867,8 +867,8 @@ describe("#14641 — an invitation reads the INVITEE's own sys_user.locale", ()
  * recipient-keyed engine, not by asserting it about this send alone.
  *
  * Two branches, because a magic link is BOTH a sign-in for an existing account
- * and a sign-up for a new address (re-measured 2026-09-11 in the installed
- * better-auth 1.7.3, unchanged from 1.7.2: the `/sign-in/magic-link` handler
+ * and a sign-up for a new address (re-measured 2026-10-21 for #25096 on
+ * better-auth 1.7.12, unchanged since 1.7.2: the `/sign-in/magic-link` handler
  * takes `email` straight off the body, stores a verification value and calls
  * `sendMagicLink` — no user lookup on that path at all — while
  * `/magic-link/verify` reads `findUserByEmail` and, finding nobody, calls
@@ -1003,8 +1003,8 @@ describe("#15106 — the magic link reads the recipient's own sys_user.locale",
   });
 
   it('matches the address better-auth itself will resolve the link with — lowercased', async () => {
-    // ⚠️ Measured against the installed better-auth 1.7.3 (2026-09-11), not
-    // assumed, and unchanged from the 1.7.2 reading this replaces:
+    // ⚠️ Measured against better-auth 1.7.12 (2026-10-21, #25096), not
+    // assumed, and unchanged since the 1.7.2 reading:
     // `signInMagicLinkBodySchema` declares `email: z.email()` with no case
     // transform, so a typed `Ada@Example.com` arrives here verbatim, while
     // `internalAdapter.findUserByEmail` — what `/magic-link/verify` resolves

packages/plugins/plugin-auth/src/auth-manager.ts

@@ -1799,8 +1799,9 @@ export class AuthManager {
       // The deployment's product name, from the one authority every auth
       // email already reads (`getAppName()`: the `branding.workspace_name`
       // override, else the configured `appName`, else 'ObjectStack').
-      // better-auth 1.7.3 reads this key once, into its context's `appName`
-      // (unset ⇒ "Better Auth"), and reads that in exactly two places: the
+      // better-auth 1.7.12 (re-read 2026-10-21 for #25096) reads this key once,
+      // into its context's `appName` (unset ⇒ "Better Auth"), and reads that
+      // in exactly two places: the
       // issuer and label prefix of the otpauth URI that `/two-factor/enable`
       // and `/two-factor/get-totp-uri` answer. No cookie name derives from it
       // (the prefix is the literal "better-auth") and nothing stores it, so an
@@ -2058,8 +2059,8 @@ export class AuthManager {
             );
           }
           // The lifetime the token in `url` really has: better-auth mints it
-          // with `resetPasswordTokenExpiresIn || 3600` seconds (installed
-          // 1.7.3 `routes/password.mjs`) — `||`, so a configured `0` is its
+          // with `resetPasswordTokenExpiresIn || 3600` seconds (better-auth
+          // 1.7.12 `routes/password.mjs`, re-measured 2026-10-21 for #25096) — `||`, so a configured `0` is its
           // default too, and the mail must not say "0 minutes" for it.
           const ttlSec = this.config.emailAndPassword?.resetPasswordTokenExpiresIn || 60 * 60;
           // [#23343] An account an administrator created (the identity
@@ -2081,7 +2082,8 @@ export class AuthManager {
           // commit 35e94c96b — the ladder's stored rung. It matters most HERE: an
           // admin-initiated send (`admin-import-users.ts` calls
           // `requestPasswordReset` server-side) reaches this callback with NO
-          // request at all (measured on 1.7.3, #23343), so without this rung
+          // request at all (measured on 1.7.3, #23343; unchanged on 1.7.12,
+          // re-read for #25096), so without this rung
           // the user's mail carries only the deployment default. Best-effort;
           // `undefined` leaves the #14319 ladder exactly as it was.
           const storedLocale = await this.storedRecipientLocale({ id: user.id });
@@ -4723,8 +4725,8 @@ export class AuthManager {
     //
     // Handing better-auth no `database` makes it build its own in-memory store
     // in `getBaseAdapter`, and that store is keyed by the schema KEY while
-    // every read resolves by `modelName`. Re-measured 2026-09-11 on the
-    // installed better-auth 1.7.3, unchanged from the 1.7.2 reading it replaces
+    // every read resolves by `modelName`. Re-measured 2026-10-21 for #25096 on
+    // better-auth 1.7.12, unchanged since the 1.7.2 reading
     // (`db/adapter-base.mjs` builds the store by schema KEY;
     // `@better-auth/memory-adapter` throws on the lookup, naming the model):
     //
@@ -9698,7 +9700,8 @@ export class AuthManager {
    * (plus `id`), or `undefined` when the identifier names no account.
    *
    * It asks exactly what better-auth's `/sign-in/email` credential check asks
-   * (1.7.3: `internalAdapter.findUserByEmail(email.toLowerCase())`, an
+   * (1.7.12, re-read 2026-10-21 for #25096:
+   * `internalAdapter.findUserByEmail(email.toLowerCase())`, an
    * equality match of the `email` column against the lower-cased address,
    * which is also the spelling `internalAdapter.createUser` stores), so the
    * gate, the counter, the ledger and the credential check name one account

packages/plugins/plugin-auth/src/auth-schema-config.ts

@@ -953,12 +953,12 @@ export const buildOidcProviderPluginSchema = buildOauthProviderPluginSchema;
 
 // NOTE: there is intentionally no scim mapping constant here, and no
 // `buildScimPluginSchema()`. `@better-auth/scim` hardcodes its models and exposes
-// NO `schema` option — still true of the installed stable `@better-auth/scim@1.7.3`
-// (re-read 2026-09-11: `SCIMOptions` declares no `schema` / `modelName` / `fields`
+// NO `schema` option — still true of the installed stable `@better-auth/scim@1.7.12`
+// (re-read 2026-10-21 for #25096: `SCIMOptions` declares no `schema` / `modelName` / `fields`
 // member at all — its six members are still connections, authentication,
 // managedConnections, identity, projection, compatibility; measured 2026-08-19 on
 // the rc, re-measured 2026-08-27 on stable 1.7.1, again 2026-08-31 on 1.7.2 for
-// #13940, and again on 1.7.3 with the family lift), so
+// #13940, again on 1.7.3 with the family lift, and on 1.7.12 with #25096), so
 // there is nowhere to hand one. This is no longer true
 // of `@better-auth/sso@1.7.1`, which now accepts one (#8224) — for scim, and for
 // scim alone, the ADAPTER layer is the only available route.

packages/plugins/plugin-auth/src/implicit-account-linking.ts

@@ -42,7 +42,7 @@
  *
  * ## Why the enforcement point is `user.validateUserInfo`
  *
- * Measured against the installed better-auth `1.7.3`
+ * Measured against better-auth `1.7.12` (re-measured 2026-10-21 for #25096)
  * (`dist/oauth2/link-account.mjs`, `handleOAuthUserInfo`):
  *
  *  - The library's own gate refuses an implicit link when
@@ -63,7 +63,8 @@
  *    implicitly (`/callback/:id`, `/sign-in/social` with an id token,
  *    one-tap, oauth-proxy, and the SSO plugin, which share the function).
  *  - The EXPLICIT link (`/link-social` → `/callback/:id` with `link` in the
- *    OAuth state) passes the same `action: 'link-account'`. It is told apart
+ *    OAuth state) passes the same `action: 'link-account'` (1.7.12 routes it
+ *    through `linkOAuthAccount`, in the same file). It is told apart
  *    by the OAuth state the callback parsed (`getOAuthState().link`), which
  *    the server writes from the session at `/link-social`; `generateState`
  *    places `link` AFTER the client-supplied `additionalData`, so a client

packages/plugins/plugin-auth/src/in-process-redispatch.ts

@@ -27,7 +27,8 @@
  * renewing — there is no cookie to fall behind.
  *
  * better-auth reads the flag from the query on both kinds of re-dispatch
- * (1.7.3, measured by `in-process-session-renewal.pin.test.ts`): the
+ * (1.7.12, re-measured 2026-10-21 for #25096 by
+ * `in-process-session-renewal.pin.test.ts`): the
  * `/get-session` route declares it (`getSessionQuerySchema`, coerced), and
  * `getSessionFromCtx` — which `sessionMiddleware` and this plugin's own
  * before-hooks call — spreads the route's `ctx.query` into the read it makes,

packages/plugins/plugin-auth/src/internal-field-readback.ts

@@ -194,7 +194,8 @@ const READBACK_FIELDS: Readonly<Record<string, readonly ReadbackColumn[]>> = {
   // that no generic exit — the data path, and the compliance ledger's CRUD
   // mirror that honours the same flag — carries it, and each is here because a
   // better-auth route reads it back OFF a row its storage adapter returned
-  // (traced in the installed better-auth / @better-auth/* dist, 1.7.3):
+  // (traced in the then-installed better-auth / @better-auth/* dist, 1.7.3;
+  // ⚠️ [#25096] NOT re-stamped for 1.7.12 — see the `identifier` note below):
   //
   //  - `sys_jwks.private_key` — the jwt plugin's key read (`findMany`, no
   //    projection) feeds signing. MEASURED before this row existed: the flag
@@ -206,6 +207,11 @@ const READBACK_FIELDS: Readonly<Record<string, readonly ReadbackColumn[]>> = {
   //    adapter's `consumeOne` re-attaches through this table too).
   //    `required: true`. `identifier` is deliberately absent: no flow reads it
   //    back off a row — it is only ever the lookup key.
+  //    ⚠️ [#25096] That census is wrong, on 1.7.3 and on 1.7.12 alike:
+  //    `@better-auth/sso`'s `/sso/verify-domain` builds the TXT record it
+  //    expects from `identifier` read back off the row, so on this store it
+  //    expects `undefined=TOKEN`. Measured and reported on #25096; nothing
+  //    here is changed by that card.
   //  - `sys_two_factor.secret` (`required: true`) and `.backup_codes` (empty
   //    until generated) — TOTP and backup-code verification read both off the
   //    enrolment row.

packages/plugins/plugin-auth/src/invite-role-not-found-code.ts

@@ -12,8 +12,8 @@
  *
  *     new APIError("BAD_REQUEST", { message: `${ROLE_NOT_FOUND}: ${unknownRoles}` })
  *
- * (`dist/plugins/organization/routes/crud-invites.mjs`, measured against the
- * installed better-auth `1.7.3`). Its sibling `update-member-role`
+ * (`dist/plugins/organization/routes/crud-invites.mjs`, measured against
+ * better-auth `1.7.12`, re-measured 2026-10-21 for #25096). Its sibling `update-member-role`
  * (`routes/crud-members.mjs`) throws the SAME refusal with
  * `code: ROLE_NOT_FOUND` beside the identical message — so one vendor
  * condition reached the wire coded on one door and uncoded on the other. The

packages/plugins/plugin-auth/src/list-user-invitations-verification.ts

@@ -7,9 +7,9 @@
  *
  * ## The defect, and where it is minted
  *
- * Not here: it comes out of the pinned vendor. Re-measured 2026-09-11 against
- * the installed better-auth `1.7.3` (unchanged from the `1.7.2` reading this
- * replaces), `dist/plugins/organization/routes/crud-invites.mjs`:
+ * Not here: it comes out of the pinned vendor. Re-measured 2026-10-21 for
+ * #25096 against better-auth `1.7.12` (unchanged since the `1.7.2` reading),
+ * `dist/plugins/organization/routes/crud-invites.mjs`:
  * the three id-addressed routes ask
  * `shouldRequireVerifiedEmailForInvitationIdAction({ organizationOptions, … })`,
  * whose first line is