Cursor Rules Template for Facility Management System

Overview

The Cursor rules configuration for this page defines a production-ready Cursor Rules Template tailored to a facility management system. It covers assets, maintenance requests, inspections, and vendor coordination using a Node.js + Express backend with PostgreSQL. The configuration enforces security, auditable actions, and predictable code patterns that an AI can safely assist with during implementation.

When to Use These Cursor Rules

• Starting a new facility management project with asset tracking and preventive maintenance.
• Standardizing asset lifecycles, service history, and inspection data.
• Implementing maintenance ticketing and SLA-based workflows.
• Coordinating vendors, work orders, and approvals with traceable records.
• Enforcing security, auditing, and compliant data access controls.
• Integrating a PostgreSQL data layer with strict SQL templates and testable queries.

Copyable .cursorrules Configuration

// Cursor Rules block for Facility Management Stack
// Framework: Node.js + Express + PostgreSQL (no ORM)
// Context: Build a production-ready facility management system with assets, maintenance requests, inspections, and vendor coordination. Cursor AI should propose safe code blocks, enforce security, and maintain audit trails.

# Architecture & Directory Rules
Architecture: Monorepo layout
Directories:
  - apps/api/
  - apps/ui/
  - packages/db/
  - packages/utils/

# Code Style & Style Guides
CodeStyle: StandardJS with ESLint (eslint-config-airbnb-base compatible)
Formatting: Prettier on commit

# Authentication & Security Rules
Auth: JWT in Authorization header; roles: admin, technician, vendor, user
Security: always parameterize queries; avoid string concatenation; validate inputs; forbid dynamic code execution; never log secrets; store keys in env vars

# Database & ORM Patterns
Database: PostgreSQL; use prepared statements; no ORM; migrations under /migrations; content keys must use parameterized queries

# Testing & Linting Workflows
Tests: Jest for unit tests; Supertest for API tests; CI runs lint, tests, and security checks on PR

# Prohibited Actions & Anti-patterns
Prohibited:
  - Do not use eval or dynamic code execution
  - Do not bypass authentication/authorization checks
  - Do not concatenate SQL strings
  - Do not store secrets in source control
  - Do not rely solely on client-side validation

Recommended Project Structure

apps/
  api/
    src/
      controllers/
      routes/
      services/
      models/
  ui/
    src/
      components/
      pages/
config/
migrations/
scripts/
tests/

Core Engineering Principles

• Security by default: least privilege and auditable actions.
• Explicit data contracts and validation at API boundaries.
• Clear separation of concerns between API, data access, and business logic.
• Testability: deterministic tests for unit, integration, and end-to-end flows.
• Observability: structured logging, metrics, and tracing for production systems.
• Fail-fast and safe AI-assisted development with strict anti-patterns.

Code Construction Rules

• Use parameterized queries and avoid string interpolation for SQL.
• Load configuration from environment variables; do not hardcode secrets.
• Define data models and DTOs with clear typing and validation (JSDoc/TypeScript suggestion).
• Keep business logic in services; controllers should delegate to services.
• Return consistent error shapes and proper HTTP status codes.
• Do not embed SQL in user-facing code paths; centralize SQL templates.
• Do not rely on client-side validation for access control.

Security and Production Rules

• JWT-based authentication with role-based access control (RBAC).
• Hash passwords with bcrypt and salt; rotate credentials regularly.
• Enforce TLS/HTTPS, secure cookies, and CSRF defenses where applicable.
• Use environment-based secret management and secret rotation.
• Audit logging for asset changes, maintenance actions, and vendor interactions.
• Rate limiting and input validation to prevent abuse and injection attacks.

Testing Checklist

• Unit tests for utilities and data transforms.
• Integration tests for API endpoints with a test database.
• Migration tests to ensure schema changes can be deployed safely.
• Linting and formatting checks in CI.
• Security scans and dependency checks in CI.
• End-to-end tests for typical workflows: asset create/update, maintenance ticket, inspection log, vendor approval.

Common Mistakes to Avoid

• Skipping parameterized queries; vulnerable to SQL injection.
• Embedding secrets in code or tests.
• Overloading controllers with business logic; failing to extract services.
• Neglecting audit trails for asset and maintenance changes.
• Assuming client-side validation is sufficient for security.

Related Cursor rules templates

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

• Cursor Rules Template: Accounts Payable Automation with OCR, Invoicing, and Approval Routing
• Cursor Rules Template: Construction Project Management Stack
• Cursor Rules Template: Node.js Express PostgreSQL Kanban SaaS
• Contract Lifecycle CLM Cursor Rules Template for Cursor AI

FAQ

What is this Cursor Rules Template for facility management?

This Cursor Rules Template provides a ready-to-paste .cursorrules block and stack-specific guidelines to build a facility management system with assets, maintenance requests, inspections, and vendor coordination using a Node.js + Express + PostgreSQL backend. It ensures safety, auditability, and production-grade patterns.

Which stack does it target?

Node.js with Express on the server, PostgreSQL as the data layer, and Cursor AI for code generation and guidance. It avoids ORM assumptions and emphasizes parameterized queries and explicit data contracts.

How do I use the copyable .cursorrules block?

Copy the entire block into the root of your project as .cursorrules in your Cursor workspace. It will configure framework, architecture, security, and testing rules for your facility management domain.

How is authentication and security handled?

The rules enforce JWT-based authentication, RBAC, input validation, and parameterized queries. Secrets live in environment variables and secret management systems. The AI assistant will not generate insecure access controls or expose credentials.

Can I adapt this to other databases?

Yes, you can adapt the database rules to your chosen provider, but you must replace PostgreSQL-specific patterns with your DB dialect and ensure parameterization and migrations are handled safely.

How do I integrate with assets, maintenance, and vendor workflows?

The template outlines dedicated modules and SQL templates for asset lifecycles, maintenance ticketing, inspection scheduling, and vendor coordination with immutable audit trails and role-based access checks.