Supplier Risk Monitoring Platform Cursor Rules Template

Overview

This Cursor rules template enables a stack-specific, copyable Cursor AI configuration for a supplier risk monitoring platform. It supports ingestion of supplier documents, news feeds, and performance metrics, followed by AI-driven risk scoring. The guardrails ensure secure data handling, auditable decisions, and deployment guidance tailored to a Node.js/TypeScript + PostgreSQL stack with TypeORM, Redis, and JWT-based authentication.

Direct answer: paste the included .cursorrules block into your project root to enforce stack-accurate AI guidance and safe development constraints while building a scalable supplier risk system.

When to Use These Cursor Rules

Starting a new supplier risk platform that ingests documents, news, and metrics.
Enforcing architecture constraints across modules like documents, news, and risk scoring.
Establishing secure data handling, role-based access, and auditable AI decisions.
Guiding code generation, migrations, and testing workflows to stay aligned with the stack.
Extending the data model to additional data sources without breaking security constraints.

Copyable .cursorrules Configuration

# Cursor Rules Template: Supplier Risk Monitoring Platform

Framework Role & Context
You are Cursor AI configured for a Node.js/TypeScript backend with PostgreSQL, TypeORM, Redis, and JWT-based auth. Your task is to guide safe, auditable AI-assisted development for a supplier risk monitoring platform that ingests documents, news, and metrics and computes AI risk scores.

Code Style and Style Guides
Use TypeScript strict mode, ESLint with a consistent style, and Prettier for formatting. Define clear interfaces for DTOs and services. Avoid any where possible and prefer explicit types. Use camelCase for variables and PascalCase for classes. Commit messages should follow conventional commits (feat, fix, docs).

Architecture & Directory Rules
src/
  modules/
    supplier/
      documents/
      news/
      metrics/
      risk-scoring/
  persistence/
  config/
  shared/
  tests/

Authentication & Security Rules
Use JWTs with short lifetimes and refresh tokens stored securely. Hash passwords with bcrypt or argon2. Enforce TLS, rotate secrets via environment managers, and redact sensitive data in logs. Implement RBAC with roles: admin, data_scientist, analyst.

Database and ORM patterns
PostgreSQL as primary store. TypeORM entities with explicit relations, migrations folder, and repository pattern. Avoid N+1 queries, leverage query builders for complex joins, and favor lazy loading only when beneficial.

Testing & Linting Workflows
Jest with ts-jest, test coverage > 85%, and CI checks on pull requests. Include unit, integration, and end-to-end tests. Lint before commit; run type checks in CI.

Prohibited Actions and Anti-patterns for the AI
Do not access production secrets. Do not log PII unredacted. Do not generate unsafe SQL or bypass security controls. Do not perform network calls unless explicitly allowed by the project policy. Do not use unsafe dynamic code generation.

Recommended Project Structure

src/
  modules/
    supplier/
      documents/
      news/
      metrics/
      risk-scoring/
      dto/
      entities/
      controllers/
      services/
      repositories/
  config/
  database/
  migrations/
  tests/
  utils/

Core Engineering Principles

Security by default: least privilege, secrets management, encrypted data at rest and in transit.
Auditability: immutable logs for risk decisions and data provenance.
Modularity: clear module boundaries for documents, news, metrics, and risk scoring.
Data integrity: strict schemas, migrations, and validation at the boundaries.
Reliability: idempotent operations and robust error handling.
Observability: structured logs, metrics, and tracing for AI-driven decisions.
Privacy by design: minimize PII exposure and enforce data retention policies.

Code Construction Rules

Define ORM entities with explicit column types and constraints. Use repository pattern for data access.
DTOs describe input/output payloads; validate at boundaries; never trust client input.
Ingestors must normalize data and store provenance metadata.
AI scoring should be deterministic for given inputs and time-bound to avoid drift.
Use feature toggles to gate experimental risk models in production.
Do not embed credentials or secrets in code; use environment variables and secret managers.
Adopt modular tests: unit tests for services, integration tests for repositories, and end-to-end tests for critical flows.

Security and Production Rules

Enforce TLS 1.2+ and secure cookies for auth tokens.
RBAC: enforce least privilege for every API endpoint.
Audit logs for risk decisions, with redaction of sensitive data where needed.
Rotate keys and credentials; use separate secrets for dev, staging, and prod.
Protect against injection by using ORM query builders and parameterized queries.
Back up risk data with verified restore procedures and disaster recovery tests.

Testing Checklist

Unit tests for all services and utilities; 80–90% coverage baseline.
Integration tests for ORM repositories and data interactions.
End-to-end tests for ingestion, scoring, and reporting flows.
Security tests: input validation, RBAC checks, and secret management validation.
CI/CD checks: lint, type-check, test suite, and deployment gate checks.

Common Mistakes to Avoid

Bypassing authentication or storing secrets in code.
Ignoring data provenance and audit trails in risk decisions.
Overly coupled modules across documents, news, and metrics leading to drift.
Neglecting input validation or unsafe dynamic SQL patterns.
Using monolithic data models that hinder scaling of ingestion pipelines.

Related Cursor rules templates

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

FAQ

What is this Cursor Rules Template for a supplier risk monitoring platform?

This template provides a copyable Cursor rules block and stack-specific guidance to configure Cursor AI for a platform that ingests supplier documents, tracks news, aggregates metrics, and applies AI-driven risk scoring. It includes architecture, security, testing, and deployment guidance tailored to the Node.js/TypeScript + PostgreSQL stack.

Which stack does this template target?

The template targets a Node.js/TypeScript backend with PostgreSQL, TypeORM for ORM patterns, Redis for caching, and JWT-based authentication. It supports document and news ingestion, metrics collection, and AI-driven risk scoring for suppliers.

How do I integrate the .cursorrules block into a project?

Copy the .cursorrules configuration into your project root as .cursorrules. Run Cursor AI in analysis mode to validate the rules against your codebase. The block enforces stack-specific constraints and governance for development tasks.

What are the security considerations for production risk scoring?

Use TLS, rotate keys, enforce RBAC, store secrets via environment managers, hash credentials, maintain audit logs of risk decisions, and limit model access with least privilege. Protect supplier data privacy and comply with regulations.

Can I extend this template to additional data sources (news, documents, metrics)?

Yes. The rules define pluggable ingestion and risk-scoring pipelines. Extend ORM entities, services, and event handlers to support new data sources while preserving auditability and security controls.

Target User

Use Cases