Cursor Rules Template: Restaurant Dashboard Analytics

Overview

The Cursor rules configuration is a copyable, stack-specific guide that governs how Cursor AI should operate when building restaurant review analytics dashboards. This template targets a Python FastAPI backend with SQLAlchemy and PostgreSQL, plus a React frontend, and enforces architecture, security, testing, and data processing patterns so developers can paste the block into their project as a starting point.

When to Use These Cursor Rules

When starting a new restaurant dashboard project that ingests reviews from multiple sources.
To enforce a consistent backend-frontend data contract and ORM usage.
To ensure security, proper testing, and CI/CD for the stack.
To prevent common anti-patterns like raw SQL leakage, insecure authentication, or ad-hoc data migrations.

Copyable .cursorrules Configuration

framework: python-fastapi-sqlalchemy-postgresql-react-ts
program: Restaurant Dashboard Cursor Rules
role_and_context:
  - You are Cursor AI guiding a Python FastAPI backend with SQLAlchemy and PostgreSQL, plus a React TS frontend, to build restaurant review dashboards.
  - Enforce architecture, security, testing, and maintainable data workflows.
design_and_style:
  - Follow PEP8 for Python; use Black for formatting
  - Use Prettier/ESLint for TS; enforce type hints with mypy
architecture_and_directories:
  - backend/app
  - backend/app/api
  - backend/app/models
  - backend/app/services
  - backend/app/core
  - frontend/src
authentication_and_security:
  - Use JWT tokens and HTTPS
  - Do not log secrets or plaintext credentials
  - Enforce role-based access controls on sensitive endpoints
orm_and_database:
  - SQLAlchemy ORM models
  - Postgres database with migrations managed via Alembic
  - Parameterized queries; avoid raw string composition
testing_and_ci_cd:
  - pytest with fixtures for API and data layer
  - lint with flake8/ruff; unit tests run on CI
  - CI checks for type and style conformance
prohibited_actions_and_anti_patterns:
  - Do not execute raw SQL without parameters
  - Do not bypass authentication in tests
  - Do not perform in-process data migrations at runtime

Recommended Project Structure

restaurant-dashboard/
├── backend/
│   ├── app/
│   │   ├── api/
│   │   ├── models/
│   │   ├── services/
│   │   ├── core/
│   │   └── main.py
│   └── tests/
├── frontend/
│   ├── src/
│   │   ├── App.tsx
│   │   ├── main.tsx
│   │   ├── components/
│   │   └── pages/
├── docker-compose.yml
└── Dockerfile

Core Engineering Principles

Single source of truth for data models and API contracts.
Clear separation of concerns between backend, frontend, and data processing.
Secure-by-default: TLS, JWT, least privilege, and audited data access.
Test-driven rules: unit, integration, and end-to-end checks.
Idempotent data processing and reliable rollback strategies.

Code Construction Rules

Define SQLAlchemy models with typed attributes and explicit __tablename__ names.
Expose API endpoints with Pydantic schemas for request/response validation.
Use async dependencies where possible in FastAPI for I/O-bound operations.
Keep business logic in services layer; avoid leaking ORM models to UI.
Frontend uses TypeScript with strict types; state managed with hooks or context.
Do not bypass authentication; all protected endpoints require valid JWT.
CI checks include type hints, linting, and unit tests for backend and frontend.

Security and Production Rules

Require TLS in all environments; store secrets in environment variables or vaults.
Parameterized queries; sanitize inputs; enforce CSRF protection on forms where applicable.
Role-based access control and audit logging for sensitive operations.
Containerized services with security baselines and image scanning in CI.
Data export endpoints are restricted and monitored; implement rate limiting where needed.

Testing Checklist

Unit tests for models and utilities; mock external calls.
Integration tests for API endpoints with a test PostgreSQL instance.
Frontend tests for components and data visualizations.
End-to-end tests to validate data flow from ingestion to dashboard visuals.
CI runs linting, type checks, and test suites on push/PR.

Common Mistakes to Avoid

Mixing business logic into routes or views; keep services isolated.
Using unparameterized queries or dynamic SQL in migrations.
Omitting input validation and failing to enforce auth in tests.
Ignoring observability; lack of proper logging or metrics.

FAQ

What is the Cursor Rules Template for this stack?

The template provides stack-specific Cursor AI instructions to guide a Python FastAPI + SQLAlchemy + PostgreSQL + React TS project for restaurant dashboards. It outlines architecture, security, testing, and data workflows, enabling developers to paste a ready-to-use rules block into their repository.

Which stack does this template cover?

It targets a Python FastAPI backend with SQLAlchemy ORM for PostgreSQL, and a React (TypeScript) frontend for interactive restaurant review analytics dashboards.

How do I adapt this template to my project?

Replace placeholder models, endpoints, and dashboards with your own restaurant dataset schemas and visuals, while preserving the Cursor AI rules for architecture and security.

What security practices are enforced by the rules?

TLS, JWT authentication, parameterized queries, no plaintext secrets, and strict access controls for endpoints and data exports are mandated.

How do I test and validate the Cursor rules?

Run unit tests with pytest, perform integration tests for API endpoints, and rely on CI to ensure code and rules meet the architecture and security requirements.

Target User

Use Cases