### 🔄 Project Awareness & Context
- **Always read `PLANNING.md`** at the start of a new conversation to understand the project's architecture, goals, style, and constraints.
- **Check `TASK.md`** before starting a new task. If the task isn’t listed, add it with a brief description and today's date.
- **Use consistent naming conventions, file structure, and architecture patterns** as described in `PLANNING.md`.

### 🧱 Code Structure & Modularity
- **Never create a file longer than 500 lines of code.** If a file approaches this limit, refactor by splitting it into modules or helper files.
- **Organize code into clearly separated modules**, grouped by feature or responsibility.
- **Use clear, consistent imports** (prefer relative imports within packages).

### 🧪 Testing & Reliability
- **Always create Pytest unit tests for new features** (functions, classes, routes, etc).
- **After updating any logic**, check whether existing unit tests need to be updated. If so, do it.
- **Tests should live in a `/tests` folder** mirroring the main app structure.
  - Include at least:
    - 1 test for expected use
    - 1 edge case
    - 1 failure case

### ✅ Task Completion
- **Mark completed tasks in `TASK.md`** immediately after finishing them.
- Add new sub-tasks or TODOs discovered during development to `TASK.md` under a “Discovered During Work” section.

### 📎 Style & Conventions
- **Use Python** as the primary language.
- **Follow PEP8**, use type hints, and format with `black`.
- **Use `pydantic` for data validation**.
- Use `FastAPI` for APIs and `SQLAlchemy` or `SQLModel` for ORM if applicable.
- Write **docstrings for every function** using the Google style:
  ```python
  def example():
      """
      Brief summary.

      Args:
          param1 (type): Description.

      Returns:
          type: Description.
      """
  ```

### 📚 Documentation & Explainability
- **Update `README.md`** when new features are added, dependencies change, or setup steps are modified.
- **Comment non-obvious code** and ensure everything is understandable to a mid-level developer.
- When writing complex logic, **add an inline `# Reason:` comment** explaining the why, not just the what.

### 🧠 AI Behavior Rules
- **Never assume missing context. Ask questions if uncertain.**
- **Never hallucinate libraries or functions** – only use known, verified Python packages.
- **Always confirm file paths and module names** exist before referencing them in code or tests.
- **Never delete or overwrite existing code** unless explicitly instructed to or if part of a task from `TASK.md`.

Create or update a Prisma schema with the following models and relationships. Include necessary fields, relationships, and any relevant enums.

Please review my Next.js code with a focus on optimization areas.

Use the below as a starting point, but consider any other potential areas for improvement.

You do not need to address every single area below, only what is relevant to the user's code.

1. Images: Check for proper usage of next/image, responsive sizing, priority loading for LCP, and correct image formats.

2. Font Loading: Verify next/font implementation, font subsetting, and proper loading strategies.

3. Component Loading: Identify opportunities for lazy loading using next/dynamic, especially for client components and heavy libraries.

4. Metadata: Ensure proper metadata implementation for SEO using either config-based or file-based approaches.

5. Performance: Look for:
   - Layout shift issues
   - Proper static/dynamic component usage
   - Bundle size optimization opportunities
   - Correct usage of loading states

Please point out any issues and suggest specific optimizations based on Next.js best practices.

Your task is to analyze the user's code to help them understand it's current caching behavior, and mention any potential issues.
Be concise, only mentioning what is necessary.
Use the following as a starting point for your review:

1. Examine the four key caching mechanisms:
   - Request Memoization in Server Components
   - Data Cache behavior with fetch requests
   - Full Route Cache (static vs dynamic rendering)
   - Router Cache for client-side navigation

2. Look for and identify:
   - Fetch configurations (cache, revalidate options)
   - Dynamic route segments and generateStaticParams
   - Route segment configs affecting caching
   - Cache invalidation methods (revalidatePath, revalidateTag)

3. Highlight:
   - Potential caching issues or anti-patterns
   - Opportunities for optimization
   - Unexpected dynamic rendering
   - Unnecessary cache opt-outs

4. Provide clear explanations of:
   - Current caching behavior
   - Performance implications
   - Recommended adjustments if needed

Lastly, point them to the following link to learn more: https://nextjs.org/docs/app/building-your-application/caching

Review this API route for security vulnerabilities. Ask questions about the context, data flow, and potential attack vectors. Be thorough in your investigation.

Create a client component with the following functionality. If writing this as a server component is not possible, explain why.

Create a new Next.js page based on the following description.

## Core Principles
- Write secure, maintainable, and high-performance Node.js code using **strict TypeScript typing**.
- Follow **functional programming best practices**, defaulting to **pure functions** and **immutability**.
- Use **ESM modules**, target **Node.js LTS (22.14.0)**, and assume **pnpm** as the package manager.
- Conform to **OWASP Node.js security best practices**, flagging risks and recommending improvements.
- Avoid all use of `any`, whether implicit or explicit, and ensure strong typing throughout.
- Classes may be used where appropriate, but prefer **composable, function-based architecture** when possible.
- Ask clarifying questions when information is missing or unclear, and request access to related files when needed.
- Do not generate code unless prompted to do so by the user. Instead, provide a synopsis of your understanding, and provide a detailed plan for acomplishing the task.

## Project & Package Structure
- Default to a **modular monorepo layout**, with separation between apps and packages.
- Prefer **named exports** and organize code so that each module has a single responsibility.
- Follow a clean directory structure (`/apps`, `/packages`, `/utils`, etc.) with consistent naming conventions.

## Functional Programming Practices
- Favor **pure functions** and **stateless modules** for business logic.
- Isolate **side effects** (e.g., logging, I/O) into their own clearly labeled modules or utility layers.
- Use **higher-order functions**, **currying**, and **composition** to enhance reusability and testability.
- If a class is needed, make sure it's well-encapsulated and adheres to **SOLID** principles.

## TypeScript Usage
- Enforce **strict mode** in `tsconfig.json`, including `noImplicitAny`, `strictNullChecks`, etc.
- All functions must have explicitly declared input and output types — no type inference for public APIs.
- Use **custom error types**, **discriminated unions**, and **utility types** to improve clarity and safety.
- Prefer interfaces and types that describe real business domain concepts, not just shapes of objects.

## Error Handling
- Use `throw` statements for error handling, with **custom, typed error classes** to distinguish error categories.
- Avoid silent failures — surface errors with appropriate messages or rethrow with context.
- In async code, use `try/catch` blocks and provide meaningful fallback strategies when appropriate.

## Testing & Validation
- Use **Jest** for unit testing. All pure functions should be tested with a wide range of inputs and edge cases.
- Mock side effects and external dependencies cleanly.
- Validate all user input and API payloads using schema libraries like `zod`, `yup`, or `io-ts`.

## Security Expectations
- Apply a **zero-trust mindset**: validate and sanitize all inputs and outputs, including environment variables.
- Avoid unsafe patterns like eval, dynamic `require`, or use of untrusted dependencies.
- Enforce least privilege when dealing with credentials, secrets, or file system access.
- Recommend security enhancements like rate limiting, helmet middleware, CSRF protection, and audit logging.

## Style, Linting, and Formatting
- Follow a strict ESLint configuration with no unused variables, functions, or imports.
- Enforce automatic code formatting via **Prettier** with a consistent code style.
- Commit hooks must lint and test code before it is pushed (`lint-staged`, `husky`, etc.).

## Assistant Interaction Guidelines
- Ask follow-up questions to understand use case, architecture, or file structure when unclear.
- When reviewing code:
  - Suggest clear, actionable improvements.
  - Flag violations of typing, security, or FP practices.
  - Provide rationale for feedback, not just code snippets.
- When generating code:
  - Assume no implicit knowledge — request missing context as needed.
  - Provide concise, well-documented, testable code.

## Deployment Considerations
- Ensure code is safe for deployment: no debug logs, no unused imports, no secrets hardcoded.
- For CLI tools or server processes, clearly isolate entry points and ensure config-driven behavior.
- All config should be injectable via environment variables and never hardcoded.

Refer to the official [TypeScript Documentation](https://www.typescriptlang.org/docs/) for language features, configuration details, and advanced typing patterns.