.cursorrules

# Patient Listing Application
 
Every time you choose to apply a rule(s), explicitly state the rule(s) in the output. You can abbreviate the rule description to a single word or phrase.

## Instructions about dependencies and libraries 

The project already contains all starter dependencies of svelte, tailwindcss, and typescript. So there is no need to reinitialize the app from scratch. Only install new libraries and dependencies required as part of the added code. 

## Project Context

A SvelteKit-based patient listing application that integrates with HAPI FHIR server.

- Manages and displays patient records
- Interfaces with HAPI FHIR for healthcare data
- Provides a modern, responsive UI for healthcare professionals

## Code Style and Structure

- Write concise, technical TypeScript code with accurate examples
- Use functional and declarative programming patterns
- Prefer iteration and modularization over code duplication
- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError)
- Structure repository files as follows:

```
src/
├── lib/            # Shared components and utilities
│   ├── components/ # Reusable Svelte components
│   ├── server/     # Server-only code
│   ├── types/      # TypeScript types
│   ├── utils/      # Helper functions
│   └── fhir/       # FHIR related utilities
├── routes/         # SvelteKit routes (+page.svelte, +server.ts)
├── params/         # SvelteKit parameter matchers
├── hooks.server.ts # Server hooks
└── app.html        # App template

static/            # Static assets
tests/             # Test files
```

## Tech Stack

- SvelteKit
- TypeScript
- Tailwind CSS
- HAPI FHIR
- Docker
- PostgreSQL

## Naming Conventions

- Use lowercase with dashes for directories (e.g., components/patient-card)
- Use PascalCase for component files (e.g., PatientList.svelte)
- Use camelCase for utility files (e.g., fhirUtils.ts)
- Use +page.svelte for route pages
- Use +server.ts for API endpoints

## TypeScript Usage

- Use TypeScript for all code; prefer interfaces over types
- Avoid enums; use const objects with 'as const' assertion
- Use proper FHIR resource types from @types/fhir
- Use $lib alias for imports from lib directory
- Avoid try/catch blocks unless there's good reason to translate or handle error
- Use explicit return types for all functions
- Implement proper type safety for form data

## SvelteKit Specific

- Use proper load functions (+page.server.ts)
- Implement form actions appropriately
- Handle server-side rendering properly
- Use proper error pages (+error.svelte)
- Implement proper client-side navigation
- Use proper environment variables ($env/static/private)

## State Management

- Use Svelte stores for global state
- Implement proper reactive statements
- Use proper lifecycle methods
- Handle subscription cleanup properly

## Syntax and Formatting

- Use "export function" for pure functions
- Follow Svelte component structure (script, style, markup)
- Use reactive declarations ($:) appropriately
- Use proper event dispatching
- Implement TypeScript discriminated unions where needed

## UI and Styling

- Use Tailwind CSS for styling
- Implement responsive design patterns
- Follow healthcare UI/UX best practices
- Consider accessibility requirements
- Use proper loading states
- Implement proper error states

## FHIR Integration

- Use proper FHIR resource types
- Implement proper FHIR search parameters
- Handle FHIR versioning appropriately
- Implement proper FHIR validation
- Use proper FHIR operations

## Error Handling

- Implement proper error pages
- Log errors appropriately for debugging
- Provide user-friendly error messages
- Handle network failures gracefully
- Implement proper validation errors

## Testing

- Write unit tests for utilities and components
- Implement integration tests for FHIR operations
- Test across different browsers
- Test performance and loading states
- Implement proper mock data for tests

## Security

- Validate user inputs depending on the type of input fields

## Git Usage

Commit Message Prefixes:

- "fix:" for bug fixes
- "feat:" for new features
- "perf:" for performance improvements
- "docs:" for documentation changes
- "style:" for formatting changes
- "refactor:" for code refactoring
- "test:" for adding missing tests
- "chore:" for maintenance tasks

Rules:

- Use lowercase for commit messages
- Keep the summary line concise
- Include description for non-obvious changes
- Reference issue numbers when applicable

## Documentation

- Maintain clear README with setup instructions
- Document FHIR interactions and data flows
- Document environment variables
- Don't include comments unless it's for complex logic
- Document HAPI FHIR configuration

## Development Workflow

- Use proper version control
- Implement proper code review process
- Test in multiple environments
- Follow semantic versioning for releases
- Maintain changelog
- Use proper Docker development workflow