Cursor Rules Template: Node.js Staff Scheduling for Cleaning Companies

Overview

Direct answer: This Cursor rules configuration enables Cursor AI to generate, validate, and optimize a Node.js + PostgreSQL backend for staff scheduling in cleaning companies. Paste the copyable .cursorrules block below into your project root to configure roles, architecture, security, and testing for this stack.

When to Use These Cursor Rules

When building a REST API for shift assignment and availability management in a cleaning-company context.
When you require a small, testable backend with Node.js (Express) and PostgreSQL without an ORM.
When enforcing JWT-based authentication, role-based access, and strict input validation.
When you need a repeatable project structure that supports migrations, seeding, and CI/testing pipelines.

Copyable .cursorrules Configuration

Framework Role & Context:
  - Framework: Node.js (Express) backend for scheduling in cleaning companies
  - Context: Node.js 18+, PostgreSQL, node-postgres (pg), no ORM, REST API, JWT-based auth

Code Style and Style Guides:
  - Language: JavaScript (ES6+). ESLint with Airbnb rules, Prettier formatting
  - Testing: Jest for unit tests; lint-staged on commit

Architecture & Directory Rules:
  - src/routes, src/controllers, src/services, src/models, src/middleware, src/database
  - Separate config and env usage; avoid hard-coded secrets

Authentication & Security Rules:
  - JWT access tokens short-lived (15–30 minutes); refresh tokens rotated
  - Passwords hashed with bcrypt; CSRF protection for state-changing actions via tokens
  - HTTPS in all environments; input validation on all endpoints

Database and ORM patterns:
  - PostgreSQL with node-postgres (pg); parameterized queries; no string-interpolated SQL
  - Migrations in ./database/migrations; seed data in ./database/seeds
  - Use a dedicated DB user with least privilege

Testing & Linting Workflows:
  - Jest + supertest for API endpoints; misconfiguration tests
  - ESLint + Prettier; GitHub Actions for lint, test, and build checks

Prohibited Actions and Anti-patterns for the AI:
  - Do not use ORM abstractions; use raw SQL with parameterized queries
  - Do not embed secrets in code or rules; always rely on environment variables
  - Do not bypass authentication or authorization checks
  - Do not generate brittle SQL; avoid SELECT *; always specify columns

Recommended Project Structure

project-root/
├── src/
│   ├── config/
│   │   └── index.js
│   ├── controllers/
│   │   └── scheduleController.js
│   ├── routes/
│   │   └── scheduleRoutes.js
│   ├── services/
│   │   └── schedulingService.js
│   ├── models/
│   │   └── user.js
│   ├── middleware/
│   │   └── authMiddleware.js
│   ├── database/
│   │   ├── migrations/
│   │   │   └── 001-initial.sql
│   │   └── index.js
│   └── app.js
├── tests/
│   ├── integration/
│   │   └── schedule.integration.test.js
│   └── unit/
│       └── schedulingService.test.js
├── .eslintrc.json
├── .prettierrc
└── package.json

Core Engineering Principles

Explicit boundaries: route handlers delegate to services; avoid business logic in controllers
Testability first: write unit tests for services and integration tests for endpoints
Security by default: validate input, sanitize outputs, and enforce authorization
Deterministic migrations and seeded data for consistent environments
Idempotent deploys: configuration-driven, not code-driven feature toggles

Code Construction Rules

Use Express routers with async handlers and centralized error handling
Validate all inputs with Joi (or similar) and reject invalid payloads early
All DB access via parameterized queries; never interpolate user input into SQL
Store secrets in environment variables; use a config loader with default fallback
Separate concerns: schedule logic in services, API surface in routes
Use migrations for schema changes; avoid ad-hoc schema edits
Do not bundle business logic inside models; keep models focused on data shapes

Security and Production Rules

Enforce TLS; rotate keys and tokens; use short-lived access tokens
Apply rate limiting and input validation to prevent abuse
Audit logs for sensitive actions; avoid logging secrets
Back up data regularly; ensure migrations are reversible

Testing Checklist

Unit tests for scheduling rules and helper utilities
Integration tests for endpoints with a test database
CI pipeline runs lint, tests, and build; verify migrations
Performance tests for frequent operations (shift assignment, availability update)

Common Mistakes to Avoid

Using ORM when not required; leads to unnecessary abstractions
Skipping input validation; unchecked payloads cause runtime errors
Hardcoding secrets or credentials in code or rules
Weak authentication flow or overly permissive roles
Non-deterministic tests due to missing migration state

FAQ

What is Cursor Rules Template for a Node.js + PostgreSQL scheduling app?

It is a structured, copyable .cursorrules block plus guidance that steers Cursor AI to generate Node.js + PostgreSQL staff scheduling backend code with best practices, secure DB access, and testable architecture.

Can I paste this into an existing project root?

Yes. Place the provided .cursorrules block at the project root and adapt environment-specific values in .env and config. The rules assume a non-ORM PostgreSQL stack with Express routes and JWT auth.

Do I need TypeScript for this template?

No. The template is written for JavaScript (ES6+) with ESLint and Prettier. It can be adapted to TypeScript later if desired, but the rules assume plain JS.

How are credentials and secrets handled?

Secrets live in environment variables and config files not checked into source. The rules enforce bcrypt for passwords and JWT token handling without exposing secrets.

What should be customized first?

Configure database connections, environment variables, and the schedule endpoints. Then expand services with business rules for shifts, availability, conflicts, and notifications.

Target User

Use Cases