cfreshman gauntlet-starter .cursorrules file for TypeScript

# UI Text Rules
- All UI text should be lowercase, except for proper nouns (names, brands, etc.)
- Text should be concise and direct
- Remove unnecessary words and verbosity
- Use consistent terminology across components
- Remove explanatory text when the UI is self-explanatory
- Keep error messages short and clear (e.g., "invalid credentials")

# Examples
✅ "sign in" instead of "Sign In" or "Login"
✅ "username" instead of "Enter your username"
✅ "invalid credentials" instead of "The username or password you entered is incorrect"
✅ "need an account?" instead of "Don't have an account? Sign up"

# Component Naming
- Keep React component names in PascalCase (e.g., Login, Button)
- Keep file names in kebab-case (e.g., sign-up.tsx)
- Keep CSS class names in kebab-case

# Spacing
- Use minimal spacing between elements (e.g., space-y-2)
- Keep forms compact (max-width: 320px)
- Use consistent padding (e.g., pt-4 for card content)
- Reduce vertical whitespace in forms
- Keep header height compact (h-12)
- Use small text (text-sm) for secondary information

# Button Rules
- Use small buttons where possible (size="sm")
- Keep button text concise
- Use ghost variant for secondary actions
- Use consistent height for header buttons (h-7) 

# Code Modification Rules
- Only make explicitly requested changes
- No unintended side effects when making changes
- Keep all working functionality intact
- Never modify code that isn't part of the requested change
- Never remove working functionality or code
- Preserve existing code behavior
- Keep working error handling
- Maintain existing security measures
- Preserve working CORS configurations

# File Structure Rules
- Keep existing file organization
- Keep existing file paths and structures
- Maintain working import/export structure
- Preserve working file relationships
- Keep existing file naming conventions
- Maintain directory hierarchy
- Keep existing file names and locations

# Configuration Rules
- Keep working environment setups
- Preserve working build processes
- Maintain deployment configurations
- Keep working cache settings
- Preserve CORS settings
- Keep working auth configurations
- Maintain database connections
- Preserve existing environment variables
- Keep working database schemas and tables
- Preserve working RLS policies
- Keep working edge function configs
- Maintain working realtime subscriptions
- Keep working edge function CORS headers
- Preserve working rate limits
- Maintain working webhook configurations
- Keep working storage bucket settings

# API & Database Rules
- Keep working API endpoints
- Preserve working database triggers
- Maintain working stored procedures
- Keep working database indexes
- Preserve working database constraints
- Keep working database roles

# Authentication Rules
- Keep working auth providers
- Preserve working auth callbacks
- Maintain working auth redirects
- Keep working auth policies
- Preserve working JWT settings

# Version Control Rules
- Keep working lock file entries
- Preserve dependency versions
- Maintain peer dependencies
- Keep working node version settings
- Preserve typescript configurations
- Keep existing gitignore patterns

# Example: What Not To Change
❌ Modifying code beyond requested changes
❌ Changing working configurations
❌ Altering existing security measures
❌ Modifying working error handling
❌ Changing working CORS settings
❌ Altering working auth flows
❌ Modifying working database connections
❌ Removing working build commands
❌ Changing working file paths
❌ Modifying working database schemas
❌ Changing working RLS policies
❌ Altering working stored procedures
❌ Modifying working auth flows
❌ Changing working realtime subscriptions
❌ Modifying working build scripts
❌ Changing working build paths
❌ Altering working CORS headers
❌ Modifying working rate limits
❌ Changing working storage settings

# Example: Acceptable Changes
✅ Making only requested modifications
✅ Adding new functionality without breaking existing code
✅ Extending configurations without breaking working ones
✅ Adding new security measures alongside existing ones
✅ Creating new files without modifying existing ones
✅ Adding new environment variables
✅ Adding new dependencies
✅ Adding new database tables
✅ Creating new stored procedures
✅ Adding new RLS policies
✅ Extending existing schemas
✅ Adding new build scripts
✅ Creating new storage buckets
✅ Adding new rate limits 

# Assistant Behavior Rules
- Only make changes explicitly requested by the user
- Never suggest "improvements" to working code
- Never try to "clean up" or "optimize" working code
- Never remove code just because it seems unused
- Never change formatting of working code
- Never modify indentation unless requested
- Never rewrite working code in a "better" way
- Never add "missing" error handling to working code
- Never add "helpful" comments to working code
- Never change variable/function names to be "clearer"

# Code Block Rules
- Always include file path when suggesting edits
- Use "// ... existing code ..." to mark unchanged sections
- Show enough context around changes for clear location
- Never rewrite entire files unless specifically requested
- Keep all working code markers and comments intact
- Use correct file paths matching project structure
- Use format: ````language:path/to/file
- Include full path from project root
- Match existing directory structure
- Keep consistent path separators

# Example: What Not To Do
❌ "This code could be improved by..."
❌ "I've cleaned up the formatting..."
❌ "I've added better error handling..."
❌ "I've made the variable names clearer..."
❌ "I've optimized this section..."
❌ Using incorrect/incomplete paths
❌ Missing file paths in codeblocks
❌ Using wrong path separators

# Example: Correct Behavior
✅ Only showing requested changes
✅ Keeping existing code markers
✅ Maintaining current formatting
✅ Preserving working code structure
✅ Including clear file paths
✅ Using full paths from root
✅ Matching project structure

# Suggestion Rules
- Suggestions should be clearly marked as optional
- Explain why each suggestion might be helpful
- Show suggestions separately from requested changes
- Never mix suggestions with direct changes
- Always preserve working code in suggestions
- Make suggestions additive, not replacements
- Provide context for each suggestion
- Let user choose which suggestions to implement

# Example: Good Suggestions
✅ "Optional improvement: Could add input validation here..."
✅ "Consider adding error logging to help with debugging..."
✅ "Might want to add a loading state for better UX..."
✅ "Could add type safety by extending the Profile interface..."

# Example: Bad Suggestions
❌ "I've improved the code by..."
❌ "This code should be changed to..."
❌ "The better way to do this is..."
❌ "I fixed the code by..." 

# Edge Function Rules
- Always check existing functions first (e.g., sign-in-with-username)
- Match existing query patterns exactly
- Use parameterized queries always
- Never interpolate values into SQL
- Keep working CORS configurations
- Maintain consistent error handling
- Follow existing security patterns
- Keep function naming consistent
- Verify data exists before use
- Check array bounds
- Deploy after every change (cd back && supabase functions deploy function-name)
- Always specify project ref when deploying (--project-ref <ref>)
- When changing data structure (e.g., array to single), update all references
- Check all usages after changing return types

# Example: What Not To Do
❌ Writing new query patterns without checking existing ones
❌ Using string interpolation in SQL
❌ Changing CORS without testing
❌ Deploying from wrong directory
❌ Breaking existing patterns
❌ Using data without checks
❌ Modifying function without deploying

# Example: Correct Steps
✅ Check sign-in-with-username first
✅ Use parameterized queries
✅ Match existing patterns
✅ Deploy after changes
✅ Test after deployment
✅ Verify security