Warehouse Forecasting Cursor Rules Template for Cursor AI

Overview

Cursor rules configuration for Cursor AI guiding generation of a Python FastAPI + PostgreSQL stack to build warehouse workload forecasting dashboards using order and picking data. This page provides a copyable .cursorrules block and stack-specific guidance for accurate, reproducible results.

When to Use These Cursor Rules

• When you need a repeatable, auditable structure for dashboards forecasting warehouse workload from orders and picking data.
• When you want Cursor AI to generate consistent data models, ETL steps, and API endpoints for a Python stack.
• When you require tests, linting, and security rules baked into the code generation process.
• When deploying to production with a PostgreSQL data warehouse and TLS-enabled connections.

Copyable .cursorrules Configuration

framework: python-fastapi-postgresql
role: Build and maintain forecasting dashboards for warehouse workloads using orders and picking data
context: This template targets warehouses; data originates from orders and pick tickets to forecast workload and staffing
styleGuide: pep8 black isort
architecture:
  root: src
  modules:
    - etl
    - dashboards
    - models
    - db
    - tests
auth:
  - use_env_vars: true
  - do_not_store_credentials_in_code: true
db:
  orm: sqlalchemy-2.0
  dialect: postgresql
patterns:
  - orders
  - shipments
  - items
  - forecast_tables
tests:
  unit: pytest
  integration: pytest httpx
lint:
  tools:
    - black
    - ruff
anti:
  - do_not_embed_plaintext_credentials
  - avoid_long_running_queries_without_limits
  - do_not_bypass_input_validation

Recommended Project Structure

warehouse-dashboard/
├── src/
│   ├── api/
│   │   └── main.py
│   │   └── routers/
│   ├── dashboards/
│   │   ├── forecast_dashboard.py
│   │   └── widgets/
│   ├── models/
│   │   └── sql_models.py
│   ├── data/
│   │   ├── raw/
│   │   └── processed/
│   ├── tests/
│   │   ├── unit/
│   │   └── integration/
│   ├── config/
│   │   └── settings.py
│   └── __init__.py
└── scripts/
    └── run_etl.sh

Core Engineering Principles

• Data quality and provenance are first-class concerns.
• Reproducible pipelines with versioned schemas and deterministic transforms.
• Idempotent ETL and dashboards to support safe retries.
• Principle of least privilege for services and DB access.
• Observability through structured logging, metrics, and tracing.
• Security by design, with secrets management and encrypted connections.
• Clear separation of concerns between data access, processing, and presentation.
• Cursor AI rules encourage safe, auditable, and testable generation patterns.

Code Construction Rules

• Use Python type hints and Pydantic models for data shapes.
• Access the database via SQLAlchemy ORM; avoid raw queries unless parameterized.
• Paths and modules must be explicit; never rely on implicit imports for dashboards.
• All ETL steps should be versioned and idempotent, with clear retry logic.
• Dashboards should read from a staging layer and cache results where appropriate.
• Do not embed credentials; load from environment variables or a secret manager.
• Testing: unit tests for transforms, integration tests for endpoints, and smoke tests for dashboards.
• Prohibit unsafe operations in AI-generated code, such as destructive data mutations without safeguards.

Security and Production Rules

• Store credentials in environment variables or a vault; never in code.
• Use TLS for all API and DB connections; enable TLS 1.2+ with rotation.
• Enforce RBAC for API endpoints; dashboards should run with least privilege service accounts.
• Mask sensitive fields in dashboards and logs; audit access to forecast data.
• Enable monitoring, alerting, and structured traces for production deployments.
• Implement rate limiting and input validation to prevent abuse and DoS.

Testing Checklist

• Unit tests cover data transforms and validators.
• Integration tests verify SQL queries against a test database.
• End-to-end tests exercise forecast endpoints and dashboard data feeds.
• Linting and type-checking run in CI; ensure 100% test coverage where feasible.
• Performance checks for large datasets and caching effectiveness.
• Security tests for credential handling and API authentication.

Common Mistakes to Avoid

• Not isolating data access layers from business logic.
• Over-fetching data in dashboards; fetch only required fields and apply server-side filtering.
• Hard-coding thresholds or data asset names in rules.
• Skipping tests or relying on manual QA for forecast accuracy.
• Ignoring data drift and schema evolution in forecasting pipelines.

Related implementation resources: AI Agent Use Case for Call Centers Using Conversation Transcripts to Monitor Service Quality and Production-grade API design for coding agents: practical rules and templates.

FAQ

What is a Cursor Rules Template?

A Cursor Rules Template is a copyable configuration that guides Cursor AI to emit code and project structure for a specific stack; it includes framework roles, architecture rules, and security expectations.

Which stack does this template target?

This template targets a Python FastAPI + PostgreSQL stack with SQLAlchemy, Pandas, and Plotly for warehouse workload forecasting dashboards built from orders and picking data.

How do I use the .cursorrules block?

Copy the code block into a .cursorrules file at your project root. Cursor AI will read the rules to shape implementations, scaffolding, and tests for the stack.

How are security and secrets handled?

Secrets come from environment variables or a vault; do not embed credentials in code; ensure TLS for DB connections and proper authentication for API endpoints.

What testing and linting should be included?

Unit tests with pytest, integration tests for DB queries, and linting with tools like Ruff and Black; CI should run tests on PRs and ensure no regressions in forecasts.