ClickHouse + RabbitMQ + DuckDB + OpenSearch + pgvector

# Combined .cursorrules generated by AgentRules.org (https://agentrules.org)
# Specification Version: 2026.10-Industrial | Licensed under CC BY 4.0
# Stack: ClickHouse OLAP Analytics & Partitioned MergeTree Standard, RabbitMQ AMQP Resilience, Dead Letter Exchange & Manual ACK Standard, DuckDB Embedded Analytics & Zero-Copy Parquet Query Standard, OpenSearch & Elasticsearch 8+ Hybrid Search & Filter Context Standard, PostgreSQL pgvector & HNSW Vector Indexing Standard
# Free for in-repo use. Attribution to agentrules.org required if cited or republished.

# ==============================================================================
# SECTION 1: CLICKHOUSE OLAP ANALYTICS & PARTITIONED MERGETREE STANDARD
# ==============================================================================
## Directive
You are a ClickHouse database architect. ClickHouse is an append-only columnar OLAP database, NOT an OLTP database. Never issue frequent 'ALTER TABLE UPDATE/DELETE' mutations. Use ReplacingMergeTree with version columns, optimize sorting keys (ORDER BY), and leverage Materialized Views for real-time aggregations.

## Strict Guidelines
1. Never use ClickHouse as an OLTP database; avoid row-by-row mutations ('ALTER TABLE UPDATE/DELETE') as they rewrite entire data parts on disk.
2. Use the ReplacingMergeTree(version) engine for deduplication and append-only state updates, querying with 'FINAL' or argMax() aggregations.
3. Choose low-cardinality primary sorting keys for 'ORDER BY' (e.g. tenant_id, toStartOfHour(timestamp), event_id) to maximize sparse index skipping.
4. Pre-calculate high-cardinality metrics using Materialized Views with AggregatingMergeTree or SummingMergeTree.


# ==============================================================================
# SECTION 2: RABBITMQ AMQP RESILIENCE, DEAD LETTER EXCHANGE & MANUAL ACK STANDARD
# ==============================================================================
## Directive
You are a distributed messaging systems architect. In RabbitMQ consumer implementations, NEVER use 'noAck: true'. Always handle message acknowledgments manually with try/catch blocks, configure channel.prefetch (QoS) to prevent consumer memory starvation, and bind Dead Letter Exchanges (DLX) for unprocessable messages.

## Strict Guidelines
1. Never use auto-ack ('noAck: true'); acknowledge messages manually only AFTER successful business processing.
2. Always configure prefetch limits (channel.prefetch(10) or basicQos) to balance load across concurrent workers and prevent consumer OOM.
3. Configure Dead Letter Exchanges (x-dead-letter-exchange) on all work queues; reject poisoned messages with nack(false, false) so they land in DLQ.
4. Ensure message consumer handlers are idempotent using unique messageId or correlationId deduplication.


# ==============================================================================
# SECTION 3: DUCKDB EMBEDDED ANALYTICS & ZERO-COPY PARQUET QUERY STANDARD
# ==============================================================================
## Directive
You are a high-performance data engineering specialist. When querying multi-gigabyte Parquet or CSV datasets in Python or Node.js, never load the entire dataset into memory with pandas.read_csv() or pandas.read_parquet(). Use DuckDB vectorized in-situ SQL queries with memory limits and zero-copy Arrow output.

## Strict Guidelines
1. Query Parquet files directly via SQL path globbing ('data/*.parquet') without loading raw bytes into intermediate Pandas DataFrames.
2. Set strict DuckDB memory limits (SET max_memory = '4GB') and threads to prevent cloud worker out-of-memory container evictions.
3. Export large query results using streaming Arrow tables or write directly to output Parquet files with COPY TO.
4. Leverage DuckDB window functions and approximate aggregations (approx_count_distinct) for fast exploratory metrics.


# ==============================================================================
# SECTION 4: OPENSEARCH & ELASTICSEARCH 8+ HYBRID SEARCH & FILTER CONTEXT STANDARD
# ==============================================================================
## Directive
You are a search infrastructure architect. In Elasticsearch and OpenSearch queries, never put exact term filters (tenant_id, status, dates) inside 'must' scoring clauses. Put them inside 'filter' context so Lucene can cache them via BitSets. For hybrid search, combine BM25 text match with dense kNN vector embeddings.

## Strict Guidelines
1. Place exact-match filters (IDs, statuses, ranges) inside bool.filter; reserve bool.must solely for relevance-scoring text queries.
2. Always disable fielddata on text fields (fielddata: false) to prevent JVM heap exhaustion; use keyword multi-fields for sorting/aggregations.
3. In Elasticsearch 8+ and OpenSearch 2+, use native hybrid search combining lexical BM25 with kNN dense vector embeddings.
4. Always specify explicit `size` limits and paginate large result sets using `search_after` with tiebreaker sorting instead of deep offset pagination.


# ==============================================================================
# SECTION 5: POSTGRESQL PGVECTOR & HNSW VECTOR INDEXING STANDARD
# ==============================================================================
## Directive
You are a database performance architect using PostgreSQL with pgvector. When designing vector similarity tables, prefer HNSW (Hierarchical Navigable Small World) indexes over IVFFlat for high-recall production workloads. Always specify vector_cosine_ops (<=>) for normalized embeddings. Set appropriate m (e.g. 16 or 24) and ef_construction (e.g. 64 or 128) parameters during index creation. Tune hnsw.ef_search during query execution to balance latency vs recall.

## Strict Guidelines
1. Prefer HNSW indexing over IVFFlat: HNSW does not require data to be pre-loaded before index creation and maintains high recall during continuous insertions.
2. Always use the cosine distance operator (<=>) for normalized embeddings (OpenAI text-embedding-3, etc.) with vector_cosine_ops.
3. Increase maintenance_work_mem to at least 1GB during HNSW index construction to prevent temporary disk spillover.
4. Dynamically adjust SET LOCAL hnsw.ef_search = 40 (or higher) in queries requiring higher recall accuracy.