• 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 == "test@example.com"');
-      expect(result).toBeDefined();
-      if (result?.type === 'condition') {
-        expect(result.field).toBe('email');
-        expect(result.operator).toBe('equals');
-        expect(result.value).toBe('test@example.com');
-      }
+      expect(result).toMatchInlineSnapshot(`
+        {
+          "field": "email",
+          "id": expect.any(String),
+          "operator": "equals",
+          "type": "condition",
+          "value": "test@example.com",
+        }
+      `);
     });
 
     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/dashboard/src/app/(main)/(protected)/projects/[projectId]/sign-up-rules/page-client.tsx (1)

508-513: Avoid as any when accessing internals.
Please add a narrow type (or at least a short rationale comment) instead of as any to keep type safety intact.

♻️ Possible typing

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

Based on learnings: Applies to **/*.{ts,tsx} : 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 (1)

292-294: Add comments explaining as any type casts.

Multiple as any casts are used to access restrictedByAdmin fields (here and at lines 317, 333, 440-442). Per coding guidelines, when using any is necessary, leave a comment explaining why the type system fails at that point.

♻️ Proposed fix: Add explanatory comment

+  // Type assertion needed: restrictedByAdmin fields are not yet exposed on ServerUser type
+  // TODO: Update ServerUser type definition to include these fields
   const restrictedByAdmin = (user as any).restrictedByAdmin ?? false;
   const restrictedByAdminReason = (user as any).restrictedByAdminReason ?? null;
   const restrictedByAdminPrivateDetails = (user as any).restrictedByAdminPrivateDetails ?? null;

Based on 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/e2e/tests/backend/endpoints/api/v1/restricted-users.test.ts (1)

320-321: Avoid any in list item mapping.
Use a typed helper (e.g., { id: string }) or a narrow cast for listResponse.body.items so the tests stay type-safe.

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.

Also applies to: 361-362, 392-392, 429-430, 495-496, 542-543

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

719-730: Type SignUpRejected details instead of any.
A narrow { message?: string } keeps deserialization typed without changing behavior.

♻️ Suggested fix

-  (json: any) => [json.message] as const,
+  (json: { message?: string }) => [json.message] as const,

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.

Also applies to: 1812-1812

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

159-169: Empty string filtering may produce unexpected results for in_list.

When the user types just whitespace or commas (e.g., , , ,), the .filter(Boolean) removes all empty strings, resulting in an empty array []. However, if the user intentionally clears the input (backspaces everything), the value becomes [] immediately. This is fine, but the UX feedback could be confusing since typing "a, " then deleting "a" leaves [] while typing ", " also leaves [].

More importantly, if a user types a single space, split(',') returns [''] → map(trim) returns [''] → filter(Boolean) returns []. This is correct behavior, but consider whether you want to preserve user input display (e.g., show what they typed) separately from the parsed value.

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

61-67: Consider simplifying the conditional spread syntax.

The !!ruleResult.restrictedBecauseOfSignUpRuleId with spread is functional but could be clearer.

♻️ Suggested simplification

   const enrichedCreateOrUpdate = {
     ...createOrUpdate,
-    ...!!ruleResult.restrictedBecauseOfSignUpRuleId ? {
+    ...(ruleResult.restrictedBecauseOfSignUpRuleId ? {
       restricted_by_admin: true,
       restricted_by_admin_private_details: existingRestrictionPrivateDetails ? `${existingRestrictionPrivateDetails}\n\n${restrictionPrivateDetails}` : restrictionPrivateDetails,
-    } : {},
+    } : {}),
   };

The !! is unnecessary since the ternary already handles truthiness, and adding parentheses improves readability.

---

70-75: Type assertion after enrichment may mask type errors.

The as KeyIntersect<...> assertion on line 73 bypasses TypeScript's ability to verify that enrichedCreateOrUpdate actually matches the expected type. If the enrichment adds fields not in the original type, this could hide issues.

Consider whether the type could be adjusted upstream to accept the restriction fields, avoiding the need for the assertion.

apps/backend/src/app/api/latest/users/crud.tsx (1)

638-643: Consider extracting shared validation logic.

The admin restriction validation logic in onCreate (lines 619-626) and onUpdate (lines 1113-1124) is similar but not identical. The onUpdate version is more sophisticated (handles effective state). Consider extracting a helper function to ensure consistency and reduce duplication.

♻️ Suggested refactor

function validateRestrictedByAdminFields(
  restrictedByAdmin: boolean,
  reason: string | null | undefined,
  privateDetails: string | null | undefined,
): void {
  if (!restrictedByAdmin) {
    if (reason != null) {
      throw new StatusError(StatusError.BadRequest, "restricted_by_admin_reason requires restricted_by_admin=true");
    }
    if (privateDetails != null) {
      throw new StatusError(StatusError.BadRequest, "restricted_by_admin_private_details requires restricted_by_admin=true");
    }
  }
}

Then use in both onCreate and onUpdate (computing effective values as needed).