|
| 1 | +# Claude AI Assistant Rules for Temporal UI |
| 2 | + |
| 3 | +This document defines the coding standards, testing practices, and project conventions that Claude should follow when working on the Temporal UI codebase. |
| 4 | + |
| 5 | +## Project Overview |
| 6 | + |
| 7 | +This is a SvelteKit-based TypeScript application for Temporal.io's web UI. The project uses: |
| 8 | + |
| 9 | +- **Framework**: SvelteKit with Svelte 5 |
| 10 | +- **Language**: TypeScript with strict type checking |
| 11 | +- **Styling**: TailwindCSS with custom design system (Holocene) |
| 12 | +- **Testing**: Vitest for unit tests, Playwright for E2E/integration tests |
| 13 | +- **Package Manager**: pnpm |
| 14 | + |
| 15 | +## Testing Standards |
| 16 | + |
| 17 | +### Unit Tests (Vitest) |
| 18 | + |
| 19 | +- **Framework**: Vitest with jsdom environment |
| 20 | +- **File Naming**: `*.test.ts` files alongside source code |
| 21 | +- **Test Structure**: Use `describe`, `it`, `expect` pattern with BDD style |
| 22 | +- **Mocking**: Use `vi.spyOn()` for mocking, prefer `vi.mock()` for module mocks |
| 23 | +- **Setup**: Global test utilities in `vitest-setup.ts` |
| 24 | +- **Coverage**: Aim for comprehensive coverage, exclude mocks and test files |
| 25 | + |
| 26 | +**Test Commands:** |
| 27 | + |
| 28 | +```bash |
| 29 | +pnpm test # Run unit tests |
| 30 | +pnpm test:ui # Run tests with UI |
| 31 | +pnpm test:coverage # Run with coverage report |
| 32 | +``` |
| 33 | + |
| 34 | +### E2E/Integration Tests (Playwright) |
| 35 | + |
| 36 | +- **Framework**: Playwright with custom accessibility reporting |
| 37 | +- **File Naming**: `*.spec.ts` in `/tests` directory |
| 38 | +- **Structure**: Separate `e2e` and `integration` test suites |
| 39 | +- **Devices**: Test both desktop and mobile viewports |
| 40 | +- **Accessibility**: Include accessibility testing with custom violations reporter |
| 41 | + |
| 42 | +**Test Commands:** |
| 43 | + |
| 44 | +```bash |
| 45 | +pnpm test:e2e # Run E2E tests |
| 46 | +pnpm test:integration # Run integration tests |
| 47 | +``` |
| 48 | + |
| 49 | +## Linting and Formatting |
| 50 | + |
| 51 | +### ESLint Configuration |
| 52 | + |
| 53 | +- **Extends**: `eslint:recommended`, `@typescript-eslint/recommended`, `prettier` |
| 54 | +- **Plugins**: `svelte`, `@typescript-eslint`, `vitest`, `import` |
| 55 | +- **Key Rules**: |
| 56 | + - Single quotes preferred: `quotes: ['error', 'single']` |
| 57 | + - No explicit `any`: `@typescript-eslint/no-explicit-any: 'error'` |
| 58 | + - Import ordering with groups and alphabetization |
| 59 | + - Unused variables prefixed with `_` are allowed |
| 60 | + |
| 61 | +### Prettier Configuration |
| 62 | + |
| 63 | +- **Print Width**: 80 characters |
| 64 | +- **Indentation**: 2 spaces (no tabs) |
| 65 | +- **Semicolons**: Required |
| 66 | +- **Quotes**: Single quotes |
| 67 | +- **Trailing Commas**: Always |
| 68 | +- **Plugins**: `prettier-plugin-svelte`, `prettier-plugin-tailwindcss` |
| 69 | + |
| 70 | +### Stylelint Configuration |
| 71 | + |
| 72 | +- **Extends**: `stylelint-config-recommended`, `stylelint-config-standard` |
| 73 | +- **Custom Syntax**: `postcss-html` for Svelte files |
| 74 | +- **Tailwind Support**: Ignores Tailwind directives and functions |
| 75 | + |
| 76 | +**Lint Commands:** |
| 77 | + |
| 78 | +```bash |
| 79 | +pnpm lint # Run all linters |
| 80 | +pnpm format # Auto-fix all formatting |
| 81 | +pnpm eslint:fix # Fix ESLint issues |
| 82 | +pnpm prettier:fix # Fix Prettier formatting |
| 83 | +pnpm stylelint:fix # Fix Stylelint issues |
| 84 | +``` |
| 85 | + |
| 86 | +## Code Style and Conventions |
| 87 | + |
| 88 | +### TypeScript Standards |
| 89 | + |
| 90 | +- **Strict Mode**: Enabled (though currently commented in tsconfig) |
| 91 | +- **Import Style**: Use `import type` for type-only imports |
| 92 | +- **File Extensions**: `.ts` for logic, `.svelte` for components |
| 93 | +- **Type Assertions**: Use `as` syntax, not angle brackets |
| 94 | + |
| 95 | +### Svelte Component Patterns |
| 96 | + |
| 97 | +- **Script Context**: Use `context="module"` for shared logic |
| 98 | +- **Props**: Export props with TypeScript types |
| 99 | +- **Styling**: Use class-variance-authority (cva) for component variants |
| 100 | +- **Events**: Define custom events with proper typing |
| 101 | + |
| 102 | +### Import Organization |
| 103 | + |
| 104 | +Import order (enforced by ESLint): |
| 105 | + |
| 106 | +1. Node.js built-ins |
| 107 | +2. External libraries (with `svelte/**` first) |
| 108 | +3. SvelteKit imports (`$app/**`, `$types`) |
| 109 | +4. Internal imports (`$lib/**`) |
| 110 | +5. Component imports (`$components/**/*.svelte`) |
| 111 | +6. Relative imports (`./`, `../`) |
| 112 | + |
| 113 | +### Naming Conventions |
| 114 | + |
| 115 | +- **Files**: kebab-case for all files (`workflow-status.svelte`) |
| 116 | +- **Components**: PascalCase in imports, kebab-case for files |
| 117 | +- **Functions**: camelCase |
| 118 | +- **Constants**: SCREAMING_SNAKE_CASE |
| 119 | +- **Types**: PascalCase |
| 120 | + |
| 121 | +### Component Structure |
| 122 | + |
| 123 | +- **Holocene Design System**: Use components from `$lib/holocene/` |
| 124 | +- **Styling**: Tailwind classes with design tokens |
| 125 | +- **Accessibility**: Include proper ARIA attributes and roles |
| 126 | + |
| 127 | +## File Organization |
| 128 | + |
| 129 | +### Directory Structure |
| 130 | + |
| 131 | +``` |
| 132 | +src/ |
| 133 | +├── lib/ |
| 134 | +│ ├── components/ # Business logic components |
| 135 | +│ ├── holocene/ # Design system components |
| 136 | +│ ├── models/ # Data models and business logic |
| 137 | +│ ├── services/ # API and external service calls |
| 138 | +│ ├── stores/ # Svelte stores for state management |
| 139 | +│ ├── types/ # TypeScript type definitions |
| 140 | +│ └── utilities/ # Pure utility functions |
| 141 | +├── routes/ # SvelteKit routes |
| 142 | +└── fixtures/ # Test data fixtures |
| 143 | +``` |
| 144 | + |
| 145 | +### Best Practices |
| 146 | + |
| 147 | +- **Co-location**: Keep tests next to source files for utilities/models |
| 148 | +- **Separation**: Keep E2E tests in dedicated `/tests` directory |
| 149 | +- **Utilities**: Pure functions in `/utilities`, side effects in `/services` |
| 150 | +- **Types**: Centralized type definitions in `/types` |
| 151 | + |
| 152 | +## Development Workflow |
| 153 | + |
| 154 | +### Pre-commit Hooks |
| 155 | + |
| 156 | +Lint-staged runs on commit: |
| 157 | + |
| 158 | +- **TypeScript/JavaScript**: ESLint + Prettier |
| 159 | +- **Svelte**: ESLint + Prettier + Stylelint |
| 160 | +- **CSS**: Stylelint |
| 161 | +- **JSON/Markdown**: Prettier |
| 162 | + |
| 163 | +### Build and Type Checking |
| 164 | + |
| 165 | +```bash |
| 166 | +pnpm check # TypeScript type checking |
| 167 | +pnpm build:local # Build for local development |
| 168 | +pnpm dev # Start development server |
| 169 | +``` |
| 170 | + |
| 171 | +### Code Quality Commands |
| 172 | + |
| 173 | +Always run before committing: |
| 174 | + |
| 175 | +```bash |
| 176 | +pnpm lint # Check all linting rules |
| 177 | +pnpm check # TypeScript type checking |
| 178 | +pnpm test # Run unit tests |
| 179 | +``` |
| 180 | + |
| 181 | +## Claude-Specific Guidelines |
| 182 | + |
| 183 | +### When Working on This Codebase |
| 184 | + |
| 185 | +1. **Always run linting**: Execute `pnpm lint` after making changes |
| 186 | +2. **Type checking**: Run `pnpm check` to verify TypeScript compliance |
| 187 | +3. **Test execution**: Run appropriate test suites based on changes |
| 188 | +4. **Follow patterns**: Use existing component patterns and utility functions |
| 189 | +5. **Design system**: Prefer Holocene components over custom implementations |
| 190 | +6. **Accessibility**: Ensure proper ARIA attributes and semantic HTML |
| 191 | + |
| 192 | +### Code Generation Preferences |
| 193 | + |
| 194 | +- **No comments**: Don't add code comments unless explicitly requested |
| 195 | +- **Type safety**: Always provide proper TypeScript types |
| 196 | +- **Component reuse**: Leverage existing components and utilities |
| 197 | +- **Test coverage**: Write tests for new utilities and business logic |
| 198 | +- **Import organization**: Follow the established import order |
| 199 | + |
| 200 | +### Error Handling |
| 201 | + |
| 202 | +- **Validation**: Use Zod for runtime type validation |
| 203 | +- **Error boundaries**: Implement proper error boundaries for components |
| 204 | +- **Network errors**: Handle API failures gracefully |
| 205 | +- **User feedback**: Provide clear error messages and loading states |
0 commit comments