Field Sales Cursor Rules Template: Location Check-ins, Visits, Notes, Tasks, and Manager Analytics

Overview

The Cursor rules configuration is a copyable .cursorrules profile for a Field Sales Tracking app. It covers a Node.js + Express backend with PostgreSQL and a frontend that handles location check-ins, customer visits, notes, tasks, and manager analytics. This Cursor Rules Template is designed for Cursor AI to generate backend routes, data models, and business rules with safety constraints.

When to Use These Cursor Rules

• When building field sales workflows requiring location check-ins and visit logging.
• When you need structured notes and task management tied to customers and visits.
• When manager analytics and dashboards rely on consistent data integrity and auditability.
• When you want a repeatable, auditable pattern for security, testing, and production readiness.

Copyable .cursorrules Configuration

Framework Role & Context:
- Node.js + Express backend for a Field Sales Tracking app with location check-ins, customer visits, notes, tasks, and manager analytics. Cursor AI should generate endpoints, models, and business logic with clear responsibilities.

Code Style and Style Guides:
- TypeScript with strict mode, ESLint, and Prettier. Use Airbnb-style rules and import/order conventions. Enable tsconfig strict settings and noImplicitAny.

Architecture & Directory Rules:
- Backend in /src with controllers, models, routes, services, and middlewares. Separate config in /config and database access in /database.

Authentication & Security Rules:
- Use JWT-based authentication stored in httpOnly cookies; implement refresh tokens; enforce strong password hashing with bcrypt; enable CSRF protection and Helmet headers.

Database and ORM patterns:
- PostgreSQL with parameterized queries (prepared statements). Do not rely on dynamic SQL concatenation. Use a simple data mapper between controllers and DB queries. Create migrations and seed data in /database/migrations.

Testing & Linting Workflows:
- Jest for unit tests, Supertest for API integration tests, and TypeScript type checks. CI should run lint, test, and type-check on push.

Prohibited Actions and Anti-patterns for the AI:
- Do not bypass authentication or security controls. Do not expose secrets in code or logs. Do not generate destructive migrations without review. Do not rely on client-side validation alone; always enforce server-side checks.

Recommended Project Structure

backend/
  src/
    controllers/
    models/
    routes/
    services/
    middlewares/
    config/
    database/
  tests/
  scripts/
  Dockerfile

Core Engineering Principles

• Explicit boundaries between layers (controllers, services, models) for testability.
• Do not leak secrets; use environment variables and secret management.
• Type safety and clear contracts between components.
• Idempotent operations; robust error handling and retries where appropriate.
• Auditable data with consistent timestamps and user attribution.

Code Construction Rules

• All database access must use parameterized queries; avoid string interpolation for SQL.
• Location data must be stored with time zone awareness; use TIMESTAMPTZ in PostgreSQL.
• Endpoints should validate input with a schema validation library and return consistent error formats.
• API contracts must be stable across versions; deprecate endpoints with clear messaging.
• Ensure idempotent create/update operations and proper upserts for visits and notes.

Security and Production Rules

• Use TLS, secure cookies, and CSRF protection in production.
• Rotate signing keys, monitor access logs, and enforce least privilege on DB roles.
• Implement rate limiting and input sanitization to prevent abuse.
• Do not log PII or secrets in plaintext; redact sensitive fields in logs.

Testing Checklist

• Unit tests for controllers, services, and utilities; 100% code coverage is not required but targeted coverage is encouraged.
• Integration tests for endpoints with a PostgreSQL test database; verify auth, validation, and error cases.
• Contract tests for API responses; snapshot tests optional.
• CI/CD checks for linting, type-checking, tests, and security scans.
• Deploy checks in staging: health checks, race-condition checks, and load tests minimal.

Common Mistakes to Avoid

• Neglecting server-side validation and authorization in favor of client checks.
• Using unparameterized queries or building SQL strings from user input.
• Hardcoding secrets in repository or logs; rely on environment secrets or vaults.
• Skipping time zone handling in date/time fields; misaligning location times with user time zones.

Related Cursor rules templates

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

• Cursor Rules Template: SaaS Revenue Dashboard (MRR, ARR, Churn & Cohorts)
• Energy Monitoring Dashboard Cursor Rules Template for Cursor AI
• Cursor Rules Template: Client Onboarding Portal with Forms, Uploads, E-Sign and Admin Dashboards
• Cursor Rules Template: Marketing Analytics Platform with Campaign Tracking, Attribution, Landing Page Analytics and AI Insights

FAQ

What is the purpose of this Cursor Rules Template?

This Cursor Rules Template provides a copyable .cursorrules block and stack-specific guidelines to implement a Field Sales Tracking app with location check-ins, visits, notes, tasks, and manager analytics using Cursor AI.

Which stack does this template target?

The template targets a Node.js + Express backend with PostgreSQL and TypeScript, complemented by a frontend capable of rendering location-based data and analytics for field sales teams.

How do I apply the .cursorrules block?

Copy the block into a file named .cursorrules at the project root. Ensure the referenced directories and modules exist or are created by the AI-generated code.

What are key security practices included?

JWT in httpOnly cookies, bcrypt password hashing, CSRF protection, TLS, and redaction of secrets in logs. Do not bypass auth or expose secrets in code.

How should testing be approached?

Include unit tests for services and utilities, integration tests for APIs, and end-to-end checks for location workflows. Use Jest and Supertest with a dedicated test database.