Cursor Rules Template: NestJS + Next.js + PostgreSQL for B2B Wholesale Portal

Overview

Cursor rules configuration for a B2B wholesale portal built with a NestJS API, Next.js frontend, and PostgreSQL data layer using TypeORM. This Cursor Rules Template enables multi-tenant account catalogs, bulk pricing, quotes, and an approvals workflow. Direct answer: this page provides a copyable .cursorrules block you can paste into your project root to guide Cursor AI through stack-specific development tasks.

When to Use These Cursor Rules

You are implementing a B2B wholesale ordering portal with account-scoped catalogs and complex pricing rules.
You want Cursor AI to stay within a NestJS API + Next.js UI + PostgreSQL data layer using TypeORM.
You need deterministic guidance for quotes, approvals, and audit trails in production.
You must enforce security constraints, multi-tenant isolation, and CI/CD quality gates.

Copyable .cursorrules Configuration

# Cursor Rules Template for NestJS + Next.js + PostgreSQL (TypeORM)
# Framework Role & Context
- You are Cursor AI configured to assist a NestJS API + Next.js frontend + PostgreSQL data store using TypeORM.
- Your outputs must follow stack conventions, security constraints, and multi-tenant patterns for a B2B portal.

# Code Style and Style Guides
- Language: TypeScript
- Linters: ESLint, Prettier; align with project's tsconfig.json and .prettierrc
- Naming: PascalCase for classes, camelCase for vars, kebab-case for CLI/paths
- Opinions: Prefer interfaces for DTOs, strictNullChecks, and explicit types

# Architecture & Directory Rules
- Monorepo layout with apps/api (NestJS) and apps/web (Next.js)
- Domain modules: auth, catalogs, pricing, quotes, approvals, tenants
- Use NestJS modules, DTOs, Entities with TypeORM; migrations for schema changes
- Public API gateway guarded by role-based access control (RBAC)
- Use a central config service for environment-specific values

# Authentication & Security Rules
- Use short-lived access tokens (JWT) with rotation via refresh tokens
- Admin and tenant admins have elevated scopes; enforce RBAC checks at service boundaries
- Input validation and output escaping at every boundary; avoid password storage in logs
- Do not log sensitive data; mask PII in non-production logs

# Database and ORM patterns
- PostgreSQL as primary data store; TypeORM as ORM; migrations applied via CI
- Multi-tenant strategy: per-tenant schema or siloed tables with tenant_id column; prefer per-tenant schema for isolation
- Use parameterized queries; avoid string concatenation in raw SQL
- Use query builders for complex pricing rules to prevent SQL injection

# Testing & Linting Workflows
- Unit tests with Jest; coverage thresholds >= 80%
- Integration tests for pricing, quotes, and approvals flows
- End-to-end tests with Playwright for critical user journeys
- GitHub Actions: lint, test, build, and deploy stubs; cache node modules

# Prohibited Actions & Anti-patterns
- Do not bypass authentication or RBAC; no hard-coded admin bypasses
- Do not generate dynamic SQL via string interpolation
- Do not create cross-tenant data leaks; ensure tenant isolation is enforced
- Do not assume frontend state can bypass backend validations

Recommended Project Structure

project-root/
├─ apps/
│  ├─ api/        # NestJS API
│  │  ├─ src/
│  │  │  ├─ modules/
│  │  │  │  ├─ auth/
│  │  │  │  ├─ catalogs/
│  │  │  │  ├─ pricing/
│  │  │  │  ├─ quotes/
│  │  │  │  ├─ approvals/
│  │  │  │  └─ tenants/
│  │  │  └─ main.ts
│  │  └─ test/
│  ├─ web/        # Next.js frontend
│  │  ├─ src/
│  │  │  ├─ pages/
│  │  │  ├─ components/
│  │  │  └─ lib/
│  │  └─ tests/
│  └─ shared/     # shared DTOs, interfaces, utilities
├─ apps/
├─ configs/
├─ migrations/
├─ scripts/
└─ README.md

Core Engineering Principles

Explicit contracts: clear DTOs, interfaces, and domain boundaries.
Security by default: least privilege RBAC, audit logs, and encrypted credentials.
Deterministic testing: unit, integration, and end-to-end tests with CI validation.
Tenant isolation: strict data separation and schema management.
Observability: structured logging, metrics, and tracing for pricing decisions.

Code Construction Rules

DTOs must validate input with class-validator; fail fast on invalid data.
Pricing logic must reside in domain services with explicit unit tests.
Queries against PostgreSQL should use parameterization and QueryBuilder where applicable.
Catalog rules must be evaluated per-account with tenant_id scoping.
Quotes and approvals workflow should be state-machine driven with auditable events.

Security and Production Rules

JWT tokens with rotation; refresh tokens securely stored and rotated on use.
RBAC checks at controllers and guarded routes; avoid permissive defaults.
Environment parity: separate dev/stage/prod; use feature flags for risky changes.
Data migrations reviewed and approved; run in CI with rollback strategies.

Testing Checklist

Unit tests cover DTO validation and services; target 80%+ coverage.
Integration tests verify multi-tenant catalog creation, bulk pricing rules, and quotes flow.
End-to-end tests simulate user journeys from catalog browse to quote approval.
CI runs lint, tests, and builds; production-like test data is used.
Security tests validate RBAC and token rotation flows.

Common Mistakes to Avoid

Assuming frontend state suffices for security; always validate on server.
Hard-coding tenant logic; prefer explicit tenant_id scoping and migrations.
Neglecting migrations in CI/CD; schemas must evolve safely.
Over-optimizing with eager loading; use proper relations and queries for pricing.

Related Cursor rules templates

Explore adjacent Cursor rules templates for similar stacks, workflows, and production constraints.

FAQ

What is a Cursor Rules Template and why use it for a NestJS + Next.js B2B portal?

A Cursor Rules Template provides stack-specific guidance for building a multi-tenant wholesale portal. It codifies role-based constraints, data access, and process flows for catalogs, pricing, quotes, and approvals using Cursor AI. This helps ensure consistent architecture and safer AI-assisted development.

Does this template support account-specific catalogs and bulk pricing?

Yes. The rules enforce per-account catalogs, tenant-scoped pricing rules, and approval workflows, with isolation at the PostgreSQL level and TypeORM entities designed to reflect account boundaries.

How are quotes and approvals modeled in Cursor Rules?

Quotes are represented as domain events with staged states (draft, submitted, approved, rejected). Approvals route to designated approvers, with audit trails and configurable thresholds to trigger notifications and escalation when needed.

What security measures are recommended for production?

Use short-lived access tokens with rotation, RBAC enforcement, encrypted credentials, audit logging, and strict data access rules. Never bypass authentication; validate all inputs and enforce tenant isolation in every service layer.

How do I test and deploy this template?

Run unit and integration tests locally, then run CI pipelines to lint, test, and build. End-to-end tests should simulate real customer journeys. Deployment should use feature flags and staged rollouts to minimize risk.

Target User

Use Cases