| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 1 | 1 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 2 | 1 | 0% |
What each file covers
Sections
0 shared · 1 only in A · 1 only in B- − Pull Request Rules
- + ClickHouse Conventions
Commands
neither file has anySection tags
0 shared · 2 only in A · 1 only in B- − git-pr
- − do-not
- + code-style
Line diff
novuhq/novu · .cursor/rules/pullrequest.mdc
@@ −1 @@
1---
2description: When creating a new pull request on GitHub, use this to specify the contents
3alwaysApply: false
4---
5
6### Pull Request Rules
7
8**Title format**: `type(scope): Description fixes NOV-<ticket-id>`
9
10- When creating a pull requests from any run, verify that there is a linear ticket associated with the pr (From branch name or other), if not, create the linear ticket before creating the PR and attach the linear ticket id in title (fixes NV-XXX)
11- Examples: `feat(dashboard): add workflow trigger button fixes NOV-123`, `fix(api-service): handle null subscriber case fixes NOV-456`
12
13
14**Scopes**: `dashboard`, `api-service`, `worker`, `shared`, `js`, `react`, `react-native`, `nextjs`, `providers`, `root`, `docs`
15
16**Description**: Summarize what changed and why. List breaking changes. Add screenshots for UI changes. For non-trivial logic or architecture changes, include a concise Mermaid diagram (flow, sequence, or component) so reviewers can grasp the change at a glance.
17
18**Enterprise packages**: When changes touch `enterprise/`, also open a matching PR in `novuhq/packages-enterprise` on a branch from `next`, and cross-link the two PR bodies (monorepo ↔ enterprise). The Validate Submodule Sync test will fail; this is expected when pointing to the `.source` submodule in the novuhq/novu repository. Do not fix it.
19
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
@@ −1 +1 @@
11 ---
2−description: When creating a new pull request on GitHub, use this to specify the contents
2+description: Rules for working with ClickHouse analytics and trace logging
3+globs:
4+ - "**/analytic-logs/**"
5+ - "**/clickhouse-migrations/**"
36 alwaysApply: false
47 ---
58
6−### Pull Request Rules
9+### ClickHouse Conventions
710
8−**Title format**: `type(scope): Description fixes NOV-<ticket-id>`
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.
915
10−- When creating a pull requests from any run, verify that there is a linear ticket associated with the pr (From branch name or other), if not, create the linear ticket before creating the PR and attach the linear ticket id in title (fixes NV-XXX)
11−- Examples: `feat(dashboard): add workflow trigger button fixes NOV-123`, `fix(api-service): handle null subscriber case fixes NOV-456`
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).
1220
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).
1325
14−**Scopes**: `dashboard`, `api-service`, `worker`, `shared`, `js`, `react`, `react-native`, `nextjs`, `providers`, `root`, `docs`
15−
16−**Description**: Summarize what changed and why. List breaking changes. Add screenshots for UI changes. For non-trivial logic or architecture changes, include a concise Mermaid diagram (flow, sequence, or component) so reviewers can grasp the change at a glance.
17−
18−**Enterprise packages**: When changes touch `enterprise/`, also open a matching PR in `novuhq/packages-enterprise` on a branch from `next`, and cross-link the two PR bodies (monorepo ↔ enterprise). The Validate Submodule Sync test will fail; this is expected when pointing to the `.source` submodule in the novuhq/novu repository. Do not fix it.
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`).
1928
