| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 1 | 2 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 1 | 0 | 0 | 100% |
What each file covers
Sections
0 shared · 1 only in A · 2 only in B- − ClickHouse Conventions
- + Dashboard
- + Dashboard Conventions
Commands
neither file has anySection tags
1 shared · 0 only in A · 0 only in B- code-style
Line diff
novuhq/novu · .cursor/rules/clickhouse.mdc
@@ −1 @@
1---
2description: Rules for working with ClickHouse analytics and trace logging
3globs:
4 - "**/analytic-logs/**"
5 - "**/clickhouse-migrations/**"
6alwaysApply: false
7---
8
9### ClickHouse Conventions
10
11**Service layer**
12- Use `ClickHouseService` for single queries/inserts and `ClickHouseBatchService` for high-throughput writes.
13- Both are registered as custom providers (`clickHouseService`, `clickHouseBatchService`) in each app's `shared.module.ts`.
14- Never instantiate ClickHouse clients directly — always inject the providers.
15
16**Repositories**
17- All ClickHouse repositories extend `LogRepository` in `libs/application-generic/src/services/analytic-logs/`.
18- Each repository has a corresponding schema file defining the table columns and types.
19- Always include `_environmentId` and `_organizationId` in queries for tenant isolation (same pattern as MongoDB DAL).
20
21**Migrations**
22- ClickHouse migrations are numbered `.sql` files in `apps/api/migrations/clickhouse-migrations/`.
23- Run locally with `cd apps/api && pnpm run clickhouse:migrate:local`.
24- New migrations must be additive — never alter or drop columns that existing queries depend on. Use temp tables and exchange patterns for schema refactors (see migration 4/5 for the established pattern).
25
26**Feature flags**
27- Gate new ClickHouse-dependent behavior behind a feature flag (see `packages/shared/src/types/feature-flags.ts` for existing flags like `IS_CLICKHOUSE_BATCHING_ENABLED`).
28
novuhq/novu · .cursor/rules/dashboard.mdc
@@ +1 @@
1---
2description: Rules for working in the Dashboard (React frontend)
3globs: apps/dashboard/**/*
4alwaysApply: false
5---
6
7## Dashboard
8
9**Stack:** React 19 + Vite + TypeScript · Radix UI · Tailwind CSS · shadcn/ui · TanStack Query · React Router · motion/react · port 4201
10
11**Run:** Do not build or start the dashboard — the user already has it running on port 4201. Check types via Cursor diagnostics.
12
13**Tests/lint:** see testing.mdc
14
15**Key directories:**
16```
17apps/dashboard/src/components/ # Shared UI components
18apps/dashboard/src/pages/ # Route-level page components
19apps/dashboard/src/hooks/ # Custom React hooks
20apps/dashboard/src/api/ # API client and query definitions
21apps/dashboard/src/ee/ # Enterprise-only features
22```
23
24**Agent sign-in:** A default user and org are pre-seeded. In Cursor cloud agent environments (`apps/dashboard/.env.agent`), the dashboard auto signs in — open `http://localhost:4201` and wait for redirect; do not type credentials unless auto sign-in fails.
25
26| Field | Value |
27|-------|-------|
28| Email | `agent@novu.co` |
29| Password | `Agent123!@#` |
30| Organization | `Agent Organization` |
31
32---
33
34### Dashboard Conventions
35
36**Data fetching**
37- Use TanStack Query (`useQuery`, `useMutation`) for all server state — do not use `useEffect` + `fetch` directly.
38- Co-locate query keys and fetcher functions in `src/api/` or alongside the feature they belong to.
39- Invalidate related queries after mutations; do not manually update the cache unless necessary for optimistic UI.
40
41**UI components**
42- Build on Radix UI primitives and the existing shadcn/ui component set in `src/components/ui/`.
43- Avoid adding new third-party UI libraries without discussion.
44- Use Tailwind utility classes for all styling; avoid inline `style` props except for dynamic values that cannot be expressed as utilities.
45
46**Routing**
47- Use React Router v6 `<Link>` and `useNavigate` — do not use `window.location` for in-app navigation.
48
49**Canonical example:** @apps/dashboard/src/components/environments/edit-environment-sheet.tsx
50
@@ −1 +1 @@
11 ---
2−description: Rules for working with ClickHouse analytics and trace logging
3−globs:
4− - "**/analytic-logs/**"
5− - "**/clickhouse-migrations/**"
2+description: Rules for working in the Dashboard (React frontend)
3+globs: apps/dashboard/**/*
64 alwaysApply: false
75 ---
86
9−### ClickHouse Conventions
7+## Dashboard
108
11−**Service layer**
12−- Use `ClickHouseService` for single queries/inserts and `ClickHouseBatchService` for high-throughput writes.
13−- Both are registered as custom providers (`clickHouseService`, `clickHouseBatchService`) in each app's `shared.module.ts`.
14−- Never instantiate ClickHouse clients directly — always inject the providers.
9+**Stack:** React 19 + Vite + TypeScript · Radix UI · Tailwind CSS · shadcn/ui · TanStack Query · React Router · motion/react · port 4201
1510
16−**Repositories**
17−- All ClickHouse repositories extend `LogRepository` in `libs/application-generic/src/services/analytic-logs/`.
18−- Each repository has a corresponding schema file defining the table columns and types.
19−- Always include `_environmentId` and `_organizationId` in queries for tenant isolation (same pattern as MongoDB DAL).
11+**Run:** Do not build or start the dashboard — the user already has it running on port 4201. Check types via Cursor diagnostics.
2012
21−**Migrations**
22−- ClickHouse migrations are numbered `.sql` files in `apps/api/migrations/clickhouse-migrations/`.
23−- Run locally with `cd apps/api && pnpm run clickhouse:migrate:local`.
24−- New migrations must be additive — never alter or drop columns that existing queries depend on. Use temp tables and exchange patterns for schema refactors (see migration 4/5 for the established pattern).
13+**Tests/lint:** see testing.mdc
2514
26−**Feature flags**
27−- Gate new ClickHouse-dependent behavior behind a feature flag (see `packages/shared/src/types/feature-flags.ts` for existing flags like `IS_CLICKHOUSE_BATCHING_ENABLED`).
15+**Key directories:**
16+```
17+apps/dashboard/src/components/ # Shared UI components
18+apps/dashboard/src/pages/ # Route-level page components
19+apps/dashboard/src/hooks/ # Custom React hooks
20+apps/dashboard/src/api/ # API client and query definitions
21+apps/dashboard/src/ee/ # Enterprise-only features
22+```
23+
24+**Agent sign-in:** A default user and org are pre-seeded. In Cursor cloud agent environments (`apps/dashboard/.env.agent`), the dashboard auto signs in — open `http://localhost:4201` and wait for redirect; do not type credentials unless auto sign-in fails.
25+
26+| Field | Value |
27+|-------|-------|
28+| Email | `agent@novu.co` |
29+| Password | `Agent123!@#` |
30+| Organization | `Agent Organization` |
31+
32+---
33+
34+### Dashboard Conventions
35+
36+**Data fetching**
37+- Use TanStack Query (`useQuery`, `useMutation`) for all server state — do not use `useEffect` + `fetch` directly.
38+- Co-locate query keys and fetcher functions in `src/api/` or alongside the feature they belong to.
39+- Invalidate related queries after mutations; do not manually update the cache unless necessary for optimistic UI.
40+
41+**UI components**
42+- Build on Radix UI primitives and the existing shadcn/ui component set in `src/components/ui/`.
43+- Avoid adding new third-party UI libraries without discussion.
44+- Use Tailwind utility classes for all styling; avoid inline `style` props except for dynamic values that cannot be expressed as utilities.
45+
46+**Routing**
47+- Use React Router v6 `<Link>` and `useNavigate` — do not use `window.location` for in-app navigation.
48+
49+**Canonical example:** @apps/dashboard/src/components/environments/edit-environment-sheet.tsx
2850
