- Follow Next.js patterns, use app router and correctly use server and client components.
- Use Tailwind CSS for styling.
- Use Shadcn UI for components.
- Use TanStack Query (react-query) for frontend data fetching.
- Use React Hook Form for form handling.
- Use Zod for validation.
- Use React Context first then Jotai if necessary for state management.
- Use PascalCase when creating new React files. UserCard, not user-card.
- Use kebab-case when creating the rest file, like hooks, lib, utils, parsers, etc.
- Use named exports when creating new react components.
- Besides of that, keep the consistency from currently codebase context and follow their code's style.
- DO NOT TEACH ME HOW TO SET UP THE PROJECT, JUMP STRAIGHT TO WRITING COMPONENTS AND CODE.

Please review my Next.js code with a focus on security issues.

Use the below as a starting point, but consider any other potential issues

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

1. Data Exposure:
- Verify Server Components aren't passing full database objects to Client Components
- Check for sensitive data in props passed to 'use client' components
- Look for direct database queries outside a Data Access Layer
- Ensure environment variables (non NEXT_PUBLIC_) aren't exposed to client

2. Server Actions ('use server'):
- Confirm input validation on all parameters
- Verify user authentication/authorization checks
- Check for unencrypted sensitive data in .bind() calls

3. Route Safety:
- Validate dynamic route parameters ([params])
- Check custom route handlers (route.ts) for proper CSRF protection
- Review middleware.ts for security bypass possibilities

4. Data Access:
- Ensure parameterized queries for database operations
- Verify proper authorization checks in data fetching functions
- Look for sensitive data exposure in error messages

Key files to focus on: files with 'use client', 'use server', route.ts, middleware.ts, and data access functions.

I will provide you with raw git commit logs and file change stats from a commit range. Please generate a clear, concise changelog summary suitable for a GitHub PR description. Use subpoints grouped by feature or area, keep important details for collaborators, but keep it easy to read.

Format the output in markdown, starting with:

```
## Changelog

- Feature or Area:
  - Key change or addition
  - Another related change
- Another Feature:
  - ...
```


When I send you git commit and diff info, produce the changelog using this format.
When I don't send you git commit and diff info, show me how to get the range commit with --first-parent and result output named git-log.txt.

Goal: Generate a concise, copy-friendly Git commit message from a provided git diff or diff context.
Instructions: - Start the commit header with a capital letter; do not use prefixes like feat:, fix:, chore:, etc. - Limit the header to a maximum of 40 characters. - If the changes require explanation, add an optional body with short bullet points. - If no diff context is provided, inform the user and show how to use @Git Diff. - If the diff shows no changes, state that there are no changes to commit. - Wrap any code-related identifiers (function names, variable names, file names, commands) in backticks. - Shorten the file directory for simple message (eg. just `fileName.{ext}` instead of `src/bla/bla/bla/fileName.{ext}`). - Output should be easy to copy, with no extra commentary.
Input: - Git diff or diff context.
Output format: - Header line (<= 40 chars) - Optional bullet list body (each line starts with “- ”)
Behavior examples: - No input or missing diff: “No diff context provided. Use `@Git Diff` to include your changes.” - Empty diff or no changes detected: “No changes to commit.”