Bakery Production Forecasting Cursor Rules Template

Overview

Direct answer: This Cursor rules configuration provides a copyable .cursorrules block tailored to bakery production forecasting using sales data. It targets a Python-based stack (FastAPI, PostgreSQL with SQLAlchemy, and Pandas for data processing) to produce reproducible forecasts while enforcing safe AI usage.

The rules define the role, context, architecture, and constraints to guide Cursor AI through data ingestion, model selection, and deployment considerations for bakery operations.

When to Use These Cursor Rules

When you need a repeatable forecasting workflow that pulls from daily sales data and promotions
When you want a clean project structure and strict data validation for forecasting inputs
When you require safe AI usage with clear authentication and secure data handling
When you deploy to production and need testing, linting, and CI integration

Copyable .cursorrules Configuration

Framework Role & Context
You are Cursor AI configured as a Python backend architect and data engineer. Your mission is to help build a bakery production forecasting tool that uses sales data to forecast daily and weekly demand by location and product category. Maintain reproducible results and guard against data leakage or leakage from external sources.

Code Style and Style Guides
Adhere to PEP8, type hints, and a clean architectural boundary between API, business logic, and data access. Use Python 3.11+ features where appropriate. Document non-obvious decisions and ensure tests cover critical paths.

Architecture & Directory Rules
Project layout should place domain logic in app/, with subfolders api/, core/, models/, services/, and a separate data/ for sample inputs. Include a migrations/ folder for SQLAlchemy migrations.

Authentication & Security Rules
Require an API key in the X-Api-Key header for internal tooling. Secrets must be sourced from environment variables or a secret manager. Never log API keys or raw credentials. Use TLS in production.

Database and ORM patterns
Use PostgreSQL with SQLAlchemy ORM. Define models for Sale, Forecast, Bakery, and Location. Use Alembic migrations for schema changes. Always close DB sessions safely and use parameterized queries.

Testing & Linting Workflows
Use pytest for unit and integration tests. Add type checking with mypy or pyright, and linting with flake8. Include test fixtures for sample sales data and deterministic seeds for forecasting components.

Prohibited Actions and Anti-patterns for the AI
Do not call unknown external services during forecasting. Do not generate fake sales data in production, even for tests. Do not bypass input validation, and do not log PII. Do not mix business logic with raw UI scaffolding.

Recommended Project Structure

root/
  app/
    main.py
    api/
      endpoints.py
      dependencies.py
    models/
      sale.py
      forecast.py
      bakery.py
      location.py
    services/
      forecasting.py
    db/
      database.py
      models.py
    core/
      config.py
  data/
    sample_sales.csv
  tests/
    test_forecasting.py
    test_api.py
  requirements.txt
  README.md

Core Engineering Principles

Reproducibility: deterministic seeds for forecasting tests; explicit versioning of data and code.
Data validation: strict input schemas and boundary checks for forecasting features.
Observability: structured logging and metrics for forecast accuracy.
Separation of concerns: clear API, services, and data layers.
Security and privacy-by-design: encrypted secrets, audit logging, and minimized data exposure.
Documentation by default: inline code comments and exposed API docs in FastAPI.

Code Construction Rules

Use Pydantic models for request validation and response schemas.
SQLAlchemy ORM should be the data access pattern; avoid raw SQL in application code except for performance-critical queries with parameter binding.
Directory structure must be honored as shown in the recommended project structure.
Configuration via environment variables (no hard-coded credentials).
Forecasting logic should be isolated into services/forecasting.py with testable interfaces.
Write unit tests for data transformation and forecasting steps; mock external dependencies in tests.
Do not bypass migrations; apply schema changes through Alembic. Do not execute schema-altering SQL at runtime in application code.

Security and Production Rules

Use TLS for all network traffic; rotate API keys; restrict access by IP if possible.
Store credentials and connection strings in environment variables or a secrets manager.
Audit logs for data access; never log full sale records or PII. Use field-level redaction if needed.
Run forecasting tasks in isolated workers; avoid blocking the main API thread with long-running jobs.
Implement rate limiting for API endpoints and proper error handling to avoid information leakage.

Testing Checklist

Unit tests for data transformation helpers and forecast models
Integration tests that simulate a full ingestion to forecast cycle against a test PostgreSQL database
End-to-end tests for API endpoints that return forecast summaries
Linting and type checking in CI; run tests on every PR

Common Mistakes to Avoid

Skipping input validation or assuming perfect data quality
Hard-coding thresholds or seeds that impair reproducibility
Neglecting data drift and feature engineering in forecasting models
Ignoring security considerations during development or deployment

FAQ

What is a Cursor Rules Template?

A Cursor Rules Template provides a ready-to-paste configuration that guides Cursor AI to generate stack-specific, safe, and testable development rules. This bakery-focused template tailors the rules to Python, FastAPI, PostgreSQL, and a Pandas-based data pipeline for forecasting using sales data.

Which models are recommended for bakery forecasting?

Start with Prophet or classical ARIMA/SARIMA models in Python for baseline forecasts; augment with regression-based models in scikit-learn for feature engineering such as promotions or holidays. Validate with backtesting on holdout data before production deployment.

How do I apply this template to my project?

Place the copyable .cursorrules block in your project root as .cursorrules. Cursor AI will guide you to implement the architecture, config files, and tests according to the template. Update paths to reflect your repository layout and data sources.

How should I validate forecasts in production?

Use backtesting with historical data, track MAE/MAPE, and monitor forecast accuracy against actual sales. Implement a retraining schedule and CI-driven tests for data drift and model performance.

How do I secure production data and credentials?

Store credentials in environment variables or a secrets manager, enable TLS, rotate API keys, and redact PII in logs. Use access controls to limit who can trigger forecast jobs or view raw sales data.

Target User

Use Cases