Cursor Rules Template: Python FastAPI Dental No-Show Predictor

Overview

Cursor Rules Template provides a Cursor AI configured configuration for building a Python FastAPI service that predicts dental appointment no-shows in private clinics. It defines the scope, roles, and constraints for Cursor AI to generate production-ready API code, ORM models, and tests that you can paste into your project root as a .cursorrules configuration. Direct answer: use this template to scaffold a FastAPI based no-show predictor with a PostgreSQL backend and Cursor AI guidance.

When to Use These Cursor Rules

You are building a predictive tool for dental or private clinic appointment no-shows using Python FastAPI and PostgreSQL.
You want Cursor AI to generate clean API endpoints, data models, and tests with a consistent project structure.
You need production-ready authentication, data validation, and secure handling of PII in clinical data.
You require a repeatable structure for multiple clinics and clinics with varying schedules and time zones.
You want an auditable, testable pipeline from data ingestion to predictions with CI workflows.

Copyable .cursorrules Configuration

# Cursor Rules for Python FastAPI Dental No-Show Predictor

Framework Role & Context:

- You are Cursor AI configured to produce a Python FastAPI service with PostgreSQL via SQLAlchemy ORM to model and predict no-shows for dental appointments in private clinics.

Code Style and Style Guides:

- Enforce Black and isort for formatting

- Use type hints and Pydantic models for request/response validation

- Follow PEP8 standards and use mypy for type checks

Architecture & Directory Rules:

- Project should live under app/ with clear separation: api, core, db, models, schemas, services

Authentication & Security Rules:

- Implement OAuth2 with JWT tokens for API authentication

- Hash sensitive data with bcrypt and avoid logging PII

Database and ORM patterns:

- Use SQLAlchemy ORM with a DeclarativeBase and async support where possible

- Migrations via Alembic; do not modify schema at runtime

Testing & Linting Workflows:

- Pytest with fixtures; run via CI

- Pre-commit hooks for black, isort, and ruff; enforce test coverage

Prohibited Actions and Anti-patterns for the AI:

- Do not emit secrets or hardcode credentials

- Do not bypass input validation or error handling

- Do not mix business logic into API handlers; keep services isolated

- Do not skip migrations or perform schema changes at runtime

Recommended Project Structure

project-root/

├── app/

│   ├── main.py

│   ├── api/

│   │   ├── endpoints/

│   │   │   └── appointment.py

│   │   └── v1.py

│   ├── core/

│   │   ├── config.py

│   │   └── security.py

│   ├── db/

│   │   ├── base.py

│   │   ├── models/

│   │   │   ├── patient.py

│   │   │   ├── appointment.py

│   │   │   └── no_show.py

│   │   └── session.py

│   ├── schemas/

│   │   ├── patient.py

│   │   └── appointment.py

│   └── services/

│       ├── predictor.py

│       └── pipeline.py

├── migrations/

│   └── versions/

├── tests/

|   ├── test_predictor.py

|   └── conftest.py

├── requirements.txt

└── alembic.ini

Core Engineering Principles

Explicit data validation and strong typing
Separation of concerns between data access, business logic, and API
Defensive programming with clear error paths
Observability through structured logging and metrics
Privacy by design and minimal data exposure
Deterministic, testable code; easy to reproduce fixes

Code Construction Rules

Use async endpoints in FastAPI when performing I/O bound tasks
Define Pydantic models for requests and responses with strict field validation
Organize ORM models under app/db/models with a shared base
Encapsulate business logic in app/services, not in route handlers
Store configuration in environment variables; never base64 secrets in code
Employ repository or service patterns for data access

Security and Production Rules

Enable OAuth2 with JWT tokens; refresh tokens managed securely
Use HTTPS in all deployments; enforce TLS
Limit data exposure by returning only necessary fields
Implement input validation, CSRF protection where applicable, and rate limiting
Audit logs for access and predictions; mask PII in logs

Testing Checklist

Unit tests for models and validators
Integration tests for API endpoints with a test database
End-to-end tests to simulate patient no-show scenarios
Linting and type checks in CI; run tests on PRs
Migration tests to ensure schema compatibility

Common Mistakes to Avoid

Hardcoding secrets or credentials in code
Skipping migrations and relying on in-memory schemas
Mixing business logic with API handlers
Neglecting data privacy and access controls
Ignoring timezone handling in scheduling data

FAQ

What is this Cursor Rules Template for dental no-show prediction?

This template provides a complete set of Cursor AI rules to generate a Python FastAPI service, PostgreSQL ORM models, and tests for predicting dental appointment no-shows in private clinics. It emphasizes a modular structure, security, and testability so you can paste the block into your project root as a .cursorrules configuration.

Which stack does this template target?

The template targets Python FastAPI with SQLAlchemy ORM on PostgreSQL, including Pydantic for validation, Alembic for migrations, and Cursor AI for code generation guidance and automation.

How do I run locally after applying these rules?

Install dependencies from requirements.txt, configure a PostgreSQL database, set environment variables for secrets, run the migrations with alembic, and start FastAPI via uvicorn. Use tests to verify endpoints and the predictor service locally.

How does it address patient privacy and data security?

The rules enforce JWT-based authentication, do not expose PII in API responses, use encryption for at rest in the database, and mandate minimal data collection. Secrets are sourced from environment variables, and logs are scrubbed of sensitive information.

Can this template scale to multiple clinics?

Yes, the structure supports multi-tenancy with clinic-scoped data and time zones. Use a clinic_id field in models, enforce access controls per tenant, and implement per-clinic configuration for prediction thresholds and scheduling rules.

Target User

Use Cases