Debug production type and range errors

.cursor/rules/README.md

@@ -0,0 +1,16 @@
+# Cursor Rules for QDrill Project
+
+This directory contains project-specific rules for AI assistants working on the QDrill codebase.
+
+## Rules Files
+
+- `development.mdc` - Core development commands and workflows
+
+## Key Points to Remember
+
+1. **ALWAYS use `vercel dev`** for development server (NOT pnpm run dev)
+2. Use `pnpm` for package management (NOT npm)
+3. Use `vercel build` for production builds
+4. Use `psql "$NEON_DB_URL"` for database queries
+
+These rules help ensure consistent development practices across all AI assistant sessions.

.cursor/rules/development.mdc

@@ -0,0 +1,33 @@
+---
+description:
+globs:
+alwaysApply: true
+---
+# Development Rules for QDrill Project
+
+## IMPORTANT: Development Server
+**ALWAYS use `vercel dev` to run the development server**
+- DO NOT use `pnpm run dev`
+- DO NOT use `npm run dev`
+- The correct command is: `vercel dev`
+
+## Package Management
+This project uses pnpm. Always use pnpm commands:
+- `pnpm install` (not npm install)
+- `pnpm add <package>` (not npm install <package>)
+- `pnpm remove <package>` (not npm uninstall)
+
+## Build Commands
+- For development server: `vercel dev`
+- For production build verification: `vercel build`
+- DO NOT use `pnpm run build` for verification
+
+## Database Access
+When examining data, use: `psql "$NEON_DB_URL"`
+
+## Summary of Key Commands
+- Start dev server: `vercel dev`
+- Install dependencies: `pnpm install`
+- Add package: `pnpm add <package>`
+- Build for production: `vercel build`
+- Check database: `psql "$NEON_DB_URL"`

.cursorignore

@@ -0,0 +1 @@
+# Add directories or file patterns to ignore during indexing (e.g. foo/ or *.csv)

.eslintrc.cjs

@@ -1,14 +1,45 @@
 module.exports = {
 	root: true,
-	extends: ['eslint:recommended', 'plugin:svelte/recommended', 'prettier'],
+	extends: [
+		'eslint:recommended',
+		'plugin:svelte/recommended',
+		'plugin:cypress/recommended',
+		'prettier'
+	],
+	plugins: ['vitest-globals'],
 	parserOptions: {
+		parser: '@typescript-eslint/parser',
 		sourceType: 'module',
-		ecmaVersion: 2020,
+		ecmaVersion: 2022,
 		extraFileExtensions: ['.svelte']
 	},
 	env: {
 		browser: true,
 		es2017: true,
-		node: true
-	}
+		node: true,
+		'cypress/globals': true
+	},
+	overrides: [
+		{
+			files: ['*.js'],
+			parser: '@typescript-eslint/parser',
+			parserOptions: {
+				ecmaVersion: 2022,
+				sourceType: 'module'
+			}
+		},
+		{
+			files: ['**/__tests__/**/*.js', '**/__mocks__/**/*.js'],
+			extends: ['plugin:vitest-globals/recommended']
+		},
+		{
+			files: ['.svelte'],
+			parser: 'svelte-eslint-parser',
+			parserOptions: {
+				parser: '@typescript-eslint/parser',
+				ecmaVersion: 2022,
+				sourceType: 'module'
+			}
+		}
+	]
 };

.gitignore

@@ -3,10 +3,23 @@ node_modules
 /build
 /.svelte-kit
 /package
+venv
+app/__pycache__
+*.pyc
 .env
 .env.*
 !.env.example
 .vercel
 .output
 vite.config.js.timestamp-*
 vite.config.ts.timestamp-*
+.env*.local
+/coverage
+.nyc_output
+tests/__pycache__
+tests/_pycache
+cypress/downloads
+cypress/screenshots
+
+# Sentry Config File
+.env.sentry-build-plugin

.prettierrc

@@ -4,6 +4,5 @@
 	"trailingComma": "none",
 	"printWidth": 100,
 	"plugins": ["prettier-plugin-svelte"],
-	"pluginSearchDirs": ["."],
 	"overrides": [{ "files": "*.svelte", "options": { "parser": "svelte" } }]
 }

.vscode/settings.json

@@ -0,0 +1,13 @@
+{
+	"svelte.plugin.svelte.diagnostics.a11y": false,
+	"svelte.plugin.svelte.compilerWarnings": {
+		"a11y-click-events-have-key-events": "ignore",
+		"a11y-missing-attribute": "ignore",
+		"a11y-missing-content": "ignore",
+		"a11y-invalid-attribute": "ignore",
+		"a11y-label-has-associated-control": "ignore",
+		"a11y-no-static-element-interactions": "ignore",
+		"a11y-img-redundant-alt": "ignore",
+		"a11y-no-noninteractive-element-interactions": "ignore"
+	}
+}

CLAUDE.md

@@ -0,0 +1,220 @@
+# QDrill Project Guide
+
+## Project Overview
+
+QDrill is a web-based application designed as a sports drill bank and practice planning tool for a niche sport. It allows users to create, manage, and share drills, as well as plan practices with timeline-based organization.
+
+## Technology Stack
+
+- **Frontend**: SvelteKit
+- **Backend**: SvelteKit (API routes)
+- **Database**: PostgreSQL (via Vercel Postgres)
+- **Styling**: Tailwind CSS
+- **Authentication**: Auth.js (Google OAuth)
+- **Deployment**: Vercel
+- **Diagramming**: Excalidraw
+- **Testing**: Playwright, Cypress
+
+## Core Features
+
+### Drill Management
+
+- Create, edit, view, and search drills
+- Tag drills with skill level, positions, duration
+- Upload diagrams/images for drills
+- Upvote/downvote and comment on drills
+- Create variations of existing drills
+
+### Practice Plan Creation
+
+- Wizard-based practice plan creation
+- Section organization with parallel timelines
+- Drag-and-drop editing interface
+- Duration tracking and management
+- Timeline visualization
+- Share and duplicate practice plans
+
+### User System
+
+- Google OAuth authentication
+- User profiles
+- Permission-based access control
+- Personal drill/plan management
+
+## Development Commands
+
+- `vercel dev` - Start development server
+- `pnpm run check` - Check TypeScript + SvelteKit sync
+
+## Package Management
+
+- `pnpm install` - Install dependencies
+- `pnpm add <package>` - Add a package
+
+## Testing
+
+- `pnpm run test` - Run Playwright tests
+- `pnpm test -- tests/test.js` - Run a specific test
+- `pnpm run test:unit` - Run Vitest unit tests in watch mode
+- `pnpm run test:unit:run` - Run Vitest unit tests once
+- `pnpm run test:unit:coverage` - Run Vitest unit tests with coverage
+- `pnpm run test:unit --run <file-path>` - Run specific Vitest tests once (e.g., `pnpm run test:unit --run src/lib/stores/__tests__/dragManager.test.js`)
+
+## Code Quality
+
+- `pnpm run lint` - Run linting checks
+- `pnpm run format` - Fix formatting issues
+
+## Deployment
+
+- Automatic deployment from GitHub main branch to Vercel
+
+## Architecture
+
+### Frontend Components
+
+- Svelte components organized by feature area
+- Modular design with reusable components
+- Tailwind CSS for styling with custom components
+- Interactive drag-and-drop interface for practice planning
+
+### State Management
+
+- Extensive use of Svelte stores
+- Separate stores for different domain concerns
+- Custom store implementation with methods
+- History tracking with undo/redo support
+
+### API Design
+
+- RESTful API endpoints
+- SvelteKit server endpoints (+server.js)
+- Standardized response formats
+- Parameterized database queries
+
+### Database
+
+- PostgreSQL with connection pooling
+- Transaction support for complex operations
+- Normalized schema design
+
+#### Database Connection
+
+- **Connection String**: Stored in ~/.zshrc as NEON_DB_URL environment variable
+- **Connection Command**: `psql "$NEON_DB_URL"`
+- **Project ID**: morning-mountain-82887088
+- **Database Name**: verceldb
+- **Tables**: drills, practice_plans, practice_plan_sections, practice_plan_drills, users, comments, votes, etc.
+- **Query Example**: `psql "$NEON_DB_URL" -c "SELECT COUNT(*) FROM drills;"`
+
+## Key Systems
+
+### Authentication
+
+- Auth.js (formerly NextAuth) integration
+- Google OAuth provider
+- Session-based authentication
+- Authorization middleware
+
+### Drag and Drop
+
+- Complex drag-and-drop system for practice plan editing
+- State management via Svelte stores
+- Multiple drop targets and interactions
+- Timeline-based organization
+- Visual feedback during drag operations
+
+### Data Filtering
+
+- Client-side filtering for drills
+- Multi-criteria filtering
+- Performance optimization for large datasets
+
+## Code Style Guidelines
+
+- **AI-Readability**: Add clear comments to make code easily understood by future AI systems
+- **Comments**: Include purpose explanations, input/output expectations, and logic clarifications
+- **Imports**: Group imports by source (svelte, lib, components)
+- **Components**: Use Svelte components with script/markup/style structure
+- **Stores**: Use reactive declarations with $ prefix for store values
+- **Error Handling**: Use try/catch with specific error messages
+- **API Endpoints**: Return standardized JSON responses with proper status codes
+- **Database**: Use parameterized queries to prevent SQL injection
+- **Naming**: Use descriptive camelCase for variables/functions, PascalCase for components
+
+## Areas for Improvement
+
+### 1. Drag and Drop System Consolidation
+
+**Impact: High**
+
+- Currently has two parallel drag-and-drop systems
+- Consolidate into a single system with consistent interface
+- Implement proper state machine for drag operations
+- Reduce code complexity and maintenance burden
+
+### 2. API Data Fetching Abstraction
+
+**Impact: High**
+
+- Direct fetch calls scattered throughout components
+- Create unified API client with standard methods
+- Implement consistent error handling and retry logic
+- Add caching and performance optimizations
+
+### 3. Test Coverage Expansion
+
+**Impact: High**
+
+- Minimal testing despite complex UI interactions
+- Add unit tests for store logic (especially drag-and-drop)
+- Implement integration tests for key user flows
+- Set up CI pipeline with automated testing
+
+### 4. Store Logic Separation
+
+**Impact: Medium**
+
+- Store files mix different concerns (data, filtering, etc.)
+- Separate into dedicated modules with single responsibilities
+- Move complex logic into utility functions
+- Improve maintainability and testability
+
+### 5. Performance Optimization
+
+**Impact: Medium**
+
+- Filtering/sorting recalculates on every store update
+- Implement memoization for expensive calculations
+- Use web workers for heavy operations
+- Optimize filter chains and add virtualization
+
+## Documentation Workflow
+
+- After completing any significant task, ALWAYS follow this documentation workflow:
+
+1. First examine `/docs/index.md` to understand the documentation structure
+2. Then navigate to the appropriate subdirectory based on the nature of your changes:
+   - `/docs/architecture/` for architectural changes or patterns
+   - `/docs/implementation/` for implementation details and technical references
+3. Update existing documentation files or create new ones as needed
+4. Update index files to reference any new documentation
+
+## Documentation Requirements
+
+- Create/update documentation when modifying .js/.svelte files
+- Document component descriptions, usage instructions, and relationships
+- Maintain documentation consistency for directory structure
+- Consider component interdependencies when making changes
+- Follow best practices for Svelte documentation
+- Add implementation notes to `/docs/implementation/` for technical patterns
+- **README Updates**: Always update the README.md file after completing substantial code edits to reflect the latest changes, features, and usage instructions
+
+## Version Control Guidelines
+
+- **Commit Message Standards**: Write clear, descriptive commit messages explaining what changes were made and why
+- **Atomic Commits**: Keep commits focused on a single logical change
+- **Pull Request Format**: Include clear descriptions of changes, impact, and testing performed
+- **Code Reviews**: Request code reviews for substantial changes
+- **No Automatic Commits**: Never commit changes without explicitly being asked to do so
+- **Testing Before Commit**: Always run relevant tests before creating a commit