Cursor Rules Template: FastAPI Customer Feedback Analytics

Overview

Cursor rules configuration for Cursor AI to enable a Python FastAPI stack that analyzes customer feedback with sentiment analysis, themes extraction, trend detection, and product recommendations. This template focuses on a PostgreSQL-backed data model, ML-driven insights, and secure API surfaces.

When to Use These Cursor Rules

• When building an API-driven analytics platform that ingests feedback from multi-channel sources.
• When you require reproducible ML inference for sentiment and theme extraction in production.
• When you need strict data access boundaries, audit trails, and secure token-based auth.
• When you want a testable project structure with migrations, CI, and linting in place.

Copyable .cursorrules Configuration

Framework: Python FastAPI
Context: You are a Cursor AI assistant configured to generate a copyable .cursorrules block for a FastAPI-based customer feedback analytics platform with sentiment analysis, themes, trends, and product recommendations.

Framework Role & Context:
- You are an expert AI that writes a precise, copyable .cursorrules block for a Python FastAPI stack (PostgreSQL, SQLAlchemy, Alembic, Redis, PyTest).

Code Style and Style Guides:
- Follow PEP8, type hints, and strict API surface design.
- Use Pydantic models for input/output and SQLAlchemy ORM for DB models.
- Prefer explicit types and descriptive names; avoid magic strings.

Architecture & Directory Rules:
- apps/ -- FastAPI app modules
- core/ -- config, security, and shared utilities
- models/ -- ORM models
- repositories/ -- data access
- services/ -- business logic
- api/ -- routers and controllers
- tests/ -- unit and integration tests

Authentication & Security Rules:
- Use OAuth2 with JWT Bearer tokens; store tokens securely; never log tokens.
- Secrets via environment variables; rotate periodically.
- Enforce HTTPS in production; enable CORS for trusted origins.

Database and ORM patterns:
- PostgreSQL with SQLAlchemy; Alembic migrations; UUID PKs; index user_id on analytics tables.
- Use SQLAlchemy relationship patterns; avoid N+1 queries; eager-load where appropriate.

Testing & Linting Workflows:
- PyTest with pytest-asyncio for async code; pytest-cov for coverage.
- Mypy for type checking; Black and Ruff for formatting and linting; pre-commit hooks.

Prohibited Actions and Anti-patterns for the AI:
- Do not use unsafe dynamic SQL; avoid string formatting for SQL; do not access external credentials.
- Do not assume network access in unit tests; do not bypass migrations.

Recommended Project Structure

apps/
└─ api/
   └─ main.py
core/
└─ config.py
models/
└─ analytics.py
repositories/
└─ analytics_repository.py
services/
└─ sentiment_service.py
api/
v1/
└─ endpoints.py
tests/
├─ unit/
└─ integration/
Dockerfile
docker-compose.yml
requirements.txt

Core Engineering Principles

• Explicit is better than implicit: clear contract boundaries between layers.
• Separation of concerns: API, domain logic, and data access are isolated.
• Testability: design modules with deterministic inputs and observable outputs.
• Security by default: validation, auth, and least privilege.
• Observability: structured logging, metrics, and tracing for ML inference paths.

Code Construction Rules

• Use Pydantic models for request/response schemas; annotate all public functions.
• Define ORM models with UUID primary keys; include created_at and updated_at timestamps.
• Write Alembic migrations for schema changes; avoid ad-hoc schema changes in code.
• Organize business logic in services; data access in repositories.
• ML components (sentiment model, theme extractor) must be testable with mock data.
• Adopt strict input validation and avoid eval-like patterns in ML inference code.

Security and Production Rules

• JWT-based authentication for API endpoints; scope-based access control for analytics data.
• Do not log secrets or plaintext tokens; rotate keys and use environment-based configs.
• Limit data exposure via API responses; implement field-level permissions for sensitive data.
• Enable rate limiting and request validation to prevent abuse; monitor ML inference costs.

Testing Checklist

• Unit tests for sentiment and theme extraction logic with edge-case inputs.
• Integration tests for API endpoints and database interactions.
• End-to-end tests for ingestion, inference, and dashboard signals.
• Static type checks with mypy; linting with Black and Ruff; pre-commit hooks in CI.
• CI/CD checks for migrations and container image builds.

Common Mistakes to Avoid

• Overfitting ML models to training data; ignore drift monitoring.
• Ignoring data migration compatibility during schema changes.
• Leaking database connections; not closing sessions or using pooling properly.
• Unvalidated user input leading to API instability or security issues.

Related Cursor rules templates

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

• Cursor Rules Template: IoT Water Monitoring with FastAPI & PostgreSQL
• Cursor Rules Template for FastAPI + PostgreSQL AI Interview Platform
• Energy Monitoring Dashboard Cursor Rules Template for Cursor AI
• Cursor Rules Template: Marketing Analytics Platform with Campaign Tracking, Attribution, Landing Page Analytics and AI Insights

FAQ

What is a Cursor Rules Template for this stack?

A Cursor Rules Template defines an executable, copyable .cursorrules block that instructs Cursor AI how to assist and constrain development for a FastAPI-based customer feedback analytics stack, including sentiment, themes, trends, and product recommendations.

How do sentiment analysis and theme extraction fit into the stack?

Sentiment analysis runs as a lightweight inference service; themes are extracted via NLP pipelines; results are persisted to PostgreSQL and surfaced through FastAPI routes for dashboards and decision support.

What should I test for this Cursor Rules Template?

Tests cover ML components, API endpoints, and data access; unit tests validate logic, integration tests verify DB interactions, and CI ensures migrations, linting, and type checks run on every PR.

How is security handled in production?

Security uses OAuth2 with JWT, secrets from environment variables, token scopes, and redacted outputs; production uses HTTPS, rate limiting, and proper logging practices.

Where should I place the Cursor Rules Template in my project?

The copyable .cursorrules block should reside at the project root in a dedicated workspace file named .cursorrules to guide Cursor AI during development.