@mallardbay/cursor-rules 1.0.34 → 1.0.35
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
---
|
|
2
|
+
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.
|
|
3
|
+
globs:
|
|
4
|
+
alwaysApply: true
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Mallard Bay Project Ecosystem
|
|
8
|
+
|
|
9
|
+
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.
|
|
10
|
+
|
|
11
|
+
## Repositories
|
|
12
|
+
|
|
13
|
+
- **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.
|
|
14
|
+
- **web** — Customer-facing Next.js web app (booking, marketing, guest experience). Consumes `server`'s GraphQL API.
|
|
15
|
+
- **dashboard** — Outfitter-facing web app for managing trips, bookings, customers, and operations. Consumes `server`'s GraphQL API. Shares many UI patterns with `web`.
|
|
16
|
+
- **outfitter-mobile** — React Native mobile app for outfitters/guides in the field. Consumes `server`'s GraphQL API. Shares domain logic with `dashboard`.
|
|
17
|
+
- **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.
|
|
18
|
+
- **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.
|
|
19
|
+
|
|
20
|
+
## Typical dependency direction
|
|
21
|
+
|
|
22
|
+
```
|
|
23
|
+
┌──────────────────────┐
|
|
24
|
+
│ server │ (GraphQL API, business logic)
|
|
25
|
+
└──────────┬───────────┘
|
|
26
|
+
│
|
|
27
|
+
┌─────────────────────┼─────────────────────┐
|
|
28
|
+
│ │ │
|
|
29
|
+
┌───▼───┐ ┌─────▼──────┐ ┌──────▼─────────┐
|
|
30
|
+
│ web │ │ dashboard │ │ outfitter-mobile│
|
|
31
|
+
└───┬───┘ └─────┬──────┘ └──────┬─────────┘
|
|
32
|
+
│ │ │
|
|
33
|
+
└─────────────┬───────┴─────────────────────┘
|
|
34
|
+
│
|
|
35
|
+
┌────────────▼────────────┐
|
|
36
|
+
│ lib-react-components │ (UI primitives — frontends only)
|
|
37
|
+
│ lib-shared-helpers │ (utilities — used everywhere)
|
|
38
|
+
└─────────────────────────┘
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## When to look in another repo
|
|
42
|
+
|
|
43
|
+
Before writing new code or assuming behavior, check sibling repos when you need:
|
|
44
|
+
|
|
45
|
+
- **GraphQL schema, query/mutation behavior, or business rules** → `server`
|
|
46
|
+
- **A UI component, theme value, or design pattern** → `lib-react-components` first, then `web` / `dashboard` for usage examples
|
|
47
|
+
- **A utility, formatter, validator, constant, or shared type** → `lib-shared-helpers`
|
|
48
|
+
- **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)
|
|
49
|
+
- **Copy strings, error messages, test IDs** → `lib-shared-helpers` (most projects re-export from there)
|
|
50
|
+
- **Type definitions that feel like they should be shared** → `lib-shared-helpers` or generated types from `server`
|
|
51
|
+
|
|
52
|
+
## How to access cross-project context
|
|
53
|
+
|
|
54
|
+
AI agents should use whichever method is available:
|
|
55
|
+
|
|
56
|
+
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/...`.
|
|
57
|
+
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:
|
|
58
|
+
- `gh search code --owner mallardbay '<query>'`
|
|
59
|
+
- `gh api repos/mallardbay/<repo>/contents/<path>`
|
|
60
|
+
- `gh repo view mallardbay/<repo>`
|
|
61
|
+
3. **Ask the user** if neither is available, or if you need to confirm which repos are cloned locally.
|
|
62
|
+
|
|
63
|
+
## Guidance for agents
|
|
64
|
+
|
|
65
|
+
- **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.
|
|
66
|
+
- **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.
|
|
67
|
+
- **Respect dependency direction.** Frontends depend on `server` and the libs — not the other way around. Don't suggest changes that would invert this.
|
|
68
|
+
- **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.
|