• pnpm-lock.yaml: Language not supported

docker/dev-postgres-with-extensions/Dockerfile (1)

56-56: Consider removing backticks for clarity; use a Dockerfile comment instead.

While backticks with # comments are technically parsed by /bin/sh without error (the # creates a comment that expands to an empty string), this syntax is unconventional and confusing. Moving the note outside the command string makes the intent clearer:

Suggested change

-    -c statement_timeout=30s `# In production this is higher, but better safe than sorry during dev` \
+    -c statement_timeout=30s \
+    # In production this is higher, but better safe than sorry during dev

packages/stack-shared/src/config/schema.ts (1)

131-136: Make action-specific fields conditional.

metadata and message are currently allowed for any action type, which weakens validation. Consider requiring them only when relevant.

♻️ Suggested tightening

 const signupRuleActionSchema = yupObject({
   type: yupString().oneOf(['allow', 'reject', 'restrict', 'log', 'add_metadata']).defined(),
-  metadata: yupRecord(yupString(), signupRuleMetadataEntrySchema).optional(),
-  message: yupString().optional(), // for reject action custom message (internal use, not shown to user)
+  metadata: yupRecord(yupString(), signupRuleMetadataEntrySchema).when("type", {
+    is: "add_metadata",
+    then: s => s.defined(),
+    otherwise: s => s.optional(),
+  }),
+  message: yupString().when("type", {
+    is: "reject",
+    then: s => s.defined(),
+    otherwise: s => s.optional(),
+  }), // for reject action custom message (internal use, not shown to user)
 });

apps/backend/src/lib/cel-evaluator.ts (1)

178-192: Edge case: emails without @ symbol.

Line 184 handles emails without @ by returning an empty string for emailDomain, which is reasonable. However, consider whether this edge case should be validated earlier in the signup flow rather than silently producing an empty domain.

 export function createSignupRuleContext(params: {
   email: string,
   authMethod: 'password' | 'otp' | 'oauth' | 'passkey',
   oauthProvider?: string,
 }): SignupRuleContext {
   const email = params.email;
-  const emailDomain = email.includes('@') ? email.split('@').pop() ?? '' : '';
+  const atIndex = email.lastIndexOf('@');
+  const emailDomain = atIndex !== -1 ? email.slice(atIndex + 1) : '';

   return {
     email,
     emailDomain,
     authMethod: params.authMethod,
     oauthProvider: params.oauthProvider ?? '',
   };
 }

packages/template/src/lib/stack-app/apps/implementations/server-app-impl.ts (1)

442-455: Avoid unsound cast for admin-restriction fields.

The assertion bypasses UsersCrud typing and can silently propagate undefined if client/server versions drift. Prefer updating shared CRUD types and/or guarding the fields to fail fast when missing.

♻️ Suggested guard (fails fast on missing fields)

-    const crudWithAdminRestriction = crud as typeof crud & {
-      restricted_by_admin: boolean,
-      restricted_by_admin_reason: string | null,
-      restricted_by_admin_private_details: string | null,
-    };
+    const crudWithAdminRestriction = crud as typeof crud & {
+      restricted_by_admin?: boolean,
+      restricted_by_admin_reason?: string | null,
+      restricted_by_admin_private_details?: string | null,
+    };
@@
-      restrictedByAdmin: crudWithAdminRestriction.restricted_by_admin,
-      restrictedByAdminReason: crudWithAdminRestriction.restricted_by_admin_reason,
-      restrictedByAdminPrivateDetails: crudWithAdminRestriction.restricted_by_admin_private_details,
+      restrictedByAdmin: crudWithAdminRestriction.restricted_by_admin ?? throwErr("restricted_by_admin missing — update UsersCrud types/server response"),
+      restrictedByAdminReason: crudWithAdminRestriction.restricted_by_admin_reason ?? null,
+      restrictedByAdminPrivateDetails: crudWithAdminRestriction.restricted_by_admin_private_details ?? null,

As per coding guidelines: Never silently use fallback values when type errors occur. Update types or throw errors instead. Use ?? throwErr(...) over non-null assertions with clear error messages explaining the assumption.

apps/dashboard/src/components/rule-builder/condition-builder.tsx (1)

44-47: Prefer Map for PREDEFINED_VALUES.

This aligns with the project guideline and keeps lookups explicit.

♻️ Suggested refactor

-const PREDEFINED_VALUES: Partial<Record<ConditionField, string[]>> = {
-  authMethod: ['password', 'otp', 'oauth', 'passkey'],
-  oauthProvider: ['google', 'github', 'microsoft', 'facebook', 'discord', 'apple', 'linkedin', 'gitlab', 'bitbucket', 'spotify', 'twitch', 'x'],
-};
+const PREDEFINED_VALUES = new Map<ConditionField, string[]>([
+  ['authMethod', ['password', 'otp', 'oauth', 'passkey']],
+  ['oauthProvider', ['google', 'github', 'microsoft', 'facebook', 'discord', 'apple', 'linkedin', 'gitlab', 'bitbucket', 'spotify', 'twitch', 'x']],
+]);
@@
-  const predefinedValues = PREDEFINED_VALUES[condition.field];
+  const predefinedValues = PREDEFINED_VALUES.get(condition.field);

As per coding guidelines: Use ES6 maps instead of records wherever possible.

Also applies to: 62-63

apps/backend/src/app/api/latest/internal/signup-rules/route.tsx (1)

47-57: Consider DB-side aggregation for high-volume tenants.

findMany pulls all triggers for 48h and aggregates in JS. For large tenants this can be expensive. Consider selecting only needed columns and using Prisma groupBy or a raw date_trunc('hour', triggeredAt) query to aggregate by rule/action/hour to reduce memory and latency.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/signup-rules/page-client.tsx (2)

625-653: Avoid try/catch-all in analytics fetch.

The fetch uses a broad catch and console.debug. Prefer runAsynchronously/runAsynchronouslyWithAlert with an onError handler and keep finally for isLoading so errors are surfaced without a catch-all.

🔧 Example refactor

-    const fetchAnalytics = async () => {
-      try {
-        const response = await (stackAdminApp as any)[stackAppInternalsSymbol].sendRequest('/internal/signup-rules', {
-          method: 'GET',
-        });
-        if (cancelled) return;
-
-        const data = await response.json();
-        ...
-        setAnalytics(analyticsMap);
-      } catch (e) {
-        console.debug('Failed to fetch signup rules analytics:', e);
-      } finally {
-        if (!cancelled) {
-          setIsLoading(false);
-        }
-      }
-    };
-
-    runAsynchronously(fetchAnalytics());
+    runAsynchronously(async () => {
+      try {
+        const response = await (stackAdminApp as any)[stackAppInternalsSymbol].sendRequest('/internal/signup-rules', {
+          method: 'GET',
+        });
+        if (cancelled) return;
+        const data = await response.json();
+        ...
+        setAnalytics(analyticsMap);
+      } finally {
+        if (!cancelled) setIsLoading(false);
+      }
+    }, {
+      onError: (error) => {
+        // handle/report error here
+      },
+    });

As per coding guidelines, "Never try-catch-all, never void a promise, and never .catch(console.error) or similar. Use loading indicators instead when UI is involved. If async is necessary, use runAsynchronously or runAsynchronouslyWithAlert".

---

630-632: Avoid the any cast for StackApp internals.

Line 630: (stackAdminApp as any)[stackAppInternalsSymbol] drops type safety. Consider a typed helper for the internal request channel, or add a short comment explaining why any is unavoidable here.

As per coding guidelines, "Avoid the any type. When necessary, leave a comment explaining why it's being used and why the type system fails at that point".

apps/backend/src/lib/signup-rules.ts (1)

64-89: Avoid broad try/catch + console.error in rule logging/eval.

Both logRuleTrigger and the rule-eval loop catch-all and log to console. Since runAsynchronously already captures rejections and evaluateCelExpression returns false on error, prefer centralized error handling instead of catch-all blocks.

As per coding guidelines, "Never try-catch-all, never void a promise, and never .catch(console.error) or similar. Use loading indicators instead when UI is involved. If async is necessary, use runAsynchronously or runAsynchronouslyWithAlert".

Also applies to: 154-157

apps/e2e/tests/backend/endpoints/api/v1/auth/signup-rules.test.ts (2)

1524-1529: Encode interpolated path segments in URLs.

When building /api/v1/users/${userId}, use encodeURIComponent(userId) (or urlString) to keep URL handling consistent and safe.

🔧 Suggested tweak

-    const userResponse = await niceBackendFetch(`/api/v1/users/${userId}`, {
+    const userResponse = await niceBackendFetch(`/api/v1/users/${encodeURIComponent(userId)}`, {
       method: "GET",
       accessType: "admin",
     });

As per coding guidelines, "Use urlString template literals or encodeURIComponent() instead of normal string interpolation for URLs, for consistency".

---

81-84: Prefer inline snapshots for response bodies.

For structured error payloads, inline snapshots keep expectations compact and aligned with test conventions.

🔧 Example

-    expect(response.body).toMatchObject({
-      code: 'SIGN_UP_REJECTED',
-    });
+    expect(response.body).toMatchInlineSnapshot(`
+      {
+        "code": "SIGN_UP_REJECTED",
+      }
+    `);

As per coding guidelines, "Prefer .toMatchInlineSnapshot over other selectors when writing tests. Check snapshot-serializer.ts to understand how snapshots are formatted".

apps/dashboard/src/lib/cel-visual-parser.ts (3)

248-261: Consider validating the parsed field against known ConditionField values.

The regex matches any word character sequence for the field name, then casts it to ConditionField without validation. If the CEL contains an unrecognized field, it will be silently accepted with an invalid type.

♻️ Proposed validation helper

+const VALID_FIELDS: readonly ConditionField[] = ['email', 'emailDomain', 'authMethod', 'oauthProvider'];
+
+function isValidField(field: string): field is ConditionField {
+  return VALID_FIELDS.includes(field as ConditionField);
+}
+
 function parseCondition(expr: string): ConditionNode | null {
   const trimmed = expr.trim();
 
   // Match patterns like: field == "value"
   const equalsMatch = trimmed.match(/^(\w+)\s*==\s*"([^"]*)"$/);
-  if (equalsMatch) {
+  if (equalsMatch && isValidField(equalsMatch[1])) {
     return {
       type: 'condition',
       id: generateNodeId(),
-      field: equalsMatch[1] as ConditionField,
+      field: equalsMatch[1],
       operator: 'equals',
       value: equalsMatch[2],
     };
   }
   // Apply similar pattern to other matches...

---

323-343: In-list parsing does not handle values containing commas.

The simple comma split will incorrectly parse ["a,b", "c"] as three items instead of two. This is a known limitation that likely won't affect typical signup rule values (emails, domains, providers), but worth documenting.

Consider adding a comment noting this limitation, or implementing a proper tokenizer if comma-containing values become a requirement.

---

394-410: Type cast in updateNodeInTree could mask incompatible updates.

The Partial<RuleNode> type allows passing properties from either ConditionNode or GroupNode, and the as RuleNode cast will accept incompatible combinations (e.g., updating a condition node with children). Consider narrowing the type or adding runtime validation.

♻️ Type-safe alternative using overloads

export function updateNodeInTree(tree: RuleNode, nodeId: string, updates: Partial<ConditionNode>): RuleNode;
export function updateNodeInTree(tree: RuleNode, nodeId: string, updates: Partial<GroupNode>): RuleNode;
export function updateNodeInTree(tree: RuleNode, nodeId: string, updates: Partial<ConditionNode | GroupNode>): RuleNode {
  if (tree.id === nodeId) {
    // Optionally validate that updates.type matches tree.type if present
    return { ...tree, ...updates } as RuleNode;
  }
  // ... rest unchanged
}

apps/e2e/tests/backend/endpoints/api/v1/auth/sign-up-rules.test.ts (1)

1472-1484: Consider documenting expected normalized behavior.

The test currently accepts both 200 and 403 for uppercase "ADMIN", which documents uncertainty about email normalization. If the system has a defined normalization behavior (lowercase), consider updating this test to assert the expected outcome once behavior is confirmed.

apps/backend/src/lib/cel-evaluator.ts (2)

17-21: Remove unused _email_lower from ExtendedContext.

The ExtendedContext type defines _email_lower but this field is never populated or used anywhere in the code. Either implement it for case-insensitive matching or remove the dead code.

♻️ Proposed fix

-// Extended context with helper functions for string operations
-type ExtendedContext = SignUpRuleContext & {
-  // Pre-computed helpers for common patterns
-  _email_lower: string,
-};

---

41-43: Regex pattern doesn't handle single quotes or escaped characters.

The pattern only matches double-quoted string arguments like email.contains("test"). Single-quoted strings email.contains('test') and escaped quotes email.contains("test\"value") won't be processed.

♻️ Enhanced pattern (optional)

-  const methodPattern = /(\w+)\.(contains|startsWith|endsWith|matches)\s*\(\s*"([^"]+)"\s*\)/g;
+  // Match both single and double quoted strings, handling basic escapes
+  const methodPattern = /(\w+)\.(contains|startsWith|endsWith|matches)\s*\(\s*(?:"([^"\\]*(?:\\.[^"\\]*)*)"|'([^'\\]*(?:\\.[^'\\]*)*)')\s*\)/g;

Note: If CEL expressions are admin-controlled and documented to use double quotes only, the current implementation is sufficient.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/users/[userId]/page-client.tsx (1)

292-294: Multiple as any casts indicate incomplete type definitions.

The ServerUser type doesn't include restrictedByAdmin, restrictedByAdminReason, and restrictedByAdminPrivateDetails, requiring as any casts throughout the component. This bypasses type safety and could lead to runtime errors if the API changes.

Consider either:

1. Extending the ServerUser type to include these fields (if they're part of the stable API)
2. Creating a local extended type until the SDK types are updated

// Temporary type extension until SDK types are updated
type ServerUserWithRestriction = ServerUser & {
  restrictedByAdmin?: boolean;
  restrictedByAdminReason?: string | null;
  restrictedByAdminPrivateDetails?: string | null;
};

Also applies to: 435-437

apps/backend/src/app/api/latest/internal/sign-up-rules/route.tsx (1)

74-79: Action type safety relies on runtime behavior.

The cast trigger.action as keyof typeof actionCounts assumes the database always contains valid action values. If an unexpected action is stored, it would silently be ignored due to the if (action in actionCounts) check.

Consider logging or capturing unexpected action values for debugging:

       const action = trigger.action as keyof typeof actionCounts;
       if (action in actionCounts) {
         actionCounts[action]++;
+      } else {
+        // Log unexpected action for debugging
+        console.warn(`Unexpected signup rule action: ${trigger.action}`);
       }

apps/backend/src/lib/sign-up-rules.ts (2)

86-89: Avoid console.error in catch blocks per coding guidelines.

The coding guidelines state to never use .catch(console.error) or similar. Consider using a proper logging infrastructure that can be monitored/alerted on, or propagate the error if it should be visible. If truly swallowing errors intentionally, at minimum use a structured logger.

♻️ Suggested approach

   } catch (e) {
-    // Don't fail the signup if logging fails
-    console.error('Failed to log sign-up rule trigger:', e);
+    // Don't fail the signup if logging fails - use structured logging
+    // TODO: Replace with proper logging infrastructure (e.g., logger.error)
+    void e; // Intentionally swallowed - analytics logging is non-critical
   }

Or better, if a logging service exists:

} catch (e) {
  logger.error('Failed to log sign-up rule trigger', { error: e, tenancyId, ruleId });
}

Based on learnings: "Never try-catch-all, never void a promise, and never .catch(console.error) or similar."

---

154-157: Avoid console.error in catch blocks per coding guidelines.

Similar to the earlier catch block, console.error should be replaced with proper structured logging. CEL evaluation errors may indicate misconfigured rules that admins should be alerted about.

♻️ Suggested approach

     } catch (e) {
-      // Log CEL evaluation error but continue to next rule
-      console.error(`CEL evaluation error for rule ${ruleId}:`, e);
+      // Log CEL evaluation error but continue to next rule
+      // TODO: Use structured logging for monitoring/alerting on rule misconfigurations
+      // logger.warn('CEL evaluation error', { ruleId, error: e, tenancyId: tenancy.id });
     }

Based on learnings: "Never try-catch-all, never void a promise, and never .catch(console.error) or similar."

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsx (1)

630-632: Replace as any with a narrow internal type.

The stackAppInternalsSymbol pattern provides internal SDK access but requires as any to bypass type checking. This can be avoided by defining a type for the internals object, improving type safety and maintainability.

♻️ Suggested change

 const stackAppInternalsSymbol = Symbol.for("StackAuth--DO-NOT-USE-OR-YOU-WILL-BE-FIRED--StackAppInternals");
+type StackAppInternals = {
+  sendRequest: (path: string, init: { method: string }) => Promise<Response>;
+};

-        const response = await (stackAdminApp as any)[stackAppInternalsSymbol].sendRequest('/internal/sign-up-rules', {
+        const internals = (stackAdminApp as { [stackAppInternalsSymbol]: StackAppInternals })[stackAppInternalsSymbol];
+        const response = await internals.sendRequest('/internal/sign-up-rules', {
           method: 'GET',
         });

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/users/[userId]/page-client.tsx (1)

293-295: Avoid any for restriction fields; make the new properties explicit.

Casting user to any and defaulting restrictedByAdmin* values hides type gaps and can silently mask missing data. Please extend ServerUser (or use a narrowed local type) and access these fields without any, using an explicit guard if absence is unexpected.

🧩 Example approach (local narrowing)

+type ServerUserRestrictionFields = {
+  restrictedByAdmin?: boolean;
+  restrictedByAdminReason?: string | null;
+  restrictedByAdminPrivateDetails?: string | null;
+};
+const restrictionUser = user as ServerUser & ServerUserRestrictionFields;
-const restrictedByAdmin = (user as any).restrictedByAdmin ?? false;
-const restrictedByAdminReason = (user as any).restrictedByAdminReason ?? null;
-const restrictedByAdminPrivateDetails = (user as any).restrictedByAdminPrivateDetails ?? null;
+const restrictedByAdmin = restrictionUser.restrictedByAdmin ?? false;
+const restrictedByAdminReason = restrictionUser.restrictedByAdminReason ?? null;
+const restrictedByAdminPrivateDetails = restrictionUser.restrictedByAdminPrivateDetails ?? null;

As per coding guidelines: Avoid the any type. When necessary, leave a comment explaining why it's being used and why the type system fails at that point; Never silently use fallback values when type errors occur. Update types or throw errors instead. Use ?? throwErr(...) over non-null assertions with clear error messages explaining the assumption.

Also applies to: 440-442

apps/e2e/tests/backend/endpoints/api/v1/auth/sign-up-rules.test.ts (1)

81-84: Consider inline snapshots for structured response assertions.

For response bodies like SIGN_UP_REJECTED, inline snapshots improve readability and make regressions more visible during test updates.

As per coding guidelines: Prefer .toMatchInlineSnapshot over other selectors when writing tests. Check snapshot-serializer.ts to understand how snapshots are formatted.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsx (1)

617-633: Avoid any when accessing SDK internals.

Using (stackAdminApp as any) discards type safety. Consider a minimal internal interface (or a helper accessor) so the unsafe surface is localized and documented.

🧩 Minimal narrowing

+type StackAdminAppInternals = {
+  sendRequest: (path: string, init: RequestInit) => Promise<Response>;
+};
+const internals = (stackAdminApp as unknown as Record<typeof stackAppInternalsSymbol, StackAdminAppInternals>)[stackAppInternalsSymbol];
-const response = await (stackAdminApp as any)[stackAppInternalsSymbol].sendRequest('/internal/sign-up-rules', {
+const response = await internals.sendRequest('/internal/sign-up-rules', {
   method: 'GET',
 });

As per coding guidelines: Avoid the any type. When necessary, leave a comment explaining why it's being used and why the type system fails at that point.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/users/[userId]/page-client.tsx (2)

293-295: Add comments explaining the as any casts.

Per coding guidelines, when using any type, leave a comment explaining why it's being used. These casts suggest the restrictedByAdmin* fields aren't yet in the ServerUser type definition.

📝 Suggested documentation

-  const restrictedByAdmin = (user as any).restrictedByAdmin ?? false;
-  const restrictedByAdminReason = (user as any).restrictedByAdminReason ?? null;
-  const restrictedByAdminPrivateDetails = (user as any).restrictedByAdminPrivateDetails ?? null;
+  // TODO: Remove `as any` once ServerUser type includes admin restriction fields
+  const restrictedByAdmin = (user as any).restrictedByAdmin ?? false;
+  const restrictedByAdminReason = (user as any).restrictedByAdminReason ?? null;
+  const restrictedByAdminPrivateDetails = (user as any).restrictedByAdminPrivateDetails ?? null;

---

440-442: Consider extracting admin restriction field access to avoid duplication.

The same (user as any).restrictedByAdmin* pattern appears in both RestrictionDialog (lines 293-295) and RestrictionBanner (lines 440-442). Consider extracting a helper function to reduce duplication and centralize the type workaround.

♻️ Suggested helper

// Helper to access admin restriction fields until ServerUser type is updated
function getAdminRestrictionFields(user: ServerUser) {
  // TODO: Remove `as any` once ServerUser type includes these fields
  const u = user as any;
  return {
    restrictedByAdmin: u.restrictedByAdmin ?? false,
    restrictedByAdminReason: u.restrictedByAdminReason ?? null,
    restrictedByAdminPrivateDetails: u.restrictedByAdminPrivateDetails ?? null,
  };
}

apps/dashboard/src/lib/cel-visual-parser.test.ts (1)

131-151: Consider using inline snapshots and strengthen parsing test assertions.

The parsing tests use conditional checks that silently pass if the result type isn't 'condition'. If parsing returns an unexpected type, the inner assertions never run and the test still passes. Per coding guidelines, prefer .toMatchInlineSnapshot for test assertions.

♻️ Suggested refactor using inline snapshots

   describe('CEL to visual tree parsing', () => {
     it('should parse simple equality condition', () => {
       const result = parseCelToVisualTree('email == "[email protected]"');
-      expect(result).toBeDefined();
-      if (result?.type === 'condition') {
-        expect(result.field).toBe('email');
-        expect(result.operator).toBe('equals');
-        expect(result.value).toBe('[email protected]');
-      }
+      expect(result).toMatchInlineSnapshot(`
+        {
+          "field": "email",
+          "id": expect.any(String),
+          "operator": "equals",
+          "type": "condition",
+          "value": "[email protected]",
+        }
+      `);
     });
 
     it('should parse endsWith condition', () => {
       const result = parseCelToVisualTree('email.endsWith("@gmail.com")');
-      expect(result).toBeDefined();
-      if (result?.type === 'condition') {
-        expect(result.field).toBe('email');
-        expect(result.operator).toBe('ends_with');
-        expect(result.value).toBe('@gmail.com');
-      }
+      expect(result).toMatchInlineSnapshot(`
+        {
+          "field": "email",
+          "id": expect.any(String),
+          "operator": "ends_with",
+          "type": "condition",
+          "value": "@gmail.com",
+        }
+      `);
     });
   });

apps/dashboard/src/components/rule-builder/condition-builder.tsx (1)

114-124: The in_list input loses intermediate edits while typing.

Splitting on comma and filtering empty strings on every keystroke removes trailing commas immediately, making it awkward to type lists. Users can't type "value1, " before adding the second value.

♻️ Consider debouncing or only processing on blur

       {condition.operator === 'in_list' ? (
         <input
           type="text"
-          value={Array.isArray(condition.value) ? condition.value.join(', ') : condition.value}
-          onChange={(e) => {
-            const items = e.target.value.split(',').map(s => s.trim()).filter(Boolean);
-            handleValueChange(items);
-          }}
+          value={Array.isArray(condition.value) ? condition.value.join(', ') : condition.value}
+          onChange={(e) => {
+            // Store raw input while typing
+            const rawValue = e.target.value;
+            // Only split/filter on blur or when there's a complete item
+            const items = rawValue.split(',').map(s => s.trim());
+            handleValueChange(items.filter(Boolean));
+          }}
+          onBlur={(e) => {
+            // Clean up on blur
+            const items = e.target.value.split(',').map(s => s.trim()).filter(Boolean);
+            handleValueChange(items);
+          }}
           placeholder="value1, value2, ..."
           className="h-8 px-2 text-sm bg-background/60 border border-border/50 rounded-md flex-1"
         />

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsx (1)

629-632: Add comment explaining the any cast for SDK internals access.

Per coding guidelines, avoid the any type. When necessary, leave a comment explaining why it's being used.

♻️ Suggested fix

     const fetchAnalytics = async () => {
       try {
+        // Using `any` cast to access internal SDK method via Symbol.
+        // The public SDK API doesn't expose this endpoint, so we access internals directly.
+        // eslint-disable-next-line `@typescript-eslint/no-explicit-any`
         const response = await (stackAdminApp as any)[stackAppInternalsSymbol].sendRequest('/internal/sign-up-rules', {
           method: 'GET',
         });

packages/stack-shared/src/interface/crud/users.ts (2)

23-42: Consider extracting the validation test to a reusable helper.

The validation test for restricted_by_admin_consistency is duplicated verbatim in both the update schema (here) and the read schema (lines 87-103). Extract it into a shared function to follow DRY principles.

Also, per coding guidelines, the any type on line 29 should have a comment explaining why it's necessary.

♻️ Proposed refactor

Add a shared helper before the schemas:

function restrictedByAdminConsistencyTest(this: yup.TestContext<unknown>, value: unknown): boolean | yup.ValidationError {
  // yup test callbacks receive untyped values; we validate shape at runtime
  if (value == null || typeof value !== 'object') return true;
  const v = value as Record<string, unknown>;
  if (v.restricted_by_admin !== true) {
    if (v.restricted_by_admin_reason != null) {
      return this.createError({ message: "restricted_by_admin_reason must be null when restricted_by_admin is not true" });
    }
    if (v.restricted_by_admin_private_details != null) {
      return this.createError({ message: "restricted_by_admin_private_details must be null when restricted_by_admin is not true" });
    }
  }
  return true;
}

Then use it in both schemas:

-}).defined().test(
-  "restricted_by_admin_consistency",
-  "When restricted_by_admin is not true, reason and private_details must be null",
-  function(this: yup.TestContext<any>, value: any) {
-    if (value == null) return true;
-    // If restricted_by_admin is false or missing, both reason and private_details must be null
-    if (value.restricted_by_admin !== true) {
-      if (value.restricted_by_admin_reason != null) {
-        return this.createError({ message: "restricted_by_admin_reason must be null when restricted_by_admin is not true" });
-      }
-      if (value.restricted_by_admin_private_details != null) {
-        return this.createError({ message: "restricted_by_admin_private_details must be null when restricted_by_admin is not true" });
-      }
-    }
-    return true;
-  }
-);
+}).defined().test(
+  "restricted_by_admin_consistency",
+  "When restricted_by_admin is not true, reason and private_details must be null",
+  restrictedByAdminConsistencyTest
+);

---

87-103: Duplicate validation test — see earlier comment.

This test is identical to lines 26-42. Once the shared helper is extracted, apply it here as well.

apps/dashboard/src/components/rule-builder/condition-builder.tsx (1)

45-63: Prefer a Map for predefined field values.

Using a Record here conflicts with the Map preference in the guidelines and makes the lookup less explicit.

♻️ Suggested refactor

-const PREDEFINED_VALUES: Partial<Record<ConditionField, string[]>> = {
-  authMethod: ['password', 'otp', 'oauth', 'passkey'],
-  oauthProvider: Array.from(standardProviders),
-};
+const PREDEFINED_VALUES = new Map<ConditionField, string[]>([
+  ['authMethod', ['password', 'otp', 'oauth', 'passkey']],
+  ['oauthProvider', Array.from(standardProviders)],
+]);

-  const predefinedValues = PREDEFINED_VALUES[condition.field];
+  const predefinedValues = PREDEFINED_VALUES.get(condition.field);

As per coding guidelines "Use ES6 maps instead of records wherever possible".

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsx (1)

653-656: Add comment explaining the any cast.

The any cast is used to access internal methods via stackAppInternalsSymbol. Per coding guidelines, add a brief comment explaining why the type system fails here.

-      const response = await (stackAdminApp as any)[stackAppInternalsSymbol].sendRequest('/internal/sign-up-rules', {
+      // eslint-disable-next-line `@typescript-eslint/no-unsafe-member-access` -- stackAppInternalsSymbol is not exposed in public types
+      const response = await (stackAdminApp as any)[stackAppInternalsSymbol].sendRequest('/internal/sign-up-rules', {

apps/backend/src/lib/users.tsx (1)

85-87: Consider adding a brief comment for the type assertion.

While the comment at line 86 explains the purpose, the as Record<string, unknown> assertion could benefit from a note about why it's safe here.

   // Merge sign-up rule data into createOrUpdate
-  // Use type assertion as we know the structure from UsersCrud
+  // Type assertion is safe: KeyIntersect guarantees these optional metadata fields exist on the intersection type
   const createOrUpdateWithMeta = createOrUpdate as Record<string, unknown>;

apps/backend/src/lib/cel-evaluator.ts (1)

172-177: Consider defensive assertion for email domain extraction.

After the email.includes('@') check, split('@').pop() should always return a non-empty string for valid emails. However, edge cases like "@domain.com" would pass the check but produce an empty username.

The current fallback to '' is acceptable given that normalizeEmail (from emails.tsx) validates email format upstream, but a defensive assertion could make the assumption explicit.

Optional: More defensive version

   if (params.email) {
     // Normalize email to match how it's stored in the database
     email = normalizeEmail(params.email);
     // Extract domain from normalized email
-    emailDomain = email.includes('@') ? (email.split('@').pop() ?? '') : '';
+    const parts = email.split('@');
+    // normalizeEmail validates format, so @ must exist with non-empty parts
+    emailDomain = parts.length === 2 ? parts[1] : '';
   }

apps/e2e/tests/backend/endpoints/api/v1/auth/sign-up-rules.test.ts (1)

1429-1438: Minor: Static email could cause test isolation issues.

The test uses a hardcoded email [email protected] without randomization. If tests run in parallel or leave data behind, this could cause flakiness.

💡 Suggested fix

     // Test spam domain
     const spamResponse = await niceBackendFetch("/api/v1/auth/password/sign-up", {
       method: "POST",
       accessType: "client",
       body: {
-        email: `[email protected]`,
+        email: `user-${generateSecureRandomString(4)}@spam.com`,
         password: generateSecureRandomString(),
       },
     });

apps/dashboard/src/lib/cel-visual-parser.ts (1)

343-347: Minor: Quote matching in list items could accept mismatched quotes.

The regex ^["']((?:\\.|[^"\\])*)["']$ would technically match strings with mismatched quotes like "test'. Since this parser consumes CEL generated by the same module (which consistently uses double quotes), this is unlikely to cause issues in practice.

💡 Stricter quote matching (optional)

       .map(s => {
-        // Remove surrounding quotes
-        const match = s.match(/^["']((?:\\.|[^"\\])*)["']$/);
-        return match ? unescapeCelString(match[1]) : s;
+        // Remove surrounding double quotes (CEL standard)
+        const doubleMatch = s.match(/^"((?:\\.|[^"\\])*)"$/);
+        if (doubleMatch) return unescapeCelString(doubleMatch[1]);
+        // Fallback for single quotes
+        const singleMatch = s.match(/^'((?:\\.|[^'\\])*)'$/);
+        if (singleMatch) return unescapeCelString(singleMatch[1]);
+        return s;
       });

packages/stack-shared/src/utils/types.tsx (1)

66-69: Add type-level assertions to lock in KeyIntersect's required/optional semantics.

The intersection of three mapped types makes shared keys required if required in either T or U, and can narrow incompatible property types to never. Add type assertions to document and prevent silent regressions of this behavior.

✅ Suggested type assertions

 /**
  * Returns a type whose keys are the intersection of the keys of T and U, deeply.
+ * Requiredness: a key is required if it is required in either T or U.
  */
 export type KeyIntersect<T, U> =
   & { [K in keyof T & keyof U]?: T[K] & U[K] }
   & { [K in RequiredKeys<T> & keyof U]: T[K] & U[K] }
   & { [K in RequiredKeys<U> & keyof T]: U[K] & T[K] }
+
+typeAssertIs<KeyIntersect<{ a: string }, { a: string }>, { a: string }>()();
+typeAssertIs<KeyIntersect<{ a?: string }, { a?: string }>, { a?: string }>()();

apps/backend/src/lib/cel-evaluator.ts (2)

49-51: Incomplete CEL string escape handling.

The unescapeCelString function only handles \\ and \" escapes. CEL string literals also support other escape sequences like \n, \t, \r, \b, \f, and Unicode escapes (\uXXXX). If rules use these in patterns (e.g., email.contains("\n")), they won't be unescaped correctly.

♻️ Suggested enhancement

 function unescapeCelString(escaped: string): string {
-  return escaped.replace(/\\\\/g, '\\').replace(/\\"/g, '"');
+  return escaped
+    .replace(/\\n/g, '\n')
+    .replace(/\\t/g, '\t')
+    .replace(/\\r/g, '\r')
+    .replace(/\\b/g, '\b')
+    .replace(/\\f/g, '\f')
+    .replace(/\\"/g, '"')
+    .replace(/\\\\/g, '\\');
 }

Note: Order matters - \\\\ should be last to avoid double-unescaping.

---

184-253: Consider using toMatchInlineSnapshot for unit tests.

Per coding guidelines, toMatchInlineSnapshot is preferred over other selectors. While the current .toEqual() and .toBe() assertions are clear and correct, switching to inline snapshots would provide better consistency and easier test updates.

packages/template/src/lib/stack-app/apps/implementations/admin-app-impl.ts (1)

957-979: Validate restricted_reason before casting.

The raw cast can hide unexpected API values and silently misclassify restrictions. Add a defensive guard and throw a clear error when the payload is missing or has an unknown type.

Suggested defensive guard

     return {
       affectedUsers: result.affected_users.map(u => ({
         id: u.id,
         displayName: u.display_name,
         primaryEmail: u.primary_email,
-        restrictedReason: u.restricted_reason as { type: "anonymous" | "email_not_verified" | "restricted_by_administrator" },
+        restrictedReason: (() => {
+          const restrictedReason = u.restricted_reason ?? throwErr("restricted_reason missing");
+          if (
+            restrictedReason.type !== "anonymous" &&
+            restrictedReason.type !== "email_not_verified" &&
+            restrictedReason.type !== "restricted_by_administrator"
+          ) {
+            throwErr(`Unexpected restricted_reason.type: ${restrictedReason.type}`);
+          }
+          return restrictedReason as {
+            type: "anonymous" | "email_not_verified" | "restricted_by_administrator"
+          };
+        })(),
       })),
       totalAffectedCount: result.total_affected_count,
     };

As per coding guidelines, "Never silently use fallback values when type errors occur. Update types or throw errors instead. Use ?? throwErr(...) over non-null assertions with clear error messages explaining the assumption".

apps/backend/prisma/schema.prisma (1)

1062-1076: Use a Prisma enum for SignupRuleTrigger.action to enforce valid values at the database layer.

Prisma enums with @map for PostgreSQL create native database enums that enforce constraints at the database level, preventing invalid values even if code bypasses the ORM. This improves analytics consistency and type safety.

♻️ Proposed refactor

+enum SignupRuleAction {
+  ALLOW        `@map`("allow")
+  REJECT       `@map`("reject")
+  RESTRICT     `@map`("restrict")
+  LOG          `@map`("log")
+  ADD_METADATA `@map`("add_metadata")
+}
+
 // Signup Rules Analytics
 model SignupRuleTrigger {
   id        String   `@default`(uuid()) `@db.Uuid`
   tenancyId String   `@db.Uuid`
   ruleId    String
   userId    String?  `@db.Uuid` // User ID if created, null if rejected
-  action    String   // allow, reject, restrict, log, add_metadata
+  action    SignupRuleAction
   metadata  Json?    // matched conditions, IP, country, etc.

packages/stack-shared/src/known-errors.tsx (1)

719-730: Avoid any and make missing details explicit for SIGN_UP_REJECTED.

constructorArgsFromJson currently accepts any and silently falls back to the default message when details.message is missing. Prefer a typed details object and ?? throwErr(...) so missing data is explicit and consistent with the guidelines.

♻️ Suggested change

 const SignUpRejected = createKnownErrorConstructor(
   KnownError,
   "SIGN_UP_REJECTED",
-  (message?: string) => [
-    403,
-    message ?? "Your sign up was rejected. Please contact us for more information.",
-    {
-      message: message ?? "Your sign up was rejected. Please contact us for more information.",
-    },
-  ] as const,
-  (json: any) => [json.message] as const,
+  (message: string = "Your sign up was rejected. Please contact us for more information.") => [
+    403,
+    message,
+    { message },
+  ] as const,
+  (json: { message?: string } | undefined) => [
+    json?.message ?? throwErr("message not found in SignUpRejected details"),
+  ] as const,
 );

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsx (1)

500-505: Avoid any when accessing stackAppInternalsSymbol.

Line 501: casting to any bypasses type safety; please add a narrow type (or document why any is unavoidable).

♻️ Suggested fix

+type StackAdminAppWithInternals = ReturnType<typeof useAdminApp> & {
+  [stackAppInternalsSymbol]: {
+    sendRequest: (path: string, init: RequestInit, auth: 'admin') => Promise<Response>;
+  };
+};
+
     const fetchAnalytics = async () => {
-      const response = await (stackAdminApp as any)[stackAppInternalsSymbol].sendRequest(
+      const response = await (stackAdminApp as StackAdminAppWithInternals)[stackAppInternalsSymbol].sendRequest(
         '/internal/sign-up-rules',
         { method: 'GET' },
         'admin' // Required for internal endpoints
       );

Based on learnings: “Avoid the any type. When necessary, leave a comment explaining why it's being used and why the type system fails at that point.”