@opensaas/stack-auth 0.20.1 → 0.22.0

package/.turbo/turbo-build.log

@@ -1,4 +1,4 @@
 
-> @opensaas/stack-auth@0.20.1 build /home/runner/work/stack/stack/packages/auth
+> @opensaas/stack-auth@0.22.0 build /home/runner/work/stack/stack/packages/auth
 > tsc
 

package/CHANGELOG.md

@@ -1,5 +1,127 @@
 # @opensaas/stack-auth
 
+## 0.22.0
+
+### Minor Changes
+
+- [#509](https://github.com/OpenSaasAU/stack/pull/509) [`fdc48f8`](https://github.com/OpenSaasAU/stack/commit/fdc48f86a5a7f161bef0b512963e1511a8c8e00e) Thanks [@list({](https://github.com/list({)! - Add `adoptBetterAuthTables()` recipe for adopting an existing better-auth installation
+
+  A migrating project that already runs better-auth (its `AuthUser`/`AuthSession`/`AuthAccount`/`AuthVerification` tables live in a separate `auth` Postgres schema, and its app `User` is a different model) can now adopt those live tables without rebuilding the auth config by hand. The recipe presets the plugin-level `schema` plus each model's `modelName` (and optional column `fields` maps) to the conventions of a standard separate-schema better-auth install, so the derived Auth lists diff clean (Schema parity) against the live database — no destructive auth migration. The app's own domain `User` is left untouched; linking it to the Auth identity is the application's concern.
+
+  ```typescript
+  import { config } from '@opensaas/stack-core'
+  import { authPlugin, adoptBetterAuthTables } from '@opensaas/stack-auth'
+
+  export default config({
+    db: { provider: 'postgresql', url: process.env.DATABASE_URL },
+    plugins: [
+      authPlugin({
+        // Defaults: AuthUser/AuthSession/AuthAccount/AuthVerification in the
+        // `auth` schema, pinned to your live table names (@@map) + schema (@@schema).
+        ...adoptBetterAuthTables(),
+        emailAndPassword: { enabled: true },
+      }),
+    ],
+    lists: {
+      // Your own domain User stays in `public` and is NOT touched by the plugin.
+   fields: { subjectId: text({ validation: { isRequired: true } }) } }),
+    },
+  })
+
+  // Customise when your live tables diverge from the defaults:
+  adoptBetterAuthTables({
+    schema: 'identity', // default: 'auth'
+    modelNamePrefix: 'BA', // default: 'Auth'
+    fields: { user: { name: 'full_name' }, session: { userId: 'user_id' } },
+  })
+  ```
+
+- [#497](https://github.com/OpenSaasAU/stack/pull/497) [`be4181a`](https://github.com/OpenSaasAU/stack/commit/be4181ada3f2d6386052df4d4869ad150d360f89) Thanks [@{](https://github.com/{)! - Derive the auth plugin's Auth lists from the better-auth config
+
+  `authPlugin` now mirrors the better-auth config a developer writes instead of hardcoding the keys `User`/`Session`/`Account`/`Verification`. Per-model `modelName` becomes the OpenSaaS list key (and a table `@@map`), and the `fields` column map becomes per-field `@map`s. The plugin only ever adds/extends its own derived keys, so an app's separate domain `User` is never overwritten. The runtime `getUser`/`getCurrentUser` helpers now resolve the user list key from the configured user model instead of a hardcoded `'user'`.
+
+  Default behaviour (no overrides) is unchanged: the lists are still keyed `User`/`Session`/`Account`/`Verification` with the original field shapes and no `@@map`.
+
+  ```typescript
+  // Adopt existing better-auth tables without a destructive migration
+  authPlugin({
+   modelName: 'AuthUser', fields: { name: 'full_name' } },
+    session: { modelName: 'AuthSession', fields: { userId: 'user_id' } },
+    account: { modelName: 'AuthAccount' },
+    verification: { modelName: 'AuthVerification' },
+  })
+  // -> lists keyed AuthUser/AuthSession/AuthAccount/AuthVerification
+  //    with @@map + column @map matching the live tables
+  ```
+
+  Lists also gain a model-level `db.map` option, which emits a `@@map("...")` on the generated Prisma model so a list key can differ from its physical table name.
+
+- [#502](https://github.com/OpenSaasAU/stack/pull/502) [`593390c`](https://github.com/OpenSaasAU/stack/commit/593390c57d9844ca7ada8f45b340c849f1d8d647) Thanks [@{](https://github.com/{)! - Add `authPlugin` schema placement so Auth lists can adopt an existing non-`public` better-auth layout (clean-diff adoption)
+
+  The auth lists can now be placed in a non-`public` Postgres schema (e.g. `auth`) so they diff CLEAN against a separate-schema better-auth installation. A plugin-level `schema` option applies `@@schema(...)` to all generated Auth lists, with a per-list override.
+
+  ```typescript
+  authPlugin({
+    schema: 'auth', // all Auth lists get @@schema("auth")
+   modelName: 'AuthUser' },
+    session: { modelName: 'AuthSession' },
+    account: { modelName: 'AuthAccount' },
+    // per-model override: relocate one list to a different schema
+    verification: { modelName: 'AuthVerification', schema: 'auth_internal' },
+  })
+  ```
+
+  The plugin's `beforeGenerate` hook wires the datasource `schemas` array (always including `public`) and defaults any list without an explicit `db.schema` to `public`, producing a valid multi-schema Prisma schema. With no `schema` option the output is unchanged (greenfield default stays in `public`, no `@@schema`).
+
+  Core support added for this (mirroring the `db.map` → `@@map` work):
+  - List-level `db.schema` → the Prisma generator emits `@@schema("...")` on the model.
+  - Database-level `db.schemas` → the generator emits the datasource `schemas = [...]` array and enables the `multiSchema` preview feature.
+
+  ```typescript
+  // Core/generator building blocks
+  db: { provider: 'postgresql', schemas: ['public', 'auth'] }
+  AuthUser: list({ fields: { ... }, db: { map: 'AuthUser', schema: 'auth' } })
+  // Generates: model AuthUser { ... @@map("AuthUser") @@schema("auth") }
+  ```
+
+### Patch Changes
+
+- [#501](https://github.com/OpenSaasAU/stack/pull/501) [`e30f6a1`](https://github.com/OpenSaasAU/stack/commit/e30f6a1ef69dc65ae68b37539fa74c3f97823cfd) Thanks [@borisno2](https://github.com/borisno2)! - Keep `createdAt`/`updatedAt` on the auth lists now that auto-timestamps are off by default
+
+  The derived auth lists (User/Session/Account/Verification) now opt into `db: { timestamps: true }`. better-auth's adapter writes those columns and the schema converter returns `null` for them assuming the generator injects them, so the opt-in keeps the generated auth models intact.
+
+## 0.21.0
+
+### Minor Changes
+
+- [#415](https://github.com/OpenSaasAU/stack/pull/415) [`8980ff3`](https://github.com/OpenSaasAU/stack/commit/8980ff36ffb0879d8f4409740493dd940572cc9d) Thanks [@borisno2](https://github.com/borisno2)! - Curate the `@opensaas/stack-core` public surface into clearly-scoped entry points
+
+  The root entry point now exposes only the everyday consumer surface — `config`,
+  `list`, `getContext`, the naming helpers (`getDbKey`, `getUrlKey`,
+  `getListKeyFromUrl`), `ValidationError`, and the config/access types you annotate
+  with. Plugin and field authoring contracts move to a new `/extend` path, and the
+  plumbing shared with sibling packages and generated code moves to `/internal`.
+
+  ```typescript
+  // Everyday usage (unchanged)
+  import { config, list, getContext } from '@opensaas/stack-core'
+
+  // Authoring a plugin or a third-party field package
+  import type { Plugin, BaseFieldConfig, TypeInfo } from '@opensaas/stack-core/extend'
+  ```
+
+  `@opensaas/stack-core/internal` carries no semver guarantees; application code
+  should never import from it. `Session` stays on the root entry point because it is
+  the module-augmentation target.
+
+  Removed from the public surface (zero callers): the nine `*HookArgs` types and the
+  callerless typed-query runtime types. The other `@opensaas/*` packages and the CLI
+  generator are updated to import from the new paths.
+
+### Patch Changes
+
+- [#414](https://github.com/OpenSaasAU/stack/pull/414) [`f03e5ac`](https://github.com/OpenSaasAU/stack/commit/f03e5ac32d5a38ef31c895b200b1a4f7a5e50c9c) Thanks [@borisno2](https://github.com/borisno2)! - Fix docs to use the canonical `authPlugin()`/`ragPlugin()` config pattern instead of the non-existent `withAuth()`/`authConfig()`/`withRAG()`/`ragConfig()` wrappers
+
 ## 0.20.1
 
 ## 0.20.0

package/CLAUDE.md

@@ -13,10 +13,9 @@ Adds complete authentication to OpenSaas Stack apps with minimal configuration.
 
 ## Key Files & Exports
 
-### Config (`src/config/index.ts`)
+### Config (`src/config/plugin.ts`)
 
-- `withAuth(config, authConfig)` - Wraps OpenSaas config, merges auth lists
-- `authConfig({ ... })` - Configures Better-auth plugins and session
+- `authPlugin({ ... })` - Plugin added to a config's `plugins` array; merges auth lists, configures Better-auth plugins and session. This is the only configuration entry point.
 
 ### Lists (`src/lists/index.ts`)
 
@@ -53,16 +52,114 @@ Pre-built forms (client components):
 
 ### Config Merging
 
-`withAuth()` merges auth lists into your config:
+`authPlugin()` merges auth lists into your config:
 
 ```typescript
-withAuth(
-  config({ lists: { Post: list({...}) } }),
-  authConfig({ emailAndPassword: { enabled: true } })
-)
+config({
+  lists: { Post: list({...}) },
+  plugins: [authPlugin({ emailAndPassword: { enabled: true } })],
+})
 // Result: { lists: { User, Session, Account, Verification, Post } }
 ```
 
+### Deriving Auth lists from better-auth config
+
+The four Auth lists are **derived** from the better-auth model config the
+developer writes — not hardcoded. The pure derivation lives in
+`src/config/derive-auth-lists.ts` (`deriveAuthLists`), which `getAuthLists`
+and the plugin's add-vs-extend logic consume:
+
+- per-model `modelName` → list key + table `@@map`
+- per-model `fields` (better-auth field → column) → field-level `@map`
+- the `userId` column override → the `user` relationship foreign-key `@map`
+- relationship refs between the Auth lists follow the derived keys
+  (e.g. `Session.user → AuthUser.sessions`)
+
+With no `modelName`/`fields` overrides the output is unchanged
+(`User`/`Session`/`Account`/`Verification`, original field shapes, no `@@map`).
+
+```typescript
+// Adopt an existing better-auth installation (Auth lists ≠ app User)
+authPlugin({
+  user: { modelName: 'AuthUser', fields: { name: 'full_name' } },
+  session: { modelName: 'AuthSession', fields: { userId: 'user_id' } },
+})
+// Adds AuthUser/AuthSession/... and leaves an app's own `User` untouched.
+```
+
+Because the plugin only ever adds/extends its **derived** keys, an app's own
+domain `User` (a different model from the better-auth user) is never extended
+or overwritten when the user model is renamed. The runtime `getUser`/
+`getCurrentUser` helpers resolve the user list's `context.db` key from the
+configured user `modelName`.
+
+### Schema placement (relocatable Auth lists)
+
+A plugin-level `schema` option places all generated Auth lists in a non-`public`
+Postgres schema via `@@schema(...)`, so they can adopt a separate-schema
+better-auth layout (e.g. an `auth` schema) and reach **Schema parity** with the
+live tables. Combined with the derived keys/`@@map`/field `@map`s above, the
+generated lists diff CLEAN against an existing `auth`-schema install — they are
+modelled for runtime/types without producing a migration.
+
+```typescript
+authPlugin({
+  schema: 'auth', // all Auth lists get @@schema("auth")
+  user: { modelName: 'AuthUser' },
+  session: { modelName: 'AuthSession' },
+  account: { modelName: 'AuthAccount' },
+  verification: { modelName: 'AuthVerification' },
+  // per-model override: relocate one list to a different schema
+  // verification: { modelName: 'AuthVerification', schema: 'auth_internal' },
+})
+```
+
+How it wires up (Postgres multi-schema):
+
+- Each Auth list gets a list-level `db.schema` → `@@schema(...)` (per-model
+  `schema` override, else the plugin-level `schema`).
+- The plugin's `beforeGenerate` hook adds the auth schema(s) (always plus
+  `public`) to the datasource `db.schemas` array and defaults any list without
+  an explicit `db.schema` to `public`, so the generated multi-schema Prisma
+  schema is valid (the generator emits `previewFeatures = ["multiSchema"]` and
+  `schemas = [...]`).
+- With no `schema` option the Auth lists stay in `public` and no `@@schema` /
+  `schemas` / preview feature is emitted (greenfield default unchanged).
+
+### Adopting an existing better-auth install (`adoptBetterAuthTables`)
+
+`adoptBetterAuthTables()` (`src/config/adopt-better-auth-tables.ts`) is a thin
+recipe that returns the `AuthConfig` adoption knobs — the plugin-level `schema`
+plus a per-model `modelName` (and optional column `fields` maps) — preset to the
+conventions of a standard separate-schema better-auth install. It ties together
+the keys/field derivation and schema placement so a migrator doesn't rebuild the
+config by hand. Spread it into `authPlugin`:
+
+```typescript
+import { authPlugin, adoptBetterAuthTables } from '@opensaas/stack-auth'
+
+authPlugin({
+  ...adoptBetterAuthTables(), // schema: 'auth', AuthUser/AuthSession/AuthAccount/AuthVerification
+  emailAndPassword: { enabled: true },
+})
+// Options: adoptBetterAuthTables({ schema, modelNamePrefix, fields })
+```
+
+It is pure config (no side effects): everything it sets can also be written
+directly on `authPlugin`, and spreading it before your own keys lets you
+override per model. Because the derived user key is `AuthUser` (not `User`), an
+app's own domain `User` is left untouched — the plugin only ever adds/extends
+its derived keys. Combined with the derivation + schema placement above, the
+generated Auth lists reach **Schema parity** (clean `schema:diff`) against a live
+`auth`-schema install — they are modelled for runtime/types, not migrated.
+
+**App User ≠ Auth identity.** The plugin models the **Auth identity** (the
+better-auth user); it does not assume that list is the app's domain `User`.
+Linking an app's `User` to the Auth identity (e.g. a `relationship({ ref:
+'AuthUser' })` the app declares) is the application's concern. See the
+[Authentication guide](../../docs/content/guides/authentication.md) (“Adopting an
+existing better-auth installation”) for the end-to-end migrator walkthrough.
+
 ### Session Provider
 
 Better-auth provides session to context via custom `prismaClientConstructor`:
@@ -78,7 +175,7 @@ const context = createContext(config, prisma, session)
 Control which User fields appear in session:
 
 ```typescript
-authConfig({ sessionFields: ['userId', 'email', 'name', 'role'] })
+authPlugin({ sessionFields: ['userId', 'email', 'name', 'role'] })
 // Access in access control:
 access: {
   operation: {
@@ -110,7 +207,7 @@ declare module '@opensaas/stack-core' {
 **Step 2: Ensure fields match your sessionFields configuration**
 
 ```typescript
-authConfig({
+authPlugin({
   sessionFields: ['userId', 'email', 'name', 'role'],
   extendUserList: {
     fields: {
@@ -153,7 +250,7 @@ if (context.session?.email) {
 Add custom fields to User:
 
 ```typescript
-authConfig({
+authPlugin({
   extendUserList: {
     fields: {
       role: select({ options: [{ label: 'User', value: 'user' }] }),
@@ -196,10 +293,11 @@ export const auth = createAuth(config, rawOpensaasContext)
 
 ```typescript
 // 1. Config
-export default withAuth(
-  config({ db: {...}, lists: {...} }),
-  authConfig({ emailAndPassword: { enabled: true } })
-)
+export default config({
+  db: {...},
+  lists: {...},
+  plugins: [authPlugin({ emailAndPassword: { enabled: true } })],
+})
 
 // 2. Server (lib/auth.ts)
 export const auth = createAuth(config)
@@ -235,7 +333,7 @@ Post: list({
 ### OAuth Providers
 
 ```typescript
-authConfig({
+authPlugin({
   socialProviders: {
     github: {
       clientId: process.env.GITHUB_CLIENT_ID!,
@@ -253,7 +351,7 @@ authConfig({
 Session type is inferred from `sessionFields`:
 
 ```typescript
-authConfig({ sessionFields: ['userId', 'email', 'role'] })
+authPlugin({ sessionFields: ['userId', 'email', 'role'] })
 // session: { userId: string, email: string, role: string } | null
 ```
 

package/INTEGRATION_SUMMARY.md

@@ -11,8 +11,7 @@ This document summarizes the complete better-auth integration for the OpenSaas S
 **Exports:**
 
 - **Main** (`@opensaas/stack-auth`):
-  - `withAuth()` - Config wrapper that adds auth lists
-  - `authConfig()` - Auth configuration builder
+  - `authPlugin()` - Plugin added to `config({ plugins: [...] })` that adds auth lists and configures Better-auth
   - `getAuthLists()` - Get all auth list definitions
 
 - **Server** (`@opensaas/stack-auth/server`):
@@ -112,20 +111,21 @@ A complete working example showing:
 
 ```typescript
 // opensaas.config.ts
-import { withAuth, authConfig } from '@opensaas/stack-auth'
+import { config } from '@opensaas/stack-core'
+import { authPlugin } from '@opensaas/stack-auth'
 
-export default withAuth(
-  config({
-    db: { provider: 'sqlite', url: 'file:./dev.db' },
-    lists: {
-      /* your custom lists */
-    },
-  }),
-  authConfig({
-    emailAndPassword: { enabled: true },
-    sessionFields: ['userId', 'email', 'name'],
-  }),
-)
+export default config({
+  db: { provider: 'sqlite', url: 'file:./dev.db' },
+  lists: {
+    /* your custom lists */
+  },
+  plugins: [
+    authPlugin({
+      emailAndPassword: { enabled: true },
+      sessionFields: ['userId', 'email', 'name'],
+    }),
+  ],
+})
 ```
 
 ### Step 2: Generate
@@ -194,7 +194,7 @@ No manual User model, no manual session handling, no manual auth routes. Everyth
 ### 2. Type-Safe Sessions
 
 ```typescript
-authConfig({
+authPlugin({
   sessionFields: ['userId', 'email', 'name', 'role'],
 })
 
@@ -205,7 +205,7 @@ authConfig({
 ### 3. Extensible User Model
 
 ```typescript
-authConfig({
+authPlugin({
   extendUserList: {
     fields: {
       role: select({ options: [...] }),
@@ -236,7 +236,7 @@ All forms accept custom props and callbacks:
 Configure what you need:
 
 ```typescript
-authConfig({
+authPlugin({
   emailAndPassword: { enabled: true },
   emailVerification: { enabled: true },
   passwordReset: { enabled: true },
@@ -325,7 +325,8 @@ Potential additions:
 packages/auth/
 ├── src/
 │   ├── config/
-│   │   ├── index.ts        # withAuth(), authConfig()
+│   │   ├── index.ts        # normalizeAuthConfig()
+│   │   ├── plugin.ts       # authPlugin()
 │   │   └── types.ts        # Auth config types
 │   ├── lists/
 │   │   └── index.ts        # User, Session, Account, Verification
@@ -366,7 +367,7 @@ Better-auth supports cookie caching to reduce database queries:
 
 ```typescript
 // Future enhancement
-authConfig({
+authPlugin({
   session: {
     cookieCaching: true, // Validate at cookie level
   },

package/README.md

@@ -23,30 +23,30 @@ pnpm add @opensaas/stack-auth better-auth
 
 ### 1. Update Your Config
 
-Wrap your OpenSaas config with `withAuth()`:
+Add `authPlugin()` to your config's `plugins` array:
 
 ```typescript
 // opensaas.config.ts
 import { config } from '@opensaas/stack-core'
-import { withAuth, authConfig } from '@opensaas/stack-auth'
+import { authPlugin } from '@opensaas/stack-auth'
 
-export default withAuth(
-  config({
-    db: {
-      provider: 'sqlite',
-      url: process.env.DATABASE_URL || 'file:./dev.db',
-    },
-    lists: {
-      // Your custom lists here
-    },
-  }),
-  authConfig({
-    emailAndPassword: { enabled: true },
-    emailVerification: { enabled: true },
-    passwordReset: { enabled: true },
-    sessionFields: ['userId', 'email', 'name'],
-  }),
-)
+export default config({
+  db: {
+    provider: 'sqlite',
+    url: process.env.DATABASE_URL || 'file:./dev.db',
+  },
+  lists: {
+    // Your custom lists here
+  },
+  plugins: [
+    authPlugin({
+      emailAndPassword: { enabled: true },
+      emailVerification: { enabled: true },
+      passwordReset: { enabled: true },
+      sessionFields: ['userId', 'email', 'name'],
+    }),
+  ],
+})
 ```
 
 ### 2. Generate Schema and Push to Database
@@ -112,32 +112,33 @@ Sessions are now automatically available in your access control functions:
 
 ```typescript
 // opensaas.config.ts
-import { withAuth, authConfig } from '@opensaas/stack-auth'
-
-export default withAuth(
-  config({
-    lists: {
-      Post: list({
-        fields: { title: text(), content: text() },
-        access: {
-          operation: {
-            // Session is automatically populated from better-auth
-            create: ({ session }) => !!session,
-            update: ({ session, item }) => {
-              if (!session) return false
-              return { authorId: { equals: session.userId } }
-            },
+import { config } from '@opensaas/stack-core'
+import { authPlugin } from '@opensaas/stack-auth'
+
+export default config({
+  lists: {
+    Post: list({
+      fields: { title: text(), content: text() },
+      access: {
+        operation: {
+          // Session is automatically populated from better-auth
+          create: ({ session }) => !!session,
+          update: ({ session, item }) => {
+            if (!session) return false
+            return { authorId: { equals: session.userId } }
           },
         },
-      }),
-    },
-  }),
-  authConfig({
-    emailAndPassword: { enabled: true },
-    // Session will contain: { userId, email, name }
-    sessionFields: ['userId', 'email', 'name'],
-  }),
-)
+      },
+    }),
+  },
+  plugins: [
+    authPlugin({
+      emailAndPassword: { enabled: true },
+      // Session will contain: { userId, email, name }
+      sessionFields: ['userId', 'email', 'name'],
+    }),
+  ],
+})
 ```
 
 ## Configuration
@@ -145,7 +146,7 @@ export default withAuth(
 ### Auth Config Options
 
 ```typescript
-authConfig({
+authPlugin({
   // Email/password authentication
   emailAndPassword: {
     enabled: true,
@@ -202,6 +203,39 @@ authConfig({
 })
 ```
 
+## Adopting an Existing better-auth Installation
+
+Migrating a project that **already runs better-auth**? The plugin can adopt your
+live tables rather than recreating them, so there's no destructive auth
+migration. Use the `adoptBetterAuthTables()` recipe to preset the model/schema
+knobs that match a standard separate-schema better-auth install:
+
+```typescript
+import { authPlugin, adoptBetterAuthTables } from '@opensaas/stack-auth'
+
+authPlugin({
+  // Defaults: AuthUser/AuthSession/AuthAccount/AuthVerification in the `auth`
+  // Postgres schema — pinned to your live table names + schema (@@map/@@schema).
+  ...adoptBetterAuthTables(),
+  emailAndPassword: { enabled: true },
+})
+
+// Customise when your live tables diverge from the defaults:
+adoptBetterAuthTables({
+  schema: 'identity', // default: 'auth'
+  modelNamePrefix: 'BA', // default: 'Auth' (→ AuthUser/AuthSession/…)
+  fields: { user: { name: 'full_name' }, session: { userId: 'user_id' } },
+})
+```
+
+**App `User` vs the Auth identity.** The plugin models the **Auth identity** (the
+better-auth user, e.g. `AuthUser`). It does not assume that list is your app's
+own domain `User` — when the keys differ, your `User` is never extended or
+overwritten. **Linking your domain `User` to the Auth identity is your app's
+concern** (declare a `relationship({ ref: 'AuthUser' })` on your `User`). See the
+[Authentication guide](https://stack.opensaas.au/docs/guides/authentication) for
+the full migrator walkthrough and a Schema-parity (clean-diff) check.
+
 ## UI Components
 
 ### SignInForm
@@ -248,7 +282,7 @@ import { authClient } from '@/lib/auth-client'
 
 ## Auto-Generated Lists
 
-The following lists are automatically created when you use `withAuth()`:
+The following lists are automatically created when you use `authPlugin()`:
 
 ### User
 
@@ -322,7 +356,7 @@ The following lists are automatically created when you use `withAuth()`:
 Add custom fields to the User model:
 
 ```typescript
-authConfig({
+authPlugin({
   extendUserList: {
     fields: {
       role: select({
@@ -353,7 +387,7 @@ authConfig({
 Control which user fields are included in the session object:
 
 ```typescript
-authConfig({
+authPlugin({
   sessionFields: ['userId', 'email', 'name', 'role'],
 })
 
@@ -434,7 +468,7 @@ See `examples/auth-demo` for a complete working example.
 
 ## How It Works
 
-1. **withAuth()** merges auth lists (User, Session, Account, Verification) with your config
+1. **authPlugin()** merges auth lists (User, Session, Account, Verification) with your config
 2. **Generator** creates Prisma schema with all auth tables
 3. **Session Provider** uses better-auth to get current session
 4. **Context** includes session automatically in all access control functions