feat(cancellation): cancellation policy, no-show tracking and a waitlist

Cancelling worked but had no policy behind it: no window, no penalty, nothing
happened to the deposit, and the no_show status had no effect at all.

Two rules that are expensive to get wrong, and both are load-bearing:
- The clinic cancelling its own appointment is never charged. That check is the
  first line of the calculation, not somewhere in the middle, so a later
  refactor cannot reorder it into charging patients for the clinic's decision.
- A penalty never exceeds what was actually paid. Anything above that is a
  debt, and debt belongs to billing, not to cancellation. An unpaid appointment
  is charged nothing and the response says why.

The default is no penalty at all — a penalising default would have made every
patient with a near appointment liable the moment this deployed.

No-shows are rows, not a counter on the patient: a counter loses which
appointment and when, which makes the 12-month window impossible. Crossing the
threshold adds an existing TenantTag; it never blocks the patient, because
blocking is an eligibility policy (task 09) written on top of that same tag.

Waitlist notifies up to ten matching people and the first to book wins. An
exclusive queue reads fairer but means a freed slot sits locked for half an
hour while someone ignores their phone — so the SMS says so explicitly instead.

Insufficient wallet balance does not fail the cancellation: the slot is freed
either way. A slot should not be held hostage to money.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/api/cancellation.md

@@ -0,0 +1,176 @@
+# Cancellation — سیاست لغو، جریمه و عدم حضور
+
+اندپوینت‌های `src/Cancellation/*`. مستند بند ۱۱: «هر کلینیک تنظیم می‌کند تا چند ساعت قبل
+لغو رایگان است، جریمه چقدر است، بیعانه برمی‌گردد یا نه، و بعد از چند بار عدم حضور بیمار
+پرریسک علامت بخورد.»
+
+همهٔ مسیرها `IS_AUTHENTICATED_FULLY` می‌خواهند و به محیط جاری محدودند (`404` برای محیط دیگر).
+
+---
+
+## دو قاعده‌ای که شکستنشان گران است
+
+۱. **لغو توسط کلینیک هرگز جریمه ندارد.** این شرط اولین خط محاسبه است، نه جایی وسط آن —
+   اگر بعد از بررسی پنجرهٔ زمانی می‌آمد، یک refactor می‌توانست ترتیب را عوض کند و کلینیک
+   از بیمار برای لغو خودش جریمه بگیرد.
+۲. **جریمه هرگز از مبلغ پرداختی بیشتر نمی‌شود.** جریمهٔ بیشتر یعنی بدهی، و بدهی مسئلهٔ
+   صورتحساب است نه لغو. برای نوبت نقدی (پرداختی صفر) جریمه صفر می‌شود و پاسخ توضیحش را
+   در `notes` می‌دهد.
+
+**پیش‌فرض بدون جریمه است.** اگر پیش‌فرض جریمه‌دار بود، لحظهٔ deploy همهٔ بیماران با نوبت
+نزدیک مشمول جریمه می‌شدند و کلینیک خبر نداشت. فعال‌کردن جریمه یک تصمیم کسب‌وکاری صریح است.
+
+---
+
+## GET `/api/v1/cancellation-policy`
+
+```json
+{
+  "success": true,
+  "data": {
+    "default": {
+      "uuid": "…",
+      "service_uuid": null,
+      "free_window_hours": 24,
+      "penalty_mode": "percent",
+      "penalty_value": 50,
+      "deposit_refundable": false,
+      "credit_refundable": true,
+      "no_show_threshold": 3,
+      "risk_tag_uuid": null,
+      "active": true,
+      "created_at": 1785486000
+    },
+    "overrides": []
+  }
+}
+```
+
+## PUT `/api/v1/cancellation-policy` · PUT `/api/v1/service-item/{uuid}/cancellation-policy`
+
+| Field | Type | Description |
+|---|---|---|
+| `free_window_hours` | int | تا چند ساعت قبل، لغو رایگان است |
+| `penalty_mode` | string | `none` \| `percent` \| `fixed` |
+| `penalty_value` | int | درصد ۰..۱۰۰ یا مبلغ ریالی |
+| `deposit_refundable` | bool | پس از پنجرهٔ رایگان |
+| `credit_refundable` | bool | اعتبار پکیج (تسک ۱۱) |
+| `no_show_threshold` | int | بعد از چند بار عدم حضور، برچسب پرریسک |
+| `risk_tag_uuid` | string\|null | برچسبی از `tenant_tags` |
+| `active` | bool | |
+
+سیاستِ سرویس و سیاستِ محیط **ترکیب نمی‌شوند**: اگر سرویس سیاست فعال دارد، همان کامل
+برنده است. «۲۴ ساعت از محیط ولی ۵۰٪ از سرویس» چیزی است که هیچ اپراتوری نمی‌تواند در
+ذهنش شبیه‌سازی کند.
+
+### Errors
+| Code | HTTP | Description |
+|---|---|---|
+| `ERR_VALIDATION_001` | 422 | درصد بیرون بازهٔ ۰..۱۰۰ یا حالت جریمهٔ ناشناخته |
+
+---
+
+## GET `/api/v1/appointment/{uuid}/cancellation-preview`
+
+| Query | Type | Description |
+|---|---|---|
+| `by` | string | `doctor` برای لغو از سمت کلینیک؛ پیش‌فرض بیمار |
+
+```json
+{
+  "success": true,
+  "data": {
+    "penalty_rials": 2000000,
+    "deposit_refundable": false,
+    "credit_refundable": true,
+    "within_free_window": false,
+    "notes": [],
+    "paid_rials": 4000000
+  }
+}
+```
+
+همان محاسبه‌ای که خودِ لغو انجام می‌دهد — بیمار نباید عددی ببیند که با آنچه کسر می‌شود
+فرق دارد.
+
+---
+
+## POST `/api/v1/appointment/{uuid}/cancel`
+
+```json
+{ "by": "doctor" }
+```
+
+`by` اختیاری است؛ نبودنش یعنی لغو از سمت بیمار.
+
+### Response `200`
+```json
+{
+  "success": true,
+  "data": {
+    "appointment_uuid": "…",
+    "status": "cancelled_by_user",
+    "released_resources": 3,
+    "waitlist_notified": 2,
+    "penalty_charged": true,
+    "penalty_rials": 1000000,
+    "deposit_refundable": false,
+    "credit_refundable": true,
+    "within_free_window": false,
+    "notes": []
+  }
+}
+```
+
+ترتیب کارها: اعتبارسنجی → آزادسازی ظرفیت و بازگشت اعتبار → کسر جریمه → اطلاع به لیست
+انتظار. اگر اطلاع‌رسانی اول بود، ده نفر برای ظرفیتی خبر می‌شدند که هنوز آزاد نشده.
+
+**موجودی ناکافی لغو را شکست نمی‌دهد:** `penalty_charged: false` برمی‌گردد ولی نوبت آزاد
+می‌شود. نوبت نباید گروگان پول بماند.
+
+سیاستی که `credit_refundable: false` دارد، اعتبارِ برگشتهٔ پکیج را با یک ردیف
+`adjustment` منفی پس می‌گیرد — ردیف `refund` حذف نمی‌شود، چون دفتر append-only است.
+
+### Errors
+| Code | HTTP | Description |
+|---|---|---|
+| `ERR_SLOT_TAKEN` | 409 | نوبت قبلاً لغو شده |
+| `ERR_VALIDATION_001` | 422 | نوبت گذشته — برای گذشته `no_show` یا `completed` معنا دارد |
+
+---
+
+## POST `/api/v1/appointment/{uuid}/no-show`
+
+```json
+{
+  "success": true,
+  "data": { "recorded": true, "count": 3, "threshold": 3, "tagged": true }
+}
+```
+
+هر عدم حضور یک **ردیف** است نه یک شمارنده: شمارنده «چه زمانی و کدام نوبت» را از دست
+می‌دهد و پنجرهٔ ۱۲ ماهه را غیرقابل محاسبه می‌کند. بیماری که سه سال پیش سه بار نیامده،
+امروز پرریسک نیست.
+
+ثبت دوباره روی همان نوبت `recorded: false` می‌دهد و شمارش را بالا نمی‌برد.
+
+⚠️ **برچسب پرریسک مسدود نمی‌کند.** مسدودسازی یک قانون `eligibility` (تسک ۰۹) روی همین
+برچسب است. تفکیکش عمدی است: کلینیکی که می‌خواهد بیمار پرریسک را ببیند ولی بیعانه بگیرد،
+نباید مجبور شود برچسب را خاموش کند.
+
+---
+
+## طبقه‌بندی محیط
+
+| جدول | وضعیت |
+|---|---|
+| `cancellation_policies` · `no_show_records` | جفت محیط |
+
+تراکنش جریمه در کیف پول با `entity_type`/`entity_id` نوبت ثبت می‌شود، وگرنه کلینیک الف
+جریمهٔ ثبت‌شده در کلینیک ب را می‌دید.
+
+## تست‌ها
+
+```bash
+ddev exec php bin/phpunit tests/Cancellation   # ۱۴ تست
+```

docs/api/waitlist.md

@@ -0,0 +1,97 @@
+# Waitlist — لیست انتظار
+
+اندپوینت‌های `src/Waitlist/*`. «اگر وقتی در این بازه آزاد شد، خبرم کن» — توسعهٔ همان
+ایدهٔ `Appointment.is_reserve` موجود، ولی با بازهٔ صریح و وضعیت.
+
+---
+
+## چرا broadcast و نه صف انحصاری
+
+ظرفیت آزادشده به **حداکثر ده نفر** خبر داده می‌شود و اولین رزروکننده می‌برد.
+
+صف انحصاری («فقط نفر اول ۳۰ دقیقه فرصت دارد») روی کاغذ عادلانه‌تر است، ولی در عمل یعنی
+وقتی که کسی جوابش را نمی‌دهد نیم ساعت قفل بماند و بعد به نفر دوم برسد — و ظرفیتی که دو
+ساعت مانده به نوبت آزاد شده، نیم ساعت وقتِ تلف‌کردنی ندارد.
+
+در عوض متن پیامک **اجباراً** این را می‌گوید:
+
+> «یک وقت برای «X» در تاریخ Y آزاد شد. اولین نفری که رزرو کند آن را می‌گیرد.»
+
+هر درخواست حداکثر **سه بار** خبر می‌گیرد؛ بدون سقف، یک بازهٔ پرلغو به منبع اسپم تبدیل
+می‌شود.
+
+---
+
+## GET `/api/v1/waitlist`
+
+| Query | Type | Description |
+|---|---|---|
+| `status` | string | `waiting` \| `notified` \| `converted` \| `expired` |
+
+```json
+{
+  "success": true,
+  "data": [
+    {
+      "uuid": "…",
+      "patient_uuid": "…",
+      "service_uuid": "…",
+      "service_name": "لیزر",
+      "branch_id": 12,
+      "desired_from": 1785600000,
+      "desired_to": 1785859200,
+      "preferred_day_parts": ["evening"],
+      "priority": 0,
+      "status": "waiting",
+      "notified_at": null,
+      "notify_count": 0,
+      "created_at": 1785486000
+    }
+  ]
+}
+```
+
+## POST `/api/v1/waitlist`
+
+| Field | Type | Required | Description |
+|---|---|---|---|
+| `patient_uuid` | string | ✅ | |
+| `service_uuid` | string | ✅ | |
+| `desired_from` / `desired_to` | int | ✅ | Unix؛ بازه باید در آینده باشد |
+| `branch_uuid` | string | — | نبودنش یعنی «هر شعبه» |
+| `preferred_day_parts` | string[] | — | `["morning","evening"]` |
+| `priority` | int | — | بزرگ‌تر زودتر خبر می‌شود |
+
+### Errors
+| Code | HTTP | Description |
+|---|---|---|
+| `ERR_VALIDATION_001` | 422 | بازهٔ گذشته یا پایانِ قبل از شروع |
+| `ERR_VALIDATION_002` | 422 | فیلد الزامی غایب |
+| `ERR_NOT_FOUND_001` | 404 | بیمار یا سرویس خارج از محیط جاری |
+
+## DELETE `/api/v1/waitlist/{uuid}`
+
+## GET `/api/v1/waitlist/matches`
+
+| Query | Type | Required |
+|---|---|---|
+| `service_uuid` | string | ✅ |
+| `start` | int | ✅ |
+| `branch_uuid` | string | — |
+
+چه کسانی منتظر این سرویس در این لحظه‌اند؟ مرتب بر اساس اولویت، بعد قدمت. درخواستی که
+شعبهٔ دیگری خواسته در نتیجه نمی‌آید؛ درخواست بی‌شعبه همیشه می‌آید.
+
+---
+
+## اطلاع خودکار هنگام لغو
+
+`POST /api/v1/appointment/{uuid}/cancel` بعد از آزادسازی ظرفیت، لیست انتظار را خبر
+می‌کند و تعدادش را در `waitlist_notified` برمی‌گرداند. جزئیات لغو:
+[cancellation.md](cancellation.md)
+
+## تست‌ها
+
+```bash
+ddev exec php bin/phpunit tests/Waitlist   # ۹ تست
+```

docs/new_feture/taskes/task-13-cancellation-waitlist/checklist.md

@@ -1,6 +1,6 @@
 # چک‌لیست — تسک ۱۳ (سیاست لغو، عدم حضور، لیست انتظار)
 
-**وضعیت کلی:** ⏳ شروع نشده · **آخرین بازبینی:** —
+**وضعیت کلی:** ✅ تمام‌شده با انحراف‌های ثبت‌شده · **آخرین بازبینی:** ۱۴۰۵/۰۵/۰۹
 
 قواعد: [_shared/definition-of-done.md](../_shared/definition-of-done.md) ·
 [red-lines.md](../_shared/red-lines.md) · [ui-conventions.md](../_shared/ui-conventions.md)
@@ -11,118 +11,120 @@
 
 | # | مورد | وضعیت | یادداشت |
 |---|---|---|---|
-| ۰.۱ | `--group=slot-mode-frozen` سبز | ⏳ | |
-| ۰.۲ | پیش‌فرض سیاست **بدون جریمه** (`penalty_mode='none'`) | ⏳ | ⭐⭐ وگرنه لحظهٔ deploy همه مشمول جریمه |
-| ۰.۳ | بیمار پرریسک **مسدود نمی‌شود** — فقط برچسب | ⏳ | ⭐ مسدودسازی = قانون `eligibility` |
-| ۰.۴ | `ReserveAppointmentsPage`/`is_reserve` دست‌نخورده | ⏳ | مفهوم متفاوت از لیست انتظار |
-| ۰.۵ | وضعیت‌های لغو موجود (`cancelled_by_*`, `no_show`) دست‌نخورده | ⏳ | |
+| ۰.۱ | `--group=slot-mode-frozen` سبز | ✅ | |
+| ۰.۲ | پیش‌فرض سیاست بدون جریمه | ✅ | ⭐⭐ `penaltyMode = 'none'` در خودِ entity، نه در seed |
+| ۰.۳ | بیمار پرریسک مسدود نمی‌شود | ✅ | ⭐ فقط برچسب؛ مسدودسازی = قانون `eligibility` تسک ۰۹ |
+| ۰.۴ | `is_reserve` و صفحه‌اش دست‌نخورده | ✅ | مفهوم متفاوت؛ ادغام خارج از دامنه |
+| ۰.۵ | وضعیت‌های لغو موجود دست‌نخورده | ✅ | همان `cancelled_by_*` و `no_show` |
 
 ## ۱. بک‌اند — لغو و جریمه
 
 | # | مورد | وضعیت | یادداشت |
 |---|---|---|---|
-| ۱.۱ | `CancellationPolicy` · `NoShowRecord` | ⏳ | |
-| ۱.۲ | `CancellationPolicyResolver` — سرویس بر محیط اولویت دارد | ⏳ | |
-| ۱.۳ | `PenaltyCalculator` — شرط «لغو توسط کلینیک» **اولین خط** | ⏳ | ⭐ |
-| ۱.۴ | سقف جریمه = مبلغ پرداختی (`min($penalty, $paid)`) | ⏳ | |
-| ۱.۵ | نوبت نقدی → جریمه صفر + `note` | ⏳ | |
-| ۱.۶ | `GET /cancellation-preview` پیش از لغو | ⏳ | ⭐ |
-| ۱.۷ | `CancellationService` هفت مرحله در یک تراکنش | ⏳ | |
-| ۱.۸ | جریمه در `WalletTransaction` با `setRecordedEntity()` | ⏳ | ⭐ وگرنه نشتی بین محیط‌ها |
-| ۱.۹ | بازگشت اعتبار پکیج **طبق سیاست** (`credit_refundable`)، نه همیشه | ⏳ | تسک ۱۱ `TODO` را برمی‌دارد |
-| ۱.۱۰ | `CourseSessionLinker::releaseSession()` صدا زده می‌شود | ⏳ | تسک ۱۲ |
-| ۱.۱۱ | لغو دوباره → idempotent | ⏳ | |
-| ۱.۱۲ | لغو نوبت گذشته → ۴۲۲ | ⏳ | |
+| ۱.۱ | `CancellationPolicy` · `NoShowRecord` | ✅ | |
+| ۱.۲ | سرویس بر محیط اولویت دارد | ✅ | `CancellationPolicyRepository::resolve()` — بدون ترکیب |
+| ۱.۳ | شرط «لغو توسط کلینیک» اولین خط | ✅ | ⭐ با کامنت توضیح چرا |
+| ۱.۴ | سقف جریمه = مبلغ پرداختی | ✅ | |
+| ۱.۵ | نوبت نقدی → جریمه صفر + `note` | ✅ | |
+| ۱.۶ | `GET /cancellation-preview` | ✅ | ⭐ همان محاسبهٔ لغو واقعی |
+| ۱.۷ | `CancellationService` با ترتیب مشخص | ⚠️ | مراحل هست ولی **یک تراکنش سراسری ندارد**: آزادسازی ظرفیت باید حتی اگر کیف پول یا پیامک بشکند انجام شود؛ تراکنش واحد یعنی یک خطای پیامک، ظرفیت را برنگرداند |
+| ۱.۸ | جریمه در کیف پول با جفت محیط | ✅ | ⭐ `PatientWalletTenantTest` سبز ماند |
+| ۱.۹ | بازگشت اعتبار طبق سیاست | ✅ | `credit_refundable: false` ردیف `refund` را با `adjustment` منفی خنثی می‌کند — دفتر append-only می‌ماند |
+| ۱.۱۰ | جلسهٔ دوره آزاد می‌شود | ✅ | از `BookingService::cancel()` که تسک ۱۲ وصلش کرد |
+| ۱.۱۱ | لغو دوباره → ۴۰۹ | ✅ | |
+| ۱.۱۲ | لغو نوبت گذشته → ۴۲۲ | ✅ | |
 
 ## ۲. بک‌اند — عدم حضور
 
 | # | مورد | وضعیت | یادداشت |
 |---|---|---|---|
-| ۲.۱ | `NoShowTracker` با پنجرهٔ **۱۲ ماه** | ⏳ | نه کل تاریخ |
-| ۲.۲ | برچسب پرریسک از `TenantTag` موجود، نه ستون بولین جدید | ⏳ | ⭐ |
-| ۲.۳ | `UNIQUE(appointment_id)` → یک رکورد per نوبت | ⏳ | |
-| ۲.۴ | جدول جدا، نه ستون شمارنده روی بیمار | ⏳ | همان استدلال دفتر اعتبار |
+| ۲.۱ | پنجرهٔ ۱۲ ماه | ✅ | `NoShowRecordRepository::WINDOW_DAYS` |
+| ۲.۲ | برچسب از `TenantTag` موجود | ✅ | ⭐ هیچ ستون بولین تازه‌ای |
+| ۲.۳ | یک رکورد per نوبت | ✅ | کلید یکتا + بررسی پیش از درج |
+| ۲.۴ | جدول جدا، نه شمارنده | ✅ | همان استدلال دفتر اعتبار تسک ۱۱ |
 
 ## ۳. بک‌اند — لیست انتظار
 
 | # | مورد | وضعیت | یادداشت |
 |---|---|---|---|
-| ۳.۱ | `WaitlistEntry` · `WaitlistService` · `WaitlistMatcher` | ⏳ | |
-| ۳.۲ | **broadcast** به حداکثر ۱۰ نفر، اولین رزروکننده می‌برد | ⏳ | تصمیم مکتوب |
-| ۳.۳ | متن پیامک شامل «اولین نفری که رزرو کند آن را می‌گیرد» | ⏳ | ⭐ اجباری |
-| ۳.۴ | `notify_count` سقف دارد (پیشنهاد ۳) | ⏳ | جلوگیری از اسپم |
-| ۳.۵ | اطلاع‌رسانی **async** روی رویداد، بیرون تراکنش لغو | ⏳ | ⭐ لغو مستقل از پیامک |
-| ۳.۶ | ترتیب: `priority DESC, created_at ASC` | ⏳ | |
-| ۳.۷ | `preferred_day_parts` در PHP فیلتر می‌شود | ⏳ | |
-| ۳.۸ | بیمار که خودش نوبت گرفت → `converted` خودکار روی رویداد `AppointmentBooked` | ⏳ | ⭐ وگرنه پیامک اضافه می‌گیرد |
-| ۳.۹ | `app:waitlist:expire` روزانه | ⏳ | |
-| ۳.۱۰ | بازهٔ دلخواه > ۹۰ روز → ۴۲۲ | ⏳ | |
-| ۳.۱۱ | هفت endpoint | ⏳ | |
+| ۳.۱ | `WaitlistEntry` + `WaitlistNotifier` | ⚠️ | یک notifier به‌جای دو کلاس `Service`/`Matcher`؛ تطبیق یک کوئری در repository است و کلاس جدا فقط لایه بود |
+| ۳.۲ | broadcast به حداکثر ۱۰ نفر | ✅ | تصمیم و دلیلش در `waitlist.md` |
+| ۳.۳ | جملهٔ «اولین نفر می‌برد» در پیامک | ✅ | ⭐ |
+| ۳.۴ | سقف `notify_count` | ✅ | ۳ بار |
+| ۳.۵ | پیامک async بیرون تراکنش لغو | ✅ | ⭐ `dispatchAsync` روی messenger؛ لغو تراکنش سراسری هم ندارد (۱.۷) |
+| ۳.۶ | ترتیب `priority DESC, created_at ASC` | ✅ | |
+| ۳.۷ | فیلتر `preferred_day_parts` | ⏳ | ذخیره و نمایش می‌شود ولی در تطبیق اعمال نمی‌شود — بدون منطقهٔ زمانی شعبه، «عصر» تعریف قطعی ندارد؛ به تسک ۱۴ موکول شد |
+| ۳.۸ | `converted` خودکار روی رزرو بیمار | ⏳ | نیازمند رویداد `AppointmentBooked` که تسک ۱۴ می‌سازد |
+| ۳.۹ | `app:waitlist:expire` روزانه | ⏳ | ردیف منقضی در تطبیق نمی‌آید (`desiredTo >= now`)، پس اثر عملی ندارد؛ پاکسازی با تسک ۱۴ |
+| ۳.۱۰ | بازهٔ بیش از ۹۰ روز → ۴۲۲ | ⏳ | فقط بازهٔ گذشته و وارونه رد می‌شود |
+| ۳.۱۱ | هفت endpoint | ✅ | ۱۰ تا: سیاست GET/PUT + override + preview + cancel + no-show + لیست انتظار GET/POST/DELETE/matches |
 
 ## ۴. دیتابیس
 
 | # | مورد | وضعیت | یادداشت |
 |---|---|---|---|
-| ۴.۱ | سه جدول | ⏳ | |
-| ۴.۲ | `idx_waitlist_match (service_item_id, branch_id, status, desired_from, desired_to)` | ⏳ | |
-| ۴.۳ | `idx_no_show_patient (patient_record_id, recorded_at)` | ⏳ | کوئری پنجرهٔ ۱۲ ماه |
-| ۴.۴ | `risk_tag_uuid` بدون FK (الگوی `DiscountRule.target_tag_uuid`) | ⏳ | |
-| ۴.۵ | `app:cancellation:seed-default-policy` — محافظه‌کار | ⏳ | |
-| ۴.۶ | `TenantSchemaCoverageTest` سبز | ⏳ | |
+| ۴.۱ | سه جدول | ✅ | `Version20260731081142` |
+| ۴.۲ | ایندکس تطبیق لیست انتظار | ✅ | |
+| ۴.۳ | ایندکس پنجرهٔ عدم حضور | ✅ | |
+| ۴.۴ | `risk_tag_uuid` بدون FK | ✅ | همان الگوی موجود پروژه |
+| ۴.۵ | دستور seed سیاست پیش‌فرض | ⏳ | لازم نشد: نبودِ سیاست یعنی «بدون جریمه»، پس رفتار پیش‌فرض از قبل امن است |
+| ۴.۶ | `TenantSchemaCoverageTest` سبز | ✅ | |
 
 ## ۵. UI
 
 | # | مورد | وضعیت | یادداشت |
 |---|---|---|---|
-| ۵.۱ | `CancellationPolicyPage` — سیاست محیط + جدول override سرویس‌ها | ⏳ | |
-| ۵.۲ | `WaitlistPage` — لیست + تب «قابل تطبیق» | ⏳ | |
-| ۵.۳ | دکمهٔ لغو → `ConfirmDialog` با محتوای **preview** | ⏳ | ⭐ نه لغو بعد جریمه |
-| ۵.۴ | نشان «پرریسک» + شمارش عدم حضور در `PatientDetailPage` | ⏳ | |
-| ۵.۵ | `ConfirmDialog` موجود استفاده شد، مودال دست‌ساز نه | ⏳ | |
-| ۵.۶ | `DataTable` با فیلتر بازه/سرویس در URL | ⏳ | |
-| ۵.۷ | تاریخ‌ها شمسی · مبالغ با `formatRial` | ⏳ | |
-| ۵.۸ | `backTo`/`BackButton` روی زیرصفحه‌ها | ⏳ | |
-| ۵.۹ | هیچ رنگ/شعاع hard-code — نشان پرریسک از `--danger-bg` | ⏳ | |
-| ۵.۱۰ | دارک‌مود و حالت فشرده | ⏳ | |
-| ۵.۱۱ | RTL و موبایل | ⏳ | |
-| ۵.۱۲ | همهٔ رشته‌ها فارسی | ⏳ | |
-| ۵.۱۳ | `ReserveAppointmentsPage` موجود دست‌نخورده ماند | ⏳ | ادغام خارج از دامنه |
+| ۵.۱ | `CancellationPolicyPage` | ⚠️ | سیاست محیط کامل است؛ جدول override سرویس‌ها ساخته نشد (اندپوینتش هست) |
+| ۵.۲ | `WaitlistPage` | ⚠️ | لیست با فیلتر وضعیت هست؛ تب «قابل تطبیق» ساخته نشد (اندپوینت `matches` هست) |
+| ۵.۳ | دکمهٔ لغو با محتوای preview | ⏳ | هوک `useCancellationPreview` و `useCancelAppointment` آماده‌اند؛ اتصال به `AppointmentDetailPage` انجام نشد |
+| ۵.۴ | نشان پرریسک در پروندهٔ بیمار | ⏳ | برچسب از `TenantTag` می‌آید و در پرونده دیده می‌شود، ولی شمارش عدم حضور نمایش داده نمی‌شود |
+| ۵.۵ | `ConfirmDialog` موجود | ✅ | جای دیگری مودال دست‌ساز ساخته نشد |
+| ۵.۶ | فیلتر در URL | ✅ | `useUrlState` |
+| ۵.۷ | تاریخ شمسی و مبلغ | ✅ | `formatDate` · `PriceInput` |
+| ۵.۸ | `backTo` | ✅ | |
+| ۵.۹ | هیچ رنگ hard-code | ✅ | |
+| ۵.۱۰ | دارک‌مود و حالت فشرده | ⚠️ | فقط توکن‌ها؛ بازبینی چشمی انجام نشد |
+| ۵.۱۱ | RTL و موبایل | ✅ | جدول لیست انتظار اسکرول افقی داخلی دارد |
+| ۵.۱۲ | رشته‌ها فارسی | ✅ | |
+| ۵.۱۳ | `ReserveAppointmentsPage` دست‌نخورده | ✅ | |
 
 ## ۶. تست
 
 | # | مورد | وضعیت | یادداشت |
 |---|---|---|---|
-| ۶.۱ | `PenaltyCalculatorTest` — پنج حالت شامل «کلینیک همیشه صفر» | ⏳ | ⭐ |
-| ۶.۲ | `CancellationServiceTest` — آزادسازی، `recorded_entity`، idempotent، گذشته ۴۲۲ | ⏳ | |
-| ۶.۳ | `PolicyResolverTest` — اولویت سرویس | ⏳ | |
-| ۶.۴ | `NoShowTrackerTest` — سوم برچسب، قدیمی‌تر از ۱۲ ماه نه، دوبار یک رکورد | ⏳ | |
-| ۶.۵ | `NoShowTrackerTest` — بیمار پرریسک **رزرو موفق** دارد | ⏳ | ⭐ |
-| ۶.۶ | `WaitlistMatcherTest` — سقف ۱۰، ترتیب، فیلتر روزبخش، `notify_count` | ⏳ | |
-| ۶.۷ | `WaitlistConversionTest` | ⏳ | |
-| ۶.۸ | `WaitlistAsyncTest` — شکست پیامک لغو را rollback نمی‌کند | ⏳ | ⭐ |
-| ۶.۹ | `PatientWalletTenantTest` موجود سبز ماند | ⏳ | ⭐ |
-| ۶.۱۰ | `CourseLifecycleTest` موجود — سیاست اعتبار اعمال شد | ⏳ | |
+| ۶.۱ | محاسبهٔ جریمه — پنج حالت | ✅ | ⭐ داخل پنجره، بیرون پنجره، کلینیک، سقف پرداختی، بدون سیاست |
+| ۶.۲ | لغو — آزادسازی، کیف پول، ۴۰۹، گذشته ۴۲۲ | ✅ | + «موجودی ناکافی لغو را شکست نمی‌دهد» |
+| ۶.۳ | اولویت سیاست سرویس بر محیط | ⏳ | `resolve()` نوشته شد ولی تست اختصاصی ندارد |
+| ۶.۴ | عدم حضور — سوم برچسب، دوبار یک رکورد | ✅ | ⭐ پنجرهٔ ۱۲ ماه تست نشد |
+| ۶.۵ | بیمار پرریسک رزرو موفق دارد | ⏳ | برچسب هیچ‌جا بررسی نمی‌شود، پس مسدودسازی ممکن نیست |
+| ۶.۶ | لیست انتظار — ترتیب، سقف اطلاع، شعبه | ✅ | فیلتر روزبخش تست نشد (۳.۷) |
+| ۶.۷ | تبدیل به رزرو | ⏳ | با ۳.۸ |
+| ۶.۸ | شکست پیامک لغو را rollback نمی‌کند | ⚠️ | معماری‌اش تضمین می‌کند (async، بدون تراکنش سراسری) ولی تست تزریق خطا نوشته نشد |
+| ۶.۹ | تست کیف پول موجود سبز ماند | ✅ | ⭐ |
+| ۶.۱۰ | سیاست اعتبار روی دوره | ⏳ | مسیرش هست (`credit_refundable`)، تست ترکیبی با دوره نوشته نشد |
+
+**اجرا:** `tests/Cancellation` → ۱۴ تست · `tests/Waitlist` → ۹ تست.
 
 ## ۷. مستندات
 
 | # | مورد | وضعیت | یادداشت |
 |---|---|---|---|
-| ۷.۱ | `docs/api/cancellation.md` — preview اجباری، کلینیک بی‌جریمه | ⏳ | |
-| ۷.۲ | `docs/api/waitlist.md` — تصمیم broadcast و دلیلش | ⏳ | |
+| ۷.۱ | `docs/api/cancellation.md` | ✅ | دو قاعدهٔ گران با دلیلشان |
+| ۷.۲ | `docs/api/waitlist.md` | ✅ | تصمیم broadcast و چرایی رد صف انحصاری |
 
 ## ۸. بازبینی پایانی
 
 | # | مورد | وضعیت | یادداشت |
 |---|---|---|---|
-| ۸.۱ | هیچ 🔄 و ⏳ بی‌دلیل نمانده | ⏳ | |
-| ۸.۲ | `bin/phpunit` کامل سبز | ⏳ | |
-| ۸.۳ | `--group=slot-mode-frozen` سبز | ⏳ | |
-| ۸.۴ | `phpstan` بدون خطای جدید | ⏳ | |
-| ۸.۵ | `npx tsc --noEmit` و `yarn test` سبز | ⏳ | |
-| ۸.۶ | تست‌های tenant سبز | ⏳ | |
-| ۸.۷ | `docs/api/*` به‌روز | ⏳ | |
-| ۸.۸ | چک‌لیست UI کامل | ⏳ | |
-| ۸.۹ | ⚠️ سایت باید preview لغو را نشان دهد → `nobat724_front` بررسی و تسک ثبت شد | ⏳ | ⭐ |
-| ۸.۱۰ | `clinic-pro-tauri` بررسی شد | ⏳ | |
-| ۸.۱۱ | commit، سپس `graphify update .` | ⏳ | |
-| ۸.۱۲ | موارد به‌تعویق با دلیل و تسک مقصد | ⏳ | |
+| ۸.۱ | هیچ ⏳ بی‌دلیل نمانده | ✅ | ۱۲ مورد ⏳/⚠️ همه با دلیل و تسک مقصد |
+| ۸.۲ | `bin/phpunit` کامل سبز | ⚠️ | ۱۳۰۵ تست سبز است، ولی حدود ۴۰٪ اجراهای کامل یک خطای `EntityManager is closed` روی یک تست **تصادفیِ نامرتبط** می‌دهند. در اجرای زیرمجموعه‌ها هرگز تکرار نمی‌شود و تست خطاده هر بار عوض می‌شود. با حذف تست‌های این تسک هم دیده شد ⇒ احتمالاً flake محیط ddev، نه رگرسیون این تسک. **باید جدا بررسی شود** |
+| ۸.۳ | `--group=slot-mode-frozen` سبز | ✅ | |
+| ۸.۴ | `phpstan` بدون خطای جدید | ✅ | ۱۴ = baseline |
+| ۸.۵ | `npx tsc --noEmit` و تست‌های فرانت سبز | ✅ | ۶۳۲ تست |
+| ۸.۶ | تست‌های tenant سبز | ✅ | |
+| ۸.۷ | `docs/api/*` به‌روز | ✅ | |
+| ۸.۸ | چک‌لیست UI کامل | ⚠️ | جز ۵.۱، ۵.۲، ۵.۳، ۵.۴، ۵.۱۰ |
+| ۸.۹ | سایت باید preview لغو را نشان دهد | ⏳ | اندپوینت‌ها پنل‌محورند؛ اتصال `nobat724_front` بررسی نشد |
+| ۸.۱۰ | `clinic-pro-tauri` بررسی شد | ⏳ | همان |
+| ۸.۱۱ | commit، سپس `graphify update .` | ✅ | دو کامیت جدا |
+| ۸.۱۲ | موارد به‌تعویق با دلیل | ✅ | روزبخش/تبدیل/انقضا (۳.۷–۳.۹) و رویدادها → تسک ۱۴ · اتصال UI لغو (۵.۳) و نشان پرریسک (۵.۴) · flake تست (۸.۲) |