The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
stack-auth-hosted-components	Ready	Preview, Comment	Mar 12, 2026 5:35pm
stack-backend	Ready	Preview, Comment	Mar 12, 2026 5:35pm
stack-dashboard	Ready	Preview, Comment	Mar 12, 2026 5:35pm
stack-demo	Ready	Preview, Comment	Mar 12, 2026 5:35pm
stack-docs	Ready	Preview, Comment	Mar 12, 2026 5:35pm

All committers have signed the CLA.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

@greptile-ai review

Greptile Summary

This PR extends the sign-up rules system with derived country code support and improved risk score handling. A countryCode field is added to the ProjectUser table, propagated through the CRUD layer and ServerUser SDK type, and surfaced in the sign-up rule CEL evaluation context. The dashboard rule builder gains a CountryCodeSelect combobox for countryCode conditions, and the test simulator supports country code and risk score overrides.

Key changes and observations:

• Country code derivation pipeline (users.tsx, end-users.tsx): getSpoofableEndUserLocation now returns user-controlled header data for all requests (previously null for spoofable requests). The country used in CEL evaluation is therefore always spoofable — this is acknowledged in CLAUDE-KNOWLEDGE.md as intentional but should be surfaced clearly in project documentation so admins understand geo rules provide soft filtering, not hard enforcement.

• countryCodeToPersist logic gap (users.tsx line 96): The existing-country-code preservation guard only applies when the current user is_anonymous. For non-anonymous currentUser paths (e.g. OAuth account linking), the derived country code from the current request overwrites whatever was previously stored — contrary to the field's "captured at sign-up time" semantics.

• normalizeConditionValue numeric path (cel-visual-parser.ts lines 90–103): If a countryCode condition node somehow carries a numeric value, the function returns it unchanged, causing conditionToCel to generate countryCode == 42 — a CEL expression that silently never matches instead of failing validation.

• Test simulator cannot force empty country code (sign-up-rules-test/route.tsx line 97): req.body.country_code ?? derivedCountryCode means explicitly passing null falls through to the server-derived value. There is no way to pin countryCode = "" in the test context when the server has geo headers available.

• Several issues raised in the previous review round have been addressed: StackAssertionError has been replaced with plain Error for user-input validation, the render-phase throw in condition-builder.tsx is replaced with a graceful [] fallback, empty in_list arrays now fail validation for countryCode, and CountryCodeField no longer coerces null to "".

• The test stub in getDerivedSignUpCountryCode that maps [email protected] to a country code (flagged previously) remains in production code.

Confidence Score: 3/5

• Mergeable with caution — the country-code persistence logic has a gap for non-anonymous users, and the test simulator cannot force an empty country code context.
• The core infrastructure (migration, schema, CEL evaluator, SDK type) is solid and well-tested. Three new logic issues were found not covered by previous review threads: (1) countryCodeToPersist only guards anonymous users, potentially overwriting a non-anonymous user's stored country code on subsequent auth events; (2) the test simulator cannot force countryCode = "" via explicit null due to the ?? operator; (3) a numeric countryCode value in normalizeConditionValue produces silently-invalid CEL instead of a validation error. Additionally, several items from prior review rounds remain open (test stub in production, index-based list keys, lack of API-level format validation for country_code updates).
• apps/backend/src/lib/users.tsx (countryCodeToPersist guard), apps/backend/src/app/api/latest/internal/sign-up-rules-test/route.tsx (null override semantics), apps/dashboard/src/lib/cel-visual-parser.ts (numeric countryCode path)

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Sign-up Request] --> B{signUpRuleOptions\ncountryCode !== null?}
    B -- Yes: explicit override --> C[Use provided countryCode]
    B -- No: derive --> D[getSpoofableEndUserLocation\nfrom request geo headers]
    D --> E[getDerivedSignUpCountryCode]
    E --> F{email matches\[email protected]?}
    F -- Yes --> G[Use email-embedded CC\ntest stub priority]
    F -- No --> H{requestLocation\ncountryCode valid?}
    H -- Yes --> I[Use geo-derived CC]
    H -- No --> J[countryCode = null]
    C --> K[createSignUpRuleContext\nnull → empty string]
    G --> K
    I --> K
    J --> K
    K --> L[evaluateSignUpRules\nCEL evaluation with countryCode]
    L --> M{Rule result}
    M -- Rejected --> N[throw SignUpRejected]
    M -- Allowed/Restricted --> O{currentUser is anonymous\nAND has country_code?}
    O -- Yes --> P[Preserve anonymous user's\nexisting country_code]
    O -- No --> Q[Use derived countryCode]
    P --> R[Persist to DB via adminUpdate/adminCreate]
    Q --> R

_{Last reviewed commit: 5e4da43}

@greptile-ai review

@greptile-ai review

@greptile-ai review

@greptile-ai review

@greptile-ai The risk-score stub in calculateSignUpRiskScores is intentional. This PR is focused on laying the groundwork — wiring up country-code derivation, the rule evaluation pipeline, CEL expression support, and the dashboard condition builder UI. The actual risk-scoring pipeline (bot detection, free trial abuse scoring) is being implemented in a follow-up PR that will be stacked on top of this one.

The { bot: 0, freeTrialAbuse: 0 } return for non-test users is a deliberate placeholder, not a missed implementation. The [email protected] case exists solely to validate that the rule evaluation machinery works end-to-end in tests.

Please re-review with this context in mind.