` خام.
+- رشته‌ها فارسی، تاریخ‌ها شمسی، RTL.
+- هر تسک جدا تست و کامیت شود. بعد از تغییر کد، `graphify update .` اجرا شود (بعد از کامیت).
diff --git a/.claude/prompt/auto-create-record-and-session-on-confirm.md b/.claude/prompt/auto-create-record-and-session-on-confirm.md
new file mode 100644
index 00000000..a24490c9
--- /dev/null
+++ b/.claude/prompt/auto-create-record-and-session-on-confirm.md
@@ -0,0 +1,385 @@
+# ایجاد خودکار پرونده و سرویس در همهٔ مسیرهای قطعی‌شدن نوبت
+
+## زمینه
+
+منطق «قطعی شدن نوبت → ساخت پرونده و سرویس» **از قبل نوشته شده** است:
+`PatientService::autoCreateOnAppointmentConfirm()`. مشکل این نیست که وجود ندارد — این است که
+فقط به **دو** مسیر از پنج مسیرِ قطعی‌شدن وصل است، و در همان دو مسیر هم به‌جای یک پرونده، دو
+پرونده (پزشک + کلینیک) می‌سازد.
+
+شواهد از دیتابیس محیط توسعه:
+
+```sql
+-- ۱۶ نوبت قطعی، ولی فقط ۱۲ مراجعه
+SELECT COUNT(*) FROM appointments WHERE status='confirmed'; -- 16
+SELECT COUNT(*) FROM appointments a JOIN patient_sessions ps ON ps.appointment_id=a.id
+ WHERE a.status='confirmed'; -- 12
+
+-- نوبت 130043 دو مراجعهٔ تکراری دارد (یکی برای پزشک، یکی برای کلینیک):
+-- id status address_id session_id entity_type entity_id
+-- 130043 confirmed 2631 30 doctor 3343
+-- 130043 confirmed 2631 31 clinic 1003
+-- و اینها هیچ مراجعه‌ای ندارند:
+-- 130044, 130028, 130025, 130011, 130010 → session_id = NULL
+```
+
+## مشکل / هدف
+
+هدف: هر نوبتی که قطعی می‌شود — **از هر مسیری** — دقیقاً **یک** پرونده و **یک** سرویس در
+**همان محیطی** بسازد که نوبت در آن رزرو شده (کلینیک، یا مطب شخصی پزشک مستقل).
+
+پنج ایراد مشخص که باید رفع شوند:
+
+### ۱. مسیر پرداخت آنلاین (Nobat724) اصلاً صدا نمی‌زند — ریشهٔ اصلی
+
+نوبتِ سایت عمومی `pending` ساخته می‌شود و بعد از پرداخت در `PaymentManager` قطعی می‌شود؛
+آنجا هیچ فراخوانی‌ای وجود ندارد. یعنی **هیچ نوبتی که از Nobat724 و سایت‌های زیرمجموعه
+رزرو و پرداخت شود، پرونده نمی‌سازد.**
+
+### ۲. دو پرونده به‌جای یک پرونده
+
+`autoCreateOnAppointmentConfirm` برای پزشکِ عضو کلینیک، هم پروندهٔ `doctor` می‌سازد و هم
+`clinic` — دو مراجعهٔ جدا برای یک نوبت واحد (ردیف 130043 بالا). این یعنی درآمد یک نوبت در
+دو جا شمرده می‌شود.
+
+**قاعدهٔ درست:** نوبتی که در کلینیک رزرو شده → فقط پروندهٔ همان کلینیک. نوبتی که در مطب
+شخصی رزرو شده → فقط پروندهٔ پزشک.
+
+### ۳. تشخیص کلینیک حدسی است
+
+کلینیک از `address_id` استنتاج می‌شود و اگر آدرس نبود، «اگر پزشک فقط عضو یک کلینیک باشد»
+همان فرض می‌شود. با مدل per-context فعلی (هر پزشک یک برنامه برای مطب شخصی + یکی به ازای هر
+کلینیک) این حدس غلط است و نوبت را بی‌سروصدا به پروندهٔ محیط اشتباه می‌چسباند. نوبت `130032`
+با `address_id = NULL` دقیقاً روی همین شاخهٔ حدسی افتاده است.
+
+### ۴. idempotent نیست
+
+هیچ گاردی نیست که مراجعهٔ تکراری برای یک نوبت ساخته نشود. مسیر
+`confirmed → cancelled → confirmed` یا دوبار PATCH، مراجعهٔ دوم می‌سازد.
+
+### ۵. نوبت‌های پنل و ادمین اصلاً قطعی نمی‌شوند
+
+`MyAppointmentsController` و `AdminApiController` نوبت را با وضعیت پیش‌فرض `pending`
+می‌سازند و هیچ‌جا قطعی نمی‌کنند (`markPendingWithTtl` هم صدا نمی‌شود، پس نه منقضی می‌شود نه
+قطعی). نوبت `130046` که همین امروز از پنل ساخته شده هنوز `pending` است. طبق نیاز، نوبتِ
+ثبت‌شده توسط خودِ کلینیک/پزشک باید مستقیم `confirmed` باشد — پرداخت آنلاین ندارد.
+
+## فایل‌های مرتبط
+
+| فایل | نقش |
+|------|-----|
+| `src/Patient/Service/PatientService.php:125-192` | `autoCreateOnAppointmentConfirm` + `autoCreateForEntity` |
+| `src/Payment/Service/PaymentManager.php:305-330` | `handleAppointmentConfirmation` — مسیر پرداخت آنلاین |
+| `src/Appointment/Controller/AppointmentController.php:871-881` | PATCH status — تنها مسیر سالم فعلی |
+| `src/Appointment/Controller/AppointmentController.php:975-988` | PATCH نوبت (ویرایش کامل) |
+| `src/Appointment/Controller/AppointmentController.php:495-537` | رزرو عمومی — `markPendingWithTtl` سپس `bookAtomically` |
+| `src/Appointment/Controller/MyAppointmentsController.php:142-198` | رزرو از پنل — بدون قطعی‌کردن |
+| `src/Admin/Controller/AdminApiController.php:925-947` | رزرو از ادمین — بدون قطعی‌کردن |
+| `src/Appointment/Entity/Appointment.php:37-42,101,178-189` | ماشین وضعیت، `status` پیش‌فرض `pending`، سازنده |
+| `src/Appointment/Service/BookingContextResolver.php` | تشخیص صریح کلینیکِ نوبت از `clinic_uuid` |
+| `src/Patient/Entity/PatientRecord.php:15` | unique روی `(entity_type, entity_id, user_id)` |
+| `src/Patient/Entity/PatientSession.php:29-37` | لینک اختیاری به `Appointment` |
+| `src/Patient/Repository/PatientSessionRepository.php` | متد lookup بر اساس نوبت **ندارد** |
+| `docs/api/patient.md:611-624` | بخش «Auto-Creation on Appointment Confirm» |
+
+## وضعیت فعلی
+
+### دو پرونده + کلینیکِ حدسی
+
+`src/Patient/Service/PatientService.php:125-147`:
+
+```php
+ public function autoCreateOnAppointmentConfirm(Appointment $appointment): void
+ {
+ $doctor = $appointment->getDoctor();
+
+ // پرونده‌ی پزشک
+ $this->autoCreateForEntity('doctor', $doctor->getId(), $appointment, $doctor->getId());
+
+ // کلینیک نوبت را تعیین کن: اول از آدرس انتخاب‌شده، وگرنه اگر دکتر فقط عضو یک کلینیک باشد.
+ $clinicId = null;
+ $addressId = $appointment->getAddressId();
+ if ($addressId !== null) {
+ $clinicId = $this->addressRepo->find($addressId)?->getClinicId();
+ }
+ if ($clinicId === null) {
+ $clinics = $this->clinicRepo->findByDoctor($doctor);
+ if (count($clinics) === 1) {
+ $clinicId = $clinics[0]->getId();
+ }
+ }
+
+ if ($clinicId !== null) {
+ $this->autoCreateForEntity('clinic', $clinicId, $appointment, $clinicId);
+ }
+ }
+```
+
+### ساخت مراجعه — بدون گارد تکرار
+
+`src/Patient/Service/PatientService.php:149-192` (بخش مرتبط):
+
+```php
+ private function autoCreateForEntity(string $entityType, int $entityId, Appointment $appointment, int $createdById): void
+ {
+ if (!$this->subscriptionService->hasFeature($entityType, $entityId, 'patient_records')) {
+ return;
+ }
+
+ $patient = $appointment->getUser();
+
+ $record = $this->recordRepo->findByEntityAndUser($entityType, $entityId, $patient);
+ if ($record === null) {
+ $record = new PatientRecord($entityType, $entityId, $patient, 'system', $createdById);
+ $this->recordRepo->save($record);
+ }
+
+ $session = new PatientSession($record, $appointment); // ← هیچ چکی که قبلاً ساخته نشده باشد
+ $session->setSessionAt($appointment->getSlotStart());
+ ...
+```
+
+### مسیر پرداخت — بدون فراخوانی
+
+`src/Payment/Service/PaymentManager.php:305-314`:
+
+```php
+ private function handleAppointmentConfirmation(Payment $payment): void
+ {
+ $appointment = $payment->getAppointment();
+ if ($appointment === null || !$appointment->canTransitionTo(Appointment::STATUS_CONFIRMED)) {
+ return;
+ }
+
+ $appointment->transitionTo(Appointment::STATUS_CONFIRMED);
+ $this->em->persist($appointment);
+ // ← اینجا هیچ ساختِ پرونده‌ای نیست
+```
+
+### رزرو پنل — وضعیت pending می‌ماند
+
+`src/Appointment/Controller/MyAppointmentsController.php:190-197`:
+
+```php
+ } else {
+ try {
+ $this->appointmentRepo->bookAtomically($appointment);
+ } catch (SlotTakenException) {
+ return $this->error(ErrorCodes::SLOT_TAKEN, 'این نوبت قبلاً رزرو شده است', 409);
+ }
+ }
+```
+
+`Appointment::$status` پیش‌فرض `STATUS_PENDING` است (`Appointment.php:101`) و هیچ‌جای این
+مسیر عوضش نمی‌کند.
+
+## وظایف
+
+### ۱. context نوبت را صریح کن — ستون `clinic_id` روی `appointments`
+
+حدس‌زدن محل، ریشهٔ ایراد ۳ است. نوبت باید بداند در کدام محیط رزرو شده، همان‌طور که
+`weekly_schedules` می‌داند.
+
+`src/Appointment/Entity/Appointment.php`:
+
+```php
+ /**
+ * محیط رزرو: null یعنی مطب شخصی پزشک، مقدار یعنی همان کلینیک. مبنای واحدِ
+ * تشخیص پرونده — از روی آدرس حدس زده نمی‌شود.
+ */
+ #[ORM\ManyToOne(targetEntity: \App\Clinic\Entity\Clinic::class)]
+ #[ORM\JoinColumn(name: 'clinic_id', nullable: true, onDelete: 'SET NULL')]
+ private ?\App\Clinic\Entity\Clinic $clinic = null;
+```
+
+هر سه مسیر رزرو از قبل `$bookingClinic` را با `BookingContextResolver` حل می‌کنند و فقط برای
+`resolveSlotLocationId` استفاده می‌کنند — همان را روی نوبت هم بنشان:
+
+- `AppointmentController.php:~510` (رزرو عمومی) — متغیر `$bookingClinic` موجود است
+- `MyAppointmentsController.php:~150` — `$bookingClinic` موجود است
+- `AdminApiController.php:~937` — `$bookingClinic` موجود است
+
+Migration بنویس. برای ردیف‌های موجود `clinic_id` را از `address_id` پر کن (همان استنتاجی که
+امروز runtime انجام می‌دهد)، ولی **فقط وقتی آدرس واقعاً کلینیکی است**؛ شاخهٔ حدسیِ «تنها
+کلینیک پزشک» را در migration تکرار نکن — ردیف بدون آدرس، مطب شخصی در نظر گرفته شود و در
+توضیح migration ذکر شود.
+
+### ۲. یک choke point برای قطعی‌شدن
+
+به‌جای پخش‌کردن فراخوانی در پنج جا، یک سرویس بساز که همه صدایش بزنند —
+`src/Appointment/Service/AppointmentConfirmationService.php`:
+
+```php
+final class AppointmentConfirmationService
+{
+ /**
+ * عوارض جانبیِ قطعی‌شدن نوبت. هر مسیری که نوبت را confirmed می‌کند باید این را
+ * صدا بزند — پرداخت آنلاین، PATCH وضعیت، و رزروِ مستقیمِ پنل/ادمین.
+ * idempotent است: فراخوانی دوباره برای همان نوبت هیچ چیزی نمی‌سازد.
+ */
+ public function onConfirmed(Appointment $appointment): void
+ {
+ $this->patientService->autoCreateOnAppointmentConfirm($appointment);
+ }
+}
+```
+
+سپس در این پنج نقطه صدا زده شود:
+
+| فایل | نقطه |
+|---|---|
+| `PaymentManager.php:312` | بعد از `transitionTo(STATUS_CONFIRMED)` — **مهم‌ترین** |
+| `AppointmentController.php:879` | جایگزین فراخوانی مستقیم فعلی |
+| `AppointmentController.php:982` | جایگزین فراخوانی مستقیم فعلی |
+| `MyAppointmentsController.php:~193` | بعد از `bookAtomically` (وظیفهٔ ۵) |
+| `AdminApiController.php:~939` | بعد از `bookAtomically` (وظیفهٔ ۵) |
+
+**دربارهٔ `PaymentManager`:** آنجا داخل تراکنش پرداخت هستی. ساخت پرونده نباید تأیید پرداخت
+را خراب کند — اگر شکست خورد، لاگ کن و پرداخت را نگه دار (همان الگویی که
+`docs/api/patient.md:446` برای مطالبهٔ بیمه توضیح داده: «خطا در این مرحله ثبت session را
+خراب نمی‌کند»). ولی **بی‌صدا رد نشو** — لاگ سطح `error` با uuid نوبت.
+
+### ۳. یک پرونده در context درست
+
+`autoCreateOnAppointmentConfirm` بازنویسی شود:
+
+```php
+ public function autoCreateOnAppointmentConfirm(Appointment $appointment): void
+ {
+ $clinic = $appointment->getClinic();
+
+ // محیط رزرو تعیین‌کننده است: کلینیک، یا مطب شخصی پزشک. هرگز هر دو —
+ // دو پرونده برای یک نوبت یعنی درآمد یک ویزیت دو بار شمرده می‌شود.
+ [$entityType, $entityId] = $clinic !== null
+ ? ['clinic', $clinic->getId()]
+ : ['doctor', $appointment->getDoctor()->getId()];
+
+ $this->autoCreateForEntity($entityType, $entityId, $appointment, $entityId);
+ }
+```
+
+سازگاری با ردیف‌های قدیمیِ بدون `clinic_id`: بعد از migration وظیفهٔ ۱ همه پر شده‌اند، پس
+شاخهٔ fallback لازم نیست. اگر لازم دیدی نگهداری، از `address_id → clinic_id` استفاده کن و
+**شاخهٔ «تنها کلینیک پزشک» را حذف کن** — همان حدسی است که باگ می‌سازد.
+
+### ۴. idempotency
+
+متد lookup به `PatientSessionRepository` اضافه کن:
+
+```php
+ /** مراجعهٔ ساخته‌شده برای این نوبت در همین محیط، یا null. */
+ public function findByAppointmentAndEntity(Appointment $appointment, string $entityType, int $entityId): ?PatientSession
+ {
+ return $this->createQueryBuilder('s')
+ ->join('s.record', 'r')
+ ->where('s.appointment = :appointment')
+ ->andWhere('r.entityType = :entityType')
+ ->andWhere('r.entityId = :entityId')
+ ->setParameter('appointment', $appointment)
+ ->setParameter('entityType', $entityType)
+ ->setParameter('entityId', $entityId)
+ ->setMaxResults(1)
+ ->getQuery()
+ ->getOneOrNullResult();
+ }
+```
+
+و در ابتدای `autoCreateForEntity` بعد از گارد feature:
+
+```php
+ if ($this->sessionRepo->findByAppointmentAndEntity($appointment, $entityType, $entityId) !== null) {
+ return; // قبلاً ساخته شده — قطعی‌شدن دوباره نباید مراجعهٔ تکراری بسازد
+ }
+```
+
+**نکتهٔ مرزی:** مراجعهٔ آرشیوشده (`PatientSession::$archived`) هم باید «ساخته‌شده» حساب شود؛
+وگرنه آرشیو کردنِ یک مراجعهٔ اشتباه باعث ساخت دوبارهٔ آن می‌شود. اگر تصمیم دیگری گرفتی در PR
+بنویس.
+
+### ۵. رزرو پنل و ادمین مستقیم `confirmed` شود
+
+نوبتی که خودِ کلینیک یا پزشک از پنل ثبت می‌کند پرداخت آنلاین ندارد و منتظر چیزی نیست؛
+`pending` ماندنش یعنی نه در تقویم درست شمرده می‌شود، نه پرونده می‌سازد.
+
+در `MyAppointmentsController` و `AdminApiController`، قبل از `bookAtomically`:
+
+```php
+ $appointment->transitionTo(Appointment::STATUS_CONFIRMED);
+```
+
+سپس بعد از موفقیت `bookAtomically`، `confirmationService->onConfirmed($appointment)`.
+
+**دقت:** `bookAtomically` روی `SLOT_OCCUPYING_STATUSES` و `active_slot_key` حساب می‌کند و
+`confirmed` جزو آن‌هاست (`Appointment.php:52-55`)، پس قفل اتمیک اسلات دست‌نخورده کار می‌کند.
+`transitionTo` را **قبل** از `bookAtomically` بگذار تا `refreshActiveSlotKey()` با وضعیت
+نهایی محاسبه شود.
+
+**استثنا:** مسیر `isReserve` (نوبت رزروِ روز-محور، `MyAppointmentsController:188-190`) اسلات
+اشغال نمی‌کند و مراجعهٔ زمان‌دار برایش معنا ندارد — رفتار فعلی‌اش را عوض نکن و در
+`onConfirmed` هم اگر `isReserve()` بود زود برگرد.
+
+### ۶. گارد اشتراک — تصمیم صریح
+
+`autoCreateForEntity` وقتی ویژگی `patient_records` فعال نباشد بی‌صدا برمی‌گردد. این درست
+است (نباید به زور پرونده بسازد) ولی الان **غیرقابل‌تشخیص** است: نه لاگی، نه نشانه‌ای.
+
+- یک لاگ سطح `info` با `entity_type`/`entity_id`/`appointment_uuid` بگذار.
+- در `docs/api/patient.md` صریح بنویس که بدون این ویژگی، نوبت قطعی پرونده نمی‌سازد.
+
+### ۷. Backfill نوبت‌های قطعیِ بی‌پرونده
+
+پنج نوبت قطعیِ فعلی مراجعه ندارند. یک console command بنویس —
+`app:appointment:backfill-sessions`:
+
+- نوبت‌های `confirmed`/`completed` که مراجعهٔ متناظر ندارند را فهرست کند (uuid پزشک، تاریخ،
+ context، دلیلِ نبودن).
+- با `--fix` همان `onConfirmed` را برایشان اجرا کند.
+- خروجی تعداد ساخته‌شده و تعداد رد شده (به‌خاطر گارد اشتراک) را جدا گزارش کند.
+
+نوبت‌های `completed` را هم پوشش بده: مراجعه‌ای که هرگز ساخته نشده با گذشتِ زمان از بین
+نمی‌رود، فقط دیرتر لازم می‌شود.
+
+### ۸. تست و مستندات
+
+تست‌ها در `tests/Patient/` و `tests/Appointment/`:
+
+1. نوبت رزروشده در کلینیک، قطعی می‌شود → **یک** پرونده با `entity_type='clinic'`، هیچ
+ پروندهٔ `doctor`ی ساخته نمی‌شود.
+2. نوبت مطب شخصی → **یک** پروندهٔ `doctor`.
+3. بیماری که از قبل پرونده دارد → پروندهٔ جدید ساخته نمی‌شود، فقط مراجعهٔ جدید به همان
+ پرونده اضافه می‌شود.
+4. قطعی‌شدن دوباره (confirmed → cancelled → confirmed) → مراجعهٔ دوم ساخته نمی‌شود.
+5. مسیر پرداخت: `PaymentManager` نوبت را قطعی می‌کند → پرونده و مراجعه ساخته می‌شوند
+ (بازتولید مستقیم باگ اصلی).
+6. رزرو از پنل → نوبت `confirmed` است و مراجعه دارد.
+7. نوبت `isReserve` → مراجعه ساخته نمی‌شود.
+8. tenant بدون ویژگی `patient_records` → چیزی ساخته نمی‌شود و خطا هم نمی‌دهد.
+
+مستندات: `docs/api/patient.md` بخش «Auto-Creation on Appointment Confirm» بازنویسی شود —
+الان صراحتاً رفتار دوپرونده‌ای را به‌عنوان رفتار درست مستند کرده (`:613-617`) که با این تغییر
+باطل می‌شود. فهرست همهٔ مسیرهای قطعی‌شدن، قاعدهٔ تک‌پرونده، و idempotency را بنویس.
+`docs/api/appointment.md` هم برای `clinic_id` نوبت و وضعیت اولیهٔ `confirmed` در رزرو
+پنل/ادمین به‌روز شود.
+
+## نکات مهم
+
+- **این تغییر رفتار مالی دارد.** حذف پروندهٔ دوم یعنی نوبت‌هایی که تا امروز در داشبورد پزشک
+ *و* کلینیک شمرده می‌شدند، از این به بعد فقط در یکی شمرده می‌شوند. دادهٔ تاریخیِ تکراری
+ (مثل دو مراجعهٔ نوبت 130043) را **حذف نکن** — تصمیم پاکسازی جدا از این تسک است؛ فقط در
+ `docs/` به‌عنوان کار بعدی ثبت کن.
+- ترتیب پیشنهادی: (۱) ستون `clinic_id` + migration → (۲) choke point → (۳) تک‌پرونده →
+ (۴) idempotency → (۵) پنل/ادمین → (۷) backfill → (۸) تست و docs. هر مرحله جدا تست شود.
+- `PatientRecord` روی `(entity_type, entity_id, user_id)` unique است؛ ساخت هم‌زمانِ دو نوبتِ
+ یک بیمار می‌تواند به `UniqueConstraintViolationException` بخورد. `findByEntityAndUser` +
+ `save` اتمیک نیست — این حالت مسابقه را در نظر بگیر (retry یا catch).
+- هویت بیمار در مسیر پنل/ادمین با `PatientResolver::resolveForBooking` بر اساس کد ملی حل
+ می‌شود، ولی در مسیر عمومی `$appointment->getUser()` مستقیم کاربر لاگین‌شده است. پرونده به
+ `User` وصل می‌شود، پس رزرو «برای شخص دیگر» (`for_self=false`) پرونده را به نام **کاربر
+ رزروکننده** می‌سازد، نه بیمار واقعی. این یک ایراد جداست — **در scope این تسک نیست**، ولی
+ اگر با آن برخورد کردی در `docs/` ثبتش کن.
+- تاریخ‌ها Unix timestamp صحیح؛ مبالغ ریال؛ رشته‌های جدید فارسی.
+- پاسخ‌ها طبق `BaseController` با `$this->success()` / `$this->error()`.
+- کاربران تست: ادمین `09390039833`، دکتر تست `09100652121`
+ (uuid `bcabb3a8-cae3-45ec-876c-548f9c1e1569`) در کلینیک
+ `41e325c4-e825-4067-8438-5d828ecaee09`، مالک کلینیک `09024206041`. کد OTP در dev همیشه
+ `12345`.
diff --git a/.claude/prompt/blog-city-field.md b/.claude/prompt/blog-city-field.md
new file mode 100644
index 00000000..ac71d7bc
--- /dev/null
+++ b/.claude/prompt/blog-city-field.md
@@ -0,0 +1,131 @@
+
+
+# افزودن شهر به بلاگ (پیش‌نیاز بلاگ شهر-محور)
+
+## پروژه
+
+`clinicpro` (backend)
+
+**cross-repo:** این قرارداد را سایت عمومی مصرف می‌کند.
+پرامپت همتا (بعد از این اجرا شود): `nobat724_front/.claude/prompt/blog-city-scoping-activate.md`
+
+## زمینه
+
+سایت عمومی ۳۵ دامنهٔ شهری دارد و هر شهر نمایندهٔ محتوایی خودش را دارد، اما بلاگ هیچ ارتباطی با شهر ندارد: نه در URL، نه در متادیتا، نه در مدل داده. نتیجه اینکه محتوای بلاگ روی همهٔ ۳۵ دامنه یکسان است و هیچ اعتبار محلی نمی‌سازد.
+
+سمت فرانت، منطق شهر-محور **از قبل نوشته و مستقر شده** ولی غیرفعال است چون داده‌اش وجود ندارد:
+
+- `nobat724_front/app/blog/[slug]/page.js` — canonical پست را با `extractEntityCityId(blog)` حساب می‌کند؛ چون `city_id` نیست، همیشه fallback به self می‌خورد.
+- برچسب بصری «مخصوص شهر: X» در `components/blog/head/index.js` فقط وقتی `cityName` بیاید رندر می‌شود.
+- `spatialCoverage` در JSON-LD مقاله فقط با وجود شهر اضافه می‌شود.
+- `app/sitemap.js` هر پست را فقط در sitemap دامنهٔ canonical خودش می‌گذارد.
+
+یعنی به‌محض اینکه API فیلد شهر بدهد، همهٔ اینها خودکار فعال می‌شوند.
+
+**وضعیت فعلی داده:** `GET /api/v1/blogs` صفر رکورد برمی‌گرداند (`totalRecords: 0`). پس این تغییر روی داده‌ای اعمال می‌شود که هنوز تولید نشده — فرصت خوبی برای اضافه‌کردن فیلد قبل از پرشدن جدول.
+
+## فایل‌های مرتبط
+
+| فایل | نقش |
+|------|-----|
+| `clinicpro/src/Blog/Entity/Blog.php` | Entity — فیلد جدید اینجا |
+| `clinicpro/src/Blog/Controller/BlogController.php` | endpointهای عمومی و ادمین |
+| `clinicpro/src/Blog/Repository/BlogRepository.php` | فیلتر لیست |
+| `clinicpro/docs/api/blog.md` | مستندات |
+| `clinicpro/assets/admin/pages/` (صفحهٔ بلاگ) | انتخاب شهر در فرم ادمین |
+
+## وضعیت فعلی
+
+`src/Blog/Entity/Blog.php` — هیچ ارجاعی به شهر ندارد:
+
+```php
+#[ORM\Entity(repositoryClass: BlogRepository::class)]
+#[ORM\Table(name: 'blogs')]
+#[ORM\Index(columns: ['status', 'created_at'], name: 'idx_blogs_status')]
+class Blog
+{
+ #[ORM\Column(type: 'string', length: 255)]
+ private string $title;
+
+ #[ORM\Column(type: 'string', length: 255, unique: true)]
+ private string $slug;
+
+ #[ORM\ManyToOne(targetEntity: User::class)]
+ #[ORM\JoinColumn(name: 'author_id', referencedColumnName: 'id', nullable: false, onDelete: 'RESTRICT')]
+ private User $author;
+
+ #[ORM\Column(type: 'json')]
+ private array $tags = [];
+
+ #[ORM\Column(type: 'string', length: 20)]
+ private string $status = self::STATUS_DRAFT;
+ // ...
+}
+```
+
+## وظایف
+
+### ۱. فیلد شهر روی Entity
+
+رابطهٔ `ManyToOne` اختیاری به Entity شهر (همان Entity که `Address`/`Clinic` استفاده می‌کنند — از آن‌ها الگو بگیر):
+
+```php
+#[ORM\ManyToOne(targetEntity: City::class)]
+#[ORM\JoinColumn(name: 'city_id', referencedColumnName: 'id', nullable: true, onDelete: 'SET NULL')]
+private ?City $city = null;
+```
+
+- **`nullable: true` الزامی است** و معنای صریح دارد: پست بدون شهر = «پست سراسری» که روی دامنهٔ اصلی canonical می‌شود. این حالت باید برای همیشه پشتیبانی شود، نه یک وضعیت موقت.
+- `onDelete: 'SET NULL'` تا حذف شهر پست را نکشد.
+- ایندکس روی `city_id` اضافه شود (فیلتر لیست per-domain روی همین ستون است).
+
+### ۲. Migration
+
+```bash
+ddev exec php bin/console doctrine:migrations:diff --no-interaction
+ddev exec php bin/console doctrine:migrations:migrate --no-interaction
+```
+
+رکوردهای موجود `city_id = NULL` می‌گیرند ⇒ همه «سراسری» می‌شوند. رفتار فعلی سایت را نمی‌شکند.
+
+### ۳. شهر در پاسخ API
+
+در سریال‌سازی پست (هم لیست هم جزئیات) شهر با **همان شکلی که سایت عمومی از کلینیک انتظار دارد** برگردد:
+
+```php
+'city' => $this->city ? [
+ 'id' => (string) $this->city->getId(),
+ 'name' => $this->city->getName(),
+] : null,
+```
+
+`nobat724_front/lib/domainHelpers.js` → `extractEntityCityId()` هر سه شکل `city_id` مسطح، `city: {id}` و `city: [{id}]` را می‌پذیرد؛ پس هر کدام از اینها کار می‌کند — ولی `{ id, name }` را انتخاب کن چون `name` برای برچسب بصری «مخصوص شهر: X» لازم است.
+
+### ۴. فیلتر شهر در لیست عمومی
+
+`GET /api/v1/blogs` پارامتر `city_id` بپذیرد با این معنا:
+
+> پست‌های **آن شهر** + پست‌های **سراسری** (`city_id IS NULL`)
+
+این دقیقاً همان چیزی است که لیست بلاگ per-domain لازم دارد (`app/blogs/page.js` روی هر دامنهٔ شهری). بدون این پارامتر، رفتار فعلی (همهٔ پست‌ها) حفظ شود.
+
+```sql
+WHERE b.status = 'published' AND (b.city_id = :cityId OR b.city_id IS NULL)
+```
+
+### ۵. انتخاب شهر در پنل ادمین
+
+در فرم ایجاد/ویرایش بلاگ، انتخابگر شهر با گزینهٔ خالی «سراسری».
+از `SearchableSelect` استفاده کن (قانون پروژه: هرگز `` بومی).
+
+### ۶. مستندات
+
+`clinicpro/docs/api/blog.md`: فیلد `city` در پاسخ لیست و جزئیات، پارامتر `city_id`، و معنای `null` = سراسری.
+
+## نکات مهم
+
+- معنای `null` را در مستندات صریح بنویس — سایت عمومی بر پایهٔ همین تصمیم می‌گیرد پست را روی دامنهٔ اصلی canonical کند یا روی دامنهٔ شهر.
+- پستی که شهر دارد نباید روی دامنه‌های دیگر از لیست حذف شود؛ فقط **canonical** و **sitemap** آن به دامنهٔ شهر می‌رود. تصمیم «چه چیزی در کدام لیست دیده شود» با پارامتر `city_id` است و اختیاری.
+- منبع شهر در سایت عمومی `data/city.json` است (۳۵ رکورد با `domain`) و `id` آن با `id` شهر در دیتابیس یکی است (مثلاً یاسوج = ۱۲۳). اگر این تطابق برقرار نیست، **قبل از هر کاری این را گزارش کن** — کل نگاشت شهر→دامنه به آن وابسته است.
+
+
diff --git a/.claude/prompt/claims-dashboard-redesign.md b/.claude/prompt/claims-dashboard-redesign.md
new file mode 100644
index 00000000..e087fbea
--- /dev/null
+++ b/.claude/prompt/claims-dashboard-redesign.md
@@ -0,0 +1,210 @@
+# بازطراحی صفحه Claims به داشبورد مدیریتی بیمار-محور
+
+## پروژه
+
+`clinicpro` (Backend Symfony + پنل ادمین React)
+
+پیش‌نیاز: `clinicpro/.claude/prompt/insurance-shared-calculation.md` باید **قبل** از این پرامپت اجرا شود — ستون‌های سهم بیمه/بیمار روی session و منطق واحد محاسبه از آنجا می‌آید.
+
+## زمینه
+
+صفحه `/admin/claims` امروز یک لیست کارتی از رکوردهای Claim است: هر Claim یک کارت، و داخل هر کارت یک `` تودرتو از اقلام. این نه DataTable استاندارد پروژه است و نه برای پیگیری پرونده‌های بیمه‌ی یک بیمار کاربردی — کاربر نمی‌تواند ببیند «بیمار X مجموعاً چقدر ادعا دارد و چقدر وصول شده».
+
+## هدف
+
+تبدیل صفحه به داشبورد دو سطحی:
+- **سطح ۱ — لیست بیماران:** هر ردیف یک بیمار با تجمیع مبالغ و وضعیت کلی.
+- **سطح ۲ — جزئیات یک بیمار:** همه‌ی درخواست‌های بیمه‌ی آن بیمار با جزئیات کامل و لاگ تغییرات.
+
+## فایل‌های مرتبط
+
+| فایل | نقش |
+|------|-----|
+| `assets/admin/pages/ClaimsPage.tsx` | صفحه فعلی (۳۶۶ خط) — بازنویسی می‌شود |
+| `assets/admin/App.tsx:237` | ثبت route `claims`؛ نقش‌های `['doctor','clinic']` + `blockClinicScope` + `` |
+| `src/Billing/Controller/BillingController.php:252` | `GET /api/v1/billing/claims` |
+| `src/Billing/Controller/BillingController.php:286` | `POST /api/v1/billing/claims/{uuid}/{submit\|approve\|reject\|pay}` |
+| `src/Billing/Controller/BillingController.php:332` | `GET /api/v1/billing/reports/insurance-debt` |
+| `src/Billing/Entity/Claim.php` | `insuranceId`, `insuranceKind`, `totalClaimedRials`, `totalApprovedRials`, `totalPaidRials`, `status`, `TRANSITIONS` (`:26`), `rejectReason`, `submittedAt`, `settledAt` |
+| `src/Billing/Entity/ClaimItem.php` | `invoiceItemId`, `claimedRials` |
+| `src/Billing/Entity/Invoice.php` / `InvoiceItem.php` | مبالغ اصلی و سهم‌ها |
+| `src/Billing/Service/ClaimService.php` | `buildClaim()` و انتقال وضعیت |
+| `assets/admin/components/ui/` | `DataTable`, `Pagination`, `SearchableSelect`, `PageHeader`, `Modal`, `StatCard`, `StatusBadge`, `PersianDatePicker`, `FeatureGate` |
+
+## وضعیت فعلی
+
+`ClaimsPage.tsx` — کارت به‌ازای هر Claim، totalها به‌صورت یک رشته متنی درهم (`:271-276`):
+
+```
+ادعا … · تأیید … · پرداخت … · دلیل رد: …
+```
+
+و جدول داخلی (`:302-337`):
+
+```tsx
+
+
+ شرح تاریخ مراجعه
+ تعداد
+ مبلغ کل
+ سهم بیمه (ادعا)
+ تأییدشده
+
+
+```
+
+مشکلات موجود که باید در بازطراحی رفع شوند:
+- `GET /api/v1/billing/reports/insurance-debt` **دو بار** با دو query key جدا fetch می‌شود (`:116`, `:122`) — یکی برای پنل بدهی، یکی برای پر کردن dropdown بیمه.
+- فیلترها با URL همگام نیستند (همه `useState`)؛ رفرش صفحه همه فیلترها را پاک می‌کند.
+- وضعیت‌ها در `STATUS_META` محلی تعریف شده‌اند (`:69-75`) به‌جای `StatusBadge`.
+- بدون `DoctorClaimsPage.tsx` اشتباه گرفته نشود — آن صفحه (`/admin/doctor-claims`) مربوط به ادعای مالکیت پروفایل پزشک است، نه بیمه.
+
+## وظایف
+
+### ۱. Backend — endpoint تجمیع بیمار-محور
+
+endpoint جدید:
+
+```
+GET /api/v1/billing/claims/by-patient
+```
+
+پارامترها: `page`, `limit`, `search` (نام/موبایل/کد ملی), `insurance_id`, `doctor_id`, `clinic_id`, `status`, `payment_status`, `from`, `to` (Unix), `sort`, `dir`.
+
+پاسخ paginated (`$this->paginated()`) با هر آیتم:
+
+```json
+{
+ "patient_uuid": "...",
+ "full_name": "...",
+ "mobile": "...",
+ "national_code": "...",
+ "claims_count": 0,
+ "total_services_rials": 0,
+ "total_insurance_rials": 0,
+ "total_patient_rials": 0,
+ "total_approved_rials": 0,
+ "total_paid_rials": 0,
+ "overall_status": "pending|submitted|approved|rejected|paid|mixed",
+ "last_activity_at": 0
+}
+```
+
+قاعده `overall_status`: اگر همه Claimهای بیمار یک وضعیت دارند همان؛ در غیر این صورت `mixed`.
+
+پیاده‌سازی با DQL و array hydration (`->getArrayResult()`)، تجمیع در SQL (`GROUP BY patient`) — نه در PHP روی کل رکوردها.
+
+### ۲. Backend — endpoint جزئیات یک بیمار
+
+```
+GET /api/v1/billing/claims/by-patient/{patientUuid}
+```
+
+لیست همه Claimهای آن بیمار (paginated)، هر رکورد شامل:
+
+```json
+{
+ "uuid": "...",
+ "visit_date": 0,
+ "doctor_name": "...",
+ "clinic_name": "...",
+ "service_title": "...",
+ "service_base_rials": 0,
+ "coverage_percent": 0,
+ "coverage_rials": 0,
+ "patient_share_rials": 0,
+ "insurance_share_rials": 0,
+ "insurance_title": "...",
+ "insurance_kind": "base|supplementary",
+ "status": "...",
+ "submitted_at": 0,
+ "settled_at": 0,
+ "tracking_number": null,
+ "reject_reason": null,
+ "description": null,
+ "allowed_transitions": ["submit"],
+ "logs": [
+ { "at": 0, "from": "pending", "to": "submitted", "by": "نام کاربر", "note": null }
+ ]
+}
+```
+
+`allowed_transitions` از `Claim::TRANSITIONS` بیاید تا فرانت دکمه‌های مجاز را خودش hardcode نکند.
+
+### ۳. Backend — شماره پیگیری و لاگ تغییرات
+
+دو مورد در دیتابیس وجود ندارند و باید اضافه شوند:
+
+**الف) `trackingNumber`** روی `Claim` (string nullable) — شماره پرونده/پیگیری بیمه. هنگام `submit` قابل ورود باشد و در `POST /api/v1/billing/claims/{uuid}/submit` به‌عنوان فیلد اختیاری بدنه پذیرفته شود.
+
+**ب) `ClaimStatusLog`** — entity جدید:
+
+| فیلد | نوع |
+|------|-----|
+| `claimId` | int |
+| `fromStatus` | string nullable |
+| `toStatus` | string |
+| `note` | text nullable |
+| `createdBy` | userId |
+| `createdAt` | Unix int |
+
+در `ClaimService` هر جا انتقال وضعیت انجام می‌شود یک رکورد لاگ نوشته شود. migration لازم است:
+
+```bash
+ddev exec php bin/console make:migration
+ddev exec php bin/console doctrine:migrations:migrate -n
+```
+
+**Backfill:** برای Claimهای موجود از `submittedAt` / `settledAt` رکوردهای لاگ تقریبی ساخته شود تا صفحه جزئیات برای داده قدیمی خالی نباشد.
+
+### ۴. Frontend — سطح ۱: DataTable بیماران
+
+`ClaimsPage.tsx` بازنویسی شود با `DataTable` استاندارد پروژه (نه کارت):
+
+ستون‌ها: نام بیمار | موبایل | کد ملی | تعداد درخواست | مجموع خدمات | مجموع سهم بیمه | مجموع سهم بیمار | وضعیت کلی (`StatusBadge`)
+
+بالای جدول: ردیف `StatCard` با مجموع کل خدمات / کل سهم بیمه / وصول‌شده / مانده وصول‌نشده — از `GET /api/v1/billing/reports/insurance-debt` که باید **فقط یک بار** fetch شود (یک `useQuery`، خروجی‌اش هم پنل و هم options فیلتر بیمه را بدهد).
+
+کلیک روی ردیف → سطح ۲.
+
+### ۵. Frontend — سطح ۲: جزئیات بیمار
+
+مسیر جدید `/admin/claims/:patientUuid` در `App.tsx` با همان roleها و ``.
+
+- `PageHeader` با breadcrumb: پرونده‌های بیمه ← نام بیمار.
+- `DataTable` از درخواست‌های بیمه با ستون‌های: تاریخ مراجعه | پزشک | کلینیک | سرویس | مبلغ اصلی | پوشش بیمه (درصد + مبلغ) | سهم بیمار | سهم بیمه | وضعیت | تاریخ ارسال | تاریخ پرداخت | شماره پیگیری.
+- `actions?(row)` → دکمه‌های انتقال وضعیت بر اساس `allowed_transitions`.
+- کلیک روی ردیف → `Modal` (size `lg`) با توضیحات کامل + **لاگ کامل تغییرات** به‌صورت timeline.
+- عملیات `reject` باید `reject_reason` بگیرد؛ `submit` باید `tracking_number` اختیاری بگیرد.
+
+### ۶. Frontend — فیلتر، جستجو، مرتب‌سازی، URL sync
+
+فیلترها در هر دو سطح: بیمار (فقط سطح ۱) | بیمه | پزشک | کلینیک | وضعیت Claim | بازه زمانی (`PersianDatePicker` + میان‌بر یک ماه/یک سال اخیر) | وضعیت پرداخت.
+
+همه‌ی فیلترها + `page` + `sort`/`dir` باید در **query string آدرس** ذخیره شوند (`useSearchParams`) تا رفرش و اشتراک‌گذاری لینک کار کند. این رفع مشکل فعلی است.
+
+مرتب‌سازی سرور-ساید از طریق `sort`/`dir` روی: نام بیمار، تعداد درخواست، مجموع خدمات، مجموع سهم بیمه، آخرین فعالیت.
+
+## نکات مهم
+
+- **الزامی:** صفحه جدید با تم، Layout و کامپوننت‌های موجود ساخته شود — بدون طراحی جدید. از `components/ui/` استفاده شود، نه جدول دست‌ساز.
+- برای dropdownها **همیشه** `SearchableSelect`، هرگز `` نیتیو.
+- `StatusBadge` فعلاً `type` برای `claim` ندارد — نوع جدید `claim` با نگاشت pending=خاکستری، submitted=آبی، approved=کهربایی، rejected=قرمز، paid=سبز، mixed=بنفش اضافه شود و `STATUS_META` محلی حذف شود.
+- استایل: از design tokenها (`var(--text-3)`, `.card`, `.btn primary sm`, `.badge`) استفاده شود. هگز hardcode ممنوع.
+- پاسخ paginated: items از `data?.data`، total از `data?.meta?.totalRecords`. single: `data?.data` (گاهی double-nested).
+- تاریخ‌ها Unix timestamp صحیح؛ تبدیل بازه با `toUnix` / `endOfDayUnix` مثل کد فعلی (`ClaimsPage.tsx:21-30`)؛ نمایش شمسی با `formatDate` / `formatDateTime`.
+- مبالغ با `formatRial`؛ مرز ریال/تومان رعایت شود.
+- همه controllerها از `BaseController`؛ پاسخ‌ها با `$this->paginated()` / `$this->success()` / `$this->error()`.
+- انتقال وضعیت غیرمجاز باید سمت سرور هم reject شود (`Claim::TRANSITIONS` منبع حقیقت است) — اتکا به مخفی‌کردن دکمه در UI کافی نیست.
+- تست با کاربر `09390039833 / 09390039833` روی `https://clinic-pro.ddev.site`.
+- بعد از تغییر API، `clinicpro/docs/api/` به‌روز شود.
+
+## تست پذیرش
+
+۱. `/admin/claims` لیست بیماران با تجمیع درست نمایش می‌دهد؛ جمع ستون سهم بیمه با `insurance-debt` هم‌خوان است.
+۲. کلیک روی بیمار → صفحه جزئیات با همه‌ی رکوردهای بیمه‌ی همان بیمار.
+۳. انتقال وضعیت یک Claim (submit با شماره پیگیری، سپس approve، سپس pay) → لاگ در timeline ثبت می‌شود.
+۴. reject بدون دلیل → خطا؛ با دلیل → ثبت و نمایش دلیل.
+۵. فیلتر بازه زمانی + بیمه اعمال شود، صفحه رفرش شود → فیلترها از URL بازیابی می‌شوند.
+۶. کاربر بدون فیچر `insurance` → صفحه در دسترس نیست (`FeatureGate`).
+۷. مبالغ سهم بیمه/بیمار در این صفحه با صفحه پرداخت و مودال فاکتور **دقیقاً** یکی است.
diff --git a/.claude/prompt/cleanup-polluted-doctor-clinic-records.md b/.claude/prompt/cleanup-polluted-doctor-clinic-records.md
new file mode 100644
index 00000000..a352b1c0
--- /dev/null
+++ b/.claude/prompt/cleanup-polluted-doctor-clinic-records.md
@@ -0,0 +1,86 @@
+
+
+# پاکسازی رکوردهای آلودهٔ پزشک و کلینیک
+
+## پروژه
+
+`clinicpro` (لایهٔ داده + اعتبارسنجی)
+
+## زمینه
+
+ممیزی SEO سایت عمومی رکوردهایی را در نتایج **عمومی** پیدا کرد که نام واقعی ندارند:
+
+- پزشک با `name: "09390039833"` (شماره‌تلفن به‌جای نام) و `owner_status: "claimed"`
+- پزشک با `name: "test"` و `owner_status: "claimed"`
+- کلینیک `9c163d69-0051-4745-a423-c830135b1c01` با `title: "09398631203"`، `is_active: false`، بدون `caption`/`logo`/`services`
+
+این رکوردها در HTML عمومی رندر می‌شدند و `