clinicpro/docs/scenarios/climed.md

حتماً، متن کامل پرامپت را در محیط قابل کپی می‌گذارم:

یک قابلیت کامل برای Claim Doctor Profile یا «احراز مالکیت پروفایل پزشک» در سیستم Clinic Pro و سایت نوبت 724 پیاده‌سازی کن.

قبل از هرگونه تغییر، ابتدا ساختار فعلی Backend و Frontend را کامل بررسی کن و مشخص کن وضعیت پزشکان ایمپورت‌شده در حال حاضر چگونه مدیریت می‌شود.

در سیستم، پزشک ایمپورت‌شده می‌تواند یکی از وضعیت‌های زیر را داشته باشد:

- unclaimed
- pending_transform
- claimed

نام دقیق enum، field و statusهای موجود در پروژه را بررسی کن و بدون ایجاد ساختار تکراری، از معماری فعلی استفاده کن.

سناریوی اصلی

زمانی که یک پزشک از دیتای سازمان نظام پزشکی Import می‌شود و هنوز به کاربر یا پزشک واقعی در Clinic Pro متصل نشده است، وضعیت آن باید unclaimed باشد.

تا زمانی که پروفایل پزشک Claim نشده است:

- نوبت‌دهی آنلاین پزشک باید غیرفعال باشد.
- در سایت اصلی نوبت 724 و تمام سایت‌های زیرمجموعه و دامنه‌های نمایندگان، وضعیت پروفایل باید مشخص باشد.
- کاربر باید متوجه شود که این پروفایل هنوز توسط پزشک تأیید و مدیریت نشده است.

در صفحه پروفایل پزشک، دقیقاً زیر بخش «نوبت‌دهی»، یک بخش برای احراز مالکیت پروفایل نمایش داده شود.

متن مناسب فارسی مانند زیر نمایش داده شود:

«آیا شما این پزشک هستید؟»

و یک دکمه با عنوان:

«تأیید و مدیریت این پروفایل»

این بخش فقط برای پزشکانی نمایش داده شود که وضعیت آن‌ها unclaimed است.

Modal احراز مالکیت پروفایل

با کلیک روی دکمه، یک Modal باز شود.

فرم باید با UI فعلی پروژه، RTL، فارسی و کاملاً Responsive طراحی شود.

اطلاعات موردنیاز فرم:

- شماره موبایل
- کد ملی
- تاریخ تولد به شمسی
- نام
- نام خانوادگی

ارتباط با API.ir

تمام فرآیند احراز هویت باید از Backend انجام شود.

هیچ Request مستقیمی از Frontend به API.ir ارسال نشود.

Token مربوط به API.ir باید در Environment Variable نگهداری شود و هرگز به Frontend ارسال نشود.

از API زیر برای دریافت اطلاعات هویتی شخص استفاده کن:

curl https://s.api.ir/api/sw1/PersonInfo
–request POST
–header ‘Content-Type: application/json’
–header ‘Authorization: Bearer [API_TOKEN]’
–data ‘{
“nationalCode”: “0010007700”,
“birthDate”: “1371/1/1”
}’

نمونه Response:

{
“data”: {
“nationalCode”: “0010007700”,
“firstName”: “محسن”,
“lastName”: “اکبری”,
“fatherName”: “علی”,
“gender”: 1,
“alive”: true
},
“success”: false,
“code”: 0,
“message”: null
}

طبق نمونه API، ورودی PersonInfo شامل nationalCode و birthDate است.

ابتدا بررسی کن که آیا API.ir Endpoint دیگری برای تطبیق شماره موبایل و کد ملی دارد یا خیر.

اگر چنین Endpointی در ساختار فعلی پروژه یا مستندات موجود تعریف شده است، از آن برای تأیید مالکیت شماره موبایل استفاده کن.

در غیر این صورت، شماره موبایل باید با OTP تأیید شود.

OTP به‌تنهایی به معنی مالکیت پروفایل پزشک نیست.

Claim فقط زمانی موفق باشد که هویت شخص با اطلاعات پزشک Import‌شده تطبیق داده شده باشد.

فرآیند احراز هویت

کاربر فرم را تکمیل و ارسال می‌کند.

Backend باید اطلاعات را دریافت و Validation کند.

سپس با استفاده از nationalCode و birthDate به API.ir درخواست PersonInfo ارسال شود.

اطلاعات برگشتی شامل موارد زیر بررسی شود:

- nationalCode
- firstName
- lastName
- alive

اگر alive برابر false بود، فرآیند Claim متوقف شود.

نام و نام خانوادگی برگشتی از API.ir باید با اطلاعات پزشک Import‌شده از سازمان نظام پزشکی مقایسه شود.

همچنین نام و نام خانوادگی واردشده توسط کاربر باید با اطلاعات تأییدشده مقایسه شود.

قبل از Compare نام‌های فارسی، عملیات Normalize انجام شود.

موارد زیر مدیریت شوند:

- تفاوت ي و ی
- تفاوت ك و ک
- فاصله‌های اضافه
- نیم‌فاصله
- فاصله ابتدا و انتهای متن
- Unicode normalization

از Compare ساده و مستقیم String استفاده نکن.

در صورت امکان، یک Service مشترک برای Persian Name Normalization ایجاد یا از Service موجود استفاده کن.

تأیید شماره موبایل

شماره موبایل کاربر باید تأیید شود.

اگر API.ir امکان تطبیق شماره موبایل با کد ملی را دارد، از همان API استفاده کن.

در غیر این صورت، از OTP موجود در سیستم استفاده کن.

اگر سیستم در حال حاضر OTP Service دارد، Service جدید و تکراری ایجاد نکن.

از زیرساخت فعلی Authentication و OTP استفاده کن.

پس از تأیید OTP، شماره موبایل Verified در نظر گرفته شود.

اما Claim نهایی فقط بعد از موفقیت احراز هویت PersonInfo انجام شود.

اتصال پروفایل پزشک به کاربر

اگر احراز هویت موفق بود:

- User مربوط به پزشک را بر اساس معماری فعلی سیستم پیدا کن.
- اگر Flow فعلی سیستم اجازه ایجاد User را می‌دهد، User مناسب ایجاد شود.
- پروفایل Doctor ایمپورت‌شده به User مربوطه متصل شود.
- وضعیت Doctor از unclaimed به claimed تغییر کند.
- زمان Claim ذخیره شود.
- روش احراز هویت ذخیره شود.
- در صورت وجود Audit Log، عملیات Claim ثبت شود.
- از Claim مجدد Doctor جلوگیری شود.

تمام عملیات نهایی Claim باید داخل Transaction انجام شود.

اگر سیستم فعلی از وضعیت pending_transform در این Flow استفاده می‌کند، ابتدا منطق آن را بررسی کن.

مشخص کن pending_transform دقیقاً در چه شرایطی استفاده می‌شود و Flow جدید را با همان معماری هماهنگ کن.

Status جدید و تکراری ایجاد نکن مگر اینکه واقعاً ضروری باشد.

جلوگیری از Race Condition

ممکن است دو Request هم‌زمان برای Claim یک Doctor ارسال شوند.

Backend باید از Race Condition جلوگیری کند.

قبل از نهایی کردن Claim، وضعیت Doctor مجدداً بررسی شود.

در صورت نیاز از Transaction، Database Lock یا مکانیزم مناسب معماری فعلی استفاده کن.

یک Doctor تحت هیچ شرایطی نباید به دو User مختلف متصل شود.

پیام موفقیت

بعد از Claim موفق، پیام خوش‌آمدگویی نمایش داده شود:

«دکتر [نام پزشک]، به نوبت 724 خوش آمدید 🎉

پروفایل شما با موفقیت تأیید شد و اکنون می‌توانید اطلاعات پروفایل و تنظیمات نوبت‌دهی خود را مدیریت کنید.»

سپس کاربر بر اساس Flow فعلی Authentication سیستم به پنل مناسب هدایت شود.

مدیریت خطاها

برای حالت‌های زیر Error Handling مناسب ایجاد کن:

- اطلاعات هویتی اشتباه است.
- تاریخ تولد اشتباه است.
- نام شخص با پزشک تطبیق ندارد.
- کد ملی نامعتبر است.
- شماره موبایل تأیید نشده است.
- OTP نامعتبر یا منقضی شده است.
- API.ir در دسترس نیست.
- API.ir Timeout شده است.
- Response API نامعتبر است.
- Doctor قبلاً Claim شده است.
- Doctor در وضعیت قابل Claim نیست.
- User دیگری هم‌زمان Doctor را Claim کرده است.
- Rate Limit رد شده است.

پیام‌های Frontend باید فارسی، واضح و قابل فهم باشند.

اطلاعات حساس API یا جزئیات Internal Error در Frontend نمایش داده نشود.

امنیت

Endpoint مربوط به Claim باید Rate Limit داشته باشد.

برای جلوگیری از Brute Force، محدودیت تعداد تلاش بر اساس موارد مناسب مانند موارد زیر اعمال شود:

- IP
- Doctor ID
- National Code Hash
- User ID
- Mobile Number Hash

کد ملی و تاریخ تولد را در Logهای معمولی به‌صورت Plain Text ثبت نکن.

شماره موبایل کامل را در Log ثبت نکن.

API Token را Log نکن.

Request و Response کامل API.ir را در Production Log ذخیره نکن.

در صورت نیاز برای Audit، فقط اطلاعات ضروری و Mask شده ذخیره شود.

در صورت وجود CAPTCHA یا ALTCHA در پروژه، بررسی کن که Claim Endpoint باید تحت محافظت ALTCHA قرار بگیرد.

از زیرساخت فعلی ALTCHA استفاده کن و سیستم CAPTCHA جدید ایجاد نکن.

Frontend

این قابلیت باید در موارد زیر کار کند:

- سایت اصلی نوبت 724
- تمام دامنه‌های زیرمجموعه
- سایت‌های نمایندگان

از Component مشترک استفاده کن.

منطق Claim را برای هر Domain جداگانه Duplicate نکن.

Tenant و Domain Logic فعلی پروژه را بررسی کن و از همان ساختار استفاده کن.

UI باید با Design System فعلی پروژه هماهنگ باشد.

Modal باید:

- RTL باشد.
- فارسی باشد.
- Responsive باشد.
- روی موبایل UX مناسبی داشته باشد.
- Loading State داشته باشد.
- Error State داشته باشد.
- Success State داشته باشد.
- از Double Submit جلوگیری کند.

برای تاریخ تولد از Date Picker شمسی موجود در پروژه استفاده کن.

Library جدید برای تاریخ شمسی نصب نکن، مگر اینکه پروژه هیچ راهکار فعلی برای تاریخ شمسی نداشته باشد.

تست

تست‌های Backend و Frontend لازم را اضافه کن.

حداقل سناریوهای زیر تست شوند:

- Claim موفق
- کد ملی اشتباه
- تاریخ تولد اشتباه
- عدم تطبیق نام پزشک
- Doctor قبلاً Claim شده
- Doctor با Status غیرمجاز
- API.ir Timeout
- API.ir Error
- Response نامعتبر API
- تلاش هم‌زمان برای Claim یک Doctor
- Normalize صحیح نام فارسی
- OTP نامعتبر
- OTP منقضی‌شده
- Rate Limit
- نمایش Claim Form فقط برای unclaimed
- عدم نمایش Claim Form برای claimed
- عدم امکان Claim یک Doctor توسط دو User

API.ir را در تست‌ها Mock کن.

تست‌ها تحت هیچ شرایطی نباید به سرویس واقعی API.ir Request ارسال کنند.

خروجی مورد انتظار

قابلیت Claim Doctor Profile را به‌صورت End-to-End پیاده‌سازی کن.

ابتدا معماری موجود پروژه را کامل بررسی کن.

سپس موارد زیر را پیاده‌سازی کن:

- Backend Claim Flow
- API.ir Integration
- Identity Verification
- Mobile Verification
- OTP Integration
- Security
- Rate Limiting
- Doctor/User Relation
- Transaction Handling
- Race Condition Protection
- Frontend Claim Section
- Claim Modal
- Success Flow
- Error Handling
- Tests

از ایجاد کد تکراری یا معماری موازی خودداری کن.

در پایان گزارشی ارائه بده که شامل موارد زیر باشد:

- فایل‌های تغییرکرده
- Flow نهایی Claim
- نحوه ارتباط با API.ir
- نحوه تطبیق هویت
- نحوه تأیید شماره موبایل
- نحوه اتصال Doctor به User
- کاربرد دقیق pending_transform در Flow
- تغییرات Database
- Environment Variableهای جدید
- تست‌های اضافه‌شده
- نکات امنیتی پیاده‌سازی‌شده

مهم:

بدون بررسی کد فعلی پروژه، درباره Entityها، Tableها، Fieldها، Routeها، Authentication Flow، OTP Service یا معماری سیستم فرض نساز.

ابتدا ساختار موجود را بررسی کن و قابلیت را کاملاً با معماری فعلی پروژه هماهنگ کن.

اگر خواستی، نسخه مخصوص Claude Code / Cursor Agent همین پرامپت را هم با دستورهای اجرایی دقیق‌تر برات تنظیم می‌کنم.