Food Delivery Admin Cursor Rules Template for Cursor AI | Suhas Bhairav

Overview

Direct answer: This Cursor rules template configures Cursor AI to assist development and operations of a food delivery admin platform, covering restaurants, menus, orders, drivers, payouts, and real-time tracking. It targets a modern Next.js admin frontend with a Node.js backend, PostgreSQL for persistence, Redis for caching and pub/sub, and Socket.IO for live events.

The Cursor rules configuration provides a copyable, stack-specific .cursorrules block that enforces data models, access controls, and safe AI interactions while guiding implementation across frontend, API, and real-time services.

When to Use These Cursor Rules

Starting a new food delivery admin project that must scale with restaurants, menus, orders, drivers, and payouts.
Defining consistent data access patterns and RBAC across Next.js pages and NestJS/Express APIs.
Integrating real-time order status and driver location updates via WebSocket-based events.
Enforcing internal security and auditing for payout workflows and driver payments.
Providing a safe, maintainable foundation for AI-assisted code generation and guidance.

Copyable .cursorrules Configuration

CursorRules
Framework: Next.js (frontend) + Node.js backend (TypeScript)
Stack: Next.js + NestJS/Express, PostgreSQL, Redis, Socket.IO
Role: Cursor AI assistant for a food delivery admin platform; maintain secure, scalable codebase
Context: You build and maintain an admin system for restaurants, menus, orders, drivers, payouts, and real-time tracking. Use PostgreSQL as the primary datastore; Redis for cache and pub/sub; Socket.IO for real-time events. Apply RBAC with roles: admin, restaurant-manager, driver, finance; ensure data integrity and auditability.
CodeStyle: TypeScript, ESLint + Prettier, strict mode, 4-space indents, 100-char max line length; prefer explicit types; keep controllers thin.
Architecture: Monorepo with apps/admin (Next.js), api (NestJS/Express), and infra (db, cache, ws). Domain logic lives in api/src/modules and api/src/domain; UI should call stable APIs only.
DirectoryRules:
  - Do not place business rules in the UI layer; implement services under api/src/modules and domain under api/src/domain.
  - Keep real-time tracking logic in the backend modules/tracking; avoid duplicating logic in the frontend.
AuthSecurity:
  - Use OAuth2 / JWT with HTTP-only cookies for sessions; rotate refresh tokens; implement CSRF protection on state-changing endpoints.
DatabasePatterns:
  - PostgreSQL with Row-Level Security (RLS); use UUID primary keys; avoid N+1 queries via eager loading and proper relations; index critical foreign keys (restaurant_id, order_id, driver_id).
ORM/QueryPattern:
  - Implement a repository/service pattern; avoid raw SQL in controllers; use parameterized queries; prefer explicit migrations and versioned schemas.
TestingLintWorkflow:
  - Unit tests for services; integration tests for API endpoints; end-to-end tests for critical flows (order placement, real-time updates); CI runs lint, unit tests, integration tests; pre-commit hooks on push.
ProhibitedActionsAntiPatterns:
  - Do not embed business rules in UI components; do not bypass authorization checks; do not expose internal IDs or secrets to clients; do not skip input validation; do not ignore real-time event security.

Recommended Project Structure

/apps
  /admin       # Next.js frontend
  /api         # NestJS/Express backend
  /infra       # DB, cache, websockets, config
  /libs        # Shared types and utilities

/apps/admin
  /src
    /app
    /pages
    /components
    /styles

/apps/api
  /src
    /main.ts
    /modules
      /restaurants
      /menus
      /orders
      /drivers
      /payouts
      /tracking
    /domain
    /common

/infra
  /db          # Postgres schemas, migrations, seeds
  /cache       # Redis configurations
  /ws          # Socket.IO gateway and events

/libs
  /shared-types
  /utils

Core Engineering Principles

Strong typing and explicit contracts across frontend, API, and data models.
Security by default: RBAC, least privilege, proper input validation, and secure secrets handling.
Event-driven real-time capabilities with scalable pub/sub and reliable web sockets.
Clear separation of concerns: UI, API, and domain logic in distinct layers.
Observability: structured logs, metrics, and tracing for production reliability.

Code Construction Rules

Frontend pages must call stable API routes; avoid embedding business logic in pages/components.
All API endpoints should validate inputs with runtime schemas; use DTOs and guards.
Database access via repositories; avoid raw SQL in controllers; use parameterized queries.
Real-time events must be authenticated; include user context in event payloads and audit logs.
Keep .cursorrules blocks concise and stack-aware; update with feature flags for staged rollout.

Security and Production Rules

Enable TLS, HSTS, and secure cookies; rotate credentials and use secret management.
Implement rate limiting, input validation, and CSRF protection on state-changing endpoints.
Audit and log critical actions (payouts, driver updates, refunds) with immutable logs.
Apply database-level security with RLS; ensure data access respects role privileges.
Monitor real-time channels for abuse; throttle event streams and validate event schemas.

Testing Checklist

Unit tests for services and controllers with deterministic mocks.
Integration tests for REST and WebSocket interactions; verify RBAC enforcement.
End-to-end tests covering core flows: restaurant creation, menu updates, order lifecycle, driver tracking, payouts.
CI pipelines run lint, type checks, tests, and security scans; deploy with feature flags.

Common Mistakes to Avoid

Mixing business logic in UI components or pages.
Ignoring RBAC or relying on client-side checks alone.
Skipping input validation and trusting user input.
Overusing real-time channels without authentication or throttling.
Neglecting migrations and schema versioning in production workflows.

Related Cursor rules templates

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

FAQ

What is the exact purpose of this Cursor rules template?

This Cursor Rules Template provides a copyable .cursorrules block to guide Cursor AI in configuring a full-stack food delivery admin platform. It defines stack-specific roles, data models, real-time flows, and security constraints to accelerate safe AI-assisted development.

Which stack does this template target?

The template targets a Next.js admin frontend with a Node.js backend (NestJS/Express), PostgreSQL as the primary datastore, Redis for caching and pub/sub, and Socket.IO for real-time tracking of orders and drivers.

How do I apply the .cursorrules block in my project?

Copy the code from the Copyable .cursorrules Configuration section and paste it into a new file named .cursorrules at your project root. Review and tailor environment-specific values, then run your usual code-generation or AI-assisted tooling to align with the rules.

What should I verify before deploying?

Ensure RBAC roles are wired to API guards, validate input at every boundary, confirm real-time event authorization, test critical payouts flows, and run security and performance tests against staging before production.

How does real-time tracking integrate with the backend?

Real-time tracking uses WebSocket-based channels (Socket.IO) connected to the backend, publishing location updates and order status to authenticated clients. The Cursor AI rules enforce safe handling and validation of live data streams and ensure scalable event processing.

What are common pitfalls I should avoid?

Avoid embedding rules in UI code, bypassing RBAC, exposing internal IDs, or neglecting input validation and auditing. Keep business logic in the API/domain layer and protect all endpoints behind authorization checks.

Food Delivery Admin Platform - Cursor Rules Template

Target User

Use Cases