Cursor Rules Template: Recycling Workload Forecasting Dashboards

Overview

This Cursor Rules Template defines a complete, copyable .cursorrules block and stack-specific guidance for building recycling workload forecasting dashboards. It targets a Node.js + Express + PostgreSQL backend with a React frontend and uses Cursor AI to automate data ingestion, transformation, and visualization workflows while enforcing secure, testable patterns. The goal is to let developers paste the included instruction block into their project root and get deterministic, auditable guidance for dashboards and forecasting pipelines.

Direct answer: paste the provided .cursorrules configuration into your project root to configure Cursor AI to assist with backend APIs, data models, SQL queries, test suites, and deployment considerations for recycling workload forecasting dashboards on a Node.js/Express + PostgreSQL stack.

When to Use These Cursor Rules

• You are building recycling facility forecasting dashboards that rely on PostgreSQL data sources and REST APIs served by Express.
• You want Cursor AI to generate consistent API routes, data access patterns, and dashboard-ready data shapes.
• You require parameterized SQL, secure authentication, and a tested CI workflow for a data-driven SPA.
• You need clear directory structure and linting standards to support maintainable forecasting code.

Copyable .cursorrules Configuration

# Cursor Rules Template for Recycling Workload Forecasting Dashboards
framework: "node-express-postgres-react"
# Context for Cursor AI
context: "You are Cursor AI acting as a senior backend/data engineer for a Node.js/Express + PostgreSQL stack, focused on recycling workload forecasting dashboards. You must produce safe, auditable, and maintainable patterns."
role: "Backend Data Engineer"
format: "yaml"
architecture:
  - backend/src/
  - frontend/src/
  - db/migrations/
  - db/seeds/
codeStyle:
  lints: [eslint, prettier]
  ts: true
security:
  auth: jwt
  https: true
  secrets: env
queries:
  - type: "parameterized"
    example: "SELECT * FROM forecast f WHERE f.facility_id = $1 AND f.date BETWEEN $2 AND $3;"
database:
  type: "postgresql"
  host: "${POSTGRES_HOST}"
  database: "${POSTGRES_DB}"
  user: "${POSTGRES_USER}"
  password: "${POSTGRES_PASSWORD}"
  patterns:
    - "parameterized queries"
    - "explicit transactions"
    - "no string concatenation for data access"
testing:
  unit: [jest, supertest]
  integration: [docker-compose db, api]
  e2e: [playwright]
auth:
  strategies: ["JWT"]
  endpoints: ["/api/v1/forecast", "/api/v1/data"]
prohibited:
  - "Do not execute system shell commands"
  - "Do not bypass authentication checks"
  - "Do not hardcode secrets or credentials in code"
  - "Do not build dynamic SQL without parameterization"
notes: "Adjust environment variable names to match your project; Cursor AI should not infer secrets from code."

Recommended Project Structure

project-root/
├── backend/
│   ├── src/
│   │   ├── api/
│   │   │   ├── controllers/
│   │   │   └── routes/
│   │   ├── services/
│   │   ├── db/
│   │   │   ├── migrations/
│   │   │   └── seeds/
│   │   ├── models/
│   │   └── index.js
│   └── test/
├── frontend/
│   ├── src/
│   │   ├── components/
│   │   ├── pages/
│   │   └── hooks/
│   └── public/
└── db/
    ├── migrations/
    └── seeds/

Core Engineering Principles

• Clear separation of concerns: backend API, data access, and frontend presentation are decoupled with explicit boundaries.
• Type safety and validation: Prefer TypeScript types, runtime validators, and explicit API contracts.
• Test-driven momentum: Emphasize unit tests for controllers/services and integration tests for DB access.
• Deterministic AI guidance: Cursor AI outputs must be auditable and reproducible with explicit inputs.
• Observability by default: Structured logging, metrics, and tracing for forecasting data flows.
• Security by default: Enforce JWT-based auth, TLS, and careful handling of secrets.
• Data governance: Validate data shapes, enforce schemas, and avoid leaking PII in dashboards.

Code Construction Rules

• Use TypeScript across backend and frontend; enable strict type checking.
• All API input/output must be validated with runtime checks (e.g., Zod/Yup).
• All SQL queries are parameterized; never interpolate values into SQL strings.
• Backend endpoints under /api/v1/ for versioning.
• Environment-driven configuration; never hardcode credentials.
• Frontend components should be data-driven and isolated for testing.
• Linting and formatting enforced via CI; adhere to a single style guide (e.g., Airbnb style).
• Avoid using ORMs with weak migrations; prefer direct pg/pool access with explicit migrations.
• Do not perform AI-driven code generation that bypasses tests or reviews.

Security and Production Rules

• Use HTTPS/TLS for all endpoints; disable insecure endpoints in production.
• Store secrets in environment variables and a secrets manager; never commit them.
• RBAC: restrict forecast data endpoints to authorized roles only.
• Validate inputs; guard against SQL injections, XSS, and CSRF where applicable.
• Rate limiting and IP whitelists for critical APIs; monitor anomaly patterns.
• Audit logging for data access and forecast model executions.

Testing Checklist

• Unit tests for controllers/services with mocked DB access.
• Integration tests for API endpoints with a real Postgres instance.
• End-to-end tests for data ingestion, transformation, and dashboard data flow.
• Lint and type checks in CI; run Prettier as part of the pipeline.
• Security tests: input validation, auth flows, and secret handling.

Common Mistakes to Avoid

• Skipping input validation and trusting client-side checks.
• Embedding secrets in code or logs; neglecting environment-based config.
• Using dynamic SQL without parameters; mixing business logic with presentation logic.
• Over-fetching data or returning unpaginated dashboards without constraints.
• Ignoring observability; lack of logs/metrics for forecasting pipelines.

Related implementation resources: AI Use Case for Software Agencies Using Github Copilot To Accelerate Boilerplate Code Generation for New Client Mvps and Skill files for production-grade admin dashboards.

FAQ

What is a Cursor Rules Template for recycling dashboards?

A Cursor Rules Template is a ready-to-use configuration and instruction block that guides Cursor AI to produce stack-specific, auditable patterns for building recycling workload forecasting dashboards on a Node.js/Express + PostgreSQL stack. It includes roles, architecture, security, testing, and anti-patterns to ensure safe AI-assisted development.

Which stack does this template cover?

This template targets a Node.js/Express backend with PostgreSQL for data storage and a React frontend. Cursor AI is guided to generate backend APIs, data access, and dashboard data models with secure, testable patterns suitable for recycling workload forecasting use cases.

How do I apply the copyable .cursorrules block?

Place the copied .cursorrules block in the project root of your repository. It will instruct Cursor AI on code style, architecture, data access, security, tests, and anti-patterns specific to the recycling forecasting dashboard stack, aligning outputs with your existing tooling.

Can I adapt this template to other stacks?

Yes. The template can be adapted by editing the framework context, architecture paths, and database adapters. Keep the same structure for sections like authentication and testing while replacing stack-specific tooling (e.g., swapping pg with another PostgreSQL client) as needed.

What should I check after applying the rules?

Verify that generated code adheres to parameterized queries, JWT auth, and proper error handling. Run unit/integration tests, validate data shapes for forecasting, and confirm dashboards render accurate, privacy-aware information without leaking secrets.