Cursor Rules TemplatesCursor Rules Template

Cursor Rules Template: Logistics Fleet Management with Live Tracking

A Cursor rules template for building a Node.js + PostgreSQL logistics fleet management app with real-time vehicle tracking and domain modules for vehicles, drivers, routes, fuel, and maintenance.

cursor-rules templatefleet managementlogisticsNode.jsExpressTypeScriptPostgreSQLKnexlive trackingvehiclesdriversroutesfuelmaintenance

Target User

Developers building logistics fleet management apps with live tracking

Use Cases

  • Real-time vehicle tracking
  • Route optimization
  • Driver assignment
  • Fuel and maintenance logging

Markdown Template

Cursor Rules Template: Logistics Fleet Management with Live Tracking

FRAMEWORK: Node.js | Express | TypeScript | PostgreSQL
STACK: fleet-management
ROLE: System Architect
CONTEXT: Build a scalable logistics fleet management app with vehicles, drivers, routes, fuel, maintenance, and live tracking
STYLE: ESLint + Prettier, TSConfig
ARCHITECTURE: layered: api, services, repositories, models, web socket gateway, auth
DIRECTORY_RULES: src/controllers, src/services, src/repositories, src/models, src/middlewares, src/routes, migrations
AUTH: JWT RS256, refresh tokens, RBAC
SECURITY: TLS, CSRF protection, CORS, secret management via env vars
DATABASE: PostgreSQL, Knex
PATTERNS: Vehicle, Driver, Route, FuelLog, MaintenanceLog, LiveLocation
TESTING: Jest + Supertest; CI workflow with unit and integration tests
PROHIBITED: avoid dynamic imports; avoid eval; avoid string-constructed SQL; never log secrets
ANTI_PATTERNS: monoliths; inline SQL; last-mile ad-hoc changes

Overview

The Cursor rules template for a logistics fleet management app on a Node.js + PostgreSQL stack defines how Cursor AI should reason about code generation, data models, and APIs. This Cursor rules template covers vehicles, drivers, routes, fuel, maintenance, and live tracking, and ensures alignment with Cursor AI rules.

When to Use These Cursor Rules

  • Starting a new fleet management project with Node.js and PostgreSQL.
  • Implementing real-time live tracking and route planning modules.
  • Enforcing stack-specific architecture, security, and testing practices.
  • Providing a copyable .cursorrules configuration for team onboarding.

Copyable .cursorrules Configuration

FRAMEWORK: Node.js | Express | TypeScript | PostgreSQL
STACK: fleet-management
ROLE: System Architect
CONTEXT: Build a scalable logistics fleet management app with vehicles, drivers, routes, fuel, maintenance, and live tracking
STYLE: ESLint + Prettier, TSConfig
ARCHITECTURE: layered: api, services, repositories, models, web socket gateway, auth
DIRECTORY_RULES: src/controllers, src/services, src/repositories, src/models, src/middlewares, src/routes, migrations
AUTH: JWT RS256, refresh tokens, RBAC
SECURITY: TLS, CSRF protection, CORS, secret management via env vars
DATABASE: PostgreSQL, Knex
PATTERNS: Vehicle, Driver, Route, FuelLog, MaintenanceLog, LiveLocation
TESTING: Jest + Supertest; CI workflow with unit and integration tests
PROHIBITED: avoid dynamic imports; avoid eval; avoid string-constructed SQL; never log secrets
ANTI_PATTERNS: monoliths; inline SQL; last-mile ad-hoc changes

Recommended Project Structure

fleet-management/
└── backend/
    └── src/
        ├── controllers/
        ├── models/
        ├── repositories/
        ├── routes/
        ├── services/
        ├── middlewares/
        ├── config/
        ├── migrations/
        └── tests/

Core Engineering Principles

  • Layered architecture with clear boundaries (API, services, data access).
  • Type-safe code using TypeScript for all server components.
  • Domain-driven design around fleet management entities.
  • Idempotent operations and robust input validation.
  • Explicit error handling and structured, observable logs.
  • Safe AI-assisted development with strict anti-patterns.

Code Construction Rules

  • Use repository and service layers for all data access.
  • Use parameterized queries via Knex to prevent SQL injection.
  • Validate all API inputs with a DTO pattern and schema validation.
  • Persist live-tracking data with a dedicated LiveLocation model and efficient indexing.
  • Keep business logic in services; keep controllers thin.
  • Write unit tests for services and integration tests for routes.
  • Do not bypass authentication where required; enforce RBAC.

Security and Production Rules

  • Use HTTPS/TLS in all environments; rotate secrets via environment variables.
  • JWT-based authentication with RS256; use short-lived access tokens and refresh tokens.
  • Audit trails for critical actions (device assignment, route changes, maintenance updates).
  • Limit data exposure; redact PII in logs and responses.
  • Enable network-level security (CORS, IP allowlists) and request rate limiting.

Testing Checklist

  • Unit tests for services and models.
  • Integration tests for API routes, DB interactions, and auth.
  • End-to-end tests for critical flows: vehicle check-in, route assignment, live tracking join/leave.
  • CI pipeline runs linting, type checking, and test suite on each PR.

Common Mistakes to Avoid

  • Relying on global state or singletons across requests.
  • Unparameterized SQL or string concatenation in queries.
  • Neglecting security reviews for live-tracking endpoints.
  • Over-optimistic assumptions about real-time data throughput.
  • Ignoring migrations and data seeding in development.

Related Cursor rules templates

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

FAQ

What is a Cursor rules template for a logistics fleet management app?

A Cursor rules template provides a copyable .cursorrules block and stack-specific guidelines to help Cursor AI reason about a Node.js + PostgreSQL fleet app with vehicles, drivers, routes, fuel, maintenance, and live tracking.

What stack does this template target?

Node.js with Express, TypeScript, PostgreSQL, Knex, Socket.IO for live tracking, and JWT-based authentication. The rules enforce safe AI-assisted development and consistent architecture.

How should live tracking be modeled?

Live tracking should stream vehicle locations via WebSocket, store only necessary coordinates in a LiveLocation entity, and persist logs in PostgreSQL with proper indexing and privacy controls.

What are the prohibited actions?

Do not execute arbitrary code or eval, avoid concatenated SQL or unsafe raw queries, do not expose secrets in logs, and avoid architecture drift by enforcing repository/service boundaries.

Where do I paste the .cursorrules block?

Place the block at the project root as .cursorrules, then run the Cursor AI workflow to apply the rules during development.

What are the main entities in this domain?

Vehicle, Driver, Route, FuelLog, MaintenanceLog, and LiveLocation form the core entities, with relationships linking Vehicles to Drivers and Routes to Stops for planning and tracking.