Cursor Rules Template: Django + PostGIS Climate Risk Analytics

Overview

This Cursor rules configuration targets a Django + PostGIS climate risk analytics stack. It covers location data handling, asset exposure modeling, scenario planning, and executive reports. The direct answer for developers: paste the included configuration block into your project root as a .cursorrules file to guide Cursor AI in safe, stack-aware code generation and governance.

When to Use These Cursor Rules

• When modeling climate risk with spatial data and asset exposure in a Django app
• When integrating PostGIS geospatial queries with the Django ORM
• When drafting reproducible scenarios and producing executive reports from analytics results
• When enforcing architecture and security constraints across the data pipeline
• When you need a copyable, auditable Cursor rules block for team handoff

Copyable .cursorrules Configuration

.cursorrules
Framework Role & Context
- Role: You are a Cursor AI assistant embedded in a Django + PostGIS climate risk analytics project.
- Context: The system stores Location data (Point/Polygon), Asset exposures, Scenario definitions, and Reports for executive audiences. Follow stack constraints and ensure safe AI usage.

Code Style and Style Guides
- Language: Python 3.11+
- Formatter: Black, isort; Lint: flake8/ruff-compatible rules
- Naming: PEP8 compliant, snake_case for identifiers, clear docstrings
- Typing: Optional type hints with mypy style guidance

Architecture & Directory Rules
- Project layout should include climate_risk/ root with manage.py and a Django project folder.
- Apps: locations, assets, scenarios, reports, core
- Data layer uses PostGIS extensions on PostgreSQL; GeoDjango models preferred
- Use DRF for APIs and serializers
- Migrations must be explicit and reviewed in PRs

Authentication & Security Rules
- Use Django auth with OAuth2/JWT for API access; enforce CSRF protection on state-changing requests
- Secrets managed via environment variables; do not commit credentials
- Enforce TLS in all environments; enable HSTS in production
- Least privilege access to database roles; rotate credentials regularly

Database and ORM patterns
- PostgreSQL with PostGIS; use GeoDjango fields (PointField, PolygonField)
- Models: Location, Asset, Exposure, Scenario, Report; relationships via ForeignKey/ManyToMany
- Avoid raw SQL in application code; prefer ORM queries with spatial functions when possible

Testing & Linting Workflows
- Unit tests for models/serializers; integration tests for geo queries
- Use pytest-django; run lint and tests in CI
- Include fixtures for Location and Asset data; snapshot tests for reports

Prohibited Actions and Anti-patterns for the AI
- Do not generate raw SQL strings beyond ORM abstractions
- Do not bypass authentication or export restricted data
- Do not hardcode secrets or credentials
- Do not propose non geo-aware indexing strategies that ignore spatial indexes
- Do not introduce vendor-locked features outside the Django + PostGIS ecosystem

Recommended Project Structure

climate_risk/
├── manage.py
├── climate_risk/                  # Django project settings
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── apps/
│   ├── locations/                 # Location models and migrations (PostGIS planes)
│   │   ├── models.py
│   │   ├── serializers.py
│   │   └── migrations/
│   ├── assets/                    # Asset exposure models
│   │   ├── models.py
│   │   ├── serializers.py
│   │   └── migrations/
│   ├── scenarios/                 # Climate scenarios and assumptions
│   │   ├── models.py
│   │   ├── serializers.py
│   │   └── migrations/
│   ├── reports/                   # Executive report generation and export
│   │   ├── models.py
│   │   ├── services.py
│   │   └── migrations/
│   └── core/                      # shared utilities, authentication hooks, utils
│       ├── auth.py
│       ├── permissions.py
│       └── utilities.py
├── data/                          # seed and test data for geo queries
├── requirements.txt
├── Dockerfile
└── docker-compose.yml

Core Engineering Principles

• Explicit data provenance and auditable data lineage for all climate inputs
• Idempotent migrations and deterministic seeds for reproducible environments
• Security-first defaults with least privilege and encrypted at rest
• Geo-aware performance with spatial indexes and efficient queries
• Observability through structured logging, metrics, and tracing

Code Construction Rules

• Adopt Django + GeoDjango for spatial data modeling; prefer models with PointField and PolygonField
• Use Django REST Framework serializers for API contracts and input validation
• Separate concerns by app: locations handles spatial data, assets handles exposure, scenarios for modeling, reports for outputs
• All data access passes through the ORM; avoid string-constructed SQL in app code
• Implement caching for heavy geo queries and report generation, with explicit cache keys
• CI gates ensure tests pass and lint rules are enforced on every PR
• Do not rely on client-side processing for critical climate computations
• Do not bypass authentication for endpoints that expose asset exposure or scenario data

Security and Production Rules

• Store secrets in environment variables; never commit keys
• Use TLS, enable HSTS, and rotate secrets regularly
• Enable CSRF protection for state-changing requests; enforce token-based auth for APIs
• Audit access to climate data; implement role-based access control for reports
• Implement input validation and strict serialization to prevent data leakage

Testing Checklist

• Unit tests for models and serializers with GeoDjango fields
• Integration tests for spatial queries and scenario computations
• End-to-end tests for report generation and export formats
• CI pipelines run linting, tests, and type checks on pull requests
• Performance tests for common geospatial queries with realistic data volumes

Common Mistakes to Avoid

• Skipping spatial indexes on location data; this kills query performance
• Ignoring data provenance when ingesting external climate data sources
• Embedding business logic in templates or views instead of services
• Overexposing sensitive model fields in API responses
• Neglecting to validate user input for scenarios and reports

Related Cursor rules templates

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

• Cursor Rules Template: Django Payroll Dashboard with Timesheets, Deductions, Approvals and Exportable Reports
• Cursor Rules Template — Real Estate Dashboard with Cash Flow, ROI, and Analytics
• Cursor Rules Template: Manufacturing Execution Dashboard (NestJS + PostgreSQL)
• Cursor Rules Template: Marketing Analytics Platform with Campaign Tracking, Attribution, Landing Page Analytics and AI Insights

FAQ

What stack is this Cursor Rules Template built for?

The template targets Django with PostGIS for climate risk analytics, leveraging GeoDjango, DRF, and Cursor AI to guide model design, data flow, and safe AI-assisted development.

What does the Copyable .cursorrules block configure?

It sets the framework role, code style, architecture, auth and security, database patterns, tests, and anti pattern rules so Cursor AI can generate compliant, stack-aware code and governance artifacts.

What should the project structure look like?

The recommended structure isolates spatial models in locations, asset exposure in assets, scenarios in scenarios, and reports in reports with a shared core for utilities and auth. This separation supports maintainability and scaling.

How should security be enforced in production?

Apply TLS, CSRF protection, OAuth2/JWT for API access, secret management via environment variables, and strict RBAC for data access to climate inputs and executive reports.

How do you validate geospatial queries performance?

Benchmark with representative datasets, ensure spatial indexes exist, cache heavy results, and profile queries to avoid N+1 patterns in geospatial joins.