| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 1 | 1 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 0 | 1 | 0% |
What each file covers
Sections
0 shared · 1 only in A · 1 only in B- − Context Engineering Checklist
- + ClickHouse Conventions
Commands
neither file has anySection tags
0 shared · 0 only in A · 1 only in B- + code-style
Line diff
novuhq/novu · .cursor/rules/context-engineering.mdc
@@ −1 @@
1---
2description: Context quality checklist for system prompts and agent instructions
3globs:
4 - "**/tools/**/*.ts"
5 - "**/prompts/**/*.ts"
6 - "**/*.prompt.ts"
7 - "AGENTS.md"
8 - ".cursor/rules/**"
9 - ".cursor/skills/**"
10 - ".agents/skills/**"
11alwaysApply: false
12---
13
14### Context Engineering Checklist
15
16When writing or reviewing agent instructions, tool descriptions, or prompts:
17
18- Is this explained elsewhere? → Consolidate to one location
19- Would a senior dev infer this? → Remove if obvious
20- Can this be an example instead? → One example beats three paragraphs of rules
21- Is this defensive repetition ("MUST", "NEVER", "CRITICAL")? → State once, remove emphasis
22- Does this duplicate a tool's own description? → Keep in tool description only
23- Are there prescriptive step lists? → Compress to a sentence
24- Is the altitude right? → Specific heuristics, not hardcoded logic or vague guidance
25- Is this stable across requests? → Move to cached/static portion
26
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: Context quality checklist for system prompts and agent instructions
2+description: Rules for working with ClickHouse analytics and trace logging
33 globs:
4− - "**/tools/**/*.ts"
5− - "**/prompts/**/*.ts"
6− - "**/*.prompt.ts"
7− - "AGENTS.md"
8− - ".cursor/rules/**"
9− - ".cursor/skills/**"
10− - ".agents/skills/**"
4+ - "**/analytic-logs/**"
5+ - "**/clickhouse-migrations/**"
116 alwaysApply: false
127 ---
138
14−### Context Engineering Checklist
9+### ClickHouse Conventions
1510
16−When writing or reviewing agent instructions, tool descriptions, or prompts:
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.
1715
18−- Is this explained elsewhere? → Consolidate to one location
19−- Would a senior dev infer this? → Remove if obvious
20−- Can this be an example instead? → One example beats three paragraphs of rules
21−- Is this defensive repetition ("MUST", "NEVER", "CRITICAL")? → State once, remove emphasis
22−- Does this duplicate a tool's own description? → Keep in tool description only
23−- Are there prescriptive step lists? → Compress to a sentence
24−- Is the altitude right? → Specific heuristics, not hardcoded logic or vague guidance
25−- Is this stable across requests? → Move to cached/static portion
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`).
2628
