| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 3 | 1 | 0% |
| Commands | 0 | 1 | 0 | 0% |
| Section tags | 0 | 2 | 1 | 0% |
What each file covers
Sections
0 shared · 3 only in A · 1 only in B- − Agent setup
- − Common tasks
- − Reference
- + ClickHouse Conventions
Commands
0 shared · 1 only in A · 0 only in B- − pnpm install
Section tags
0 shared · 2 only in A · 1 only in B- − setup
- − agent-behaviour
- + code-style
Line diff
novuhq/novu · .deepsec/AGENTS.md
@@ −1 @@
1# Agent setup
2
3This is a deepsec scanning workspace. Each registered project has its
4own setup prompt at `data/<id>/SETUP.md` — open the relevant one when
5asked to set a project up.
6
7## Common tasks
8
9- **Set up a project for scanning**: read `data/<id>/SETUP.md` and
10 follow it (read `node_modules/deepsec/SKILL.md`, then fill
11 `data/<id>/INFO.md` from the target codebase).
12- **Add a new project**: run `deepsec init-project <root>` — it
13 scaffolds `data/<id>/` and prints/writes the setup prompt for the
14 new project.
15- **Write a custom matcher** (only after a real true-positive shows you
16 a pattern worth keeping): read
17 `node_modules/deepsec/dist/docs/writing-matchers.md`.
18
19## Reference
20
21The deepsec skill is at `node_modules/deepsec/SKILL.md` (after
22`pnpm install`). The full docs ship at
23`node_modules/deepsec/dist/docs/`.
24
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 @@
1−# Agent setup
1+---
2+description: Rules for working with ClickHouse analytics and trace logging
3+globs:
4+ - "**/analytic-logs/**"
5+ - "**/clickhouse-migrations/**"
6+alwaysApply: false
7+---
28
3−This is a deepsec scanning workspace. Each registered project has its
4−own setup prompt at `data/<id>/SETUP.md` — open the relevant one when
5−asked to set a project up.
9+### ClickHouse Conventions
610
7−## Common tasks
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.
815
9−- **Set up a project for scanning**: read `data/<id>/SETUP.md` and
10− follow it (read `node_modules/deepsec/SKILL.md`, then fill
11− `data/<id>/INFO.md` from the target codebase).
12−- **Add a new project**: run `deepsec init-project <root>` — it
13− scaffolds `data/<id>/` and prints/writes the setup prompt for the
14− new project.
15−- **Write a custom matcher** (only after a real true-positive shows you
16− a pattern worth keeping): read
17− `node_modules/deepsec/dist/docs/writing-matchers.md`.
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).
1820
19−## Reference
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).
2025
21−The deepsec skill is at `node_modules/deepsec/SKILL.md` (after
22−`pnpm install`). The full docs ship at
23−`node_modules/deepsec/dist/docs/`.
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`).
2428
