@mallardbay/cursor-rules 1.0.8 → 1.0.10

package/.cursor/backend/rules/backend.mdc

@@ -1,8 +1,9 @@
 ---
 description:
 globs:
-alwaysApply: false
+alwaysApply: true
 ---
+
 # Mallard Bay Backend Development Rules
 
 ## Project Structure

package/.cursor/frontend/rules/ui.mdc

@@ -1,70 +1,85 @@
 ---
 description: Defines best practices for building consistent, maintainable, and responsive UI in Mallard Bay projects
 globs:
-alwaysApply: false
+alwaysApply: true
 ---
+
 # UI Development Standards
 
 ## Theme Usage
+
 Use theme values consistently across all components:
 
 ### Colors
-- Use theme colors instead of hardcoded values
-- Example: `theme.colors.primary` instead of `'#000000'`
+
+-   Use theme colors instead of hardcoded values
+-   Example: `theme.colors.primary` instead of `'#000000'`
 
 ### Spacing
-- Use theme spacing values for margins and padding
-- Example: `theme.space[4]` instead of `'16px'`
+
+-   Use theme spacing values for margins and padding
+-   Example: `theme.space[4]` instead of `'16px'`
 
 ### Typography
-- Use theme typography settings for text styles
-- Example: `theme.fontSizes.md` instead of `'16px'`
+
+-   Use theme typography settings for text styles
+-   Example: `theme.fontSizes.md` instead of `'16px'`
 
 ### Borders
-- Use theme border styles and radius values
-- Example: `theme.borders.sm` instead of `'1px solid'`
+
+-   Use theme border styles and radius values
+-   Example: `theme.borders.sm` instead of `'1px solid'`
 
 ## Component Structure
+
 Maintain clean and consistent component structure:
 
 ### Nesting
-- Limit component nesting to maximum depth of 3
-- Keep component hierarchy readable and maintainable
+
+-   Limit component nesting to maximum depth of 3
+-   Keep component hierarchy readable and maintainable
 
 ### Inline Styles
-- Limit inline styles to maximum of 2 per component
-- Prefer theme-based styling
+
+-   Limit inline styles to maximum of 2 per component
+-   Prefer theme-based styling
 
 ### Component Library
-- Use existing components in @mallardbay/lib-react-components, @mallardbay/lib-react-components is based off Crakra UI v2
-- If no component available in @mallardbay/lib-react-components, create one using Crakra UI and place it under src/components/shared/todo-lib-react-components/ to me moved later
+
+-   Use existing components in @mallardbay/lib-react-components, @mallardbay/lib-react-components is based off Crakra UI v2
+-   If no component available in @mallardbay/lib-react-components, create one using Crakra UI and place it under src/components/shared/todo-lib-react-components/ to me moved later
 
 ## Responsive Design
+
 Ensure responsive and accessible design:
 
 ### Breakpoints
-- Use theme breakpoints for responsive design
-- Implement mobile-first approach
+
+-   Use theme breakpoints for responsive design
+-   Implement mobile-first approach
 
 ### Spacing
-- Use responsive spacing values
-- Adapt layouts for different screen sizes
+
+-   Use responsive spacing values
+-   Adapt layouts for different screen sizes
 
 ### Animations
-- Use theme transition values for animations
-- Keep animations smooth and performant
+
+-   Use theme transition values for animations
+-   Keep animations smooth and performant
 
 ### Rendering
-- Optimize component rendering
-- Avoid unnecessary re-renders
-- Use React.memo and useMemo when appropriate
+
+-   Optimize component rendering
+-   Avoid unnecessary re-renders
+-   Use React.memo and useMemo when appropriate
 
 ## File Patterns
+
 These rules apply to all TypeScript and TSX files in the project.
 
 ## Components
-- Keep components small and focused on a single responsibility
-- Use functional components with hooks instead of class components
-- Prefer `export default function ImpersonationBox() {` over `function ImpersonationBox(): React.ReactElement | null {` when defining components
-
 
+-   Keep components small and focused on a single responsibility
+-   Use functional components with hooks instead of class components
+-   Prefer `export default function ImpersonationBox() {` over `function ImpersonationBox(): React.ReactElement | null {` when defining components

package/.cursor/shared/rules/mallardbay.mdc

@@ -1,8 +1,9 @@
 ---
 description: Describes Mallard Bay’s mission to simplify and scale outfitter operations through purpose-built software—emphasizing real-world impact, outfitter collaboration, and a long-term vision to digitize and unify the outdoor experience industry.
 globs:
-alwaysApply: false
+alwaysApply: true
 ---
+
 # Mallard Bay: Outfitter Management System Overview
 
 Mallard Bay is a specialized platform designed to streamline operations for outfitters—businesses that offer guided outdoor experiences such as hunting, fishing, and eco-tourism. At its core, Mallard Bay operates as an outfitter management system, purpose-built to reduce administrative burden, improve customer experience, and unlock new revenue channels for guides and lodge operators.
@@ -19,4 +20,4 @@ We’re building tools that fit into the way outfitters actually work — not th
 
 # Vision
 
-Mallard Bay aims to be the digital backbone for the outfitting industry—a single source of truth for trip logistics, customer interaction, and business growth. The long-term goal is to transform an analog, fragmented market into a digital-first, scalable ecosystem.
+Mallard Bay aims to be the digital backbone for the outfitting industry—a single source of truth for trip logistics, customer interaction, and business growth. The long-term goal is to transform an analog, fragmented market into a digital-first, scalable ecosystem.

package/.cursor/shared/rules/testing.mdc

@@ -1,11 +1,13 @@
 ---
 description: Outlines practical, value-driven testing guidelines focused on reliability, developer confidence, and speed. Emphasizes high-impact coverage (not overkill), structured test organization, clear scenarios, and reusable mock/test utilities—enabling fast iteration without sacrificing quality.
 globs:
-alwaysApply: false
+alwaysApply: true
 ---
+
 # Testing Standards
 
 ## Test Coverage and Structure
+
 We aim for high-impact test coverage, focused on adding value and improving developer confidence and experience. The priority is to cover critical logic, edge cases, and integration points where bugs would hurt the most. Tests should act as a safety net and enable fast, fearless iteration—not as a box-ticking exercise.
 
 We do not chase 100% coverage for its own sake. If a test doesn’t meaningfully reduce risk or help developers move faster, it’s not worth writing. The goal is smart coverage, not maximum coverage—optimize for reliability, clarity, and development speed without overengineering.
@@ -13,49 +15,56 @@ We do not chase 100% coverage for its own sake. If a test doesn’t meaningfully
 Avoid e2e tests for UI. Favor unit tests.
 
 ### Coverage Requirements
-- Minimum test coverage: 80%
-- Place tests in `_tests_` directory closest to the file being tested
-- Use `.spec.ts` or `.spec.tsx` file extensions
-- Do NOT Use `.test.ts` or `.test.tsx` file extensions
 
+-   Minimum test coverage: 80%
+-   Place tests in `_tests_` directory closest to the file being tested
+-   Use `.spec.ts` or `.spec.tsx` file extensions
+-   Do NOT Use `.test.ts` or `.test.tsx` file extensions
 
 ### Test Organization
-- Maximum nesting level: 2
-- Use `test` or `it` for test cases
-- Keep tests focused and atomic
-- Follow AAA pattern (Arrange, Act, Assert)
+
+-   Maximum nesting level: 2
+-   Use `test` or `it` for test cases
+-   Keep tests focused and atomic
+-   Follow AAA pattern (Arrange, Act, Assert)
 
 ### Required Scenarios
-- Happy path testing
-- Error case handling
-- Edge case coverage
-- All tests must pass before completion
+
+-   Happy path testing
+-   Error case handling
+-   Edge case coverage
+-   All tests must pass before completion
 
 ### Test Quality
-- Write clear, descriptive test names
-- Test one concept per test case
-- Avoid test interdependence
-- Use meaningful assertions
-- Avoid tests that will make the overall run slower
+
+-   Write clear, descriptive test names
+-   Test one concept per test case
+-   Avoid test interdependence
+-   Use meaningful assertions
+-   Avoid tests that will make the overall run slower
 
 ### Component Testing
-- Use `renderWithProviders` for component tests
-- Use `renderHookWithProviders` for hook tests
-- Avoid mocking dependent components
-- Test component behavior, not implementation
+
+-   Use `renderWithProviders` for component tests
+-   Use `renderHookWithProviders` for hook tests
+-   Avoid mocking dependent components
+-   Test component behavior, not implementation
 
 ### Mocking Guidelines
-- Use mock helpers instead of inline mocks
-- Follow existing patterns for:
-  - Entity mocks
-  - Apollo mocks
-  - Provider mocks
-- Keep mocks simple and maintainable
+
+-   Use mock helpers instead of inline mocks
+-   Follow existing patterns for:
+    -   Entity mocks
+    -   Apollo mocks
+    -   Provider mocks
+-   Keep mocks simple and maintainable
 
 ### Test Utilities
-- Leverage testing utilities from [@testing-library/react](mdc:package.json)
-- Use [@testing-library/jest-dom](mdc:package.json) for DOM assertions
-- Follow established patterns in existing tests
+
+-   Leverage testing utilities from [@testing-library/react](mdc:package.json)
+-   Use [@testing-library/jest-dom](mdc:package.json) for DOM assertions
+-   Follow established patterns in existing tests
 
 ## File Patterns
+
 These rules apply to all test files with `.spec.ts` or `.spec.tsx` extensions.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@mallardbay/cursor-rules",
-    "version": "1.0.8",
+    "version": "1.0.10",
     "description": "Mallard Bay shared cursor rules",
     "main": "bin/setup-cursor.sh",
     "repository": "git@github.com:mallardbay/cursor-rules.git",