90 lines
2.8 KiB
Markdown
90 lines
2.8 KiB
Markdown
|
# CLQMS Frontend - Post-Task Checklist
|
||
|
|
|
||
|
|
## When a Task is Completed
|
||
|
|
|
||
|
|
### Verification Steps
|
||
|
|
|
||
|
|
1. **Build Check** (if changes are significant)
|
||
|
|
- Run `pnpm run build` to ensure the application builds successfully
|
||
|
|
- Check for build errors or warnings
|
||
|
|
|
||
|
|
2. **Manual Testing**
|
||
|
|
- Start dev server: `pnpm run dev`
|
||
|
|
- Test the feature/fix in the browser
|
||
|
|
- Verify no console errors
|
||
|
|
- Check that existing functionality is not broken
|
||
|
|
|
||
|
|
3. **Code Review Checklist**
|
||
|
|
- Follow code style conventions (see `code_style_conventions.md`)
|
||
|
|
- Imports are in correct order
|
||
|
|
- Components use Svelte 5 runes (`$props`, `$state`, `$derived`, `$effect`, `$bindable`)
|
||
|
|
- Event handlers prefixed with `handle`
|
||
|
|
- JSDoc comments on exported functions
|
||
|
|
- Proper error handling with try-catch
|
||
|
|
- Toast notifications for user feedback
|
||
|
|
|
||
|
|
### Code Style Verification
|
||
|
|
|
||
|
|
- ✅ Single quotes for strings
|
||
|
|
- ✅ Semicolons used consistently
|
||
|
|
- ✅ 2-space indentation
|
||
|
|
- ✅ Trailing commas in multi-line objects/arrays
|
||
|
|
- ✅ PascalCase for components
|
||
|
|
- ✅ camelCase for variables and functions
|
||
|
|
- ✅ Descriptive naming
|
||
|
|
|
||
|
|
### Svelte 5 Runes Verification
|
||
|
|
|
||
|
|
- ✅ Using `$props()` for component props
|
||
|
|
- ✅ Using `$state()` for reactive state
|
||
|
|
- ✅ Using `$derived()` for computed values
|
||
|
|
- ✅ Using `$effect()` for side effects
|
||
|
|
- ✅ Using `$bindable()` for two-way binding props
|
||
|
|
- ✅ Using `{@render snippet()}` for slots/content
|
||
|
|
|
||
|
|
### API Integration Verification
|
||
|
|
|
||
|
|
- ✅ Proper error handling with try-catch
|
||
|
|
- ✅ Toast notifications for success/error
|
||
|
|
- ✅ Loading states during async operations
|
||
|
|
- ✅ Form validation before submission
|
||
|
|
- ✅ API calls follow established patterns (get, post, put, patch, del from client.js)
|
||
|
|
|
||
|
|
### Accessibility Verification
|
||
|
|
|
||
|
|
- ✅ Semantic HTML elements
|
||
|
|
- ✅ ARIA labels where needed
|
||
|
|
- ✅ Keyboard navigation support
|
||
|
|
- ✅ Proper form labels and focus management
|
||
|
|
|
||
|
|
### Performance Considerations
|
||
|
|
|
||
|
|
- ✅ No unnecessary re-renders
|
||
|
|
- ✅ Proper use of `$derived` for computed values
|
||
|
|
- ✅ Efficient event handling (avoid inline functions in templates when possible)
|
||
|
|
|
||
|
|
### Browser Compatibility
|
||
|
|
|
||
|
|
- ✅ Check browser console for errors
|
||
|
|
- ✅ Test in Chrome/Firefox/Edge if possible
|
||
|
|
- ✅ Verify responsive design on different screen sizes
|
||
|
|
|
||
|
|
## NO Auto-Commit Policy
|
||
|
|
|
||
|
|
**IMPORTANT**: Do NOT commit changes automatically. Only commit when explicitly requested by the user.
|
||
|
|
|
||
|
|
If user asks to commit:
|
||
|
|
1. Run `git status` to see all untracked files
|
||
|
|
2. Run `git diff` to see changes
|
||
|
|
3. Run `git log` to see commit message style
|
||
|
|
4. Stage relevant files
|
||
|
|
5. Create commit with descriptive message
|
||
|
|
6. Run `git status` to verify
|
||
|
|
|
||
|
|
## Before Marking Task as Complete
|
||
|
|
|
||
|
|
- Ensure all verification steps are completed
|
||
|
|
- Confirm the application runs without errors
|
||
|
|
- If applicable, verify the feature works as expected
|
||
|
|
- Only confirm completion if you have tested the changes
|