Warehouse Robotics Cursor Rules Template for Node.js + React + PostgreSQL

Overview

Direct answer: this Cursor Rules Template delivers production-focused Cursor AI guidance for building a warehouse robotics control dashboard on a Node.js + Express backend, a React frontend, and a PostgreSQL data layer. It codifies tasks, zones, exceptions, and operational analytics into a copyable .cursorrules configuration that you can paste at project root to align AI behavior with safe, observable engineering practices.

The Cursor rules configuration is designed to support a stack with a TypeScript codebase, strict API boundaries, and clear separation between server, client, and data access layers. It enables Cursor AI to draft rules that respect authentication, data privacy, and robust error handling while guiding the UI and backend to behave predictably under load.

When to Use These Cursor Rules

Starting a new warehouse robotics dashboard project that tracks tasks, zones, and exceptions in real time.
Enforcing consistent coding standards across a Node.js API and a React frontend with TypeScript.
Defining data access patterns for PostgreSQL with prepared statements and explicit migrations.
Implementing secure authentication and audit logging for robotics operations data.
Guiding testing, linting, and CI workflows to prevent regression in dashboard features.

Copyable .cursorrules Configuration

# Cursor Rules Template: Warehouse Robotics Dashboard
Framework Role & Context:
- You are Cursor AI configured to generate safe, production-ready code guidance for a Node.js (Express) API + React frontend + PostgreSQL data layer, written in TypeScript.
- Maintain strict boundaries between server, client, and data access; avoid embedding secrets in code.

Code Style and Style Guides:
- Language: TypeScript
- Linting: ESLint with standard rules; Prettier formatting; Arrow functions preferred; explicit types everywhere
- Naming: camelCase for vars, PascalCase for types, kebab-case for file/directory names
- Testing: Jest for unit tests; SuperTest for API tests; Cypress for end-to-end tests

Architecture & Directory Rules:
- Monorepo layout:
  apps/api        # Express + TS API
  apps/web        # React + TS frontend
  packages/common # shared utilities and types
- API should expose REST endpoints with OpenAPI-like typings; avoid leaking internal DB schemas
- All data access must occur through a single data layer in the API; UI should call API only
- Use a dedicated migrations tool; do not run ad-hoc schema changes from code

Authentication & Security Rules:
- Use JWT-based authentication with access and refresh tokens; keep secrets in environment variables or KMS
- Do not cache credentials; never store secrets in code or in the browser
- Enforce role-based access control (RBAC) for tasks, zones, and analytics endpoints
- Enable CSRF protection for browser-based requests; use secure, HttpOnly cookies

Database and ORM patterns:
- Database: PostgreSQL
- Access: node-postgres (pg) with parameterized queries
- Migrations: timestamped SQL migrations; avoid in-app schema changes
- ORM: optional; if used, prefer a simple query builder (e.g., Knex) over full-ORM abstractions

Testing & Linting Workflows:
- Unit tests for services and utilities
- Integration tests for API endpoints using SuperTest
- End-to-end tests for frontend flows using Cypress
- CI: run lint, tests, and type checks on pull requests; fail on TS errors

Prohibited Actions and Anti-patterns for the AI:
- Do not output insecure code or routes; no hard-coded secrets; no server-side secrets in React code
- Do not bypass authentication checks or authorization constraints
- Do not rely on client-side validation for security-critical logic
- Do not use eval or dynamic code execution in API or build steps
- Do not perform synchronous blocking operations that could freeze the event loop

# Paste this entire block into your project root as .cursorrules to drive Cursor AI generation in your warehouse robotics dashboard project

Recommended Project Structure

warehouse-dashboard/
├─ apps/
│  ├─ api/        # Express + TS API server
│  │  └─ src/
│  │     ├─ controllers/
│  │     ├─ routes/
│  │     └─ services/
│  └─ web/        # React + TS frontend
│     └─ src/
│        ├─ components/
│        ├─ pages/
│        └─ hooks/
├─ packages/
│  └─ common/     # shared types and utilities
└─ tests/          # shared test data and suites

Core Engineering Principles

Fail-safe by design: graceful degradation and explicit error handling
Idempotent API and UI actions to prevent duplicate work
Principle of least privilege for every role and endpoint
Clear separation of concerns across server, client, and data layers
Observability: structured logging, tracing, and metrics
Security by default: default deny, audit trails, and secret management
Cursor AI safety: validate inputs, constrain AI-drafted code, and avoid unsafe patterns

Code Construction Rules

Server API: define types for requests/responses; never rely on untyped data
Database: use parameterized queries; prefer prepared statements; centralize SQL fragments
Frontend: strong TypeScript types; a separate API client with typed endpoints
Authentication: store tokens in HttpOnly cookies; refresh tokens rotate
Validation: validate all inputs in the API layer (Zod or Joi recommended)
Error handling: avoid leaking internal error messages to clients; return sanitized errors
Logging: include request IDs; do not log secrets

Security and Production Rules

Use TLS; protect endpoints with RBAC; implement rate limiting and IP blocking where needed
Secret management: environment variables, vaults, or KMS; rotate keys regularly
Audit logging: log access to tasks, zones, and analytics data
CI/CD: run type checks, lint, tests, and security scanning on PRs
Containerization: image scanning; minimal base images; non-root container users

Testing Checklist

Unit tests for services and utilities with deterministic fixtures
API integration tests covering authentication, authorization, and error paths
Frontend tests for components and pages; end-to-end tests for critical user flows
Performance tests for task routing and analytics endpoints
Security tests for input validation and token handling

Common Mistakes to Avoid

Hard-coding secrets or tokens in code or in the frontend
Skipping migrations or relying on in-app schema migrations
Relying on client-side checks for security constraints
Not validating or sanitizing inputs at boundaries
Mixing UI state with business logic in API handlers

Related Cursor rules templates

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

FAQ

What stack is this Cursor Rules Template designed for?

It targets a Node.js + Express API, a React + TypeScript frontend, and a PostgreSQL data layer, with Cursor AI guiding safe, production-grade rules for a warehouse robotics dashboard.

What are the main components covered by this template?

The configuration covers tasks, zones, exceptions, and operational analytics within the warehouse robotics dashboard, including how AI rules interact with authentication, data access, and observability.

How do I apply the .cursorrules block?

Copy the entire code block into a file named .cursorrules at your project root. Cursor AI will parse it to tailor rules for your repo structure and CI/CD pipeline.

Can Cursor AI enforce security in this stack?

Yes. The rules emphasize secret management, RBAC, token handling, and sanitized error reporting to minimize exposure in production environments.

What testing approach is recommended?

Adopt unit tests for services, integration tests for API routes, and E2E tests for dashboard flows; integrate these in CI with type checks and linting to prevent regressions.

Target User

Use Cases