Cursor Rules TemplatesDashboard Rule Template

Cursor Rules Template: Dynamic Pricing Dashboard for Marketplace Sellers

Cursor Rules Template for building a Node.js/Express + PostgreSQL dynamic pricing dashboard for marketplace sellers using Cursor AI.

cursor-rules-templatecursor-rulesdynamic-pricingmarketplacenodejspostgresqlreactcursor-ai-rules

Target User

Developers building dynamic pricing dashboards for marketplaces

Use Cases

  • Dynamic pricing dashboards for marketplace sellers
  • Pricing rule validation and auditing
  • Data modeling for price aggregations

Markdown Template

Cursor Rules Template: Dynamic Pricing Dashboard for Marketplace Sellers

Overview


This Cursor rules configuration provides a practical, copyable Cursor Rules Template for building a dynamic pricing dashboard tailored to marketplace sellers. It targets a Node.js + Express backend with a PostgreSQL data layer and a React/Next.js frontend. The rules ensure safe AI-assisted development, enforce data integrity, and guide Cursor AI through architecture, security, and testing constraints for this stack.


When to Use These Cursor Rules



  - You are building a dynamic pricing dashboard for marketplace sellers using a Node.js + Express backend with PostgreSQL.

  - You need consistent currency handling, auditing, and deterministic pricing calculations.

  - You require server-side validation and safe data access controls for pricing data.

  - You want a clear project structure and CI/CD guidance to prevent architecture drift.


Copyable .cursorrules Configuration


FRAMEWORK_ROLE: Backend: Node.js + Express; Frontend: React/Next.js; DB: PostgreSQL; AI: Cursor AI rules for dynamic pricing dashboards
CODE_STYLE: TypeScript; ESLint; Prettier; Airbnb
ARCHITECTURE: server/controllers; server/models; server/routes; server/middleware; client/src; client/pages; client/components
AUTH: JWT tokens; OAuth2 for admin; TLS; environment secrets
DB: PostgreSQL; parameterized queries via pg; migrations
QUERIES: use parameterized queries; no string concatenation
VALIDATION: server side input validation
CACHING: Redis for aggregations
TESTING: Jest + Supertest; React Testing Library
CI_CD: GitHub Actions; lint before build; tests run
DO_NOT:
  - Do not concatenate SQL strings
  - Do not hardcode secrets
  - Do not skip input validation
ANTIPATTERNS:
  - UI side pricing calculations without API validation
  - Multiple data sources without a single source of truth
PRICING:
  - Round to two decimals; use numeric type

Recommended Project Structure


.
├── server/
│   ├── src/
│   │   ├── controllers/
│   │   ├── models/
│   │   ├── routes/
│   │   ├── services/
│   │   └── config/
│   └── tests/
├── client/
│   ├── src/
│   │   ├── components/
│   │   ├── pages/
│   │   └── hooks/
│   └── tests/
├── infra/
├── migrations/
└── scripts/
Core Engineering Principles



  - Single source of truth for pricing data across API, DB, and UI layers.

  - Validate and sanitize all inputs at the API boundary; never trust client data.

  - Idempotent pricing calculations and deterministic rounding for currency.

  - Observability: structured logs, metrics, and tracing for pricing operations.

  - Secure by default: least privilege DB access, secret rotation, and TLS everywhere.

  - Performance budgets: cache frequent aggregations and paginate dashboards.

  - Cursor AI rules guide development with auditable decisions and backstop rules.


Code Construction Rules



  - Use TypeScript types for request/response shapes and domain models.

  - All SQL must be parameterized; avoid string concatenation to prevent SQL injection.

  - Pricing calculations use numeric types with explicit rounding to two decimals.

  - External API calls (if any) are gated behind timeouts and retries with backoff.

  - All migrations are versioned and tested in CI before production deployment.

  - Frontend dashboards fetch server-validated data; avoid client-side trust for pricing logic.


Security and Production Rules



  - Enforce HTTPS and TLS; use short-lived JWTs with rotation on refresh.

  - Implement role-based access control for sensitive pricing data.

  - Rate limit pricing endpoints; monitor anomalies and implement feature flags.

  - Validate inputs server-side; sanitize all outputs to prevent leakage or exposure of internal schemas.

  - Encrypt or use vault-managed secrets; avoid hard-coded credentials.


Testing Checklist



  - Unit tests for pricing calculation helpers and validators.

  - Integration tests for API endpoints with parameterized data scenarios.

  - End-to-end tests covering data flow from DB to dashboard rendering.

  - CI checks for linting, type checks, and test suites on PRs.

  - Load tests for pricing aggregations and caching layers.


Common Mistakes to Avoid



  - Relying on client-side pricing logic without server verification.

  - Neglecting currency precision and rounding rules in aggregations.

  - Skipping migrations in CI or failing to migrate production data safely.

  - Hardcoding secrets or using insecure defaults in configs.



Related implementation resources: AI Use Case for Airbnb Hosts Using Guesty To Dynamically Adjust Nightly Pricing Based On Local Events and Designing secure Server Actions with mandatory input schema validations at the server boundary.




FAQ


What stack does this Cursor Rules Template target?


It targets a Node.js + Express backend with PostgreSQL for data persistence and a React/Next.js frontend. Cursor AI rules guide the data flow, security, and testing strategies specific to dynamic pricing dashboards for marketplace sellers.


How do I paste the .cursorrules into my project?


Copy the code block under Copyable .cursorrules Configuration and paste it into a new file named .cursorrules at your project root. Then adjust paths, environment references, and any stack-specific constants before running your build and tests.


How is currency precision handled?


Pricing values use numeric types with two-decimal rounding. All aggregations apply explicit rounding at the API boundary, and formatting to strings is performed only in the UI.


What security considerations are included?


The template enforces JWT-based authentication, TLS, input validation, and role-based access control for pricing data. Secrets are sourced from environment variables or a vault, never from code, and all sensitive endpoints are rate-limited.


How can I extend the template for multi-tenant sellers?


Introduce a tenant_id in pricing tables, scopes, and caches. Add middleware for tenant isolation, enforce row-level security policies in PostgreSQL, and use per-tenant caching buckets to prevent cross-tenant data leakage.

Overview

This Cursor rules configuration provides a practical, copyable Cursor Rules Template for building a dynamic pricing dashboard tailored to marketplace sellers. It targets a Node.js + Express backend with a PostgreSQL data layer and a React/Next.js frontend. The rules ensure safe AI-assisted development, enforce data integrity, and guide Cursor AI through architecture, security, and testing constraints for this stack.

When to Use These Cursor Rules

  • You are building a dynamic pricing dashboard for marketplace sellers using a Node.js + Express backend with PostgreSQL.
  • You need consistent currency handling, auditing, and deterministic pricing calculations.
  • You require server-side validation and safe data access controls for pricing data.
  • You want a clear project structure and CI/CD guidance to prevent architecture drift.

Copyable .cursorrules Configuration

FRAMEWORK_ROLE: Backend: Node.js + Express; Frontend: React/Next.js; DB: PostgreSQL; AI: Cursor AI rules for dynamic pricing dashboards
CODE_STYLE: TypeScript; ESLint; Prettier; Airbnb
ARCHITECTURE: server/controllers; server/models; server/routes; server/middleware; client/src; client/pages; client/components
AUTH: JWT tokens; OAuth2 for admin; TLS; environment secrets
DB: PostgreSQL; parameterized queries via pg; migrations
QUERIES: use parameterized queries; no string concatenation
VALIDATION: server side input validation
CACHING: Redis for aggregations
TESTING: Jest + Supertest; React Testing Library
CI_CD: GitHub Actions; lint before build; tests run
DO_NOT:
  - Do not concatenate SQL strings
  - Do not hardcode secrets
  - Do not skip input validation
ANTIPATTERNS:
  - UI side pricing calculations without API validation
  - Multiple data sources without a single source of truth
PRICING:
  - Round to two decimals; use numeric type

Recommended Project Structure

.
├── server/
│   ├── src/
│   │   ├── controllers/
│   │   ├── models/
│   │   ├── routes/
│   │   ├── services/
│   │   └── config/
│   └── tests/
├── client/
│   ├── src/
│   │   ├── components/
│   │   ├── pages/
│   │   └── hooks/
│   └── tests/
├── infra/
├── migrations/
└── scripts/

Core Engineering Principles

  • Single source of truth for pricing data across API, DB, and UI layers.
  • Validate and sanitize all inputs at the API boundary; never trust client data.
  • Idempotent pricing calculations and deterministic rounding for currency.
  • Observability: structured logs, metrics, and tracing for pricing operations.
  • Secure by default: least privilege DB access, secret rotation, and TLS everywhere.
  • Performance budgets: cache frequent aggregations and paginate dashboards.
  • Cursor AI rules guide development with auditable decisions and backstop rules.

Code Construction Rules

  • Use TypeScript types for request/response shapes and domain models.
  • All SQL must be parameterized; avoid string concatenation to prevent SQL injection.
  • Pricing calculations use numeric types with explicit rounding to two decimals.
  • External API calls (if any) are gated behind timeouts and retries with backoff.
  • All migrations are versioned and tested in CI before production deployment.
  • Frontend dashboards fetch server-validated data; avoid client-side trust for pricing logic.

Security and Production Rules

  • Enforce HTTPS and TLS; use short-lived JWTs with rotation on refresh.
  • Implement role-based access control for sensitive pricing data.
  • Rate limit pricing endpoints; monitor anomalies and implement feature flags.
  • Validate inputs server-side; sanitize all outputs to prevent leakage or exposure of internal schemas.
  • Encrypt or use vault-managed secrets; avoid hard-coded credentials.

Testing Checklist

  • Unit tests for pricing calculation helpers and validators.
  • Integration tests for API endpoints with parameterized data scenarios.
  • End-to-end tests covering data flow from DB to dashboard rendering.
  • CI checks for linting, type checks, and test suites on PRs.
  • Load tests for pricing aggregations and caching layers.

Common Mistakes to Avoid

  • Relying on client-side pricing logic without server verification.
  • Neglecting currency precision and rounding rules in aggregations.
  • Skipping migrations in CI or failing to migrate production data safely.
  • Hardcoding secrets or using insecure defaults in configs.

Related implementation resources: AI Use Case for Airbnb Hosts Using Guesty To Dynamically Adjust Nightly Pricing Based On Local Events and Designing secure Server Actions with mandatory input schema validations at the server boundary.

FAQ

What stack does this Cursor Rules Template target?

It targets a Node.js + Express backend with PostgreSQL for data persistence and a React/Next.js frontend. Cursor AI rules guide the data flow, security, and testing strategies specific to dynamic pricing dashboards for marketplace sellers.

How do I paste the .cursorrules into my project?

Copy the code block under Copyable .cursorrules Configuration and paste it into a new file named .cursorrules at your project root. Then adjust paths, environment references, and any stack-specific constants before running your build and tests.

How is currency precision handled?

Pricing values use numeric types with two-decimal rounding. All aggregations apply explicit rounding at the API boundary, and formatting to strings is performed only in the UI.

What security considerations are included?

The template enforces JWT-based authentication, TLS, input validation, and role-based access control for pricing data. Secrets are sourced from environment variables or a vault, never from code, and all sensitive endpoints are rate-limited.

How can I extend the template for multi-tenant sellers?

Introduce a tenant_id in pricing tables, scopes, and caches. Add middleware for tenant isolation, enforce row-level security policies in PostgreSQL, and use per-tenant caching buckets to prevent cross-tenant data leakage.