Cursor Rules Template: Node/NestJS Tour Operator SaaS

Overview

This Cursor rules template defines the Cursor AI behavior for building a tour operator management SaaS with packages, bookings, guides, payments, and customer communications. It targets a Node.js / NestJS stack on PostgreSQL with Stripe for payments and email/SMS for customer channels. You can paste the copyable .cursorrules configuration below into your project root.

Direct answer: Use this Cursor rules template to guide AI-driven implementation of modular domains (Packages, Bookings, Guides, Payments, Customers) with secure auth, reliable data access, and testable workflows.

When to Use These Cursor Rules

• Starting a Node.js / NestJS based tour operator SaaS with packages, bookings, guides, payments, and customer communications.
• Defining domain boundaries and data models for Packages, Bookings, Guides, and Payments.
• Enforcing security, authentication, authorization, and PCI-conscious payment flows.
• Orchestrating async tasks like email/SMS notifications and payment webhooks.
• Setting up testable, CI-friendly architectures with clear module boundaries.

Copyable .cursorrules Configuration

# Cursor rules for Node.js / NestJS Tour Operator SaaS
Framework Role & Context
Role: System Architect for a Node.js + NestJS backend that manages Packages, Bookings, Guides, Payments, and Customer Communications for a tour operator SaaS.
Context: Build safe, maintainable AI-assisted guidance. Avoid unsafe patterns. Use a clean, modular architecture.
Code Style and Style Guides
- Language: TypeScript
- Typing: strict or higher
- Formatting: Prettier-compatible; formatting rules enforced by CI
Architecture & Directory Rules
- Use a modular domain layout: src/modules/{packages, bookings, guides, payments, customers}
- Repositories for data access; services for business logic; controllers for HTTP APIs
- DTOs for all input/output; validators for all endpoints
- Centralized config and environment variables (DATABASE_URL, STRIPE_API_KEY, EMAIL_SERVICE, etc.)
Authentication & Security Rules
- JWT-based authentication with short-lived access tokens and refresh tokens
- RBAC with roles: admin, operator, guide, customer
- Do not log secrets; sanitize PII in logs; enforce HTTPS
Database and ORM patterns
- PostgreSQL as the data store
- Use parameterized queries or ORM-layer abstractions; avoid string concatenation for queries
- Transactional boundaries for bookings and payments; use compensating actions on failures
Testing & Linting Workflows
- Unit tests for services and domain logic
- Integration tests for repositories and adapters
- End-to-end tests for core flows (booking, payment, notification)
- CI/CD with lint, test, and build steps
Prohibited Actions and Anti-patterns for the AI
- Do not expose secrets or API keys in code or prompts
- Do not bypass authentication or authorization checks
- Do not generate destructive migrations without validation
- Do not propose insecure payment flows or handling of PCI data outside PCI scope

Recommended Project Structure

src/
  modules/
    packages/
      controllers/
      services/
      dtos/
      entities/
      repositories/
    bookings/
    guides/
    payments/
    customers/
  common/
  config/
  database/
  migrations/
  tests/

Core Engineering Principles

• Clear domain boundaries and single-responsibility modules for Packages, Bookings, Guides, Payments, and Customers.
• Strict typing and input validation for every API boundary.
• Idempotent operations where possible; robust error handling and retries.
• Observability: structured logs, metrics, and traceability across services.
• Security by design: least privilege, secret management, and PCI-conscious payment handling.
• Testable architecture with end-to-end coverage and CI/CD gates.

Code Construction Rules

• Each domain (Packages, Bookings, Guides, Payments, Customers) is a bounded context with its own module, controllers, services, and data models.
• Define DTOs for all input/output and validate with consistent schemas.
• Use repository pattern for data access; ensure transactions for multi-step operations (booking + payment).
• Consistent naming: entities in singular PascalCase; DTOs in PascalCase; services in PascalCase.
• Do not rely on dynamic SQL; always parameterize queries or use a safe ORM abstraction.
• Guard endpoints with role-based access checks and input validation guards.

Security and Production Rules

• Enforce TLS/HTTPS in all environments and store secrets in a protected vault.
• Implement RBAC with roles: admin, operator, guide, customer; ensure least privilege access.
• Secure payment flows by avoiding PCI data handling on your servers; use tokenization via Stripe.
• Implement audit logging for critical actions (booking creation, payment events).

Testing Checklist

• Unit tests for domain services and validators.
• Integration tests for repository actions and API adapters.
• Contract tests for external integrations (Stripe, email provider).
• End-to-end tests of booking -> payment -> notification flows.
• Static analysis and lint checks in CI; run tests on pull requests.

Common Mistakes to Avoid

• Ignoring timezone handling for bookings and schedules.
• Overly broad permissions or missing RBAC checks on APIs.
• Hardcoding secrets or environment-specific configurations in code.
• Skipping tests or skipping data migration validations.

Related Cursor rules templates

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

• Cursor Rules Template for Node.js Hotel Booking Platform
• Cursor Rules Template: Salon Booking System with Staff Calendars, Services, Packages, Memberships, and Payments
• Cursor Rules Template: LMS with Courses, Lessons, Quizzes, Certificates, Payments, and Admin Dashboard
• Cursor Rules Template: Rental Marketplace with Property Listings, Applications, Tenant Screening, Payments and Messaging

FAQ

What is this Cursor rules template for the Node/NestJS tour operator stack?

The template provides a precise, copyable .cursorrules block and guidelines to implement a modular tour operator SaaS with packages, bookings, guides, payments, and customer communication, all tailored to a Node/NestJS/PostgreSQL stack.

Which stack is targeted by this template?

The template targets Node.js with NestJS, PostgreSQL for data, Stripe for payments, and a Node-based service layer for packages, bookings, guides, and customer notifications.

How do I apply the copyable .cursorrules?

Copy the entire .cursorrules block from the Copyable section and paste it into your project root as .cursorrules. The rules guide AI-driven coding, architecture decisions, and safety checks specific to this stack.

Can this template be extended for multi-tenant deployments?

Yes. The template includes RBAC and module boundaries that support multi-tenant expansions; you can add a tenant layer in config and separate schemas per tenant if needed.

What tests are recommended with this template?

Unit tests for services, integration tests for repositories and adapters, and end-to-end tests for core flows like booking creation, payment processing, and customer notifications. Integrate with CI/CD pipelines.

Is Stripe used for payments in this template?

Yes. The template assumes Stripe for tokenized payment handling and webhooks, with server-side validation and PCI-conscious practices.