Cursor Rules Template for Circular Economy Marketplace (NestJS + PostgreSQL) | Suhas Bhairav

Overview

Direct answer: This Cursor Rules Template provides a structured, auditable Cursor AI instruction set for a NestJS + PostgreSQL stack. It covers a circular economy marketplace focused on reusable materials, suppliers, logistics, and transaction workflows, with security, testing, and deployment baked in.

When to Use These Cursor Rules

Starting a new circular economy marketplace backend using NestJS + PostgreSQL.
Enforcing clear domain boundaries: materials, suppliers, logistics, transactions, and payments.
Need auditable AI interactions and consistent code generation across modules.

Copyable .cursorrules Configuration

// Framework Role & Context
FRAMEWORK: NestJS + PostgreSQL
ROLE: Backend Architect for a circular economy marketplace
CONTEXT: Build an API-first marketplace for reusable materials with suppliers, logistics and transactional workflows using Cursor AI. Ensure type safety and testability.

// Code Style and Style Guides
LANG: TypeScript
STYLE: ESLint + Prettier; AirBnB style; strict TS config

// Architecture & Directory Rules
ARCH: Monorepo with apps/api, apps/admin, libs/shared
DIRS: domains materials, suppliers, logistics, transactions, auth, payments
MODULES: auth, payments, inventory, orders, shipments

// Authentication & Security Rules
AUTH: JWT with refresh tokens; RBAC roles for suppliers and buyers
SECURITY: TLS, HSTS, CSRF protection for web flows, secrets via environment, audit logs

// Database and ORM patterns
ORM: TypeORM or Prisma (choose TypeORM if NestJS preference)
DB: PostgreSQL; migrations, seed scripts

// Testing & Linting Workflows
TEST: Jest unit tests; integration tests for services; e2e tests with Cypress
CI: GitHub Actions: lint, test, build, deploy to staging and prod

// Prohibited Actions and Anti-patterns
DO_NOT: hard-coded credentials, building raw string SQL, bypassing validation, skipping migrations, exposing DB dumps
ANTI: circular dependencies between modules; mixing domain responsibilities

Recommended Project Structure

/
  apps/
    api/
      src/
        main.ts
        app.module.ts
        modules/
          materials/
          suppliers/
          logistics/
          transactions/
          auth/
          payments/
        dtos/
        interfaces/
        repositories/
        services/
        controllers/
    admin/
    worker/
  libs/
    shared/
      src/
        config/
        constants/
        utils/
        decorators/
        guards/

Core Engineering Principles

Modular, domain-driven architecture with clear module boundaries.
Idempotent operations and strict transaction boundaries across materials, suppliers, logistics, and transactions.
Type-safe data models with strict input validation and API contracts.
Observability: structured logging, metrics, and tracing for every workflow.
Auditable AI-enabled code generation with deterministic outputs.
Security-by-default: RBAC, proper secrets management, and secure API design.

Code Construction Rules

Domain modules mirror business concepts: materials, suppliers, logistics, transactions, auth.
Controllers remain thin; business logic lives in services; DTOs define inputs/outputs.
Use repository or ORM data mappers with explicit migrations.
All external calls are parameterized; avoid raw string interpolation in queries.
Cursor AI outputs must be validated against the API schema before use.
Testing drives development: unit tests for services, integration tests for repositories, and e2e flows for critical paths.

Security and Production Rules

JWT-based authentication with refresh tokens; RBAC to separate supplier and buyer capabilities.
Enforce TLS, secure cookies, and CSRF protections for web interfaces.
Rate limiting, IP allow/deny lists, and audit trails for sensitive actions.
Environment-specific config; secrets stored securely via vaults or KMS.

Testing Checklist

Unit tests for each service; mocks for external dependencies.
Integration tests for repository and service interactions with a real PostgreSQL instance.
E2E tests covering supplier onboarding, material listing, logistics orchestration, and transaction completion.
CI pipelines run lint, type checks, unit tests, integration tests, and deployment to staging.

Common Mistakes to Avoid

Ignoring migrations; staging and production drift from schema changes.
Unbounded queries or query construction without parameterization.
Bypassing auth or using privileged tokens in client code.
Overloading a single module with multiple domain responsibilities.

Related Cursor rules templates

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

FAQ

What is the purpose of this Cursor Rules Template?

This template provides a structured set of Cursor AI instructions to guide a NestJS + PostgreSQL stack for a circular economy marketplace. It defines roles, architecture, security, and testing rules so AI can generate consistent, safe code blocks and configurations.

Which stack does this template target?

The template targets a NestJS backend with PostgreSQL as the data store, using TypeORM for ORM patterns and a modular monorepo. It emphasizes domain-driven modules, RBAC authentication, and CI/CD workflows for reliable deployments.

How can I extend the rules for new domains?

Extend domain modules under apps/api/src/modules and align services, DTOs, and migrations to include the new aggregates. Maintain consistent rule structure across modules and ensure tests cover the new paths.

How should I run tests and validate the rules?

Run unit tests for services, integration tests for repositories, and end-to-end tests for critical flows. Use CI to run lint, type checks, and tests on every pull request and on deploy to staging.

What are deployment prerequisites?

Ensure migrations run on deploy, secrets loaded securely, and TLS enabled. Verify health checks, monitoring, and rollback procedures for safe production releases.

Circular Economy Marketplace: Cursor Rules Template for NestJS + PostgreSQL

Target User

Use Cases