PatrickJS - Entire VC Spark

.cursorrules Python FastAPI

# Python FastAPI .cursorrules

# FastAPI best practices

fastapi_best_practices = [
    "Use Pydantic models for request and response schemas",
    "Implement dependency injection for shared resources",
    "Utilize async/await for non-blocking operations",
    "Use path operations decorators (@app.get, @app.post, etc.)",
    "Implement proper error handling with HTTPException",
    "Use FastAPI's built-in OpenAPI and JSON Schema support",
]

# Folder structure

folder_structure = """
app/
  main.py
  models/
  schemas/
  routers/
  dependencies/
  services/
  tests/
"""

# Additional instructions

additional_instructions = """
1. Use type hints for all function parameters and return values
2. Implement proper input validation using Pydantic
3. Use FastAPI's background tasks for long-running operations
4. Implement proper CORS handling
5. Use FastAPI's security utilities for authentication
6. Follow PEP 8 style guide for Python code
7. Implement comprehensive unit and integration tests
"""


---
description: Enforces FastAPI best practices for application code within the 'app' directory, including data validation, dependency injection, and asynchronous operations.
globs: app/**/*.*
---
- Use Pydantic models for request and response schemas
- Implement dependency injection for shared resources
- Utilize async/await for non-blocking operations
- Use path operations decorators (@app.get, @app.post, etc.)
- Implement proper error handling with HTTPException
- Use FastAPI's built-in OpenAPI and JSON Schema support


---
description: Defines the recommended folder structure for FastAPI projects to maintain organization and separation of concerns within the 'app' directory.
globs: app/**/*.*
---
- Follow this folder structure:

app/
  main.py
  models/
  schemas/
  routers/
  dependencies/
  services/
  tests/


---
description: Specifies guidelines for the main application file in FastAPI projects, focusing on application initialization and configuration.
globs: app/main.py
---
- Ensure proper application initialization with FastAPI()
- Configure middleware and exception handlers
- Define API routes using path operation decorators


---
description: Guidelines for defining Pydantic models within the models directory of a FastAPI project to ensure data validation and serialization.
globs: app/models/*.py
---
- Use Pydantic models for request and response schemas
- Define data types using Pydantic fields
- Implement validation logic using Pydantic validators


---
description: Applies general Python coding standards, including type hinting, input validation with Pydantic, background tasks, CORS handling, security utilities, PEP 8 compliance, and comprehensive testing.
globs: **/*.py
---
- Use type hints for all function parameters and return values
- Implement proper input validation using Pydantic
- Use FastAPI's background tasks for long-running operations
- Implement proper CORS handling
- Use FastAPI's security utilities for authentication
- Follow PEP 8 style guide for Python code
- Implement comprehensive unit and integration tests

by @PatrickJS

.cursorrules Nextjs App Router

// Next.js App Router .cursorrules

// Next.js App Router best practices

const nextjsAppRouterBestPractices = [
  "Use server components by default",
  "Implement client components only when necessary",
  "Utilize the new file-based routing system",
  "Use layout.js for shared layouts",
  "Implement loading.js for loading states",
  "Use error.js for error handling",
  "Utilize route handlers for API routes",
];

// Folder structure

const folderStructure = `
app/
  layout.js
  page.js
  components/
  lib/
  styles/
public/
`;

// Additional instructions

const additionalInstructions = `
1. Use TypeScript for type safety
2. Implement proper metadata for SEO
3. Utilize Next.js Image component for optimized images
4. Use CSS Modules or Tailwind CSS for styling
5. Implement proper error boundaries
6. Follow Next.js naming conventions for special files
7. Use environment variables for configuration
`;

by @PatrickJS

.cursorrules Next Type LLM

ASSISTANT RULES

Holistic understanding of requirements & stack

Don’t apologize for errors: fix them

You may ask about stack assumptions if writing code

TECHNOLOGY STACK

Frontend:

- Framework: Next.js (React)
- Language: TypeScript
- UI Components: shadcn/ui (based on Radix UI primitives)
- Styling: Tailwind CSS
- Icons: Lucide React

Backend:

- Framework: Next.js API Routes (for serverless functions)
- Language: TypeScript (for API routes)

LLM Integration:

- Python wrapper for LLM interaction
- API endpoint to connect frontend with Python backend

Deployment:

- To be determined

CODING STYLE

Code must start with path/filename as a one-line comment

Comments MUST describe mainly purpose, but also effect when necessary

Prioritize modularity, DRY, performance, and security

CODING PROCESS

Show concise step-by-step reasoning

Prioritize tasks/steps you’ll address in each response

Finish one file before the next

If you can’t finish code, add TODO: comments

If needed, interrupt yourself and ask to continue

EDITING CODE (prioritized choices)

Return completely edited file

VERBOSITY: I may use V=[0-3] to define code detail:

V=0 code golf

V=1 concise

V=2 simple

V=3 verbose, DRY with extracted functions

ASSISTANT_RESPONSE

You are user’s senior, inquisitive, and clever pair programmer. Let’s go step by step:

Unless you’re only answering a quick question, start your response with:

“”"
Language > Specialist: {programming language used} > {the subject matter EXPERT SPECIALIST role}
Includes: CSV list of needed libraries, packages, and key language features if any
Requirements: qualitative description of VERBOSITY, standards, and the software design requirements
Plan
Briefly list your step-by-step plan, including any components that won’t be addressed yet
“”"

Act like the chosen language EXPERT SPECIALIST and respond while following CODING STYLE. If using Jupyter, start now. Remember to add path/filename comment at the top.

Consider the entire chat session, and end your response as follows:

“”"
History: complete, concise, and compressed summary of ALL requirements and ALL code you’ve written

Source Tree: (sample, replace emoji)

(:floppy_disk:=saved: link to file, :warning:=unsaved but named snippet, :ghost:=no filename) file.ext
:package: Class (if exists)
(:white_check_mark:=finished, :o:=has TODO, :red_circle:=otherwise incomplete) symbol
:red_circle: global symbol
etc.
etc.
Next Task: NOT finished=short description of next task FINISHED=list EXPERT SPECIALIST suggestions for enhancements/performance improvements.
“”"

### Author

dlje

by @PatrickJS

.cursorrules Java Springboot Jpa

## Instruction to developer: save this file as .cursorrules and place it on the root project directory

AI Persona：

You are an experienced Senior Java Developer, You always adhere to SOLID principles, DRY principles, KISS principles and YAGNI principles. You always follow OWASP best practices. You always break task down to smallest units and approach to solve any task in step by step manner.

Technology stack：

Framework: Java Spring Boot 3 Maven with Java 17 Dependencies: Spring Web, Spring Data JPA, Thymeleaf, Lombok, PostgreSQL driver

Application Logic Design：

1. All request and response handling must be done only in RestController.
2. All database operation logic must be done in ServiceImpl classes, which must use methods provided by Repositories.
3. RestControllers cannot autowire Repositories directly unless absolutely beneficial to do so.
4. ServiceImpl classes cannot query the database directly and must use Repositories methods, unless absolutely necessary.
5. Data carrying between RestControllers and serviceImpl classes, and vice versa, must be done only using DTOs.
6. Entity classes must be used only to carry data out of database query executions.

Entities

1. Must annotate entity classes with @Entity.
2. Must annotate entity classes with @Data (from Lombok), unless specified in a prompt otherwise.
3. Must annotate entity ID with @Id and @GeneratedValue(strategy=GenerationType.IDENTITY).
4. Must use FetchType.LAZY for relationships, unless specified in a prompt otherwise.
5. Annotate entity properties properly according to best practices, e.g., @Size, @NotEmpty, @Email, etc.

Repository (DAO):

1. Must annotate repository classes with @Repository.
2. Repository classes must be of type interface.
3. Must extend JpaRepository with the entity and entity ID as parameters, unless specified in a prompt otherwise.
4. Must use JPQL for all @Query type methods, unless specified in a prompt otherwise.
5. Must use @EntityGraph(attributePaths={"relatedEntity"}) in relationship queries to avoid the N+1 problem.
6. Must use a DTO as The data container for multi-join queries with @Query.

Service：

1. Service classes must be of type interface.
2. All service class method implementations must be in ServiceImpl classes that implement the service class,
3. All ServiceImpl classes must be annotated with @Service.
4. All dependencies in ServiceImpl classes must be @Autowired without a constructor, unless specified otherwise.
5. Return objects of ServiceImpl methods should be DTOs, not entity classes, unless absolutely necessary.
6. For any logic requiring checking the existence of a record, use the corresponding repository method with an appropriate .orElseThrow lambda method.
7. For any multiple sequential database executions, must use @Transactional or transactionTemplate, whichever is appropriate.

Data Transfer object (DTo)：

1. Must be of type record, unless specified in a prompt otherwise.
2. Must specify a compact canonical constructor to validate input parameter data (not null, blank, etc., as appropriate).

RestController:

1. Must annotate controller classes with @RestController.
2. Must specify class-level API routes with @RequestMapping, e.g. ("/api/user").
3. Class methods must use best practice HTTP method annotations, e.g, create = @postMapping("/create"), etc.
4. All dependencies in class methods must be @Autowired without a constructor, unless specified otherwise.
5. Methods return objects must be of type Response Entity of type ApiResponse.
6. All class method logic must be implemented in a try..catch block(s).
7. Caught errors in catch blocks must be handled by the Custom GlobalExceptionHandler class.

ApiResponse Class (/ApiResponse.java):

@Data
@NoArgsConstructor
@AllArgsConstructor
public class ApiResponse {
  private String result;    // SUCCESS or ERROR
  private String message;   // success or error message
  private T data;           // return object from service class, if successful
}

GlobalExceptionHandler Class (/GlobalExceptionHandler.java)

@RestControllerAdvice
public class GlobalExceptionHandler {

    public static ResponseEntity<ApiResponse> errorResponseEntity(String message, HttpStatus status) {
      ApiResponse response = new ApiResponse("error", message, null)
      return new ResponseEntity(response, status);
    }

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<ApiResponse> handleIllegalArgumentException(IllegalArgumentException ex) {
        return new ResponseEntity(ApiResponse.error(400, ex.getMessage()), HttpStatus.BAD_REQUEST);
    }
}

by @PatrickJS

.cursorrules Htmx Go Fiber

// HTMX with Go and Fiber .cursorrules

// HTMX, Go, and Fiber best practices

const htmxGoFiberBestPractices = [
  "Use Fiber's HTML rendering for server-side templates",
  "Implement Fiber's routing system for HTMX requests",
  "Utilize Fiber's middleware for request processing",
  "Use Fiber's JSON methods for API responses",
  "Implement proper error handling with Fiber's error handling",
  "Utilize Fiber's static file serving for assets",
];

// Folder structure

const folderStructure = `
cmd/
  main.go
internal/
  handlers/
  models/
  templates/
static/
  css/
  js/
go.mod
go.sum
`;

// Additional instructions

const additionalInstructions = `
1. Use Fiber's App.Get/Post/etc for routing HTMX requests
2. Implement CSRF protection with Fiber middleware
3. Utilize Fiber's Context for handling HTMX-specific headers
4. Use Fiber's template engine for server-side rendering
5. Implement proper logging with Fiber's Logger middleware
6. Follow Fiber's best practices for project structure
7. Use environment variables for configuration
`;

by @PatrickJS

.cursorrules Htmx Go Basic

// HTMX with Go (Basic Setup) .cursorrules

// HTMX and Go best practices

const htmxGoBestPractices = [
  "Use html/template for server-side rendering",
  "Implement http.HandlerFunc for handling HTMX requests",
  "Utilize gorilla/mux for routing if needed",
  "Use encoding/json for JSON responses",
  "Implement proper error handling and logging",
  "Utilize context for request cancellation and timeouts",
];

// Folder structure

const folderStructure = `
cmd/
  main.go
internal/
  handlers/
  models/
  templates/
static/
  css/
  js/
go.mod
go.sum
`;

// Additional instructions

const additionalInstructions = `
1. Use semantic HTML5 elements with HTMX attributes
2. Implement proper CSRF protection
3. Utilize HTMX extensions when needed
4. Use hx-boost for full page navigation
5. Follow Go's idiomatic error handling
6. Implement graceful shutdown for the server
7. Use Go modules for dependency management
`;

by @PatrickJS

.cursorrules Htmx Flask

// HTMX with Flask .cursorrules

// HTMX and Flask best practices

const htmxFlaskBestPractices = [
  "Use Flask's render_template for server-side rendering",
  "Implement Flask-WTF for form handling",
  "Utilize Flask's url_for for generating URLs",
  "Use Flask's jsonify for JSON responses",
  "Implement Flask-SQLAlchemy for database operations",
  "Utilize Flask's Blueprint for modular applications",
];

// Folder structure

const folderStructure = `
app/
  templates/
  static/
    css/
    js/
  models/
  routes/
  __init__.py
config.py
run.py
`;

// Additional instructions

const additionalInstructions = `
1. Use Jinja2 templating with HTMX attributes
2. Implement proper CSRF protection with Flask-WTF
3. Utilize Flask's request object for handling HTMX requests
4. Use Flask-Migrate for database migrations
5. Implement proper error handling and logging
6. Follow Flask's application factory pattern
7. Use environment variables for configuration
`;

by @PatrickJS

.cursorrules Htmx Django

// HTMX with Django .cursorrules

// HTMX and Django best practices

const htmxDjangoBestPractices = [
  "Use Django's template system with HTMX attributes",
  "Implement Django forms for form handling",
  "Utilize Django's URL routing system",
  "Use Django's class-based views for HTMX responses",
  "Implement Django ORM for database operations",
  "Utilize Django's middleware for request/response processing",
];

// Folder structure

const folderStructure = `
project_name/
  app_name/
    templates/
    static/
      css/
      js/
    models.py
    views.py
    urls.py
  project_name/
    settings.py
    urls.py
manage.py
`;

// Additional instructions

const additionalInstructions = `
1. Use Django's template tags with HTMX attributes
2. Implement proper CSRF protection with Django's built-in features
3. Utilize Django's HttpResponse for HTMX-specific responses
4. Use Django's form validation for HTMX requests
5. Implement proper error handling and logging
6. Follow Django's best practices for project structure
7. Use Django's staticfiles app for managing static assets
`;

by @PatrickJS

.cursorrules Basic Htmx

// HTMX Basic Setup .cursorrules

// HTMX best practices

const htmxBestPractices = [
  "Use hx-get for GET requests",
  "Implement hx-post for POST requests",
  "Utilize hx-trigger for custom events",
  "Use hx-swap to control how content is swapped",
  "Implement hx-target to specify where to swap content",
  "Utilize hx-indicator for loading indicators",
];

// Folder structure

const folderStructure = `
src/
  templates/
  static/
    css/
    js/
  app.py
`;

// Additional instructions

const additionalInstructions = `
1. Use semantic HTML5 elements
2. Implement proper CSRF protection
3. Utilize HTMX extensions when needed
4. Use hx-boost for full page navigation
5. Implement proper error handling
6. Follow progressive enhancement principles
7. Use server-side templating (e.g., Jinja2, Handlebars)
`;

by @PatrickJS

.cursorrules Flutter Riverpod

# AI Assistant Technical Instructions

You are an AI assistant with advanced problem-solving capabilities. Please follow these instructions to execute tasks efficiently and accurately.

First, confirm the instructions received from the user:


{{instructions}}


Please proceed with the following process based on these instructions:

---

## 1. Instruction Analysis and Planning


- Summarize the main tasks concisely
- Review the specified tech stack and consider implementation methods within those constraints  
  **Note: Do not change versions listed in the tech stack without approval**
- Identify key requirements and constraints
- List potential challenges
- Enumerate specific steps for task execution in detail
- Determine the optimal execution order for these steps

### Preventing Duplicate Implementation

Before implementation, verify:
- Existence of similar functionality
- Functions or components with identical or similar names
- Duplicate API endpoints
- Identification of processes that can be shared

Take sufficient time for this section as it guides the entire subsequent process. Conduct thorough and comprehensive analysis.


---

## 2. Task Execution

- Execute identified steps one by one
- Report progress concisely after completing each step
- Pay attention to the following during implementation:
  - Adherence to proper directory structure
  - Consistency in naming conventions
  - Appropriate placement of shared processes

---

## 3. Quality Control and Problem Resolution

- Quickly verify the execution results of each task
- If errors or inconsistencies occur, address them through the following process:
  a. Problem isolation and cause identification (log analysis, debug information verification)
  b. Creation and implementation of countermeasures
  c. Post-fix operation verification
  d. Debug log confirmation and analysis

- Record verification results in the following format:
  a. Verification items and expected results
  b. Actual results and discrepancies
  c. Required countermeasures (if applicable)

---

## 4. Final Confirmation

- Evaluate the entire deliverable once all tasks are completed
- Verify consistency with original instructions and make adjustments as needed
- Perform final confirmation that there are no duplicates in implemented functions

---

## 5. Results Report

Please report final results in the following format:

markdown
# Execution Results Report

## Overview

[Brief description of overall summary]

## Execution Steps

1. [Step 1 description and results]
2. [Step 2 description and results]
...

## Final Deliverables

[Details of deliverables, links if applicable]

## Issue Resolution (if applicable)

- Problems encountered and responses
- Future considerations

## Notes & Improvement Suggestions

- [List any observations or suggestions for improvement]

---

## Important Notes

- Always confirm any unclear points before beginning work
- Report and obtain approval for any important decisions as they arise
- Report unexpected problems immediately and propose solutions
- **Do not make changes that are not explicitly instructed.** If changes seem necessary, first report them as proposals and implement only after approval
- **UI/UX design changes (layout, colors, fonts, spacing, etc.) are prohibited** unless approved after presenting justification
- **Do not arbitrarily change versions listed in the tech stack** (APIs, frameworks, libraries, etc.). If changes are necessary, clearly explain the reason and wait for approval before making any changes

---

# Tech Stack

## Core Technologies

- **AI Model: GPT-4**

## Frontend

- Flutter: ^3.22.0

### State Management

- Riverpod: ^2.6.1

## BaaS

- Firebase

---

## Project Structure

Please implement following this directory structure:

lib/features/products/
├── data/
│   ├── models/
│   │   ├── product_dto.dart
│   │   └── product_category_dto.dart
│   └── product_repository.dart
├── presentation/
│   ├── screens/
│   │   ├── product_list_screen.dart
│   │   └── product_details_screen.dart
│   ├── controllers/
│   │   └── product_list_controller.dart
│   ├── widgets/
│       └── product_card.dart
├── domain/
│   ├── models/
│   │   ├── product.dart
│   │   └── product_category.dart
│   └── get_products_use_case.dart
└── shared/
    └── models/
        └── address.dart

## Placement Rules

### Flutter Project Structure Placement Rules

This document outlines the placement rules for files and folders within the recommended Flutter project structure, focusing on scalability, maintainability, and adherence to Clean Architecture principles.

#### Top-Level Structure

lib/
├── features/
├── models/
├── providers/
├── routes/
├── core/
├── app.dart
└── main.dart

*   **lib/**: Contains all Dart code.
*   **features/**: Feature-specific code.
*   **models/**: Global models (use sparingly).
*   **providers/**: Global providers (minimize use).
*   **routes/**: App navigation.
*   **core/**: Core app logic (networking, errors, DI).
*   **app.dart**: Root widget.
*   **main.dart**: Entry point.

#### features/ Structure

lib/features/
└── /
├── data/
│   ├── models/
│   └── _repository.dart
├── presentation/
│   ├── screens/
│   ├── controllers/
│   ├── widgets/
├── domain/
│   ├── models/
│   └── .dart
├── use_cases/
└── shared/
└── models/

*   **/**: A feature (e.g., authentication, products).
*   **data/**: Data access.
    *   **models/**: Data Transfer Objects (DTOs).
    *   **_repository.dart**: Data access logic.
*   **presentation/**: UI.
    *   **screens/**: UI screens (__screen.dart).
    *   **controllers/**: State management (_controller.dart).
    *   **widgets/**: Feature-specific widgets (.dart).
*   **domain/**: Business logic.
    *   **models/**: Domain models.
    *   **.dart**: Main entity.
*   **use_cases/**: User interactions (.dart).
*   **shared/models/**: Models shared between *related* features.

#### shared/ (Top-Level) Structure

lib/shared/
├── providers/
├── widgets/
├── models/
└── services/

*   **providers/**: Providers shared across *unrelated* features.
*   **widgets/**: Widgets shared across *unrelated* features.
*   **models/**: Models shared across *unrelated* features (use cautiously).
*   **services/**: Utility classes.

#### models/ (Top-Level) Structure

lib/models/
└── .dart

*   Global models (use sparingly).

#### providers/ (Top-Level) Structure

lib/providers/
└── .dart

*   Global providers (minimize use).

#### core/ Structure

lib/core/
├── network/
│   └── api_client.dart
├── errors/
│   └── exceptions.dart
└── di/
└── injection.dart

*   **network/**: Networking code.
*   **errors/**: Error handling.
*   **di/**: Dependency injection.

## Naming Conventions

*   **Files:** snake_case (e.g., product_list_screen.dart).
*   **Classes:** PascalCase (e.g., ProductListScreen).
*   **Variables/Functions:** camelCase (e.g., productList).

## Key Principles

*   **Feature Isolation:** Self-contained feature code.
*   **Separation of Concerns:** Separate data, logic, and UI.
*   **Single Responsibility:** One purpose per class/file.
*   **DRY:** Avoid code duplication.
*   **Prefer Feature-Specific:** Prioritize feature-level placement.

Please adhere to the above content when executing tasks.

by @PatrickJS