merge dev

Author: BilalG1

.claude/CLAUDE-KNOWLEDGE.md

@@ -178,9 +178,9 @@ const [result1, result2] = await Promise.all([
 ```
 
 ### Q: What's the correct way to update project configuration in E2E tests?
-A: Use the `/api/v1/internal/config/override` endpoint with PATCH method and admin access token:
+A: Use the `/api/v1/internal/config/override/environment` endpoint with PATCH method and admin access token:
 ```typescript
-await niceBackendFetch("/api/v1/internal/config/override", {
+await niceBackendFetch("/api/v1/internal/config/override/environment", {
   method: "PATCH",
   accessType: "admin",
   headers: {

.github/workflows/db-migration-backwards-compatibility.yaml

@@ -1,22 +1,22 @@
-name: DB migrations are backwards-compatible with main branch
+name: DB migrations are backwards-compatible
 
 on:
   push:
-    branches:
+    branches-ignore:
       - main
-      - dev
   pull_request:
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: ${{ github.ref != 'refs/heads/main' && github.ref != 'refs/heads/dev' }}
+  cancel-in-progress: ${{ github.ref != 'refs/heads/dev' }}
 
 jobs:
   check-migrations-changed:
     name: Check if migrations changed
     runs-on: ubuntu-latest
     outputs:
       migrations_changed: ${{ steps.check-diff.outputs.migrations_changed }}
+      base_branch: ${{ steps.check-diff.outputs.base_branch }}
     steps:
       - name: Checkout current branch
         uses: actions/checkout@v6
@@ -26,9 +26,17 @@ jobs:
       - name: Check for migration changes
         id: check-diff
         run: |
-          # Get the merge base with main
-          git fetch origin main
-          MERGE_BASE=$(git merge-base HEAD origin/main)
+          # Determine base branch: dev compares to main, all others compare to dev
+          if [ "${{ github.ref }}" = "refs/heads/dev" ]; then
+            BASE_BRANCH="main"
+          else
+            BASE_BRANCH="dev"
+          fi
+          echo "base_branch=$BASE_BRANCH" >> $GITHUB_OUTPUT
+          
+          # Get the merge base with the base branch
+          git fetch origin $BASE_BRANCH
+          MERGE_BASE=$(git merge-base HEAD origin/$BASE_BRANCH)
           
           # Check if there are any changes in the migrations folder
           if git diff --quiet "$MERGE_BASE" HEAD -- apps/backend/prisma/migrations/; then
@@ -40,7 +48,7 @@ jobs:
           fi
 
   backwards-compatibility:
-    name: Test migrations with main branch code
+    name: Test migrations with ${{ needs.check-migrations-changed.outputs.base_branch }} branch code
     needs: check-migrations-changed
     if: needs.check-migrations-changed.outputs.migrations_changed == 'true'
     runs-on: ubicloud-standard-8
@@ -62,25 +70,19 @@ jobs:
           mkdir -p saved-migrations
           cp -r current-branch/apps/backend/prisma/migrations/* saved-migrations/
 
-      # Now checkout main branch
-      - name: Checkout main branch
+      # Now checkout base branch (main for dev, dev for all others)
+      - name: Checkout base branch
         uses: actions/checkout@v6
         with:
-          ref: main
-          path: main-branch
+          ref: ${{ needs.check-migrations-changed.outputs.base_branch }}
+          path: base-branch
 
-      # Replace main's migrations with current branch's migrations
-      - name: Replace migrations with current branch migrations
-        run: |
-          rm -rf main-branch/apps/backend/prisma/migrations/*
-          cp -r saved-migrations/* main-branch/apps/backend/prisma/migrations/
-
-      # Move main-branch to the root for the rest of the workflow
+      # Move base-branch to the root for the rest of the workflow (keep base's migrations for now)
       - name: Setup working directory
         run: |
           shopt -s dotglob
-          mv main-branch/* .
-          rm -rf main-branch current-branch saved-migrations
+          mv base-branch/* .
+          rm -rf base-branch current-branch
 
       - name: Setup Node.js
         uses: actions/setup-node@v6
@@ -194,9 +196,27 @@ jobs:
       - name: Wait 10 seconds
         run: sleep 10
 
-      - name: Run tests
+      # First test run: base branch with base's migrations
+      - name: Run tests (base branch with original migrations)
         run: pnpm test
 
+      # Now copy over current branch's migrations and run migrate
+      - name: Replace migrations with current branch migrations
+        run: |
+          rm -rf apps/backend/prisma/migrations/*
+          cp -r saved-migrations/* apps/backend/prisma/migrations/
+          rm -rf saved-migrations
+
+      - name: Run database migrations
+        run: pnpm run db:migrate
+
+      # Second test run: base branch code with new migrations applied
+      - name: Run tests (base branch with new migrations)
+        run: pnpm test
+
+      - name: Verify data integrity
+        run: pnpm run verify-data-integrity
+
       - name: Print Docker Compose logs
         if: always()
         run: docker compose -f docker/dependencies/docker.compose.yaml logs

.vscode/settings.json

@@ -7,6 +7,7 @@
   "typescript.tsdk": "node_modules/typescript/lib",
   "editor.tabSize": 2,
   "cSpell.words": [
+    "pushable",
     "autoupdate",
     "backlinks",
     "Cancelation",

AGENTS.md

@@ -83,13 +83,15 @@ To see all development ports, refer to the index.html of `apps/dev-launchpad/pub
 - NEVER try-catch-all, NEVER void a promise, and NEVER .catch(console.error) (or similar). In most cases you don't actually need to be asynchronous, especially when UI is involved (instead, use a loading indicator! eg. our <Button> component already takes an async callback for onClick and sets its loading state accordingly — if whatever component doesn't do that, update the component instead). If you really do need things to be asynchronous, use `runAsynchronously` or `runAsynchronouslyWithAlert` instead as it deals with error logging.
 - WHENEVER you create hover transitions, avoid hover-enter transitions, and just use hover-exit transitions. For example, `transition-colors hover:transition-none`.
 - Any environment variables you create should be prefixed with `STACK_` (or NEXT_PUBLIC_STACK_ if they are public). This ensures that their changes are picked up by Turborepo (and helps readability).
+- NEVER just silently use fallback values or whatever when you don't know how to fix type errors. If there is a state that should never happen because of higher-level logic, and the type system doesn't represent that, either update the types or throw an error. Stuff like `?? 0` or `?? ""` is often code smell when `?? throwErr("this should never happen because XYZ")` would be better.
 - Code defensively. Prefer `?? throwErr(...)` over non-null assertions, with good error messages explicitly stating the assumption that must've been violated for the error to be thrown.
 - Try to avoid the `any` type. Whenever you need to use `any`, leave a comment explaining why you're using it (optimally it explains why the type system fails here, and how you can be certain that any errors in that code path would still be flagged at compile-, test-, or runtime).
 - Don't use Date.now() for measuring elapsed (real) time, instead use `performance.now()`
 - Use urlString`` or encodeURIComponent() instead of normal string interpolation for URLs, for consistency even if it's not strictly necessary.
 - When making config updates, use path notation (`{ "path.to.field": my-value }`) to avoid overwriting sibling properties
 - IMPORTANT: Any assumption you make should either be validated through type system (preferred), assertions, or tests. Optimally, two out of three.
 - If there is an external browser tool connected, use it to test changes you make to the frontend when possible.
+- Whenever you update an SDK implementation in `sdks/implementations`, make sure to update the specs accordingly in `sdks/specs` such that if you reimplemented the entire SDK from the specs again, you would get the same implementation. (For example, if the specs are not precise enough to describe a change you made, make the specs more precise.)
 
 ### Code-related
 - Use ES6 maps instead of records wherever you can.

CHANGELOG.md

@@ -2,6 +2,17 @@
 
 ---
 
+## 2026.01.21
+
+### Payments
+- Payments page updated with new UI changes
+- Added a new Payments Settings page with an option to temporarily disable all payments
+- Subscription renewal emails are now sent automatically to users
+- Past payment invoices are now visible on the Account Settings page
+
+### Documentation
+- Updated JWT documentation to include `isRestricted` and `restrictedReason`
+
 ## 2026.01.19
 - Updated package dependencies to their newest versions.
 

CONTRIBUTING.md

@@ -43,8 +43,9 @@ For vibecoding, it can help to have multiple parallel copies of the codebase ope
   ```sh
   # ~/.bash_profile, ~/.bashrc, ~/.zprofile, ~/.zshrc, ~/.zshenv, etc.
   # note that different coding agents use a different shell in a different mode (login, non-login, interactive, non-interactive, etc.); from my experimentation, as of 2025-10-17 on a Mac, Cursor uses non-interactive zsh (requiring ~/.zshenv), whereas Codex uses a non-interactive login bash (requiring ~/.bash_profile). It's easiest to just add these lines of code to all of your shell configs.
-  eval "$(direnv hook <bash|zsh>)"
-  eval "$(direnv export <bash|zsh>)"
+  # also, make sure to use the correct path to the direnv binary; for example, on a Mac with Homebrew installed, it is /opt/homebrew/bin/direnv
+  eval "$(/path/to/direnv hook <bash|zsh>)"
+  eval "$(/path/to/direnv export <bash|zsh>)"
   ```
 3. Now, create a `.envrc` file in the root of Stack Auth's codebase with the following content:
   ```sh

apps/backend/prisma/migrations/20260201200000_branch_config_override/migration.sql

@@ -0,0 +1,14 @@
+-- CreateTable
+CREATE TABLE "BranchConfigOverride" (
+    "projectId" TEXT NOT NULL,
+    "branchId" TEXT NOT NULL,
+    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "updatedAt" TIMESTAMP(3) NOT NULL,
+    "config" JSONB NOT NULL,
+
+    CONSTRAINT "BranchConfigOverride_pkey" PRIMARY KEY ("projectId","branchId")
+);
+
+-- AddForeignKey
+ALTER TABLE "BranchConfigOverride" ADD CONSTRAINT "BranchConfigOverride_projectId_fkey" FOREIGN KEY ("projectId") REFERENCES "Project"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+

apps/backend/prisma/migrations/20260201210000_testmode_to_environment_config/migration.sql

@@ -0,0 +1,43 @@
+-- Migration to set testMode to true for existing environment config overrides
+-- This is needed because testMode default is changing from true to false,
+-- and we want existing projects to retain their current behavior.
+--
+-- The config can store testMode in two ways:
+-- 1. Top-level key: "payments.testMode": true
+-- 2. Nested syntax: "payments": { "testMode": true }
+--
+-- We need to set testMode to true only if it's not already set in either form.
+
+-- Create temporary index to speed up the migration
+-- SPLIT_STATEMENT_SENTINEL
+-- SINGLE_STATEMENT_SENTINEL
+-- RUN_OUTSIDE_TRANSACTION_SENTINEL
+CREATE INDEX CONCURRENTLY IF NOT EXISTS "temp_eco_testmode_idx" ON /* SCHEMA_NAME_SENTINEL */."EnvironmentConfigOverride" USING GIN ("config");
+-- SPLIT_STATEMENT_SENTINEL
+
+-- SPLIT_STATEMENT_SENTINEL
+-- SINGLE_STATEMENT_SENTINEL
+-- CONDITIONALLY_REPEAT_MIGRATION_SENTINEL
+WITH to_update AS (
+  SELECT "projectId", "branchId", "config"
+  FROM "EnvironmentConfigOverride"
+  WHERE NOT "config" ? 'payments.testMode'
+    AND NOT ("config" ? 'payments' AND ("config" -> 'payments') ? 'testMode')
+  LIMIT 10000
+)
+UPDATE "EnvironmentConfigOverride" eco
+SET "config" = jsonb_set(
+  COALESCE(eco."config", '{}'::jsonb),
+  '{payments.testMode}',
+  'true'::jsonb,
+  true
+)
+FROM to_update
+WHERE eco."projectId" = to_update."projectId"
+  AND eco."branchId" = to_update."branchId"
+RETURNING true AS should_repeat_migration;
+-- SPLIT_STATEMENT_SENTINEL
+
+-- Clean up temporary index
+DROP INDEX IF EXISTS "temp_eco_testmode_idx";
+

apps/backend/prisma/migrations/20260201220000_branch_config_source/migration.sql

@@ -0,0 +1,7 @@
+-- Add source column to BranchConfigOverride
+-- This tracks where the branch config was pushed from (GitHub, CLI, or dashboard)
+ALTER TABLE "BranchConfigOverride" ADD COLUMN "source" JSONB;
+
+-- Set existing rows to unlinked source (they were configured before source tracking existed)
+UPDATE "BranchConfigOverride" SET "source" = '{"type": "unlinked"}' WHERE "source" IS NULL;
+