# نوبت‌دهی بر پایهٔ منبع: رابطهٔ منبع↔سرویس، گزینهٔ سرویس، و حل مدت/قیمت

## پروژه

`clinicpro` (backend + پنل ادمین).
**cross-repo:** قرارداد `POST /api/v1/appointment` و `GET /api/v1/appointment-booking-locations/{doctorUuid}` را سایت عمومی مصرف می‌کند
(`nobat724_front/services/response.js` → `getBookingLocations`, `getServiceSlots`, `postAppointment`).
تغییر قرارداد در build سایت خطا نمی‌دهد؛ باید دستی دنبال شود.

## قواعد غیرقابل‌مذاکره

این سه بند شرط پذیرش‌اند، نه توصیه. کاری که این‌ها را نقض کند «تمام‌شده» نیست حتی اگر تست‌هایش سبز باشد.

**۱. هر UI جدید داخل تم فعلی، در حد یک متخصص UI/UX.** هیچ تم، پالت، فونت یا کتابخانهٔ CSS تازه‌ای
ساخته نمی‌شود. مشخصاً:

- رنگ‌ها فقط از توکن‌های `assets/admin/styles.css` (`var(--primary)`، `var(--surface)`، `var(--border)`،
  `var(--text-2)`، …). هیچ hex خامی در کامپوننت جدید.
- کامپوننت از `assets/admin/components/ui/` استفاده شود، نه نسخهٔ دست‌ساز: `DataTable`، `Modal`،
  `ConfirmDialog`، `PageHeader` (با `backTo`)، `SearchableSelect`، `StatusBadge`، `Pagination`،
  `PersianDateInput`. **`<select>` خام ممنوع** — همیشه `SearchableSelect`.
- سه حالت نمایش باید سالم باشند: دارک‌مود (`[data-theme="dark"]`)، حالت فشرده
  (`[data-density="compact"]`) و موبایل ۳۹۰px بدون اسکرول افقی.
- دو تلهٔ شناخته‌شدهٔ همین CSS: `.card` **padding ندارد** (برای فاصله `card-pad` اضافه کن) و
  `.field` خودش جعبهٔ ورودی است (برچسبِ بالای فیلد با `.field-block` می‌آید، نه داخل `.field`).
- RTL و متن فارسی؛ تاریخ‌ها شمسی با `formatDate()`.
- صفحهٔ زیرمجموعه بدون دکمهٔ بازگشت پذیرفته نیست: `PageHeader backTo=…` یا `<BackButton fallback=…/>`.
- وضعیت لیست‌ها (جستجو، فیلتر، صفحه) در query string با `hooks/useUrlState.ts`، نه در `useState`.

**۲. هر چیزِ اضافه حذف می‌شود.** فقط منبع، سرویس، گزینهٔ سرویس و دسته‌بندی می‌ماند. وظیفهٔ ۸ فهرست
حذف را دارد؛ ولی قاعده کلی‌تر است: در همین کار هم صفحه، فیلد، endpoint یا گزینه‌ای که سند
نخواسته اضافه نکن.

**۳. ساختار ساده.** بدون abstraction برای آینده:

- جدول جدید فقط وقتی هیچ جدول موجودی — حتی با یک ستون تازه — کافی نباشد؛ دلیلش نوشته شود.
  (به همین دلیل «گزینهٔ سرویس» جدول جدید نمی‌گیرد — پایین‌تر.)
- Controller نازک، منطق در Service، کوئری در Repository، وابستگی با constructor injection.
- interface و کلاس پایه فقط وقتی **الان** بیش از یک پیاده‌سازی دارد.
- نام‌گذاری و سبک کد دقیقاً مثل فایل‌های همسایه.

## زمینه

تسک‌های `docs/new_feture/taskes/` لایهٔ منبع را ساخته‌اند — `ResourceType`، `ClinicResource`،
تقویم منبع، استثنا، استخر، مهارت، موتور دسترس‌پذیری و اشغال واقعی. ولی **واحد رزرو هنوز پزشک است**:
نوبت به `Doctor` گره خورده، و «کدام منبع این سرویس را می‌دهد» و «مدت/قیمت این سرویس برای این منبع»
هیچ‌جا داده نیست. سند مالک محصول می‌گوید مدل باید بر پایهٔ منبع باشد، و هر چیزی خارج از
منبع/سرویس/گزینه از محصول حذف شود.

## مشکل / هدف

سه شکاف واقعی نسبت به سند:

1. **رابطهٔ منبع↔سرویس وجود ندارد.** انتخاب منبع فقط با `type + skill` انجام می‌شود، پس
   «دستگاه لیزر ۱ این سرویس را می‌دهد ولی دستگاه ۲ نه» قابل بیان نیست.
2. **مدت و قیمت بُعد منبع ندارند.** override موجود per **شعبه** است؛ «دکتر احمدی ۳۰ دقیقه /
   دکتر رضایی ۴۵ دقیقه برای همان گزینه» نمایش‌دادنی نیست.
3. **نوبت منبع را نگه نمی‌دارد.** `Appointment.doctor` غیرتهی است و رزرو بدون پزشک ممکن نیست،
   پس نوبتِ «دستگاه لیزر ۲» در مدل جا ندارد.

هدف: منبع واحد رزرو شود، مدت و قیمت با زنجیرهٔ **منبع+گزینه → منبع+سرویس → پیش‌فرض** حل شود،
و نوبت منبع و snapshot را نگه دارد.

> **گزینهٔ سرویس در این کدبیس جدول جدید نمی‌خواهد.** «گزینه» همان `ServiceItem` عضو یک
> `ItemGroup` است (`select_min`/`select_max` از قبل هست) و «سرویس» همان آیتم والد. ساختن
> جدول سوم `service_options` یعنی دو منبع حقیقت برای یک چیز، و همهٔ مسیرهای امروز
> (`appointment-booking-services`، `appointment-service-slots`، `PriceListItem`، `Tariff`)
> باید دوباره نوشته شوند. دلیل انتخاب در «نکات مهم» ثبت شده است.

## معیار پذیرش

- ✅ **موفق:** برای سرویس «لیزر» و گزینهٔ «پا» دو ردیف منبع ثبت شود (دستگاه ۱: ۲۰ دقیقه/۸ میلیون ریال،
  دستگاه ۲: ۱۵ دقیقه/۹٫۵ میلیون ریال). `GET /api/v1/resource/{uuid}/services` هر دو را برگرداند و
  `POST /api/v1/appointment` با `resource_uuid` دستگاه ۲ → `201` با
  `service_total_minutes: 15` و `price_snapshot.final_rials: 9500000`.
- ❌ **خطا:** رزرو با `resource_uuid` منبعی که آن سرویس را ندارد → `422` با
  `ERR_VALIDATION_001` و پیام «این منبع این سرویس را ارائه نمی‌دهد»؛ بدون توکن → `401` با envelope خطا.
- ✅ **دسته‌بندی:** دستهٔ «تمام بدن» شامل «دست» و «پا» تعریف شود؛ انتخاب هم‌زمان «لیزر تمام بدن» و
  «لیزر دست» → `422` با پیام فارسی، و یک دستگاه بتواند هم‌زمان به چند دسته وصل باشد.
- ⚠️ **مرزی:** منبعی که برای گزینه مقدار ندارد ولی برای سرویس دارد → مقدار سطح سرویس استفاده شود؛
  منبعی که هیچ‌کدام را ندارد → پیش‌فرض خودِ آیتم؛ و نوبت‌های **قبلاً ثبت‌شده** (بدون `resource_id`)
  باید همچنان در لیست‌ها و پنل بدون خطا نمایش داده شوند.

## فایل‌های مرتبط

| فایل | نقش |
|---|---|
| `src/Resource/Entity/ClinicResource.php` | منبع؛ امروز به `Doctor`/`ClinicStaff`/`Room` لینک می‌شود |
| `src/Resource/Repository/ClinicResourceRepository.php` | `findEligible()` — انتخاب کاندید با type+skill |
| `src/ClinicService/Entity/ServiceItem.php` | سرویس و گزینه (هر دو item) با `solo/additional` و قیمت |
| `src/ClinicService/Entity/ItemGroup.php` · `ItemGroupMember.php` | گروه گزینه‌ها با بازهٔ انتخاب |
| `src/ClinicService/Entity/CatalogCategory.php` | دستهٔ سراسری محیط؛ `parent` تک‌والدی و `MAX_DEPTH = 4` |
| `src/ClinicService/Service/ServiceSelectionValidator.php` | اعتبارسنجی ترکیب انتخاب‌ها |
| `src/ClinicService/Entity/ServiceBranchOverride.php` | override per شعبه (باید در زنجیره بماند) |
| `src/ClinicService/Service/DurationCalculator.php` | جمع solo/additional |
| `src/Pricing/Service/PricingEngine.php` | `quote()` — بدون بُعد منبع |
| `src/Appointment/Entity/Appointment.php` | `private Doctor $doctor` غیرتهی |
| `src/Appointment/Controller/AppointmentController.php` | `book()` — `doctor_uuid` الزامی |
| `src/Appointment/Plan/Service/AppointmentPlanBuilder.php` | ساخت برنامه و نیازمندی‌ها |
| `src/Appointment/Availability/Service/AvailabilityEngine.php` | جستجوی وقت آزاد روی منابع |
| `assets/admin/pages/ResourcesPage.tsx` | صفحهٔ منابع پنل |
| `docs/api/appointment.md` · `docs/api/clinic.md` | سند endpointها |

## وضعیت فعلی

انتخاب کاندید هیچ ربطی به سرویس ندارد — `src/Resource/Repository/ClinicResourceRepository.php:108`:

```php
public function findEligible(DoctorAddress $address, ResourceType $type, array $skillIds = []): array
{
    $qb = $this->createQueryBuilder('r')
        ->where('r.address = :address')
        ->andWhere('r.type = :type')
        ->andWhere('r.active = true')
        // … فیلتر مهارت
```

override فقط per شعبه است — `src/ClinicService/Entity/ServiceBranchOverride.php:41`:

```php
#[ORM\Column(name: 'price_rials', type: 'bigint', nullable: true)]
private ?int $priceRials = null;

#[ORM\Column(name: 'solo_duration_minutes', type: 'smallint', nullable: true)]
private ?int $soloDurationMinutes = null;
```

نوبت بدون پزشک ساخته نمی‌شود — `src/Appointment/Entity/Appointment.php:101` و `:242`:

```php
private Doctor $doctor;

public function __construct(Doctor $doctor, User $user, int $slotStart, int $slotEnd)
```

قیمت‌گذاری بُعد منبع ندارد — `src/Pricing/Service/PricingEngine.php:59`:

```php
public function quote(
    ServiceItem $service,
    array $items,
    DoctorAddress $address,
    int $at,
    array $policy = [],
    ?PatientRecord $patient = null,
): PriceQuote {
```

## وظایف

### ۱. جدول رابطهٔ منبع↔سرویس

`src/Resource/Entity/ResourceServiceOffering.php` — رابطهٔ چند‌به‌چند با تنظیمات اختصاصی.
همان الگوی `ResourceSkill`/`ResourcePoolMember`: entity رابطه‌ای با جفت یکتا.

```php
#[ORM\Entity(repositoryClass: ResourceServiceOfferingRepository::class)]
#[ORM\Table(name: 'resource_service_offerings')]
#[ORM\UniqueConstraint(name: 'uniq_resource_service', columns: ['resource_id', 'service_item_id'])]
#[ORM\Index(columns: ['entity_type', 'entity_id', 'service_item_id'], name: 'idx_offering_tenant_service')]
class ResourceServiceOffering
{
    use TenantOwnedTrait;   // جفت از خود منبع مشتق می‌شود، نه از بدنهٔ درخواست

    public function __construct(ClinicResource $resource, ServiceItem $serviceItem) { … }

    private ?int $durationMinutes = null;   // null = ارث از سطح بالاتر
    private ?int $priceRials      = null;   // null = ارث از سطح بالاتر
    private bool $active          = true;
}
```

نکته: چون «گزینه» هم `ServiceItem` است، همین یک جدول هر دو سطحِ سند را پوشش می‌دهد —
ردیف با آیتمِ والد = «منبع + سرویس»، ردیف با آیتمِ عضو گروه = «منبع + گزینه».

**نحوه تست:** migration ساخته و اجرا شود؛ سپس
`ddev exec php bin/phpunit tests/Resource/ResourceServiceOfferingTest.php` با سه تست:
ثبت ردیف، جفت تکراری → خطای یکتایی، و اینکه جفت محیط از منبع گرفته می‌شود نه از ورودی.

### ۲. Resolver مدت و قیمت

`src/ClinicService/Service/ResourceServiceResolver.php` — الگوی **Chain of Responsibility**،
چون سند صریحاً ترتیب اولویت تعریف کرده و افزودن سطح بعدی (مثلاً قرارداد بیمه) نباید
`if` تازه در دل موتور بگذارد.

ترتیب (از خاص به عام) — سطح شعبه عمداً در زنجیره می‌ماند چون داده‌اش امروز وجود دارد:

```
۱. منبع + گزینه            → ResourceServiceOffering(resource, optionItem)
۲. منبع + سرویس            → ResourceServiceOffering(resource, parentItem)
۳. شعبه + آیتم             → ServiceBranchOverride(item, address)
۴. پیش‌فرض خودِ آیتم        → ServiceItem::getSoloDurationMinutes() / getPriceRials()
```

```php
public function resolve(ClinicResource $resource, ServiceItem $item, DoctorAddress $address): ResolvedServiceSpec
{
    // اولین سطحی که مقدارِ غیرnull دارد برنده است — مدت و قیمت **جدا** حل می‌شوند:
    // منبعی که فقط مدت را override کرده نباید قیمتش هم از همان سطح بیاید.
}
```

`ResolvedServiceSpec` باید بگوید هر مقدار از کدام سطح آمده (`durationSource`, `priceSource`) —
بدون این، دیباگِ «چرا این عدد؟» در پنل غیرممکن است.

**نحوه تست:** `tests/ClinicService/ResourceServiceResolverTest.php` — چهار تست، هر سطح یکی، به‌علاوهٔ
تستِ مرزی «مدت از سطح ۱ و قیمت از سطح ۳».

### ۳. فیلتر کاندیدها بر اساس سرویس

`ClinicResourceRepository::findEligible()` یک آرگومان اختیاری `?ServiceItem $service` بگیرد و
وقتی داده شد، فقط منابعی برگردد که ردیف فعال در `resource_service_offerings` دارند.

**قاعدهٔ سازگاری عقب‌رو:** اگر برای آن سرویس **هیچ** ردیفی ثبت نشده باشد، فیلتر اعمال نشود
(همان رفتار امروز). وگرنه هر محیطی که هنوز رابطه‌ها را پر نکرده، یک‌شبه بدون وقت آزاد می‌شود.

`AppointmentPlanBuilder::planRequirements()` سرویس را به `eligibleFor()` پاس بدهد.

**نحوه تست:** دو منبع از یک نوع بساز، فقط یکی را به سرویس وصل کن، `POST /api/v1/appointment-availability`
بزن و مطمئن شو `assignment` همیشه همان یک منبع است. سپس ردیف را غیرفعال کن → `slots` خالی با `reason`.

### ۴. منبع و snapshot روی نوبت

- `Appointment::$resource` (`ManyToOne`, **nullable**) + `Appointment::$serviceOptionItem` (nullable).
  nullable بودن اجباری است: ۷۲ نوبت موجود منبع ندارند و migration نباید آن‌ها را بشکند.
- `service_total_minutes` و `PriceSnapshot` از قبل هستند — فقط باید از خروجی resolver پر شوند،
  نه از `ServiceItem` مستقیم.
- `Appointment::toArray()` باید `resource` (`uuid`, `name`, `type`) و `service_option` را برگرداند.

**نحوه تست:** `tests/Appointment/ResourceBookingTest.php` — رزرو با منبع، سپس تغییر قیمت سرویس و
اطمینان از اینکه `price_snapshot` نوبت قبلی تکان نمی‌خورد (همان قاعدهٔ snapshot سند).

### ۵. رزرو با منبع در endpointها

- `POST /api/v1/appointment`: `resource_uuid` پذیرفته شود. اگر آمد، `doctor_uuid` اختیاری است و
  پزشک از `resource->subject()` استنتاج می‌شود (اگر منبع پزشک باشد). اگر منبع دستگاه باشد و
  نوبت پزشک ندارد، `Appointment.doctor` باید nullable شود — این تغییر schema است و migration جدا می‌خواهد.
- `GET /api/v1/appointment-booking-services/{doctorUuid}` مکمل بگیرد:
  `GET /api/v1/resource/{uuid}/services` → سرویس‌های آن منبع با مدت و قیمتِ **حل‌شده**.
- `POST /api/v1/appointment` بدون هیچ‌کدام → `422`.

**نحوه تست:** با `curl` و توکن بیمار روی دادهٔ `app:seed-scenarios`: یک‌بار با `resource_uuid` دستگاه،
یک‌بار با `doctor_uuid` (مسیر قدیمی باید سالم بماند)، یک‌بار با منبعِ بی‌ارتباط → `422`.

### ۶. پنل ادمین: تب «سرویس‌های این منبع»

در `assets/admin/pages/ResourcesPage.tsx` (یا صفحهٔ جزئیات منبع) جدولی با ستون‌های
سرویس/گزینه · مدت · قیمت · فعال، با ویرایش inline. خالی‌گذاشتن مدت یا قیمت یعنی «ارث از سطح بالاتر» و
باید مقدار مؤثر را به‌صورت placeholder با برچسب منبعش نشان دهد (`از شعبه`، `پیش‌فرض سرویس`).

از `SearchableSelect` استفاده شود، نه `<select>` خام؛ فرم با React Hook Form + Zod؛ داده با TanStack Query.

**صفحهٔ تازه ساخته نشود** — این یک تب روی صفحهٔ منبع موجود است. جدول با `DataTable` و ستون وضعیت با
`StatusBadge`؛ حذف رابطه با `ConfirmDialog`. طبق قاعدهٔ ۱، هیچ رنگ خام و هیچ کامپوننت موازی.

**نحوه تست:** `npx vitest run assets/admin/pages/ResourceServicesTab.test.tsx` — سه تست:
نمایش مقدار مؤثر، ذخیرهٔ override، پاک‌کردن override → بازگشت به ارث.
سپس **بازبینی چشمی** در مرورگر: دارک‌مود، حالت فشرده و موبایل ۳۹۰px — هر سه بدون شکستگی و
بدون اسکرول افقی. بدون این سه اسکرین‌شات، وظیفه تمام‌شده نیست.

### ۷. دسته‌بندی سراسری کلینیک، مشترک بین سرویس و منبع، با «شامل بودن»

سند مالک محصول: دسته‌بندی باید در سطح کلینیک تعریف شود و **هم سرویس‌ها هم منابع** از همان
استفاده کنند؛ و یک دسته می‌تواند شامل دسته‌های دیگر باشد («تمام بدن» شامل دست و پا و …).

**وضعیت امروز:** `CatalogCategory` از قبل سراسریِ محیط است (جفت `(entity_type, entity_id)` +
`parent` + `MAX_DEPTH = 4`) و روی `ServiceItem::$catalogCategory` می‌نشیند. دو چیز کم است:

الف) `ClinicResource` هیچ فیلد دسته‌ای ندارد، پس «این دستگاه برای دست و پا است» گفتنی نیست.

ب) **`parent` برای «شامل بودن» کافی نیست.** درخت تک‌والدی است: «دست» نمی‌تواند هم‌زمان زیر
«تمام بدن» و زیر «اندام فوقانی» باشد، در حالی که در لیزر مجموعه‌ها روی هم می‌افتند. پس
containment یک **گراف جهت‌دار بدون دور** است، جدا از سلسله‌مراتب نمایشی.

سه تغییر:

```php
// ۱) عضویت چندگانهٔ منبع در دسته‌ها — m2m، چون یک دستگاه چند ناحیه را پوشش می‌دهد
#[ORM\Table(name: 'resource_catalog_categories')]
#[ORM\UniqueConstraint(name: 'uniq_resource_category', columns: ['resource_id', 'category_id'])]

// ۲) یال «شامل بودن» بین دسته‌ها — DAG، نه درخت
#[ORM\Table(name: 'catalog_category_includes')]
#[ORM\UniqueConstraint(name: 'uniq_category_include', columns: ['parent_category_id', 'child_category_id'])]
class CatalogCategoryInclude
{
    // «تمام بدن» → «دست» ، «تمام بدن» → «پا» …
    // parent === child ممنوع، و بستارِ گذرا نباید به خودش برگردد.
}
```

```php
// ۳) بستار گذرا: «تمام بدن» شامل «نیم‌تنهٔ پایین» و آن شامل «پا» ⇒ تمام بدن شامل پا
final class CategoryClosureResolver
{
    /** @return int[] شناسهٔ همهٔ دسته‌های زیرمجموعه، با پیمایش عمقی و محافظ دور */
    public function descendants(CatalogCategory $category): array { … }

    public function overlaps(CatalogCategory $a, CatalogCategory $b): bool { … }
}
```

مصرفش در دو نقطه:

- **تعارض انتخاب:** `ServiceSelectionValidator` وقتی دو آیتم انتخاب‌شده دسته‌هایی دارند که یکی
  دیگری را شامل می‌شود → `422` با پیام «تمام بدن شامل دست است؛ هر دو با هم انتخاب نمی‌شوند».
  این جای رابطهٔ دستیِ `incompatible_with` را برای این حالت می‌گیرد — یک بار در دسته تعریف
  می‌شود، نه به‌ازای هر جفت آیتم.
- **فیلتر منبع:** در `findEligible()` (وظیفهٔ ۳) اگر سرویس دسته دارد، منابعی که آن دسته یا یکی از
  اجدادش را پوشش می‌دهند مقدم‌اند.

**حلقه ممنوع:** پیش از ذخیرهٔ یال، `descendants($child)` بررسی شود و اگر `$parent` در آن بود
`422` برگردد. بدون این، `descendants()` تا سرریز استک می‌رود.

**نحوه تست:** `tests/ClinicService/CategoryClosureTest.php` —
✅ «تمام بدن» → دست/پا ثبت شود و `descendants` هر دو را بدهد ·
✅ زنجیرهٔ سه‌سطحی بستار گذرا را درست بدهد ·
❌ یال دوری («دست شامل تمام بدن») → `422` ·
⚠️ دسته‌ای که هیچ یالی ندارد → آرایهٔ خالی، نه خطا.
سپس با `curl`: انتخاب هم‌زمان «لیزر تمام بدن» و «لیزر دست» در `POST /api/v1/appointment` → `422`.

### ۸. حذف زیرسیستم‌های خارج از این مدل

**تصمیم مالک محصول (۱۴۰۵/۰۵/۱۰):** هر چیزی خارج از منبع/سرویس/گزینه از محصول حذف شود.
ریسکش گفته شد (جریمهٔ لغو و پکیج معمولاً نیاز واقعی کلینیک‌اند) و مالک محصول تصمیم را تکرار کرد.

حذف کامل این پنج زیرسیستم — کد، جدول، endpoint، تست، صفحهٔ پنل، سند:

| دامنه | مسیر | حجم |
|---|---|---|
| موتور سیاست | `src/Policy/` | ۲۷ فایل · ۶ فایل تست |
| پکیج و دفتر اعتبار | `src/Package/` | ۱۳ فایل · ۲ تست |
| دورهٔ درمان | `src/Course/` | ۱۴ فایل · ۲ تست |
| لغو/جریمه/لیست انتظار | `src/Cancellation/` + `src/Waitlist/` | ۱۹ فایل · ۲ تست |
| رویداد و گزارش | `src/Report/` + `src/Shared/Event/` | ۳ فایل · ۳ تست |

صفحات پنل: `PolicyFormPage`, `PolicySimulationPage`, `PackagesPage`, `PatientPackageLedgerPage`,
`CourseProtocolsPage`, `CancellationPolicyPage`, `ResourceUtilizationPage` (+ تست‌هایشان) و مسیرهایشان در `App.tsx`.

**قلاب‌هایی که باید از کد باقی‌مانده کنده شوند** (اینجا کامپایل می‌شکند، پس ترتیب مهم است):

```
src/Appointment/Plan/Service/AppointmentPlanBuilder.php   → applyTimingPolicies() و applyResourcePolicies()
src/Pricing/Service/PricingEngine.php                     → PricingPolicyEngine و PackageConsumptionService
src/Appointment/Booking/Controller/BookingController.php  → BookingPolicyGuard
src/ClinicService/Service/ServiceSelectionValidator.php   → SelectionPolicyEngine
src/Appointment/Booking/Service/BookingService.php        → PackageConsumptionService، CreditLedgerService، CourseSessionLinker
src/Shared/Tenant/GlobalTables.php                        → ردیف‌های همین دامنه‌ها
src/Shared/Command/BookingEngineSeeder.php                → متدهای policies/packagesAndCourses/cancellationAndWaitlist
```

migration جدا برای `DROP TABLE` جدول‌های این دامنه‌ها با `down()` واقعی.

**نحوه تست:** بعد از حذف: `ddev exec php bin/phpunit` کامل سبز ·
`ddev exec php vendor/bin/phpstan analyse` روی همان baseline ۱۴ خطا ·
`ddev exec npx tsc --noEmit` بدون خطا · `ddev exec php bin/console debug:router | grep -cE "policy|package|course|waitlist|cancellation"` → `0` ·
`ddev exec php bin/console app:seed-scenarios --reset -n` بدون خطا.

### ۹. مستندات

- `docs/api/appointment.md`: فیلد `resource_uuid` در رزرو + پاسخ `resource`/`service_option`، و حذف
  بخش‌های سیاست/پکیج/دوره/لغو.
- `docs/api/clinic.md`: endpoint جدید `resource/{uuid}/services`.
- `docs/architecture/`: سند مدل منبع‌محور با همان چهار سطح زنجیره.
- `docs/new_feture/taskes/`: چک‌لیست تسک‌های ۹ تا ۱۴ با وضعیت «حذف‌شده به تصمیم مالک محصول» و تاریخ.
- `TEST_USERS.md`: جدول «موتور نوبت‌دهی» باید سطرهای حذف‌شده را از دست بدهد.

## نکات مهم

- **خط قرمز:** منطق نوبت‌دهی اسلاتی نباید تغییر کند. `ddev exec php bin/phpunit --group=slot-mode-frozen`
  باید در هر مرحله سبز بماند.
- **چرا جدول `service_options` جدید نمی‌سازیم:** گزینه از قبل `ServiceItem` است و `ItemGroup`
  قواعد «حداقل یکی، حداکثر سه‌تا» را دارد. جدول سوم یعنی `PriceListItem`، `Tariff`،
  `appointment_service_items`، `SegmentTemplate` و کل مسیر `appointment-service-slots` باید دو نوع
  ورودی بشناسند — دو منبع حقیقت برای یک مفهوم.
- **مدت و قیمت جدا حل می‌شوند.** منبعی که فقط مدت را override کرده نباید قیمتش هم از همان سطح بیاید.
- **جفت محیط (`entity_type`,`entity_id`) از خود منبع مشتق شود**، نه از بدنهٔ درخواست — همان قاعده‌ای که
  `ClinicResource` و `ServiceItem` رعایت می‌کنند. `TenantSchemaCoverageTest` entity طبقه‌بندی‌نشده را قرمز می‌کند.
- **سازگاری داده:** `resource_id` و `service_option_item_id` روی نوبت nullable؛ فیلتر سرویس در
  `findEligible` فقط وقتی رابطه‌ای ثبت شده باشد.
- **cross-repo:** بعد از تغییر قرارداد، مصرف واقعی در `nobat724_front/services/response.js` و
  `nobat724_front/components/appointment/` دستی بررسی شود؛ سایت امروز فقط `doctor_uuid` می‌فرستد و
  با اختیاری‌شدنش نمی‌شکند، ولی برای رزرو دستگاه باید به‌روز شود.
- **ترتیب اجرا:** اول وظیفهٔ ۷ (حذف) یا اول ۱ تا ۶؟ حذف اول انجام شود — وگرنه resolver و
  `PlanBuilder` را دوبار می‌نویسی: یک‌بار با قلاب سیاست، یک‌بار بدون آن.