Cursor Rules Template: Automotive Supplier Risk Monitoring for SMEs

Overview

Direct answer: This Cursor rules configuration provides a copyable template for a Node.js + TypeScript backend with PostgreSQL to support supplier risk monitoring for automotive component SMEs. It defines architecture, security, ORM usage, testing workflows, and anti-patterns so you can paste a single .cursorrules block into your project root and have Cursor AI enforce stack-consistent guidance.

Cursor AI role: You are an automation architect and coding assistant for a TypeScript backend that ingests supplier data, risk signals, and event streams to compute risk scores and trigger alerts for procurement and supply-chain teams.

When to Use These Cursor Rules

Starting a supplier risk module for automotive component SMEs that requires reliable risk scoring and alerting.
Enforcing a Node.js + TypeScript+ PostgreSQL backend with TypeORM data models and strict typing.
Implementing secure authentication and production-grade testing in a risk-monitoring service.
Onboarding new developers to the project with a ready-to-paste governance baseline.

Copyable .cursorrules Configuration

frameworkRole: You are Cursor AI configured to enforce rules for a Node.js TypeScript backend with PostgreSQL for automotive supplier risk monitoring.
frameworkContext: Backend stack uses Express, TypeORM, PostgreSQL, JWT RS256 authentication, and a REST API surface for risk scoring.
frameworkConstraints: Do not bypass TLS, do not expose secrets, do not generate unsafe SQL, do not use libraries outside the allowed stack.

codeStyle: Use ESLint + Prettier with strict TypeScript options; prefer explicit types; avoid any; enforce consistent naming.
styleGuides: Airbnb TypeScript rules as baseline; align with project conventions; run Prettier on commit.

architectureAndDirectoryRules:
  - src/controllers
  - src/services
  - src/repositories
  - src/entities
  - src/migrations
  - src/config
  - tests
  - docker

authenticationAndSecurity:
  - Use JWT RS256 with short-lived access tokens and httpOnly refresh tokens; rotate keys and store in a secrets manager
  - Enforce HTTPS, HSTS, and TLS termination at edge proxies; validate inputs and sanitize data
  - Do not log secrets; enable structured logging with redaction

databaseAndOrm:
  - PostgreSQL as the primary database; TypeORM as ORM layer
  - Entities: Supplier, Component, RiskScore, MonitoringRule, AuditLog, Event, User
  - Use migrations; avoid schema sync in production; index critical fields (supplier_id, risk_score, monitoring_rule_id)
  - Prefer repository methods or query builders to minimize N+1 patterns

testingAndLinting:
  - Jest with ts-jest; SuperTest for API tests; ensure 80%+ coverage; CI runs on PRs
  - Lint on commit; run type checks with tsc --noEmit

ProhibitedActions:
  - Do not construct dynamic SQL via string concatenation; use parameterized queries
  - Do not circumvent authentication or expose private keys
  - Do not bypass input validation or skip unit tests for critical paths

Recommended Project Structure

src
  /controllers
  /services
  /repositories
  /entities
  /migrations
  /routes
  /config
  /Middlewares
  /dtos
  /utils
  /tests
  /docker

Core Engineering Principles

Explicit typing and strict TypeScript usage
Single-responsibility modules and clear API boundaries
Robust data access via repositories and query builders
Security-by-design: strong authentication, secrets management, and validation
Infrastructure as code and reproducible local development

Code Construction Rules

Define DTOs for all external inputs and map to domain entities
Use TypeORM repositories for data access and avoid raw queries when possible
Validate inputs with class-validator and sanitize outputs before responding
Write idempotent endpoints and handle retries safely
Document API schemas and keep API evolution backward compatible

Security and Production Rules

Store secrets in a dedicated secrets manager; read at startup and refresh as needed
Rotate JWT signing keys; implement short-lived access tokens and secure refresh strategy
Enable TLS everywhere; enforce CSP and input sanitization
Monitor dependencies for CVEs and pin versions in package.json

Testing Checklist

Unit tests for services and helpers with deterministic input
Integration tests for repositories and ORM flows with a test database
End-to-end tests for the risk scoring API with real-world-ish data
Static analysis and type checks in CI; lint and test on pull requests

Common Mistakes to Avoid

Ignoring N+1 queries due to improper ORM usage
Storing secrets in code or environment files without access controls
Overexposing internal APIs or skipping input validation
Assuming JSON schema changes are free; breakages should be versioned

FAQ

What is a Cursor Rules Template?

A Cursor Rules Template provides a copyable .cursorrules block that guides Cursor AI to enforce a stack-specific development discipline. It packs framework role, architecture, security, ORM patterns, and testing guidance into a paste-ready snippet, tailored for a given tech stack such as Node.js with PostgreSQL for automotive supplier risk tooling.

Which stack is this template for?

This template targets a Node.js with TypeScript backend using PostgreSQL and TypeORM, focused on supplier risk monitoring for automotive component SMEs. It includes authentication, data models, and audit trails aligned with best practices for enterprise risk tooling.

How do I use the .cursorrules block?

Copy the entire block from the Copyable section and paste it into the root of your project as .cursorrules. Then run Cursor AI tooling to validate stack-specific enforcement and auto-generate coding guardrails and scaffolds.

How should migrations be handled?

Use TypeORM migrations for all schema changes; do not apply schema updates directly in production. Run migrations via CI/CD pipelines to ensure consistency across environments.

How is authentication secured?

JWT tokens use RS256 with short-lived access tokens and rotate keys; refresh tokens are stored in httpOnly cookies and rotated on every login. Secrets are sourced from a dedicated manager, not from code.

How should risk scoring be tested?

Unit test the scoring logic with deterministic inputs and mock external data sources. Integration tests should cover end-to-end flows from supplier data ingestion to risk score calculation and alerting, including audit logging.

Target User

Use Cases