@mallardbay/cursor-rules 1.0.35 → 1.1.0

package/.cursor/rules/ui.mdc

@@ -1,91 +0,0 @@
----
-description: Defines best practices for building consistent, maintainable, and responsive UI in Mallard Bay projects
-globs:
-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'`
-
-### Spacing
-
--   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'`
-
-### Borders and border radius
-
--   Use theme border styles and radius values
--   Examples: `theme.borders.sm` instead of `'1px solid'`, `theme.radii.md` instead of using px values
-
-## Component Structure
-
-Maintain clean and consistent component structure:
-
-### Nesting
-
--   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
-
-### 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
-
-## Responsive Design
-
-Ensure responsive and accessible design:
-
-### Breakpoints
-
--   Use theme breakpoints for responsive design
--   Implement mobile-first approach
-
-### Spacing
-
--   Use responsive spacing values
--   Adapt layouts for different screen sizes
-
-### Animations
-
--   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
--   Avoid defining functions inside components to prevent recreation on each render
--   Move function definitions outside components or use useCallback for event handlers
--   Use useCallback for functions passed as props to child components
--   Use useMemo for expensive computations and complex data transformations
--   Memoize filtered, sorted, or mapped arrays to avoid recalculation on every render
--   Use useMemo for object/array creation that would otherwise be recreated on each render
-
-## 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

package/.cursor/shared/rules/project-ecosystem.mdc

@@ -1,68 +0,0 @@
----
-description: Map of Mallard Bay's interconnected repositories and guidance on where to look for cross-project context. AI agents should consult sibling repos (locally) or the GitHub org when context is missing.
-globs:
-alwaysApply: true
----
-
-# Mallard Bay Project Ecosystem
-
-Mallard Bay is split across several repositories that depend on and reference each other. When working in one repo, the answers you need (types, GraphQL schema, shared helpers, business logic, similar UI patterns) often live in another. Always check sibling repos before assuming context is missing or building something from scratch.
-
-## Repositories
-
--   **server** — Node.js/GraphQL backend. The source of truth for the GraphQL schema, resolvers, business logic, database models, integrations (Stripe, HubSpot, etc.), and background jobs. Any frontend questions about API shape, mutation behavior, or business rules are answered here.
--   **web** — Customer-facing Next.js web app (booking, marketing, guest experience). Consumes `server`'s GraphQL API.
--   **dashboard** — Outfitter-facing web app for managing trips, bookings, customers, and operations. Consumes `server`'s GraphQL API. Shares many UI patterns with `web`.
--   **outfitter-mobile** — React Native mobile app for outfitters/guides in the field. Consumes `server`'s GraphQL API. Shares domain logic with `dashboard`.
--   **lib-react-components** — Shared React component library (Chakra UI v2 based) used by `web`, `dashboard`, and (where compatible) other frontends. The first place to look before building any new UI primitive.
--   **lib-shared-helpers** — Shared TypeScript utilities, constants, types, copy strings, and helpers consumed across all frontends and sometimes the server. The first place to look for utility functions, formatters, validators, and shared constants.
-
-## Typical dependency direction
-
-```
-                  ┌──────────────────────┐
-                  │       server         │  (GraphQL API, business logic)
-                  └──────────┬───────────┘
-                             │
-       ┌─────────────────────┼─────────────────────┐
-       │                     │                     │
-   ┌───▼───┐           ┌─────▼──────┐      ┌──────▼─────────┐
-   │  web  │           │ dashboard  │      │ outfitter-mobile│
-   └───┬───┘           └─────┬──────┘      └──────┬─────────┘
-       │                     │                     │
-       └─────────────┬───────┴─────────────────────┘
-                     │
-        ┌────────────▼────────────┐
-        │ lib-react-components    │  (UI primitives — frontends only)
-        │ lib-shared-helpers      │  (utilities — used everywhere)
-        └─────────────────────────┘
-```
-
-## When to look in another repo
-
-Before writing new code or assuming behavior, check sibling repos when you need:
-
--   **GraphQL schema, query/mutation behavior, or business rules** → `server`
--   **A UI component, theme value, or design pattern** → `lib-react-components` first, then `web` / `dashboard` for usage examples
--   **A utility, formatter, validator, constant, or shared type** → `lib-shared-helpers`
--   **How a similar feature was implemented on another surface** → check the parallel repo (e.g. building it in `dashboard`? see how `web` or `outfitter-mobile` did it)
--   **Copy strings, error messages, test IDs** → `lib-shared-helpers` (most projects re-export from there)
--   **Type definitions that feel like they should be shared** → `lib-shared-helpers` or generated types from `server`
-
-## How to access cross-project context
-
-AI agents should use whichever method is available:
-
-1.  **Sibling folders (preferred when running locally).** All Mallard Bay repos are typically cloned as siblings. From any repo, check `../<other-repo>` first — it's the fastest and gives full code search. Example: working in `dashboard`, look at `../server/src/...` or `../lib-react-components/src/...`.
-2.  **GitHub via `gh` CLI.** When sibling folders aren't available (CI, sandboxed environments, or the user hasn't cloned the other repo), use `gh` with the configured GitHub token to search and read code across the `mallardbay` org. Useful commands:
-    -   `gh search code --owner mallardbay '<query>'`
-    -   `gh api repos/mallardbay/<repo>/contents/<path>`
-    -   `gh repo view mallardbay/<repo>`
-3.  **Ask the user** if neither is available, or if you need to confirm which repos are cloned locally.
-
-## Guidance for agents
-
--   **Don't reinvent.** If a helper, component, type, or constant might already exist elsewhere, search before writing. Duplication across repos is a recurring pain point.
--   **Mention what you found.** When you pull context from another repo, briefly note where (e.g. "based on `../server/src/resolvers/booking.ts`") so the user can verify.
--   **Respect dependency direction.** Frontends depend on `server` and the libs — not the other way around. Don't suggest changes that would invert this.
--   **When changing a shared lib**, remember that `web`, `dashboard`, and `outfitter-mobile` all consume it. A breaking change in `lib-shared-helpers` or `lib-react-components` ripples everywhere.