diff --git a/.cursor/rules/bulma-usage.mdc b/.cursor/rules/bulma-usage.mdc
index 6547834..ea8d92e 100644
--- a/.cursor/rules/bulma-usage.mdc
+++ b/.cursor/rules/bulma-usage.mdc
@@ -18,90 +18,101 @@ When styling components:
- Keep modifier classes consistent with Bulma's patterns
- Use semantic Bulma classes (e.g., 'button is-primary' not custom colors)
-3. Custom Styles:
- - Only add custom CSS when Bulma doesn't provide the functionality
- - Document why custom CSS is needed
- - Use Bulma's CSS variables for theming
- - Keep custom styles minimal and focused
+3. Dark Mode Implementation:
+ - Define CSS variables in app.html for global theme
+ - Use --bulma-* prefix for all theme variables
+ - Override component-specific variables as needed
+ - Test all components in both light/dark modes
+ - Common variables to define:
+ ```css
+ body.dark-mode {
+ --bulma-scheme-main: #1a1a1a;
+ --bulma-scheme-main-bis: #242424;
+ --bulma-scheme-main-ter: #2f2f2f;
+ --bulma-text: #e6e6e6;
+ --bulma-text-strong: #ffffff;
+ --bulma-border: #4a4a4a;
+ }
+ ```
-4. Dark Mode:
- - Use Bulma's CSS variables for theming
- - Override colors using CSS variables, not direct colors
- - Maintain consistent contrast ratios
- - Test dark mode for all components
+4. Navigation Patterns:
+ - Mobile: Use fixed bottom navbar
+ - Desktop: Use fixed left sidebar
+ - Handle responsive transitions cleanly
+ - Use consistent icon + label patterns
+ - Maintain active state indicators
-5. Responsive Design:
- - Use Bulma's responsive classes (is-*-mobile, is-*-tablet, etc.)
+5. Card Patterns:
+ - Use standard card structure:
+ ```html
+
+
+
Title
+
Subtitle
+
Content
+
+
+
+ ```
+ - Keep actions in card-footer
+ - Use consistent spacing
+ - Handle long content gracefully
+
+6. Form Patterns:
+ - Use standard field structure:
+ ```html
+
+
+
+
+
+
+ ```
+ - Group related fields with field-group
+ - Use appropriate input types
+ - Add helper text when needed
+
+7. Responsive Design:
+ - Use Bulma's responsive classes
- Test all breakpoints
- - Maintain consistent spacing across screen sizes
+ - Maintain consistent spacing
- Use proper container classes
-
-6. Common Patterns:
- - Forms: field > label + control > input
- - Buttons: button + is-* modifiers
- - Cards: card > card-header + card-content + card-footer
- - Navigation: navbar with proper structure
- - Grid: columns > column with proper sizes
-
-7. Performance:
- - Don't duplicate Bulma styles
- - Minimize custom CSS
- - Use Bulma's minified version
- - Remove unused Bulma features if size is a concern
+ - Handle mobile-specific patterns:
+ - Touch-friendly tap targets
+ - Simplified navigation
+ - Adjusted font sizes
+ - Full-width buttons
metadata:
priority: high
- version: 1.0
+ version: 1.1
examples:
- input: |
- # Bad: Custom styles for spacing
-
+ # Bad: Custom dark mode colors
+ .dark-mode .button {
+ background: #333;
+ color: white;
+ }
output: |
-
-
+ # Good: Responsive navigation
+ {#if isMobile}
+
+ {:else}
+
+ {/if}
\ No newline at end of file
diff --git a/.cursor/rules/frontend-testing.mdc b/.cursor/rules/frontend-testing.mdc
index db7b86e..f33eb2d 100644
--- a/.cursor/rules/frontend-testing.mdc
+++ b/.cursor/rules/frontend-testing.mdc
@@ -14,10 +14,10 @@ When working on frontend features:
2. Test Structure:
- Use descriptive test names
+ - Reset database state before each test
- Group related tests in describe blocks
- - Use beforeEach for common setup
- - Clean up test data after each test
- Keep tests focused and atomic
+ - Add explicit waits and checks at key points
3. Testing Best Practices:
- Test user interactions, not implementation
@@ -26,7 +26,16 @@ When working on frontend features:
- Test across multiple browsers
- Verify visual and functional aspects
-4. Required Test Cases:
+4. Reliable Test Execution:
+ - Always reset database state with `/api/test/reset`
+ - Wait for redirects with URL checks
+ - Wait for content with `.waitForSelector()`
+ - Check element visibility before interaction
+ - Use specific selectors (id, role, exact text)
+ - Add explicit waits after state changes
+ - Store URLs after navigation for reliable returns
+
+5. Required Test Cases:
- Navigation flows
- Form submissions
- Error handling
@@ -34,25 +43,48 @@ When working on frontend features:
- Responsive behavior
- Cross-browser compatibility
-5. Running Tests:
+6. Database Considerations:
+ - Use single worker mode due to shared database
+ - Reset database state before each test
+ - Avoid parallel test execution
+ - Consider test isolation needs
+
+7. Running Tests:
- Run tests before committing: `bun test`
- Debug tests with UI: `bun test:ui`
- Debug specific test: `bun test:debug`
- Install browsers: `bun test:install`
-6. CI Integration:
- - Tests must pass in CI
- - Screenshots on failure
- - HTML test reports
- - Retry failed tests
- - Parallel execution where possible
-
metadata:
priority: high
- version: 1.0
+ version: 1.1
examples:
+ - input: |
+ # Bad: Unreliable waiting
+ await page.click('button');
+ await page.locator('h1').textContent();
+ output: |
+ # Good: Explicit waits and checks
+ await page.click('button');
+ await expect(page).toHaveURL(/\/expected-path/);
+ await page.waitForSelector('h1');
+ await expect(page.locator('h1')).toBeVisible();
+
+ - input: |
+ # Bad: No state reset
+ test('creates item', async ({ page }) => {
+ await page.goto('/items/new');
+ });
+ output: |
+ # Good: Reset state first
+ test('creates item', async ({ page }) => {
+ await page.goto('/');
+ await page.request.post('/api/test/reset');
+ await page.goto('/items/new');
+ });
+
- input: |
# Bad: No tests for new feature
git commit -m "feat: add note search"