Cursor Rules Template: Inventory SaaS with Stock Tracking, POs, Barcode Scanning

Overview

The Cursor rules configuration defines how Cursor AI should operate when scaffolding and validating code for an Inventory Management SaaS stack (Node.js + Express + PostgreSQL). This Cursor rules template provides a complete, copyable .cursorrules block and stack-specific guidance to help developers implement stock tracking, purchase orders, barcode scanning, and reorder alerts with safe AI-assisted development.

Direct answer: This file tells Cursor AI your role, the stack, architecture constraints, security requirements, and QA expectations so AI-generated code adheres to the project conventions.

When to Use These Cursor Rules

Starting a new inventory SaaS project that includes stock levels, POs, and barcode workflows.
Generating backend scaffolds that integrate with PostgreSQL and provide reorder alerts.
Enforcing authentication, authorization, and data access patterns across modules.
Establishing a consistent project structure and CI/CD around the Cursor AI workflow.

Copyable .cursorrules Configuration

.cursorrules
# Cursor Rules for Inventory SaaS (Node.js + Express + PostgreSQL)
framework_role: Backend Engineer
context: You are assisting in building an Inventory Management SaaS with stock tracking, purchase orders, barcode scanning, and reorder alerts using Node.js (Express) and PostgreSQL. Implement safe, testable backends and clear data models.
code_style: typescript, eslint, prettier
architecture:
  - module: inventory
  - module: orders
  - module: barcodes
  - module: alerts
directory_rules:
  - src/api/
  - src/models/
  - src/controllers/
  - src/services/
auth_security:
  jwt: true
  RBAC: roles: [admin, manager, staff]
database:
  orm: TypeORM
  db: postgres
  naming: camelCase
testing:
  unit: jest
  integration: supertest
lint: eslint + prettier
ci_cd: github-actions
anti_patterns:
  - avoid string interpolation in raw SQL queries
  - do not hard-code secrets in source
prohibited_actions:
  - eval()
  - dynamic code execution in request handlers
notes:
  - Ensure barcode scanning endpoints accept scanned codes as strings, not numbers that could lose leading zeros
  - Use transactions for stock adjustments and POs to avoid race conditions

Recommended Project Structure

inventory-saas/
├── src/
│   ├── api/
│   │   ├── inventory/
│   │   │   ├── inventory.controller.ts
│   │   │   ├── inventory.service.ts
│   │   │   └── inventory.entity.ts
│   │   ├── orders/
│   │   │   ├── orders.controller.ts
│   │   │   └── orders.service.ts
│   │   ├── barcodes/
│   │   │   ├── barcode.controller.ts
│   │   │   └── barcode.service.ts
│   │   └── alerts/
│   │       ├── alerts.controller.ts
│   │       └── alerts.service.ts
│   ├── models/
│   │   ├── inventoryItem.ts
│   │   ├── purchaseOrder.ts
│   │   └── stockTransaction.ts
│   ├── controllers/
│   ├── services/
│   └── config/
└── tests/

Core Engineering Principles

Data correctness: use ACID transactions for stock and PO updates.
Security by default: enforce RBAC, validate input schemas, and avoid leaking errors.
Observability: structured logging, metrics for stock levels and reorder events.
Testability: unit and integration tests for all critical paths.
Maintainability: clear module boundaries and consistent naming.

Code Construction Rules

Use TypeScript for all backend code; enable strict type checking.
Validate input against defined DTOs and database schemas before processing.
All DB calls must be parameterized to avoid SQL injection.
Stock updates must occur within a database transaction.
Barcode scanning endpoints must accept and normalize input; reject non-code values.
Do not bypass authentication for inventory or orders endpoints.
Do not rely on in-memory caches for stock counts in production.

Security and Production Rules

Use JWT with short-lived access tokens and refresh tokens; implement rotation.
RBAC: map roles to CRUD access per module; deny unknown roles by default.
Secret management: use environment variables and a vault; never log secrets.
Data export controls: redact sensitive fields in exports; audit trails for stock changes.
Deployment: containerized with health checks; immutable images in production.

Testing Checklist

Unit tests for inventory and orders models; 100% branch coverage where feasible.
Integration tests for stock adjustment flows and PO creation; verify transactions commit/rollback.
End-to-end tests simulating barcode scanning and reorder alerts.
Linting and type checks in CI; run test suite on PRs.

Common Mistakes to Avoid

Skipping transactions leading to race conditions on stock levels.
Allowing unauthenticated access to inventory endpoints; missing RBAC checks.
Hard-coding thresholds for reorder alerts; not configuring per-warehouse.
Overfetching data; neglecting pagination on large inventories.

Related Cursor rules templates

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

FAQ

What stack is this Cursor Rules Template for?

This template targets a Node.js + Express backend with PostgreSQL for an Inventory Management SaaS with stock tracking, POs, barcode scanning, and reorder alerts. It provides a complete configuration to guide Cursor AI in generating safe, structured code.

Can I adapt the rules for TypeORM or raw SQL?

Yes. The rules specify ORM usage (TypeORM in this template) and emphasize parameterized queries and transactions; you can adapt to your ORM or raw SQL by updating the database section while preserving security constraints.

How are barcode inputs validated?

Barcode inputs are normalized to strings, validated against a strict pattern, and processed within a database transaction to avoid partial updates; invalid codes are rejected with a clear error message.

What should I customize after pasting?

Customize module boundaries (inventory, orders, barcodes, alerts), environment-specific settings (DB connection, host, port), and RBAC roles according to your organization’s requirements; keep Cursor rules as guardrails, not implementation specifics.

Is multi-warehouse support addressed?

The template supports multi-warehouse extensions by separating stock by warehouse_id and adding per-warehouse thresholds; implement these in data models and API boundaries.

Target User

Use Cases