Cursor Rules Template: Python FastAPI Wellness Feedback Dashboard

Overview

Direct answer: This Cursor rules template provides a deterministic setup for building a wellness center feedback analysis dashboard using Python FastAPI, PostgreSQL, SQLAlchemy, Pandas, and Plotly Dash, guided by Cursor AI rules to ensure security and maintainability.

What it covers: A Python FastAPI backend, a PostgreSQL datastore via SQLAlchemy ORM, and a Plotly Dash frontend for interactive wellness dashboards. Cursor AI rules govern architecture, testing, deployment, and safe AI-assisted development patterns.

When to Use These Cursor Rules

• When you need a repeatable, linted setup for building wellness feedback dashboards with Python FastAPI.
• When you require a strict directory layout and testable architecture to enable CI/CD for dashboards.
• When you want guardrails on data access, authentication, and database queries to protect sensitive wellness data.
• When you need a copyable .cursorrules block for project root usage.

Copyable .cursorrules Configuration

// Cursor Rules Template for Python FastAPI Wellness Dashboard
framework: python-fastapi
runtime: python-3.11

stack:
  - FastAPI
  - SQLAlchemy
  - PostgreSQL
  - Pandas
  - Plotly Dash

WorkspaceGuidance:
  - Framework Role & Context:
      - You are a Cursor AI assistant tasked with generating a safe, maintainable backend + data visualization stack for wellness center feedback dashboards using Python FastAPI and Plotly Dash.
  - Code Style and Style Guides:
      - Enforce Black + isort, mypy type hints, and flake8-compatible linting.
  - Architecture & Directory Rules:
      - Use a clear app/ root with subpackages: api/, core/, db/, dashboards/, tests/.
      - Separate concerns: endpoints, services, models, and data access layers.
  - Authentication & Security Rules:
      - Implement OAuth2 with JWTs, bcrypt for passwords, and environment-based secret keys.
      - Do not log plaintext secrets or reveal DB creds in code.
  - Database and ORM patterns:
      - SQLAlchemy ORM models, session-per-request pattern, migrations with Alembic.
      - Use parameterized queries; avoid raw string concatenation.
  -Testing & Linting Workflows:
      - pytest-based tests; pre-commit hooks; type-checks with mypy.
  - Prohibited Actions and Anti-patterns:
      - Do not embed credentials; do not execute arbitrary shell commands; avoid dynamic evaluation of user input.

Recommended Project Structure

project-root/
├─ app/
│  ├─ main.py
│  ├─ api/
│  │  └─ v1/
│  │     ├─ endpoints/
│  │     │  ├─ dashboards.py
│  │     │  └─ feedback.py
│  │     └─ dependencies.py
│  ├─ core/
│  │  └─ config.py
│  ├─ db/
│  │  ├─ models.py
│  │  └─ session.py
│  └─ dashboards/
│     └─ wellness_dashboard.py
├─ tests/
│  ├─ test_api.py
│  └─ test_dashboard.py
├─ migrations/
│  └─ 20240501_init.py
├─ requirements.txt
├─ alembic.ini
<Note: exclude irrelevant files>

Core Engineering Principles

• Strong typing and clear API contracts with Pydantic models.
• Separation of concerns with a clean architecture (api, services, db, dashboards).
• Security by default: proper authentication, secret management, and data access controls.
• Automated testing and linting as part of CI/CD.
• Deterministic, testable data processing with Pandas + SQLAlchemy.

Code Construction Rules

• Endpoints are asynchronous where possible; use FastAPI path operations with dependency injection.
• Request models and response models must be defined via Pydantic.
• Database access uses SQLAlchemy ORM with session-per-request and migrations.
• All data access uses parameterized queries; never build SQL via string concatenation.
• Dashboards are generated with Plotly; data is prepared with Pandas prior to rendering.
• CI ensures black, isort, mypy, and pytest run on push.

Security and Production Rules

• Store secrets in environment variables; do not commit credentials.
• Use TLS in production; validate JWT tokens; enforce role-based access where needed.
• Limit query sizes; implement pagination; audit trails for data access.
• Deploy with immutable infrastructure and proper logging/metrics.

Testing Checklist

• Unit tests for models, schemas, and utilities.
• Integration tests for API endpoints and database interactions.
• End-to-end tests for the dashboard data flow.
• Lint and type checks in CI; run tests on each PR.

Common Mistakes to Avoid

• Hard-coding secrets or creds in code or tests.
• Mixing business logic with API handlers; keep services thin.
• Omitting input validation; ignore edge cases in data ingestion.
• Using raw SQL; avoid unsafe string concatenation.

Related implementation resources: AI Use Case for Software Agencies Using Github Copilot To Accelerate Boilerplate Code Generation for New Client Mvps and Skill files for secure file upload implementations in production AI systems.

FAQ

What is this Cursor Rules Template for Python FastAPI wellness dashboards?

This template provides a complete, copyable Cursor Rules configuration for building a wellness center feedback analysis dashboard with a Python FastAPI backend, PostgreSQL storage via SQLAlchemy, and a Plotly Dash frontend. It defines guardrails for architecture, security, testing, and AI-assisted development to ensure reliable results.

Which stack does this template cover?

The template targets Python 3.11+, FastAPI for API endpoints, SQLAlchemy for ORM, PostgreSQL as the data store, Pandas for data processing, and Plotly Dash for interactive dashboards. Cursor AI rules guide implementation details and ensure safe AI-assisted development.

Where do I paste the .cursorrules block?

Paste the block at the project root as a dedicated file named .cursorrules or inline in your repository as a root-level configuration. Cursor will reference this block to steer code generation, validation, and testing steps for the wellness dashboard stack.

What security considerations are included?

Authentication uses OAuth2 with JWT tokens; credentials are stored in environment variables, and all secrets are kept out of version control. Data access is guarded by scoped endpoints, and database queries are parameterized to prevent injection.

How can I extend this template for additional dashboards?

You can duplicate the Wellness Dashboard module, adjust data sources, and adapt endpoints and visuals. Ensure new dashboards follow the same architectural rules, update tests, and extend the .cursorrules block with any new models, migrations, or permissions.