Freight Quote Extraction Cursor Rules Template for Cursor AI

Overview

The Cursor rules configuration is a copyable template tailored for Freight Quote Extraction apps. It targets a Python FastAPI + PostgreSQL stack that ingests shipment emails and customer requests to extract quotes, standardize fields, and feed downstream ERP or rate-shopping workflows. This page provides a complete, drop-in .cursorrules configuration you can paste into your project root to bootstrap safe, testable AI-assisted development.

When to Use These Cursor Rules

• Building an automated freight quoting service that reads shipment confirmations and customer inquiries.
• Need consistent extraction of origin, destination, service level, weight, packaging, and quoted rates.
• Require a reproducible project structure with linting, testing, and secure patterns.
• Want safe AI interactions with deterministic outputs and no external network calls during parsing.

Copyable .cursorrules Configuration

[CursorRules]
stack = python-fastapi-postgresql
slug = freight-quote-extraction-cursor-rules
title = 'Freight Quote Extraction Cursor Rules Template'
framework_role_context = 'You are Cursor AI, assisting a Python FastAPI backend to parse shipment emails and customer requests, extracting freight quotes with deterministic rules and testable patterns.'
code_style = 'PEP8, type hints, docstrings, linting'
architecture = 'project structure: app/, app/api/, app/services/, app/parsers/, app/db/, tests/'
authentication = 'internal API using OAuth2 client credentials; TLS; never log secrets'
database = 'PostgreSQL with SQLAlchemy; Alembic migrations; async session where supported'
testing = 'pytest, pytest-asyncio, black, isort, mypy'
anti_patterns = 'do not eval, do not execute network calls in parsers, do not log PII'

Recommended Project Structure

freight_quote_extractor/
├── app/
│   ├── main.py
│   ├── config.py
│   ├── api/
│   │   ├── endpoints.py
│   │   └── schemas.py
│   ├── services/
│   │   ├── quote_extractor.py
│   │   └── email_parser.py
│   ├── parsers/
│   │   └── shipment_email.py
│   ├── db/
│   │   ├── models.py
│   │   ├── session.py
│   │   └── migrations/
│   └── tests/
│       ├── test_extractor.py
│       └── test_parser.py
├── alembic.ini
├── tests/
└── docker-compose.yml

Core Engineering Principles

• Single source of truth for parsed data; strict typing and data validation.
• Idempotent parsing; re-runs produce the same output.
• Clear separation between parsing, normalization, and persistence layers.
• Observability: structured logs, metrics, and tracing for extraction pipelines.
• Security by default: encrypt at rest, TLS in transit, and validated inputs.

Code Construction Rules

• Use Pydantic models for request/response schemas and internal data validation.
• Follow PEPP8 conventions; enable mypy type checking; run pre-commit hooks.
• Directory boundaries: parsers/ contains input parsers; services/ contains orchestration; db/ contains ORM models and migrations.
• Regex patterns for numeric and currency parsing must be robust and tested; prefer named groups.
• All credentials and secrets must be accessed via environment variables or secret managers; never hardcode.
• Do not perform blocking I/O in FastAPI endpoints; use async DB sessions or thread pools as needed.
• Include unit tests for parsers and integration tests for end-to-end quote extraction.

Security and Production Rules

• Use TLS for all endpoints; rotate API keys; enforce HSTS in production.
• Validate and sanitize all inputs; use strict schemas; log redacted data only.
• Store quotes and PII in encrypted fields; apply column-level encryption if required.
• Limit database permissions and use read/write roles; implement audit logging.
• Deploy with CI/CD; include security scanning and dependency checks; use containerized secrets management.

Testing Checklist

• Unit tests for parsers and extraction rules.
• Integration tests that simulate email payloads and customer requests.
• End-to-end tests that exercise the FastAPI layers and the DB interactions.
• Linting, type checks, and formatting checks in CI.
• Performance checks for parse performance and rate-limiting tests.

Common Mistakes to Avoid

• Relying on fragile regexes; prefer structured parsing and normalization.
• Assuming email formats are constant; implement resilient parsing with fallbacks.
• Exposing internal audit data in API responses; apply data masking.
• Neglecting SQL injection protections in dynamic query building.
• Omitting migrations when schema changes occur; run migrations in production.

Related implementation resources: AI Agent Use Case for Freight Forwarding SMEs Using Shipment Emails to Extract Quotes, Deadlines, and Customer Requirements and Connecting AI to Excel: Practical patterns for production-grade workflows.

FAQ

What is a Cursor Rules Template for freight quote extraction?

A Cursor Rules Template provides a copyable .cursorrules configuration that codifies best practices for parsing shipment emails and customer requests to extract freight quotes, including architecture, security, testing, and anti-patterns for a Python FastAPI stack.

Which stack is this template designed for?

This template is tailored for Python FastAPI with PostgreSQL using SQLAlchemy, following Cursor AI guidelines to build robust freight quote extraction services.

How do I use the copyable .cursorrules block?

Paste the large block into the root of your project as .cursorrules; adjust paths, secrets, and endpoints to fit your environment; then run your standard tests and CI checks.

What are common pitfalls when parsing emails?

Email formats vary widely; implement multiple fallbacks, normalize fields, and guard against missing data; ensure quotes, dates, and addresses are parsed deterministically.

How should I structure tests for this stack?

Write unit tests for parsing logic, integration tests for the FastAPI endpoints, and end-to-end tests that simulate real email payloads and customer requests; include CI to run tests on PRs.