@terreno/mcp 57.18.0 → 57.19.2

package/src/docs/versioned/57.1.0/how-to/call-external-apis.md

@@ -1,101 +0,0 @@
-# Call external APIs
-
-How to talk to third-party HTTP APIs (payment processors, health integrations, meeting providers, etc.) from a `@terreno/api` backend using the shared HTTP client utilities, instead of hand-rolling axios setup, token caching, retry, and error handling per integration.
-
-## When to use each piece
-
-| You are... | Use |
-|---|---|
-| Calling a third-party REST API that needs a bearer token, OAuth2 client-credentials, or API-key auth | `createAuthenticatedClient` |
-| Calling an external service through its own SDK (Twilio, Google APIs, Stripe) | `withApiErrorHandling` around the SDK calls — the SDK owns transport, you standardize failures |
-| Logging or classifying a caught error from any external call | `normalizeApiError` |
-| Surfacing an external failure to your API's consumers from a route handler | `withApiErrorHandling` with `rethrowAs: "apiError"` |
-| Making internal requests to your own `@terreno/api` backend | None of these — use `@terreno/rtk` on the frontend or direct function calls on the backend |
-
-**Rule of thumb:** any file that would otherwise contain `axios.create(...)` plus a token variable plus a `try/catch → axios.isAxiosError → log → throw` block should use these utilities instead.
-
-## Create a client
-
-```typescript
-import {createAuthenticatedClient} from "@terreno/api";
-
-const widgetApi = createAuthenticatedClient({
-  apiName: "widgetService", // used in logs and normalized errors; defaults to baseURL
-  auth: {
-    credentials: {clientId: process.env.WIDGET_CLIENT_ID!, clientSecret: process.env.WIDGET_CLIENT_SECRET!},
-    refreshOn401: true,
-    tokenUrl: "https://api.widgets.example/oauth/token",
-    type: "oauth2",
-  },
-  baseURL: "https://api.widgets.example/v2",
-});
-
-const response = await widgetApi.axios.get("/widgets/123");
-```
-
-Auth strategies:
-
-- `{type: "bearer", getToken}` — you supply an async token fetcher; the client caches the result until `invalidateToken()` is called.
-- `{type: "oauth2", tokenUrl, credentials, refreshOn401}` — the client performs the client-credentials grant itself (HTTP Basic auth, form-encoded). With `refreshOn401: true`, a 401 response invalidates the cached token and retries the request exactly once with a fresh one.
-- `{type: "apiKey", header, getKey}` — the key is sent on the header you name.
-
-Tokens are fetched lazily and concurrent first requests share a single fetch. Create the client once per service at module scope — not per request — so the token cache is actually shared.
-
-## What you get for free
-
-- **Retry with backoff** for transient failures (429 rate limits, 5xx, network errors), honoring `Retry-After`, capped by `maxDelayMs`. Defaults: 3 total attempts, 250ms base delay, 30s delay ceiling — override via the `retry` option.
-- **Idempotency safety**: only GET/HEAD/OPTIONS are retried by default. Retrying a failed POST can duplicate side effects (a payment, a prescription, a meeting). If a specific POST/PUT/DELETE is genuinely safe to repeat, opt it in per request:
-
-  ```typescript
-  import {markRetryUnsafe} from "@terreno/api";
-
-  // Safe to repeat: the upstream endpoint is idempotent on externalId.
-  await widgetApi.axios.post("/widgets", {externalId, name}, markRetryUnsafe());
-  ```
-
-  The request body must be replayable — JSON is fine; streams/FormData are consumed on first send.
-- **Quiet transport logging**: the client logs retries and token refreshes at debug level only and always rejects with the original axios error. Error-level logging belongs to the call site (next section) so composed usage logs each failure exactly once.
-
-## Handle failures at the call site
-
-Wrap calls with `withApiErrorHandling` to normalize, log once, and rethrow:
-
-```typescript
-import {withApiErrorHandling} from "@terreno/api";
-
-export const getWidget = async (id: string): Promise<Widget> => {
-  const response = await withApiErrorHandling(() => widgetApi.axios.get(`/widgets/${id}`), {
-    apiName: "widgetService",
-    operation: "getWidget",
-  });
-  return response.data;
-};
-```
-
-- Default (`rethrowAs: "raw"`): logs the normalized shape (status code, classification, extracted messages) and rethrows the original error for callers that need it.
-- `rethrowAs: "apiError"`: throws a terreno `APIError` (stable title, per-occurrence `detail`) so route handlers surface a clean JSONAPI error instead of a raw axios failure. In this mode the `APIError` constructor does the logging.
-
-For SDK-based integrations where `createAuthenticatedClient` doesn't apply, `withApiErrorHandling` still works — `normalizeApiError` classifies non-axios errors as `"unknown"` while preserving the message.
-
-## Sensitive response data
-
-`normalizeApiError` never logs raw payload bodies: it extracts only recognized message fields (`{message}`, JSONAPI `{errors: [{title, detail}]}`, plain strings truncated to 500 chars). If the upstream service puts sensitive data *inside* those message fields, supply a `redactError` hook (available on both `createAuthenticatedClient` and `withApiErrorHandling`):
-
-```typescript
-redactError: (normalized) => ({
-  ...normalized,
-  messages: normalized.messages.map((message) => message.replace(PATIENT_ID_PATTERN, "[redacted]")),
-}),
-```
-
-Note the hook's output classification also feeds the client's retry decision — redact messages, don't rewrite classifications, unless changing retry behavior is intended.
-
-## When not to use this
-
-- **Your own backend's routes** — use the generated `@terreno/rtk` SDK (frontend) or call the function directly (backend).
-- **SDK-managed transport** (Twilio, googleapis) — don't fight the SDK's HTTP layer; adopt only `normalizeApiError`/`withApiErrorHandling` for consistent failure handling.
-- **Webhook notifiers** — `sendSlackMessage`/`sendGoogleChatMessage`/`sendZoomMessage` already exist; see [Webhooks & Notifications](../reference/api.md#webhooks--notifications).
-
-## Related
-
-- [@terreno/api reference — HTTP Client](../reference/api.md#http-client)

package/src/docs/versioned/57.1.0/how-to/circleci.md

@@ -1,173 +0,0 @@
-# CircleCI (Terreno)
-
-Dual-run migration from GitHub Actions. See
-[`docs/implementationPlans/migrate-cicd-to-circleci.md`](../implementationPlans/migrate-cicd-to-circleci.md).
-
-**Status (2026-08-20):** CircleCI is **disabled**. GitHub Actions is the CI of
-record. Setup/path-filtering is parked in `.circleci/config.setup.yml`;
-`.circleci/config.yml` is a no-op (`workflows.disabled.when: false`). Real jobs
-remain in `.circleci/continue-config.yml`. To re-enable, copy `config.setup.yml`
-over `config.yml`.
-
-**Parked (2026-08-17):** Phase 1–3 config is in-repo (package CI, repo policy, Playwright
-e2e). **Deploys are not ported yet** (Netlify, GCP CD, EAS, npm publish). GHA remains
-required until CircleCI twins are trusted.
-
-## Project setup (maintainers)
-
-1. Link `TerrenoLabs/terreno` in CircleCI (GitHub App).
-2. Default branch: `master`.
-3. Enable **dynamic config** / setup workflows for the project (required for
-   `.circleci/config.yml` `setup: true`).
-4. Build forked PRs if you want DCO + rulesync on forks.
-
-Org/project slug: _(record after Phase 0.1 — e.g. `TerrenoLabs/terreno`)_.
-
-## Config layout
-
-| File | Role |
-|------|------|
-| `.circleci/config.yml` | Active CircleCI config (currently a disabled no-op) |
-| `.circleci/config.setup.yml` | Parked setup workflow + `path-filtering` (copy over `config.yml` to re-enable) |
-| `.circleci/continue-config.yml` | Real jobs/workflows gated by those params |
-
-Smoke job `config-ok` always runs on continuation.
-
-`.circleci/**` sets `run-circleci-config`, which starts the `circleci-config`
-workflow: one job from each ported family (package CI, policy, example apps,
-`e2e` with `spec: login`, admin-spa). `comms/**` also sets
-`run-example-backend` and `run-example-backend-script`, matching the GitHub
-Actions twins.
-
-## Contexts (create empty shells, then fill)
-
-Do **not** paste secret values into the repo. Create these CircleCI Contexts and restrict
-`terreno-release` to tag/release pipelines when publish is ported.
-
-| Context | Maps from GHA | Used by (planned / current) |
-|---------|---------------|------------------------------|
-| `terreno-npm` | `NPM_TOKEN` | publish (deferred) |
-| `terreno-netlify` | `NETLIFY_*` | deploys (deferred) |
-| `terreno-expo` | `EXPO_TOKEN` | EAS (deferred) |
-| `terreno-gcp` | OIDC / WIF (no long-lived key for CD) | GCP CD (deferred) |
-| `terreno-e2e` | `E2E_TOKEN_SECRET`, `E2E_REFRESH_TOKEN_SECRET`, `E2E_SESSION_SECRET` | `e2e`, `admin-spa-integration` |
-| `terreno-release` | `REPO_ADMIN_TOKEN`, Zoom webhooks | publish (deferred) |
-| `terreno-agentic` | `CURSOR_API_KEY` | agentic replacements (deferred) |
-| `terreno-github-api` | PAT (`pull-requests`, `contents`, …) | `dco`, PR comments later |
-
-Until contexts exist, e2e jobs may use **project env vars for `E2E_*` secrets only**
-(or the in-job `ci-e2e-*-secret` fallbacks). **Do not** put `GITHUB_TOKEN` (or any
-GitHub PAT) in project env vars — those are injected into every job, including
-`bun` scripts from the PR. Create `terreno-github-api`, restrict it to this
-project, leave fork-PR secret passing off, and attach that context **only** to
-`dco` (and later comment jobs). DCO skips if `GITHUB_TOKEN` is unset.
-
-After contexts exist, attach them on the matching jobs in
-`.circleci/continue-config.yml` (see comments in the `workflows:` section).
-
-## Check name map (GHA → CircleCI)
-
-Branch protection still requires **GitHub Actions** names during dual-run. CircleCI
-checks appear as CircleCI job names in the GitHub Checks UI.
-
-| GHA job `name:` / workflow | CircleCI job |
-|----------------------------|--------------|
-| Repository policies / No barrel imports | `no-barrel-imports` |
-| Explicit any baseline | `explicit-any` |
-| License coverage | `license-coverage` |
-| Verify rules are in sync | `rulesync-check` |
-| `dco` | `dco` |
-| Run all tests (API CI) | `api-ci` |
-| Run all tests (AI CI) | `ai-ci` |
-| RTK Lint and Build | `rtk-ci` |
-| UI Lint, Build, Types, and Tests | `ui-ci` |
-| Demo TypeScript Check (UI dependency) | `ui-demo-typecheck` |
-| Demo Lint and TypeScript Check | `ui-demo-ci` |
-| Lint, compile, and test communications | `comms-ci` |
-| Lint, Build, and Test (MCP) | `mcp-server-ci` |
-| Build Docker Image (MCP) | `mcp-server-docker` |
-| Example Frontend Lint and Test | `example-frontend-ci` |
-| Example Backend Lint, Build, and Test | `example-backend-ci` |
-| Run admin script CLI | `example-backend-script-runner` |
-| Build backend Docker image | `example-backend-docker` |
-| Admin SPA Build and E2E | `admin-spa-ci` |
-| E2E · `<spec>` | `e2e` (matrix `spec`) |
-| E2E Load · syncdb-loadlab | `e2e-load` (trigger-gated, see below) |
-| Admin SPA Backend Integration E2E | `admin-spa-integration` |
-| _(new)_ CircleCI path-filter parity | `circleci-parity` |
-| _(smoke)_ | `config-ok` |
-
-Deferred phases keep their GHA checks for now; these are the planned CircleCI job
-names so branch protection can be remapped in one pass later:
-
-| GHA job `name:` / workflow (not yet ported) | Planned CircleCI job |
-|---------------------------------------------|----------------------|
-| Fingerprint gate (`fingerprint-gate.yml`) | `fingerprint-gate` (Phase 5) |
-| EAS PR update/build (`eas-pr.yml`) | `eas-pr` (Phase 5) |
-| EAS dev build (`eas-dev-build.yml`) | `eas-dev-build`, manual pipeline (Phase 5) |
-| CD terraform preview/apply (`cd.yml`) | `cd-terraform`, `cd-deploy` (Phase 6) |
-| Preview cleanup (`preview-cleanup.yml`) | `preview-cleanup` (Phase 6) |
-| Netlify demo / frontend / docs deploys | `deploy-demo`, `deploy-example-frontend`, `deploy-docs` (Phase 4) |
-| Publish on tag (`publish-on-tag.yml`) | `publish-npm` (Phase 7, single-writer cutover) |
-| Appium / Maestro | `appium-android`, `appium-ios`, `maestro` (Phase 8) |
-
-## Path-filter parity guard
-
-`bun run check:circleci-parity` fails when a GHA `paths:` entry has no mapping to
-its CircleCI parameter — otherwise the twin silently never runs. It runs as the
-`circleci-parity` job (CircleCI) and the **CircleCI path-filter parity** job
-(GitHub Actions `repo-policies`). Add new packages/paths to the mapping in
-`.circleci/config.setup.yml` (or `config.yml` when enabled) and to `WORKFLOW_PARAMETERS` in
-`scripts/check-circleci-parity/lib.ts`.
-
-## Config-only changes
-
-When CircleCI is enabled, `.circleci/config.yml` / `continue-config.yml` /
-`example-frontend/playwright.circleci.config.ts` edits set `run-circleci-config`,
-which runs a representative slice (`api-ci`, `ui-ci`, `example-backend-ci`,
-`no-barrel-imports`, `e2e` spec `login`) so config changes are actually exercised
-instead of only hitting the always-on smoke jobs. While disabled, keep the mapping
-in `config.setup.yml` in sync; `check:circleci-parity` reads that file first. CircleCI e2e
-pre-starts a static `bun expo export` on `:8082` (`NODE_OPTIONS=--max-old-space-size=3072`
-for the export only) and reuses it (60s test timeout, `large` Docker). Keeping Metro
-alive next to Chromium gets SIGKILL on 8GB. `xlarge` is not on this project's plan.
-
-## Nightly load test
-
-`e2e-load` (syncdb-loadlab) is never PR-blocking. Trigger the **setup** pipeline
-with `run-e2e-load`. Setup skips path-filtering and continues with a differently
-named continuation parameter (`e2e-load`) so CircleCI does not report conflicting
-pipeline parameters.
-
-```json
-{"run-e2e-load": true}
-```
-
-This replaces the GHA cron / `workflow_dispatch` / `load-test` label triggers in
-`e2e-load-nightly.yml`.
-
-## Local validation
-
-```bash
-circleci config validate .circleci/config.yml
-circleci config validate .circleci/continue-config.yml
-```
-
-## Dual-run drift
-
-While both systems run, keep these in sync when editing a GHA workflow:
-
-1. `paths:` → mapping in `.circleci/config.setup.yml` (or `config.yml` when enabled; enforced by `check:circleci-parity`)
-2. e2e `spec:` matrix → `e2e` workflow matrix in `continue-config.yml`
-3. New package CI workflow → new param + job + `WORKFLOW_PARAMETERS` entry
-
-## Not in this phase
-
-- Netlify / docs / demo / example-frontend **deploys**
-- GCP `cd.yml`, preview-cleanup, OIDC
-- EAS / fingerprint
-- npm publish-on-tag
-- Appium / Maestro
-- CodeQL, Dependabot auto-merge, triage, gh-aw agentics
-
-Keep matching `.github/workflows/*` until dual-run cutover deletes them per phase.

package/src/docs/versioned/57.1.0/how-to/configure-better-auth.md

@@ -1,299 +0,0 @@
-# Configure Better Auth
-
-Set up Better Auth as the **default** authentication provider for new Terreno apps — session-based auth with built-in social OAuth and first-class `@terreno/syncdb` integration.
-
-## Overview
-
-Better Auth is the recommended authentication system for new Terreno frontends. Register `BetterAuthApp` on the backend, set `AUTH_PROVIDER=better-auth`, and wire `createBetterAuthClient` + `generateBetterAuthSlice` on the client. Pair with `betterAuthAdapter` when using `@terreno/syncdb`.
-
-JWT/Passport remains available for legacy deployments (`AUTH_PROVIDER=jwt`). Both can run in parallel during migration.
-
-**Choose Better Auth for:**
-- New apps and greenfield screens
-- Social login (Google, GitHub, Apple)
-- Session-based authentication with `@terreno/syncdb`
-- Socket.io sync via `RealtimeApp` bearer sessions
-
-**Stay on JWT only when:**
-- You have an existing JWT deployment and are mid-migration
-- You require a fully stateless token contract with no session cookies
-- You have custom JWT payload requirements Better Auth cannot satisfy
-
-## Backend Setup
-
-### 1. Configure Environment Variables
-
-Set `AUTH_PROVIDER` to enable Better Auth:
-
-``````bash
-# Choose authentication provider
-AUTH_PROVIDER=better-auth  # or "jwt" (default)
-
-# Better Auth configuration
-BETTER_AUTH_SECRET=your-secret-key-min-32-chars
-BETTER_AUTH_URL=http://localhost:4000
-
-# Optional: Social OAuth providers
-GOOGLE_CLIENT_ID=your-google-client-id
-GOOGLE_CLIENT_SECRET=your-google-client-secret
-
-GITHUB_CLIENT_ID=your-github-client-id  
-GITHUB_CLIENT_SECRET=your-github-client-secret
-
-APPLE_CLIENT_ID=your-apple-client-id
-APPLE_CLIENT_SECRET=your-apple-client-secret
-``````
-
-### 2. Build Better Auth Configuration
-
-Create a function to build your Better Auth config:
-
-``````typescript
-import {BetterAuthConfig, AuthProvider} from "@terreno/api";
-
-const buildBetterAuthConfig = (): BetterAuthConfig | undefined => {
-  const authProvider = process.env.AUTH_PROVIDER as AuthProvider | undefined;
-
-  if (authProvider !== "better-auth") {
-    return undefined; // Use JWT auth instead
-  }
-
-  const config: BetterAuthConfig = {
-    enabled: true,
-    // Deep link schemes for mobile app redirects
-    trustedOrigins: ["yourapp://", "exp://"],
-  };
-
-  // Add Google OAuth if configured
-  if (process.env.GOOGLE_CLIENT_ID && process.env.GOOGLE_CLIENT_SECRET) {
-    config.googleOAuth = {
-      clientId: process.env.GOOGLE_CLIENT_ID,
-      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
-    };
-  }
-
-  // Add GitHub OAuth if configured
-  if (process.env.GITHUB_CLIENT_ID && process.env.GITHUB_CLIENT_SECRET) {
-    config.githubOAuth = {
-      clientId: process.env.GITHUB_CLIENT_ID,
-      clientSecret: process.env.GITHUB_CLIENT_SECRET,
-    };
-  }
-
-  // Add Apple OAuth if configured
-  if (process.env.APPLE_CLIENT_ID && process.env.APPLE_CLIENT_SECRET) {
-    config.appleOAuth = {
-      clientId: process.env.APPLE_CLIENT_ID,
-      clientSecret: process.env.APPLE_CLIENT_SECRET,
-    };
-  }
-
-  return config;
-};
-``````
-
-### 3. Register BetterAuthApp Plugin
-
-Use the TerrenoApp plugin system:
-
-``````typescript
-import {TerrenoApp, BetterAuthApp} from "@terreno/api";
-import {User} from "./models/user";
-
-const betterAuthConfig = buildBetterAuthConfig();
-
-const app = new TerrenoApp({
-  userModel: User,
-  // ... other options
-});
-
-// Register Better Auth plugin if configured
-if (betterAuthConfig) {
-  app.register(new BetterAuthApp({
-    config: betterAuthConfig,
-    userModel: User,
-  }));
-}
-
-const server = app.start();
-``````
-
-### 4. Update User Model
-
-Add optional Better Auth fields to your User schema:
-
-``````typescript
-import {betterAuthUserPlugin} from "@terreno/api";
-
-const userSchema = new mongoose.Schema({
-  email: {type: String, unique: true},
-  name: {type: String},
-  // ... other fields
-});
-
-// Adds: betterAuthId, oauthProvider
-userSchema.plugin(betterAuthUserPlugin);
-``````
-
-## Frontend Setup
-
-### 1. Create Better Auth Client
-
-``````typescript
-import {createBetterAuthClient} from "@terreno/rtk";
-
-export const authClient = createBetterAuthClient({
-  baseURL: process.env.EXPO_PUBLIC_API_URL || "http://localhost:4000",
-});
-``````
-
-### 2. Add Session Redux Slice
-
-``````typescript
-import {generateBetterAuthSlice} from "@terreno/rtk";
-import {configureStore} from "@reduxjs/toolkit";
-import {authClient} from "./authClient";
-
-const {sessionReducer, sessionMiddleware} = generateBetterAuthSlice(authClient);
-
-export const store = configureStore({
-  reducer: {
-    session: sessionReducer,
-    // ... other reducers
-  },
-  middleware: (getDefault) => getDefault().concat(sessionMiddleware),
-});
-``````
-
-### 3. Add Social Login UI
-
-Use the SocialLoginButton component:
-
-``````typescript
-import {SocialLoginButton, Box} from "@terreno/ui";
-import {authClient} from "@/store/authClient";
-
-const LoginScreen = () => {
-  return (
-    <Box padding={4} gap={3}>
-      <SocialLoginButton
-        provider="google"
-        onPress={async () => {
-          await authClient.signIn.social({
-            provider: "google",
-            callbackURL: "yourapp://auth/callback",
-          });
-        }}
-      />
-      
-      <SocialLoginButton
-        provider="github"
-        onPress={async () => {
-          await authClient.signIn.social({
-            provider: "github",
-            callbackURL: "yourapp://auth/callback",
-          });
-        }}
-      />
-      
-      <SocialLoginButton
-        provider="apple"
-        onPress={async () => {
-          await authClient.signIn.social({
-            provider: "apple",
-            callbackURL: "yourapp://auth/callback",
-          });
-        }}
-      />
-    </Box>
-  );
-};
-``````
-
-## OAuth Provider Setup
-
-### Google OAuth
-
-1. Go to [Google Cloud Console](https://console.cloud.google.com/)
-2. Create a new project or select existing
-3. Enable Google+ API
-4. Create OAuth 2.0 credentials
-5. Add authorized redirect URIs:
-   - `http://localhost:4000/api/auth/callback/google` (development)
-   - `https://yourapp.com/api/auth/callback/google` (production)
-6. Copy Client ID and Client Secret to `.env`
-
-### GitHub OAuth
-
-1. Go to [GitHub Developer Settings](https://github.com/settings/developers)
-2. Create a new OAuth App
-3. Set Authorization callback URL:
-   - `http://localhost:4000/api/auth/callback/github` (development)
-   - `https://yourapp.com/api/auth/callback/github` (production)
-4. Copy Client ID and generate Client Secret
-5. Add to `.env`
-
-### Apple Sign In
-
-1. Go to [Apple Developer Console](https://developer.apple.com/)
-2. Create a new Services ID
-3. Configure Sign in with Apple
-4. Add return URLs (similar to above)
-5. Generate private key and download
-6. Copy Service ID and Key to `.env`
-
-## Generated Endpoints
-
-When Better Auth is enabled, these endpoints are available:
-
-- `POST /api/auth/signup/email` — Email/password signup
-- `POST /api/auth/signin/email` — Email/password signin
-- `GET /api/auth/signin/google` — Initiate Google OAuth
-- `GET /api/auth/signin/github` — Initiate GitHub OAuth
-- `GET /api/auth/signin/apple` — Initiate Apple Sign In
-- `GET /api/auth/callback/{provider}` — OAuth callback handler
-- `POST /api/auth/signout` — Sign out current session
-- `GET /api/auth/session` — Get current session
-
-## Troubleshooting
-
-### "BETTER_AUTH_SECRET is not set"
-
-Ensure you've set both `AUTH_PROVIDER=better-auth` and `BETTER_AUTH_SECRET` in your environment variables.
-
-### OAuth redirect mismatch
-
-Verify the callback URLs in your OAuth provider settings match your `BETTER_AUTH_URL` + `/api/auth/callback/{provider}`.
-
-### Session not persisting
-
-Check that `trustedOrigins` in your Better Auth config includes your app's deep link scheme (e.g., `"yourapp://"`).
-
-### Social login opens browser but doesn't redirect back
-
-Ensure your mobile app has the proper deep link configuration in `app.json`:
-
-``````json
-{
-  "expo": {
-    "scheme": "yourapp"
-  }
-}
-``````
-
-## Migration from JWT Auth
-
-Better Auth runs **in parallel** with JWT auth. You don't need to migrate existing users immediately:
-
-1. Set `AUTH_PROVIDER=better-auth`
-2. Keep existing JWT endpoints available (they still work)
-3. New users can sign up via Better Auth
-4. Existing users continue using JWT tokens
-5. Optionally add migration logic to link accounts
-
-## Learn More
-
-- [Authentication Architecture](../explanation/authentication.md)
-- [@terreno/api Reference](../reference/api.md#better-auth)
-- [@terreno/rtk Reference (legacy)](../reference/legacy/rtk.md#better-auth)
-- [Better Auth Documentation](https://better-auth.com/)