تو به‌عنوان یک Senior Front-end Engineer و متخصص React، TypeScript و Next.js عمل کن.

مشخصات پروژه:
- Framework: [Next.js version]
- Router: [App Router / Pages Router]
- Language: [TypeScript / JavaScript]
- Styling: [Tailwind / CSS Module / ...]
- State management: [در صورت وجود]
- Database/API: [در صورت مرتبط بودن]

هدف من:
[تغییر موردنظر را دقیق توضیح بده]

قوانین:
1. قبل از تغییر، کد فعلی را تحلیل کن.
2. منطق و رفتارهای غیرمرتبط را تغییر نده.
3. اگر اطلاعات کافی نیست، دقیقاً بگو کدام فایل یا بخش لازم است.
4. از ساخت API، prop، type یا function خیالی خودداری کن.
5. تغییرات را تا حد ممکن کوچک و قابل بازگشت نگه دار.
6. سازگاری Server Component و Client Component را بررسی کن.
7. TypeScript type safety را حفظ کن.
8. خطاها، loading state و edge caseها را در صورت ارتباط بررسی کن.
9. قبل از ارائه نسخه نهایی، احتمال regression را ارزیابی کن.

خروجی را با این ساختار بده:
- علت یا تحلیل مسئله
- فایل‌های نیازمند تغییر
- تغییر پیشنهادی
- کد نهایی یا Patch
- مواردی که باید بعد از تغییر تست شوند

کد/فایل فعلی:
[کد را اینجا قرار بده]

به‌عنوان Senior React Developer این کامپوننت را طراحی کن:

نام کامپوننت:
[نام]

کاربرد:
[توضیح]

ورودی‌ها:
[Props و داده‌ها]

رفتارهای تعاملی:
[کلیک، فیلتر، modal، loading و...]

الزامات:
- TypeScript با typeهای دقیق
- Responsive از موبایل تا دسکتاپ
- HTML semantic
- دسترس‌پذیری مناسب
- عدم استفاده از useEffect مگر واقعاً لازم باشد
- جلوگیری از state غیرضروری
- component responsibilities واضح باشد
- اگر بخشی قابل استخراج است، فقط در صورت ارزش واقعی آن را جدا کن

ابتدا ساختار پیشنهادی را کوتاه توضیح بده، سپس کد نهایی را ارائه کن.
در پایان edge caseها و موارد تست را هم بنویس.

این خطا در پروژه من رخ داده است:

[متن کامل Error]

فایل مرتبط:
[کد فایل]

رفتار مورد انتظار:
[توضیح]

رفتار فعلی:
[توضیح]

می‌خواهم:
1. ابتدا علت ریشه‌ای خطا را مشخص کنی.
2. تفاوت symptom و root cause را توضیح بدهی.
3. با کمترین تغییر ممکن مشکل را رفع کنی.
4. هیچ منطق غیرمرتبطی را بازنویسی نکنی.
5. اگر تغییر پیشنهادی ممکن است regression ایجاد کند، قبل از کد هشدار بده.
6. در پایان بگو چه تست‌هایی اجرا کنم.

اگر برای تشخیص قطعی به فایل دیگری نیاز داری، نام دقیق آن فایل یا نوع کدی که باید ببینی را مشخص کن.

این فایل متعلق به یک پروژه Next.js با App Router است:

[کد]

بررسی کن:
- آیا این فایل واقعاً به "use client" نیاز دارد؟
- کدام قسمت‌ها می‌توانند Server Component باقی بمانند؟
- آیا useState، useEffect، event handler یا Browser API وجود دارد؟
- آیا data fetching را می‌توان در Server Component انجام داد؟
- آیا secret یا منطق حساس به اشتباه وارد Client شده؟
- آیا می‌توان Client boundary را کوچک‌تر کرد؟

هدف:
کمترین JavaScript لازم به مرورگر ارسال شود، بدون اینکه رفتار رابط کاربری تغییر کند.

در خروجی:
1. وضعیت فعلی را تحلیل کن.
2. معماری پیشنهادی را توضیح بده.
3. در صورت نیاز فایل‌ها را تفکیک کن.
4. کد نهایی هر فایل را بده.

یک صفحه Next.js بر اساس مشخصات زیر پیاده‌سازی کن:

نوع صفحه:
[Landing / Dashboard / Product / Profile / ...]

سبک طراحی:
[توضیح دقیق]

بخش‌ها:
1. [...]
2. [...]
3. [...]

رنگ‌ها:
[...]

رفتار Responsive:
- موبایل: [...]
- تبلت: [...]
- دسکتاپ: [...]

الزامات:
- React + TypeScript
- ساختار semantic
- عدم استفاده از inline style مگر ضرورت
- componentization متعادل
- states لازم مثل loading / empty / error
- رعایت accessibility
- عدم استفاده از کتابخانه جدید بدون اجازه من
- هیچ functionality خیالی اضافه نکن

ابتدا component tree را پیشنهاد بده و سپس کد را فایل‌به‌فایل ارائه کن.

این فایل React/Next.js بیش از حد بزرگ شده است:

[کد]

هدف ریفکتور:
- افزایش خوانایی
- کاهش duplication
- تفکیک مسئولیت‌ها در صورت نیاز
- حفظ کامل رفتار فعلی
- حفظ public API کامپوننت
- حفظ نام و قرارداد propهای موجود مگر با دلیل ضروری

قبل از تغییر:
1. code smellهای واقعی را فهرست کن.
2. بگو کدام بخش ارزش استخراج دارد و کدام بخش بهتر است همان‌جا بماند.
3. از over-engineering خودداری کن.

سپس نسخه refactor شده را ارائه کن.
در پایان تفاوت رفتاری نسخه قبل و بعد باید صفر باشد، مگر مواردی که صریحاً اعلام می‌کنی.

این کد TypeScript را از نظر type safety بررسی کن:

[کد]

مواردی که باید پیدا کنی:
- any غیرضروری
- type assertion خطرناک
- optional propertyهای مدیریت‌نشده
- null/undefined edge case
- typeهای تکراری
- union ناقص
- API response بدون validation
- genericهای اشتباه یا بیش از حد پیچیده

قانون:
فقط برای حذف warningها type را ضعیف‌تر نکن.

برای هر مشکل این موارد را بده:
Severity:
Reason:
Suggested type:
Corrected code:

در پایان نسخه نهایی type-safe را ارائه کن.

به‌عنوان Tech Lead این کد را Review کن:

[کد]

بررسی را در 6 بخش انجام بده:
1. Correctness
2. Security
3. Performance
4. Maintainability
5. React/Next.js best practices
6. Type safety

هر یافته را با سطح زیر مشخص کن:
- Critical
- High
- Medium
- Low
- Nit

برای هر مورد:
- مشکل چیست؟
- در چه شرایطی رخ می‌دهد؟
- چرا اهمیت دارد؟
- حداقل اصلاح مناسب چیست؟

موارد سلیقه‌ای را با bug واقعی مخلوط نکن.
در پایان فقط اصلاحات ضروری و باارزش را در قالب Patch پیشنهادی ارائه کن.

این صفحه/کامپوننت Next.js از نظر performance بررسی شود:

[کد]

به ترتیب اهمیت بررسی کن:
- JavaScript غیرضروری سمت Client
- re-renderهای قابل اجتناب
- data fetching waterfall
- درخواست‌های تکراری
- bundle سنگین
- dynamic importهای مناسب
- تصاویر و assetها
- caching strategy
- loading و streaming
- استفاده غیرضروری از useEffect
- محاسبات سنگین هنگام render

برای هر پیشنهاد، اثر احتمالی و trade-off را توضیح بده.

قانون:
از memo، useMemo و useCallback به صورت خودکار و بدون دلیل استفاده نکن.

در پایان 3 اصلاحی را که بیشترین ارزش واقعی دارند اولویت‌بندی کن.

برای این صفحه Next.js App Router بهترین Data Fetching architecture را پیشنهاد بده:

نوع داده:
[...]

منبع:
[Database / Internal API / Third-party API]

نیاز به تازگی داده:
[Real-time / چند دقیقه / روزانه / تقریباً ثابت]

آیا داده وابسته به کاربر است؟
[بله/خیر]

آیا secret وجود دارد؟
[بله/خیر]

رفتار مورد انتظار:
[...]

بررسی کن:
- Server Component
- Client Fetch
- Route Handler
- Server Action در صورت مرتبط بودن
- caching
- revalidation
- parallel fetching
- loading/streaming
- error handling

ابتدا معماری را انتخاب و دلیل آن را توضیح بده.
بعد نمونه implementation حداقلی ارائه کن.

این Route Handler مربوط به Next.js است:

[کد]

آن را از نظر موارد زیر بررسی کن:
- authentication
- authorization
- input validation
- method validation
- error handling
- status code
- اطلاعات حساس در response
- secret handling
- rate limiting در صورت ضرورت
- idempotency در عملیات حساس
- race condition
- logging بدون نشت اطلاعات حساس

هیچ آسیب‌پذیری فرضی را قطعی معرفی نکن.
برای هر یافته سناریوی واقعی رخ دادن آن را توضیح بده.

سپس نسخه اصلاح‌شده را با حداقل تغییر تولید کن.

تمام useEffectهای این کامپوننت را بررسی کن:

[کد]

برای هر useEffect مشخص کن:
- آیا واقعاً یک external synchronization انجام می‌دهد؟
- آیا می‌توان مقدار را مستقیماً هنگام render محاسبه کرد؟
- آیا بهتر است منطق داخل event handler باشد؟
- آیا dependency array کامل است؟
- آیا امکان loop یا stale closure وجود دارد؟
- آیا cleanup لازم است؟
- آیا Effect باعث state duplication شده؟

هیچ useEffect را فقط برای کوتاه‌تر شدن کد حذف نکن.

خروجی را به شکل:
Effect #:
وضعیت:
مشکل:
راه‌حل:
کد پیشنهادی:
ارائه کن.

برای کد زیر تست طراحی کن:

[کد]

Test stack موجود:
[Vitest / Jest / Playwright / React Testing Library / ...]

ابتدا behaviorهای قابل مشاهده را استخراج کن.

تست‌ها را اولویت‌بندی کن:
1. Critical path
2. Edge cases
3. Error cases
4. Regression cases

قوانین:
- implementation detail را تست نکن مگر لازم باشد.
- تست‌های تکراری نساز.
- فقط برای بالا بردن coverage تست بی‌ارزش اضافه نکن.
- mock را حداقل نگه دار.

سپس کد تست‌ها را مطابق stack فعلی پروژه ارائه کن.

این log را تحلیل کن:

[Log]

بدون حدس زدن، موارد زیر را جدا کن:
1. اطلاعات قطعی که از log می‌دانیم
2. فرضیه‌های محتمل
3. فرضیه‌های ضعیف
4. اطلاعاتی که برای تشخیص قطعی کم داریم

سپس یک مسیر عیب‌یابی مرحله‌ای طراحی کن که با کم‌هزینه‌ترین بررسی شروع شود.

برای هر مرحله بگو:
- چه چیزی بررسی شود؟
- چه نتیجه‌ای فرضیه را تایید می‌کند؟
- چه نتیجه‌ای آن را رد می‌کند؟

تا زمانی که علت مشخص نشده، بازنویسی گسترده کد پیشنهاد نده.

برای این تغییر فقط Minimal Patch ارائه کن.

فایل فعلی:
[کد]

تغییر موردنظر:
[...]

قوانین:
- هیچ خط غیرمرتبطی را تغییر نده.
- formatting کل فایل را عوض نکن.
- نام متغیرهای غیرمرتبط را تغییر نده.
- dependency جدید اضافه نکن.
- API و رفتار قبلی را حفظ کن.

خروجی:
1. توضیح دو یا سه خطی علت تغییر
2. Diff یا بخش دقیق قبل/بعد
3. موارد تست

اگر درخواست من بدون تغییر وسیع قابل انجام نیست، قبل از ارائه Patch دلیل آن را توضیح بده.

این بخش از پروژه Next.js را از نظر امنیت بررسی کن:

[کد]

تمرکز روی:
- authorization سمت سرور
- افشای secret در Client
- ورودی بدون validation
- XSS
- unsafe HTML
- CSRF در صورت مرتبط بودن
- IDOR
- اطلاعات حساس در log یا response
- اعتماد اشتباه به داده Client
- redirect یا URL کنترل‌شده توسط کاربر
- دسترسی مستقیم به resource بر اساس ID

برای هر مورد:
Risk:
Exploit scenario:
Affected code:
Recommended fix:

فقط مواردی را Critical یا High اعلام کن که واقعاً سناریوی سوءاستفاده عملی دارند.
در پایان نسخه اصلاح‌شده حداقلی را ارائه کن.