Cursor Rules Template: Personal AI OS with Notes, Tasks, Calendar, Memory and Chat (FastAPI + PostgreSQL)

Overview

Direct answer: This Cursor Rules Template provides a copyable .cursorrules block and stack-specific guidance for building a personal AI operating system (notes, tasks, calendar, documents, memory, and a chat interface) using a FastAPI backend with PostgreSQL. It defines the role, architecture, and guardrails needed for safe, scalable development with Cursor AI.

The Cursor rules configuration is designed to live at the project root as a .cursorrules file and to guide Cursor AI in maintaining stack discipline while enabling rapid iteration on features like memory, notes, tasks, and chat integration.

When to Use These Cursor Rules

• Starting a new personal AI OS project with a FastAPI + PostgreSQL backend.
• Enforcing architecture boundaries for modules: notes, tasks, calendar, documents, memory, and chat.
• Guiding Cursor AI to avoid unsafe data access patterns and to protect secrets.
• Standardizing code style and CI hooks (linting, formatting, and tests) across the team.
• Ensuring data models, migrations, and security controls align with best practices for a production-grade system.

Copyable .cursorrules Configuration

# Cursor Rules Template for FastAPI + PostgreSQL Personal AI OS
# Core Framework and Context
Framework: FastAPI
Runtime: Python 3.11+
Database: PostgreSQL 15+
ORM: SQLAlchemy
Migrations: Alembic
Context: You are Cursor AI collaborating with a developer building a personal AI operating system with notes, tasks, calendar, documents, memory, and chat.

# Framework Role & Context
Role: System Architect for a Personal AI OS
Context: Provide implementable guidance, not business fluff. Prioritize safety, clarity, and stack adherence.

# Code Style and Style Guides
Language: Python
Formatting: Black
Import Ordering: isort
Linting: flake8
Docstrings: Google style
Typing: Pydantic models for request/response shapes

# Architecture & Directory Rules
ProjectRoot: .
Structure:
  app/
  app.api/
  app.core/
  app.db/
  app.models/
  app.services/
  app.memory/
  app.notes/
  app.tasks/
  app.calendar/
  app.documents/
  app.chat/
  tests/
  migrations/

# Authentication & Security Rules
Auth: OAuth2 with JWT tokens
Secrets: Use environment vars or Vault; never log secrets
Cookies: Secure, HttpOnly, SameSite=Lax
RBAC: Keep read/write permissions scoped per module

# Database and ORM patterns
DB: PostgreSQL 15+
ORM: SQLAlchemy ORM with declarative models
Migrations: Alembic versioned migrations
Data Seeding: Separate migration/data script
DB Connections: Pooling with max 10-20 per process

# Testing & Linting Workflows
Tests: pytest with asyncio support
CI: GitHub Actions or similar
Quality: pre-commit with Black, isort, Flake8, Ruff
TestsCatagories: unit, integration, migration tests

# Prohibited Actions and Anti-patterns for the AI
Do not: eval/exec untrusted code
Do not: access secrets from client-side context
Do not: bypass authentication or logging sensitive data
Avoid: coupling memory or notes schema directly to a single vendor service
Avoid: heavy server-side business rules in a single module; keep concerns separated

Recommended Project Structure

project-root/
├── app/
│   ├── api/
│   │   └── v1/
│   │       └── endpoints.py
│   ├── core/
│   │   └── config.py
│   ├── db/
│   │   ├── models/
│   │   │   ├── user.py
│   │   │   ├── note.py
│   │   │   ├── task.py
│   │   │   ├── calendar_event.py
│   │   │   ├── document.py
│   │   │   └── memory.py
│   │   ├── session.py
│   │   └── migrations/
│   ├── models/
│   │   ├── user.py
│   │   ├── note.py
│   │   ├── task.py
│   │   ├── calendar_event.py
│   │   ├── document.py
│   │   └── memory.py
│   ├── memory/
│   │   └── memory_store.py
│   ├── notes/
│   │   └── notes_service.py
│   ├── tasks/
│   │   └── tasks_service.py
│   ├── calendar/
│   │   └── calendar_service.py
│   ├── documents/
│   │   └── documents_service.py
│   ├── chat/
│   │   └── chat_service.py
│   └── main.py
├── tests/
├── migrations/
├── alembic.ini
├── requirements.txt
└── README.md

Core Engineering Principles

• Single source of truth for domain entities: notes, tasks, calendar, documents, memory, and chat models.
• Explicit data ownership and clear boundary between API, services, and storage.
• Consistent interfaces for memory retrieval, query expansion, and chat context management.
• Secure by default: least privilege, encrypted data at rest, and tokens with short lifetimes.
• Test-driven emphasis: unit, integration, and migrations tests with reproducible environments.
• Deterministic code formatting and linting across all modules.

Code Construction Rules

• All business logic lives in service modules under app/; routers only delegate to services.
• Database models use SQLAlchemy declarative base with explicit relationships and indexes.
• Use Pydantic models for all external request/response payloads with strict validation.
• Memory module stores contextual history with timestamps and privacy boundaries; avoid leaking context across users.
• Notes, tasks, calendar, and documents modules share a common base model for CRUD patterns.
• Chat interface must read from memory store to construct context; never expose raw memory to clients.
• All secrets rotated and rotated keys invalidated in case of suspected breach.
• CI must fail on any lint or test error; migrations must run in CI before deployment.
• Do not hard-code credentials; always pull from environment or vaults.

Security and Production Rules

• Use HTTPS, secure cookies, CSRF protection for state-changing endpoints, and strict API authentication.
• Audit logging for user actions on notes, memory, and chat data; redact sensitive content in logs.
• Limit request sizes and enforce rate limits; protect memory and chat endpoints from abuse.
• Isolate memory, notes, and documents data with per-user access controls and RBAC checks.
• Implement data retention policies and encryption at rest for sensitive data (memory, documents).
• Perform regular dependency scanning for vulnerabilities; pin dependency versions.

Testing Checklist

• Unit tests for all service methods and data access layers.
• Integration tests for API endpoints and database interactions.
• Migration tests to verify Alembic scripts run without errors.
• Security tests including token validation, RBAC checks, and input validation tests.
• End-to-end tests simulating notes/tasks/calendar flows with memory and chat context.

Common Mistakes to Avoid

• Conflating memory storage with ephemeral in-process state; memory must be persisted with proper privacy controls.
• Embedding business rules in the client; keep policy in server-side code and Cursor rules.
• Overusing Redis or in-memory databases for persistent OS data; use PostgreSQL for durable storage.
• Skipping migrations or relying on automatic schema changes in production.
• Neglecting secret management and hard-coded credentials.

Related Cursor rules templates

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

• Cursor Rules Template for AI Bookkeeping with Python FastAPI & PostgreSQL
• Cursor Rules Template: Podcast Management Stack
• Cursor Rules Template: Python FastAPI API Monitoring
• Cursor Rules Template — Real Estate Dashboard with Cash Flow, ROI, and Analytics

FAQ

What is this Cursor Rules Template for FastAPI + PostgreSQL Personal AI OS?

This template provides a copyable .cursorrules block and stack-specific guidance to implement a personal AI operating system with notes, tasks, calendar, documents, memory, and chat using FastAPI and PostgreSQL, with strong security, testing, and architecture practices.

Which stack does this template target?

The template targets a FastAPI backend with a PostgreSQL database, SQLAlchemy ORM, Alembic migrations, and a modular app structure covering notes, tasks, calendar, documents, memory, and chat interfaces.

How should memory be modeled in this OS?

Memory should be persisted in the database with per-user scoping, timestamps, and context windows. It should be contextually retrieved for conversations without leaking data between users, and purged according to a retention policy.

How do you ensure security and proper authentication?

Use OAuth2 with JWT tokens, secure storage of secrets, and environment-based rotation. Authenticate every API call, enforce per-resource RBAC, and encrypt sensitive data at rest and in transit.

What testing and CI practices are recommended?

Employ pytest with asyncio support, run pre-commit hooks (Black, isort, Flake8), perform unit and integration tests for API endpoints, and validate migrations in CI before deployment.