Cursor Rules Template: Accounts Receivable Dashboard (Node.js + PostgreSQL)

Overview


Cursor rules configuration for building accounts receivable risk dashboards on a modern web stack. This template targets a Node.js (Express) backend, PostgreSQL database, and a React frontend. It provides concrete guardrails for Cursor AI to generate safe, maintainable code, enforce authentication and data integrity, and produce auditable artifacts in a small-business context.


Direct answer: use this Cursor rules template to guide AI-assisted development of AR dashboards with secure APIs, robust data models, and reliable tests on a Node.js + PostgreSQL stack.



When to Use These Cursor Rules



- When implementing AR aging, dispute handling, and credit risk scoring dashboards for small businesses.

- When the stack consists of Node.js/Express backend, PostgreSQL data layer, and a React frontend.

- When you require JWT-based auth with RBAC (admin, finance-manager, viewer) and secure API boundaries.

- When you need parameterized SQL, explicit transactions, and clear data access patterns to avoid SQL injection and N+1 queries.

- When you want consistent testing, linting, and CI pipelines that guard data quality and security.



Copyable .cursorrules Configuration


# Cursor Rules Template for AR Dashboard (Node.js + PostgreSQL)

framework: "nodejs-postgresql-react"
context: "You are Cursor AI. Build a back-end API in Node.js (Express) with PostgreSQL, and a React frontend. Ensure secure, auditable code for an Accounts Receivable risk dashboard for small businesses. Prioritize parameterized queries, clear separation of concerns, and robust testing."
codeStyle: "eslint+prettier; use StandardJS/airbnb as applicable; enforce strict types if using TypeScript; enforce consistent error handling."
architecture: "MVC with services layer; repository pattern for data access; separate concerns between api, business logic, and data models; clear module boundaries."
auth: "JWT-based authentication with short-lived access tokens and long-lived refresh tokens; RBAC with roles: admin, finance-manager, viewer; enforce auth in every route; never leak tokens."
database: "PostgreSQL; use parameterized queries; migrations in db/migrations; seeds in db/seeds; create/read/update/delete via well-defined repositories; use prepared statements."
orm: "Prefer pg library (node-postgres) with parameterized queries; avoid heavy ORMs; leverage views for complex reads."
testing: "Backend: Jest + SuperTest; Frontend: React Testing Library; linting via ESLint/Prettier; CI gates run on PRs."
ci: "GitHub Actions: lint, test, build, and security scan; fail builds on test or lint failures."
antiPatterns: "Do not concatenate SQL; Do not bypass auth checks; Do not expose secrets in code; Do not trust client-only validation; Do not perform server-side operations without explicit authorization."

Recommended Project Structure


project-root/
  backend/
    src/
      api/
        controllers/
        routes/
      database/
        migrations/
        seeds/
      models/
      services/
      config/
    tests/
  frontend/
    src/
      components/
      pages/
    public/
  db/
    migrations/
    seeds/
  scripts/
  .env.example

Core Engineering Principles



- Least privilege and proper RBAC for all API endpoints.

- Clear separation of concerns: API, business logic, and data access layers.

- Deterministic data shapes and explicit API contracts.

- Security-first design: input validation, nonces, CSRF protection where relevant, and encrypted secrets.

- Prefer parameterized queries and explicit transactions to maintain data integrity.

- Observability: structured logs, metrics, and tracing for AR dashboard operations.

- Testing pyramid: unit tests, integration tests, and end-to-end checks with CI gates.

- Cursor AI rules compliance: avoid unsafe code patterns, document decisions, and keep a reproducible footprint.



Code Construction Rules



- Frontend and backend must expose stable, versioned APIs with predictable response shapes.

- Backend routes should follow RESTful conventions; use nouns for resources (ar-dashboard, ar-records, etc.).

- All data access must use parameterized queries; never interpolate user input into SQL strings.

- Use transactions for multi-step writes to ensure atomicity.

- Prefer views or CTEs in PostgreSQL for complex reads to avoid client-side joins.

- TypeScript is recommended for the backend to improve reliability; enable strictNullChecks.

- Authentication tokens must be validated on every request; refresh tokens rotate and short-lived access tokens expire promptly.

- CI must run linting, type checks (if TS), unit tests, and integration tests before merging.

- Do not rely on client-side validation for security; enforce server-side validation for all inputs.



Security and Production Rules



- Store secrets in environment variables; do not commit credentials.

- Use TLS for all external endpoints; enforce HttpOnly cookies for session tokens if used.

- Apply strict CORS policy, only allowing known frontend origins.

- Audit access control changes; log authentication and authorization events with user identifiers.

- Implement rate limiting and input validation to prevent abuse and resource exhaustion.

- Regularly review dependencies for known vulnerabilities and apply patches swiftly.



Testing Checklist



- Unit tests for data transformation and validation functions.

- API integration tests covering authentication, authorization, and AR data endpoints.

- End-to-end tests for typical dashboard scenarios (aging, DSO, risk scoring) with mocked data.

- Lint and type checks run in CI; ensure pre-commit hooks are enabled.

- Performance tests on critical queries and API paths; monitor with simple dashboards.



Common Mistakes to Avoid



- Assuming client-side validation is sufficient for security.

- Building SQL with string concatenation; always use parameterized queries.

- Over-fetching data or producing N+1 queries in AR dashboards.

- Storing secrets in code or accidentally logging sensitive data.

- Ignoring RBAC changes in new endpoints; ensure new resources are protected.



Related implementation resources: AI Use Case for Google Sheets Expense Tracking and Summaries and Abstracting DB ops with a clean repository interface.





FAQ


What is a Cursor Rules Template for an AR dashboard?


A Cursor Rules Template defines stack-specific guardrails that guide Cursor AI in generating safe, maintainable code for an accounts receivable risk dashboard built on Node.js, PostgreSQL, and React. It enforces authentication, data integrity, testing, and security practices tailored to small-business needs.


Which stack does this template target?


The template targets a Node.js/Express backend, PostgreSQL data layer, and a React frontend. It emphasizes parameterized SQL, a clear MVC-like structure, and robust testing and linting in CI.


How do I paste the .cursorrules block into my project?


Copy the block under the Copyable .cursorrules Configuration section and place it at the root of your project or within a suitable rules directory. Update any stack-specific names to match your repository layout while preserving the syntax.


What security practices are required by these rules?


Use JWT-based authentication with access/refresh tokens, enforce RBAC, validate all inputs on the server, store secrets in environment variables, and limit data exposure via API responses.


How should testing be structured for AR dashboards?


Provide unit tests for data validation and utilities, integration tests for API endpoints, and end-to-end tests that simulate AR dashboard workflows with mocked data, all integrated into CI pipelines.


What are common pitfalls when building AR dashboards?


Common pitfalls include insecure endpoints, unparameterized queries, insufficient data validation, missing RBAC enforcement, and poor test coverage for critical dashboard components.