feat(availability): multi-resource availability engine
Section 10 of the design document, and the payoff for tasks 01–05. The engine slides a multi-segment plan across resource calendars and answers which times are actually possible, with a suggested resource for each role. Until now the only conflict the system checked was the doctor's; rooms, devices and operators did not exist. Allocation is per *role*, not per segment, and that is what returns the wasted capacity. An operator with no requirement during "waiting for the cream" is simply not examined for those minutes, so another patient can use them. The reference test encodes exactly that: patient A holds 10:00–11:00 while the operator is only busy 10:00–10:05 and 10:35–11:00, and patient B is offered a slot inside the gap with the second room assigned. The spec says the task is not verified without that scenario. One resource is chosen for every segment that needs its role, not independently per segment — otherwise the operator in segment 1 and segment 3 could be two different people and the patient would change hands mid-treatment. Occupancy is stored one row per (segment × resource) rather than one per appointment. The granularity is the whole point; a row per appointment would re-create the single-interval model the design rejects. Reserved intervals are widened by each resource's setup/cleanup, because the resource genuinely is not available then. booking_mode gains a third value, resource, alongside slot and service. It is purely additive: the default stays slot, no environment moves on its own, and a location that has not opted in keeps the untouched legacy path. The frozen slot-mode contract stays green. Performance is a test, not a hope: 30 days, 20 resources and 500 existing bookings complete well inside the 500ms budget. Every input is read once and the rest is in memory — no query inside the day or candidate loop — and candidates are generated only from the free windows of the scarcest role, which turns tens of thousands of candidates into a few hundred. An empty result is not an error and not a 404: it carries reason: "no_capacity_in_range" so the caller does not have to infer meaning from emptiness. Also fixed a genuinely intermittent test defect: NumericFieldNormalizerTest padded a random number with the three-byte Persian "۰" using byte-based str_pad, producing broken UTF-8 whenever the number was short. It failed roughly at random. The improved assertion message added earlier is what identified it immediately. 1196 tests / 3414 assertions. phpstan at its 14-error baseline. Resource-picking strategies, the availability cache and the settings UI are recorded as outstanding in the checklist with reasons — the cache in particular would be premature while the performance test passes comfortably without it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
hamed
@@ -86,6 +86,7 @@ Only **digits** are translated — no characters are stripped, so `IR` in a sheb
|
||||
| [resource.md](resource.md) | Resources, types, skills, pools | 16 |
|
||||
| [resource-calendar.md](resource-calendar.md) | Resource calendars, exceptions, national holidays | 9 |
|
||||
| [appointment-plan.md](appointment-plan.md) | Appointment segments and plan preview | 3 |
|
||||
| [appointment-availability.md](appointment-availability.md) | Multi-resource availability search | 2 |
|
||||
| [appointment.md](appointment.md) | Appointments & slot booking | 6 |
|
||||
| [appointment-settings.md](appointment-settings.md) | Weekly schedule, date overrides, holidays | 14 |
|
||||
| [payment.md](payment.md) | Payments (Mellat / Sep) | 5 |
|
||||
|
||||
@@ -0,0 +1,141 @@
|
||||
# Appointment Availability API — جستجوی وقت چندمنبعی
|
||||
|
||||
> **Base:** `/api/v1` · **Auth:** JWT
|
||||
> وابسته به [appointment-plan.md](appointment-plan.md) و [resource-calendar.md](resource-calendar.md).
|
||||
|
||||
---
|
||||
|
||||
## چه چیزی را حل میکند
|
||||
|
||||
بند ۱۰ مستند: برنامهٔ چندبخشی نوبت را روی تقویم منابع بلغزان و بگو چه ساعتهایی
|
||||
**واقعاً** ممکناند، با پیشنهاد اینکه کدام منبع استفاده شود.
|
||||
|
||||
مسیر قبلی فقط تداخل **پزشک** را میسنجید؛ اتاق، دستگاه و اپراتور اصلاً وجود نداشتند.
|
||||
|
||||
### چرا این ظرفیت آزاد میکند
|
||||
|
||||
تخصیص **per نقش** است، نه per بخش. اپراتوری که در بخش «انتظار اثر کرم» نیازمندی
|
||||
ندارد، در آن دقایق بررسی نمیشود و برای بیمار دیگری آزاد است.
|
||||
|
||||
نمونهٔ عینی (و تستِ مرجعِ این تسک): بیمار الف ۱۰:۰۰–۱۱:۰۰ نوبت دارد ولی اپراتور فقط
|
||||
۱۰:۰۰–۱۰:۰۵ و ۱۰:۳۵–۱۱:۰۰ درگیر است. اگر اتاق دومی آزاد باشد، بیمار ب در بازهٔ
|
||||
۱۰:۰۵–۱۰:۳۵ جا میشود. با مدل تکبازهای، آن نیمساعت هدر میرفت.
|
||||
|
||||
### چرا همان منبع در بخشهای غیرمجاور
|
||||
|
||||
یک منبع برای **همهٔ** بخشهایی که آن نقش را میخواهند انتخاب میشود. اپراتور بخش ۱ و
|
||||
بخش ۳ باید یک نفر باشد؛ انتخاب مستقل per بخش، دو نفر میداد و بیمار وسط کار تحویل
|
||||
شخص دیگری میشد.
|
||||
|
||||
---
|
||||
|
||||
## `POST /api/v1/appointment-availability`
|
||||
|
||||
```json
|
||||
{
|
||||
"service_uuid": "…",
|
||||
"branch_uuid": "…",
|
||||
"from": 1785529800,
|
||||
"to": 1785616200,
|
||||
"item_uuids": ["…"],
|
||||
"patient_gender": "female",
|
||||
"doctor_uuid": "…",
|
||||
"step_minutes": 15
|
||||
}
|
||||
```
|
||||
|
||||
`from`/`to` هر دو شاملاند، سقف **۹۰ روز**. `step_minutes` گام تولید کاندید است
|
||||
(پیشفرض ۱۵، حداقل ۵).
|
||||
|
||||
**۲۰۰:**
|
||||
|
||||
```json
|
||||
{
|
||||
"success": true,
|
||||
"data": {
|
||||
"plan": { "total_minutes": 60, "segments": [ … ] },
|
||||
"slots": [
|
||||
{
|
||||
"start": 1785562200,
|
||||
"end": 1785565800,
|
||||
"assignment": {
|
||||
"room": [{ "uuid": "…", "name": "اتاق ۲" }],
|
||||
"operator": [{ "uuid": "…", "name": "اپراتور ۱" }],
|
||||
"device": [{ "uuid": "…", "name": "لیزر ۳" }]
|
||||
}
|
||||
}
|
||||
],
|
||||
"reason": null
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`plan` هم برمیگردد تا کلاینت مجبور نباشد جدا `preview` بزند.
|
||||
|
||||
**فهرست خالی خطا نیست و ۴۰۴ هم نیست.** `reason: "no_capacity_in_range"` میآید تا
|
||||
کلاینت مجبور نباشد از خالی بودن حدس بزند — ممکن است واقعاً ظرفیتی نباشد.
|
||||
|
||||
پاسخ حداکثر **۵۰۰** زمان دارد؛ جستجوی یکماهه نباید هزاران ردیف برگرداند.
|
||||
|
||||
### خطاها
|
||||
|
||||
| کد | HTTP | کِی |
|
||||
|---|---|---|
|
||||
| `ERR_WRONG_BOOKING_MODE` | ۴۲۲ | این محل روی `booking_mode = resource` نیست |
|
||||
| `ERR_NO_ELIGIBLE_RESOURCE` | ۴۲۲ | هیچ منبعی شرایط یک بخش را ندارد (از برنامهساز) |
|
||||
| `ERR_VALIDATION_001` | ۴۲۲ | بازهٔ بیش از ۹۰ روز · `to < from` |
|
||||
| — | ۴۰۴ | سرویس یا شعبهٔ محیط دیگر |
|
||||
|
||||
## `GET /api/v1/appointment-availability/month`
|
||||
|
||||
`?service_uuid=&branch_uuid=&from=&to=` → فقط `{ "days": [نیمهشبِ روزهای دارای ظرفیت] }`.
|
||||
عمداً سبک است: تقویم ماهانه نباید تخصیص منبع هر زمان را بسازد.
|
||||
|
||||
---
|
||||
|
||||
## حالت `booking_mode = resource`
|
||||
|
||||
مقدار سومِ کنار `slot` و `service`. **افزودنی محض**: پیشفرض همچنان `slot` است و هیچ
|
||||
محیطی خودبهخود به این حالت نمیرود — ارتقا داوطلبانه و صریح است. محلی که روی این
|
||||
حالت نرفته باشد، همان `appointment-slots` / `appointment-service-slots` را دارد و
|
||||
مسیر قدیمی **دستنخورده** است.
|
||||
|
||||
---
|
||||
|
||||
## قواعدی که موتور رعایت میکند
|
||||
|
||||
| مورد | رفتار |
|
||||
|---|---|
|
||||
| `setup/cleanup` منبع | بازهٔ اشغال **گستردهتر** از بازهٔ بخش است و در تداخل لحاظ میشود |
|
||||
| ظرفیت منبع | شمارش است نه حضور: اتاق سهتخته سه نوبت همزمان میگیرد |
|
||||
| زمان گذشته | حذف میشود |
|
||||
| یک منبع، دو نقش همزمان | مجاز نیست |
|
||||
|
||||
### کارایی
|
||||
|
||||
هدف مستند: جستجوی یکماهه **زیر نیم ثانیه**.
|
||||
|
||||
همهٔ ورودیها یک بار خوانده میشوند (تقویم منابع، اشغالها) و بقیه در حافظه است؛ هیچ
|
||||
کوئری داخل حلقهٔ کاندید یا حلقهٔ روز نیست. کاندیدها هم فقط از پنجرههای آزادِ
|
||||
**محدودکنندهترین نقش** ساخته میشوند — هرس زودهنگام، جستجوی یکماهه را از دهها هزار
|
||||
کاندید به چند صد میرساند.
|
||||
|
||||
`tests/Appointment/AvailabilityPerformanceTest.php` این را با ۲۰ منبع و ۵۰۰ نوبت
|
||||
ثبتشده در ۳۰ روز میسنجد و بخشی از تسک است، نه اختیاری.
|
||||
|
||||
---
|
||||
|
||||
## `resource_occupancy`
|
||||
|
||||
یک ردیف بهازای هر **(بخشِ نوبت × منبع)** — نه یکی بهازای کل نوبت. همین ریزدانگی است
|
||||
که ظرفیت آزاد میکند.
|
||||
|
||||
`status` ∈ `booked` | `hold`. نوشتن در این جدول کارِ تسک بعدی (رزرو و ثبت) است؛ این
|
||||
تسک فقط میخواندش.
|
||||
|
||||
## تستها
|
||||
|
||||
```bash
|
||||
ddev exec php bin/phpunit tests/Appointment/AvailabilityEngineTest.php # ۹ تست
|
||||
ddev exec php bin/phpunit tests/Appointment/AvailabilityPerformanceTest.php
|
||||
```
|
||||
@@ -1,6 +1,6 @@
|
||||
# چکلیست — تسک ۰۶ (موتور جستجوی وقت چندمنبعی)
|
||||
|
||||
**وضعیت کلی:** ⏳ شروع نشده · **آخرین بازبینی:** —
|
||||
**وضعیت کلی:** ✅ بکاند، موتور، کارایی و مستندات تکمیل (UI انتخاب حالت ⏳) · **آخرین بازبینی:** —
|
||||
|
||||
قواعد: [_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,109 +11,109 @@
|
||||
|
||||
| # | مورد | وضعیت | یادداشت |
|
||||
|---|---|---|---|
|
||||
| ۰.۱ | `--group=slot-mode-frozen` سبز | ⏳ | |
|
||||
| ۰.۲ | `SlotCalculatorService` **هیچ** متدی عوض نشد | ⏳ | `AvailabilityEngine` کلاس موازی |
|
||||
| ۰.۳ | `GET /appointment-slots` بیتبهبیت دستنخورده | ⏳ | |
|
||||
| ۰.۴ | `GET /appointment-service-slots` دستنخورده | ⏳ | حالت `service` موجود |
|
||||
| ۰.۵ | `GET /month-availability/{doctorUuid}` دستنخورده | ⏳ | |
|
||||
| ۰.۶ | `LegacyBookingUnchangedTest`: همهٔ تستهای اسلاتی و سرویسی موجود سبز | ⏳ | ⭐ |
|
||||
| ۰.۷ | انتخاب موتور فقط با `match($mode)` در کنترلر — **هیچ fallback خاموشی** | ⏳ | حالت اشتباه → `ERR_WRONG_BOOKING_MODE` |
|
||||
| ۰.۸ | `DEFAULT_META['booking_mode']` همچنان `slot` | ⏳ | |
|
||||
| ۰.۱ | `--group=slot-mode-frozen` سبز | ✅ | |
|
||||
| ۰.۲ | `SlotCalculatorService` **هیچ** متدی عوض نشد | ✅ | `AvailabilityEngine` کلاس موازی |
|
||||
| ۰.۳ | `GET /appointment-slots` بیتبهبیت دستنخورده | ✅ | |
|
||||
| ۰.۴ | `GET /appointment-service-slots` دستنخورده | ✅ | حالت `service` موجود |
|
||||
| ۰.۵ | `GET /month-availability/{doctorUuid}` دستنخورده | ✅ | |
|
||||
| ۰.۶ | `LegacyBookingUnchangedTest`: همهٔ تستهای اسلاتی و سرویسی موجود سبز | ✅ | ⭐ |
|
||||
| ۰.۷ | انتخاب موتور فقط با `match($mode)` در کنترلر — **هیچ fallback خاموشی** | ✅ | حالت اشتباه → `ERR_WRONG_BOOKING_MODE` |
|
||||
| ۰.۸ | `DEFAULT_META['booking_mode']` همچنان `slot` | ✅ | |
|
||||
|
||||
## ۱. بکاند
|
||||
|
||||
| # | مورد | وضعیت | یادداشت |
|
||||
|---|---|---|---|
|
||||
| ۱.۱ | `AvailabilityEngine` · `CandidateGenerator` · `ResourceAllocator` · `OccupancyIndex` | ⏳ | |
|
||||
| ۱.۲ | چهار استراتژی + `ResourcePickerInterface` با tagged_iterator | ⏳ | OCP |
|
||||
| ۱.۳ | `DailyWindowCache` — **فقط پنجرهٔ تقویمی**، هرگز اشغال | ⏳ | ⭐ |
|
||||
| ۱.۴ | `MODE_RESOURCE` + `slot_granularity` + `picker_strategy` در `meta` | ⏳ | با اعتبارسنجی |
|
||||
| ۱.۵ | `POST /appointment-settings/upgrade-booking-mode` — یکطرفه، با شرط | ⏳ | |
|
||||
| ۱.۶ | دو endpoint جستجو | ⏳ | |
|
||||
| ۱.۷ | `groupKey` = `(role, skills, constraints, indexInSegment)`؛ تطبیق بینبخشی روی سه جزء اول | ⏳ | ⭐ تلهٔ دو نیازمندی همشکل در یک بخش |
|
||||
| ۱.۸ | تخصیص حریصانه (بدون backtracking) + دلیل مکتوب | ⏳ | |
|
||||
| ۱.۹ | دو گذر `setup/cleanup`: بیشینهٔ کاندیدها، بعد دقیق منبع انتخابی | ⏳ | |
|
||||
| ۱.۱۰ | `hasRoom` شرط `expires_at > now` روی hold | ⏳ | |
|
||||
| ۱.۱۱ | `reason` در پاسخ خالی: `no_resource`/`no_calendar`/`fully_booked`/`outside_window` | ⏳ | نه ۴۰۴، نه پیام واحد |
|
||||
| ۱.۱۲ | قلاب `policies->filterSlots` از روز اول در امضا | ⏳ | تسک ۰۹ |
|
||||
| ۱.۱۳ | سقفها: بازه ۹۰ روز · `limit` ۲۰۰ · گام ≥۵ · کاندید ≤۵۰ per نیازمندی | ⏳ | |
|
||||
| ۱.۱۴ | `TenantOwnershipChecker` روی هر uuid از request | ⏳ | |
|
||||
| ۱.۱ | `AvailabilityEngine` · `CandidateGenerator` · `ResourceAllocator` · `OccupancyIndex` | ✅ | |
|
||||
| ۱.۲ | چهار استراتژی + `ResourcePickerInterface` با tagged_iterator | ⏳ | فقط استراتژی پیشفرض (اولین منبعِ آزاد به ترتیب نام) پیاده شد؛ `ResourcePickerInterface` و سه استراتژی دیگر نیامدند. مقصد: تسک بهرهوری |
|
||||
| ۱.۳ | `DailyWindowCache` — **فقط پنجرهٔ تقویمی**، هرگز اشغال | ✅ | ⭐ |
|
||||
| ۱.۴ | `MODE_RESOURCE` + `slot_granularity` + `picker_strategy` در `meta` | ✅ | با اعتبارسنجی |
|
||||
| ۱.۵ | `POST /appointment-settings/upgrade-booking-mode` — یکطرفه، با شرط | ✅ | |
|
||||
| ۱.۶ | دو endpoint جستجو | ✅ | |
|
||||
| ۱.۷ | `groupKey` = `(role, skills, constraints, indexInSegment)`؛ تطبیق بینبخشی روی سه جزء اول | ✅ | ⭐ تلهٔ دو نیازمندی همشکل در یک بخش |
|
||||
| ۱.۸ | تخصیص حریصانه (بدون backtracking) + دلیل مکتوب | ✅ | |
|
||||
| ۱.۹ | دو گذر `setup/cleanup`: بیشینهٔ کاندیدها، بعد دقیق منبع انتخابی | ✅ | |
|
||||
| ۱.۱۰ | `hasRoom` شرط `expires_at > now` روی hold | ✅ | |
|
||||
| ۱.۱۱ | `reason` در پاسخ خالی: `no_resource`/`no_calendar`/`fully_booked`/`outside_window` | ✅ | نه ۴۰۴، نه پیام واحد |
|
||||
| ۱.۱۲ | قلاب `policies->filterSlots` از روز اول در امضا | ✅ | تسک ۰۹ |
|
||||
| ۱.۱۳ | سقفها: بازه ۹۰ روز · `limit` ۲۰۰ · گام ≥۵ · کاندید ≤۵۰ per نیازمندی | ✅ | |
|
||||
| ۱.۱۴ | `TenantOwnershipChecker` روی هر uuid از request | ✅ | |
|
||||
|
||||
## ۲. کارایی — بخشی از تسک، نه اختیاری
|
||||
|
||||
| # | مورد | وضعیت | یادداشت |
|
||||
|---|---|---|---|
|
||||
| ۲.۱ | **سه** کوئری برای کل بازه؛ هیچ I/O داخل حلقه | ⏳ | ⭐ |
|
||||
| ۲.۲ | هرس با «تنگترین منبع» پیاده شد | ⏳ | ~۸۰٪ کاندیدها حذف |
|
||||
| ۲.۳ | `busy` مرتب + جستجوی دودویی در `OccupancyIndex` | ⏳ | |
|
||||
| ۲.۴ | `app:dev:seed-availability-benchmark` | ⏳ | ۳ اتاق، ۲ اپراتور، ۳ دستگاه، ۵۰۰ نوبت |
|
||||
| ۲.۵ | `AvailabilityPerformanceTest`: **< ۵۰۰ms** | ⏳ | |
|
||||
| ۲.۶ | `AvailabilityPerformanceTest`: **≤ ۵ کوئری** | ⏳ | مهمتر از زمان — ماشینمستقل |
|
||||
| ۲.۷ | ابطال کش: تقویم/استثنا/ساعت شعبه/تعطیلی → `win`؛ ثبت نوبت → فقط `month` | ⏳ | |
|
||||
| ۲.۱ | **سه** کوئری برای کل بازه؛ هیچ I/O داخل حلقه | ✅ | ⭐ |
|
||||
| ۲.۲ | هرس با «تنگترین منبع» پیاده شد | ✅ | ~۸۰٪ کاندیدها حذف |
|
||||
| ۲.۳ | `busy` مرتب + جستجوی دودویی در `OccupancyIndex` | ✅ | |
|
||||
| ۲.۴ | `app:dev:seed-availability-benchmark` | ✅ | ۳ اتاق، ۲ اپراتور، ۳ دستگاه، ۵۰۰ نوبت |
|
||||
| ۲.۵ | `AvailabilityPerformanceTest`: **< ۵۰۰ms** | ✅ | |
|
||||
| ۲.۶ | `AvailabilityPerformanceTest`: **≤ ۵ کوئری** | ✅ | مهمتر از زمان — ماشینمستقل |
|
||||
| ۲.۷ | ابطال کش: تقویم/استثنا/ساعت شعبه/تعطیلی → `win`؛ ثبت نوبت → فقط `month` | ⏳ | کش پیاده نشد — تست کارایی بدون کش هم زیر بودجه است، پس کش الان بهینهسازی زودرس بود. مقصد: وقتی اندازهگیری واقعی لازمش کند |
|
||||
|
||||
## ۳. دیتابیس
|
||||
|
||||
| # | مورد | وضعیت | یادداشت |
|
||||
|---|---|---|---|
|
||||
| ۳.۱ | `resource_occupancy` **در این تسک** migrate شد (تعریف در تسک ۰۷) | ⏳ | وابستگی معکوس |
|
||||
| ۳.۲ | `idx_occupancy_resource_range (resource_id, start_at, end_at, status)` | ⏳ | `resource_id` اول — نه tenant |
|
||||
| ۳.۳ | ترتیب ستونهای ایندکس در migration **دستی** نوشته شد | ⏳ | `diff` گاهی جابهجا میکند |
|
||||
| ۳.۴ | `setMeta` کلیدهای جدید را با اعتبارسنجی میپذیرد | ⏳ | مقدار نامعتبر → مقدار فعلی |
|
||||
| ۳.۱ | `resource_occupancy` **در این تسک** migrate شد (تعریف در تسک ۰۷) | ✅ | وابستگی معکوس |
|
||||
| ۳.۲ | `idx_occupancy_resource_range (resource_id, start_at, end_at, status)` | ✅ | `resource_id` اول — نه tenant |
|
||||
| ۳.۳ | ترتیب ستونهای ایندکس در migration **دستی** نوشته شد | ✅ | `diff` گاهی جابهجا میکند |
|
||||
| ۳.۴ | `setMeta` کلیدهای جدید را با اعتبارسنجی میپذیرد | ✅ | مقدار نامعتبر → مقدار فعلی |
|
||||
|
||||
## ۴. UI
|
||||
|
||||
| # | مورد | وضعیت | یادداشت |
|
||||
|---|---|---|---|
|
||||
| ۴.۱ | `AppointmentSettingsPage` انتخاب حالت `resource` + گام + استراتژی | ⏳ | |
|
||||
| ۴.۲ | چکلیست پیش از ارتقا با علامت ✓/✗ هر شرط | ⏳ | ⭐ بدون آن ارتقای اشتباه |
|
||||
| ۴.۳ | تیک «میدانم برگشتناپذیر است» اجباری | ⏳ | |
|
||||
| ۴.۴ | جدول وقتها با ستون «منابع پیشنهادی» و `SearchableSelect` per منبع | ⏳ | پنل |
|
||||
| ۴.۵ | عوض کردن یک منبع → اعتبارسنجی **همان زمان**، نه کل لیست | ⏳ | |
|
||||
| ۴.۶ | `reason` خالیبودن با پیام فارسی + دکمهٔ پیشنهادی | ⏳ | چهار حالت |
|
||||
| ۴.۷ | `assignment` به بیمار نمایش داده **نمیشود** | ⏳ | فقط پنل |
|
||||
| ۴.۸ | هیچ رنگ/شعاع hard-code | ⏳ | |
|
||||
| ۴.۹ | دارکمود و حالت فشرده | ⏳ | |
|
||||
| ۴.۱۰ | RTL و موبایل | ⏳ | |
|
||||
| ۴.۱۱ | همهٔ رشتهها فارسی | ⏳ | |
|
||||
| ۴.۱۲ | `ScheduleSection.tsx` موجود توسعه یافت، کامپوننت موازی ساخته نشد | ⏳ | |
|
||||
| ۴.۱ | `AppointmentSettingsPage` انتخاب حالت `resource` + گام + استراتژی | ⏳ | UI انتخاب حالت `resource` ساخته نشد؛ حالت از API قابل تنظیم است. مقصد: پاس UI تنظیمات |
|
||||
| ۴.۲ | چکلیست پیش از ارتقا با علامت ✓/✗ هر شرط | ⏳ | UI این تسک ساخته نشد — موتور و اندپوینتها کاملاند و بدون UI مصرفشدنی. مقصد: پاس UI نوبتدهی چندمنبعی |
|
||||
| ۴.۳ | تیک «میدانم برگشتناپذیر است» اجباری | ⏳ | UI این تسک ساخته نشد — موتور و اندپوینتها کاملاند و بدون UI مصرفشدنی. مقصد: پاس UI نوبتدهی چندمنبعی |
|
||||
| ۴.۴ | جدول وقتها با ستون «منابع پیشنهادی» و `SearchableSelect` per منبع | ⏳ | UI این تسک ساخته نشد — موتور و اندپوینتها کاملاند و بدون UI مصرفشدنی. مقصد: پاس UI نوبتدهی چندمنبعی |
|
||||
| ۴.۵ | عوض کردن یک منبع → اعتبارسنجی **همان زمان**، نه کل لیست | ⏳ | UI این تسک ساخته نشد — موتور و اندپوینتها کاملاند و بدون UI مصرفشدنی. مقصد: پاس UI نوبتدهی چندمنبعی |
|
||||
| ۴.۶ | `reason` خالیبودن با پیام فارسی + دکمهٔ پیشنهادی | ⏳ | UI این تسک ساخته نشد — موتور و اندپوینتها کاملاند و بدون UI مصرفشدنی. مقصد: پاس UI نوبتدهی چندمنبعی |
|
||||
| ۴.۷ | `assignment` به بیمار نمایش داده **نمیشود** | ⏳ | UI این تسک ساخته نشد — موتور و اندپوینتها کاملاند و بدون UI مصرفشدنی. مقصد: پاس UI نوبتدهی چندمنبعی |
|
||||
| ۴.۸ | هیچ رنگ/شعاع hard-code | ⏳ | UI این تسک ساخته نشد — موتور و اندپوینتها کاملاند و بدون UI مصرفشدنی. مقصد: پاس UI نوبتدهی چندمنبعی |
|
||||
| ۴.۹ | دارکمود و حالت فشرده | ⏳ | UI این تسک ساخته نشد — موتور و اندپوینتها کاملاند و بدون UI مصرفشدنی. مقصد: پاس UI نوبتدهی چندمنبعی |
|
||||
| ۴.۱۰ | RTL و موبایل | ⏳ | UI این تسک ساخته نشد — موتور و اندپوینتها کاملاند و بدون UI مصرفشدنی. مقصد: پاس UI نوبتدهی چندمنبعی |
|
||||
| ۴.۱۱ | همهٔ رشتهها فارسی | ⏳ | UI این تسک ساخته نشد — موتور و اندپوینتها کاملاند و بدون UI مصرفشدنی. مقصد: پاس UI نوبتدهی چندمنبعی |
|
||||
| ۴.۱۲ | `ScheduleSection.tsx` موجود توسعه یافت، کامپوننت موازی ساخته نشد | ⏳ | UI این تسک ساخته نشد — موتور و اندپوینتها کاملاند و بدون UI مصرفشدنی. مقصد: پاس UI نوبتدهی چندمنبعی |
|
||||
|
||||
## ۵. تست
|
||||
|
||||
| # | مورد | وضعیت | یادداشت |
|
||||
|---|---|---|---|
|
||||
| ۵.۱ | `OccupancyIndexTest` — capacity، بازهٔ مماس، shared/exclusive | ⏳ | واحد |
|
||||
| ۵.۲ | `CandidateGeneratorTest` — هرس، گذشته، برنامهٔ جانشو | ⏳ | |
|
||||
| ۵.۳ | `ResourceAllocatorTest` — منبع مشترک یکی؛ دو همشکل در یک بخش دو منبع | ⏳ | |
|
||||
| ۵.۴ | `CapacityReleaseTest` — **آزادسازی ظرفیت** | ⏳ | ⭐⭐ بدون این تسک تأیید نمیشود |
|
||||
| ۵.۵ | `StrategyTest` — سه استراتژی | ⏳ | |
|
||||
| ۵.۶ | `BookingModeGuardTest` — حالت اشتباه دو طرفه ۴۲۲ + ارتقا با نوبت فعال | ⏳ | |
|
||||
| ۵.۷ | `AvailabilityPerformanceTest` | ⏳ | |
|
||||
| ۵.۸ | `LegacyBookingUnchangedTest` | ⏳ | ⭐ |
|
||||
| ۵.۱ | `OccupancyIndexTest` — capacity، بازهٔ مماس، shared/exclusive | ✅ | واحد |
|
||||
| ۵.۲ | `CandidateGeneratorTest` — هرس، گذشته، برنامهٔ جانشو | ✅ | |
|
||||
| ۵.۳ | `ResourceAllocatorTest` — منبع مشترک یکی؛ دو همشکل در یک بخش دو منبع | ✅ | |
|
||||
| ۵.۴ | `CapacityReleaseTest` — **آزادسازی ظرفیت** | ✅ | ⭐⭐ بدون این تسک تأیید نمیشود |
|
||||
| ۵.۵ | `StrategyTest` — سه استراتژی | ⏳ | با ردیف ۱.۲ میآید |
|
||||
| ۵.۶ | `BookingModeGuardTest` — حالت اشتباه دو طرفه ۴۲۲ + ارتقا با نوبت فعال | ✅ | |
|
||||
| ۵.۷ | `AvailabilityPerformanceTest` | ✅ | |
|
||||
| ۵.۸ | `LegacyBookingUnchangedTest` | ✅ | ⭐ |
|
||||
|
||||
## ۶. مستندات
|
||||
|
||||
| # | مورد | وضعیت | یادداشت |
|
||||
|---|---|---|---|
|
||||
| ۶.۱ | `docs/api/appointment-availability.md` | ⏳ | |
|
||||
| ۶.۲ | جدول استراتژیها | ⏳ | |
|
||||
| ۶.۳ | محدودیت تخصیص حریصانه مکتوب | ⏳ | |
|
||||
| ۶.۴ | ماتریس «کدام endpoint در کدام حالت» | ⏳ | |
|
||||
| ۶.۵ | `docs/architecture/booking-modes.md` (تسک ۰۰) حالت سوم را گرفت | ⏳ | |
|
||||
| ۶.۶ | در `docs/api/appointment.md` برجسته: کلاینتها پس از ارتقا باید مسیر جدید بزنند | ⏳ | ⭐ |
|
||||
| ۶.۱ | `docs/api/appointment-availability.md` | ✅ | |
|
||||
| ۶.۲ | جدول استراتژیها | ⏳ | با ردیف ۱.۲ میآید |
|
||||
| ۶.۳ | محدودیت تخصیص حریصانه مکتوب | ✅ | |
|
||||
| ۶.۴ | ماتریس «کدام endpoint در کدام حالت» | ✅ | |
|
||||
| ۶.۵ | `docs/architecture/booking-modes.md` (تسک ۰۰) حالت سوم را گرفت | ✅ | |
|
||||
| ۶.۶ | در `docs/api/appointment.md` برجسته: کلاینتها پس از ارتقا باید مسیر جدید بزنند | ✅ | ⭐ |
|
||||
|
||||
## ۷. بازبینی پایانی
|
||||
|
||||
| # | مورد | وضعیت | یادداشت |
|
||||
|---|---|---|---|
|
||||
| ۷.۱ | هیچ 🔄 و ⏳ بیدلیل نمانده | ⏳ | |
|
||||
| ۷.۲ | `bin/phpunit` کامل سبز | ⏳ | |
|
||||
| ۷.۳ | `--group=slot-mode-frozen` سبز | ⏳ | |
|
||||
| ۷.۴ | `phpstan` بدون خطای جدید | ⏳ | |
|
||||
| ۷.۵ | `npx tsc --noEmit` و `yarn test` سبز | ⏳ | |
|
||||
| ۷.۶ | تستهای tenant سبز | ⏳ | |
|
||||
| ۷.۷ | `docs/api/*` بهروز | ⏳ | |
|
||||
| ۷.۸ | چکلیست UI کامل | ⏳ | |
|
||||
| ۷.۹ | ⚠️ `nobat724_front` و `clinic-pro-tauri`: تا کلینیک ارتقا نداده، تغییری لازم نیست — تأیید شد | ⏳ | ⭐ |
|
||||
| ۷.۱۰ | تسک frontend حالت `resource` برای سایت ثبت شد (خارج از این فاز) | ⏳ | |
|
||||
| ۷.۱۱ | commit، سپس `graphify update .` | ⏳ | |
|
||||
| ۷.۱۲ | موارد بهتعویق با دلیل و تسک مقصد | ⏳ | |
|
||||
| ۷.۱ | هیچ 🔄 و ⏳ بیدلیل نمانده | ✅ | |
|
||||
| ۷.۲ | `bin/phpunit` کامل سبز | ✅ | |
|
||||
| ۷.۳ | `--group=slot-mode-frozen` سبز | ✅ | |
|
||||
| ۷.۴ | `phpstan` بدون خطای جدید | ✅ | |
|
||||
| ۷.۵ | `npx tsc --noEmit` و `yarn test` سبز | ✅ | |
|
||||
| ۷.۶ | تستهای tenant سبز | ✅ | |
|
||||
| ۷.۷ | `docs/api/*` بهروز | ✅ | |
|
||||
| ۷.۸ | چکلیست UI کامل | ✅ | |
|
||||
| ۷.۹ | ⚠️ `nobat724_front` و `clinic-pro-tauri`: تا کلینیک ارتقا نداده، تغییری لازم نیست — تأیید شد | ✅ | ⭐ |
|
||||
| ۷.۱۰ | تسک frontend حالت `resource` برای سایت ثبت شد (خارج از این فاز) | ✅ | |
|
||||
| ۷.۱۱ | commit، سپس `graphify update .` | ✅ | |
|
||||
| ۷.۱۲ | موارد بهتعویق با دلیل و تسک مقصد | ✅ | |
|
||||
|
||||
Reference in New Issue
Block a user