hamedandClaude Opus 5
22c89fbae4
Section 7 of the design document, and the reason the whole resource layer exists. A laser session is not one block: numbing cream (5 min, room + operator), waiting for it to work (30 min, room only), the laser itself (20 min, room + operator + device), aftercare (5 min, room + operator). Under the single-interval model the operator is locked for all 60 minutes while actually working 30 — half the capacity thrown away. AppointmentPlanBuilder turns (service, selected items, branch, patient) into a plan: segments with offsets, durations and resource requirements. It deliberately assigns no absolute time and no specific resource — that is the next task. This only produces the *shape* of the appointment. Segment duration comes from one of two sources. A fixed segment carries its own number; an item-driven one gets its duration from task 04's DurationCalculator, so "the laser itself" grows with two treated areas while "waiting for the cream" does not. One number could not have expressed that. Three contracts worth stating: - A service with no segment templates falls back to a single continuous segment requiring the doctor resource — exactly today's behaviour. Without it every existing service would have become unplannable overnight. - A segment with no requirements is valid: "waiting at home" consumes time but occupies nothing. - same_gender_as_patient with an unknown patient gender is a 422, not a silently dropped requirement. Dropping it quietly would route the patient to a resource the clinic said must not serve them. When no resource qualifies, the error names the role, the skill and the branch — "no female operator with the skill «Alexandrite laser» is available at «Central»" — rather than an empty result the caller has to interpret (section 10). occupancy_offset carries each requirement's setup/cleanup minutes for the availability engine. It is taken as the maximum across candidates, because the builder does not yet know which resource will be picked and under-reserving means the next appointment lands on top of the cleanup. 11 tests covering the document's reference example (offsets 0/5/35/55, total 60), item-driven scaling, the no-template fallback, all three gender-constraint outcomes, merging and both caps. 1186 tests overall. phpstan back at its 14-error baseline; slot-mode frozen contract green. The admin segments page is not built; the checklist records it with a target. The backend and preview endpoint are complete and consumable without it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
تسکهای موتور نوبتدهی چندمنبعی Clinic Pro
پیادهسازی تدریجی clinic-pro-mostanad-sade.md روی کد موجود. گزارش وضعیت فعلی و تحلیل شکاف: 00-current-state-report.md
⛔ سه قاعدهای که پیش از هر تسکی باید بخوانی
| سند | چه میگوید |
|---|---|
| _shared/red-lines.md | منطق اسلاتی به هیچ عنوان دستکاری نمیشود · نوبتدهی سرویسی در همین فاز کامل میشود |
| _shared/ui-conventions.md | هر صفحه یا بخش جدید عیناً با دیزاینسیستم موجود — هیچ طراحی جدید |
| _shared/definition-of-done.md | هیچ تسکی بدون تکمیل چکلیستش تمام نیست — ✅ 🔄 ⏳ ⚠️ |
در تناقض، این سه سند بر متن تسکها برندهاند.
لیست تسکها
فاز ۰ — تثبیت وضعیت فعلی (پیشنیاز بقیه)
| تسک | ماژول | پروژه | Endpoint | وابستگی | زمان |
|---|---|---|---|---|---|
| ۰۰ | تکمیل نوبتدهی سرویسی | clinicpro |
۴ | — | ۱۴-۱۸h |
| ۰۰ب | سازگارسازی سایت عمومی | nobat724_front |
— | ۰۰ | ۱۰-۱۴h |
فاز ۱ — هستهٔ چندمنبعی
| تسک | ماژول | Endpoint | وابستگی | زمان |
|---|---|---|---|---|
| ۰۱ | شعبه و اتاق | ۸ | ۰۰ | ۱۰-۱۲h |
| ۰۲ | منبع، نوع منبع، مهارت، استخر | ۱۴ | ۰۱ | ۱۴-۱۸h |
| ۰۳ | تقویم منبع، مرخصی، تعطیلات ملی | ۹ | ۰۱، ۰۲ | ۱۲-۱۴h |
| ۰۴ | کاتالوگ خدمات v2 (گروه آیتم، دو نوع زمان) | ۱۰ | ۰۱ | ۱۴-۱۶h |
| ۰۵ | بخشهای نوبت و سازندهٔ برنامه | ۳ | ۰۲، ۰۴ | ۱۶-۲۰h |
| ۰۶ | موتور جستجوی وقت چندمنبعی | ۲ | ۰۳، ۰۵ | ۲۰-۲۴h |
| ۰۷ | رزرو موقت و ثبت نهایی چندمنبعی | ۴ | ۰۶ | ۱۶-۲۰h |
| ۰۸ | لیست قیمت بازهدار و snapshot فاکتور | ۷ | ۰۴، ۰۷ | ۱۲-۱۴h |
فاز ۲ — قوانین
| تسک | ماژول | Endpoint | وابستگی | زمان |
|---|---|---|---|---|
| ۰۹ | موتور قوانین ششدستهای | ۶ | ۰۵، ۰۶، ۰۸ | ۲۰-۲۴h |
| ۱۰ | فرم ساخت قانون + محیط آزمایش | ۲ | ۰۹ | ۱۰-۱۲h |
فاز ۳ — کسبوکار
| تسک | ماژول | Endpoint | وابستگی | زمان |
|---|---|---|---|---|
| ۱۱ | پکیج و دفتر اعتبار جلسات | ۸ | ۰۸ | ۱۰-۱۲h |
| ۱۲ | دوره درمان | ۹ | ۰۷، ۱۱ | ۱۶-۲۰h |
| ۱۳ | سیاست لغو، عدم حضور، لیست انتظار | ۷ | ۰۷ | ۱۰-۱۲h |
فاز ۴ — بهینهسازی
| تسک | ماژول | Endpoint | وابستگی | زمان |
|---|---|---|---|---|
| ۱۴ | رویدادهای دامنه و گزارش بهرهوری | ۳ | ۰۷ | ۸-۱۰h |
مجموع endpoint جدید: ~۹۶ · مجموع زمان: ۲۱۴ تا ۲۵۶ ساعت
ساختار هر تسک
task-XX-name/
├── task.md ← شرح، دامنه، endpoint ها، معیار پذیرش، زمان
├── architecture.md ← فایلها، entity ها، سرویسها، لایهها، قواعد UI
├── database.md ← جداول، ستونها، ایندکسها، migration
├── implementation_notes.md ← نکات فنی، edge case، سازگاری عقبرو، تست
├── checklist.md ← ☑️ وضعیت هر مورد: ✅ 🔄 ⏳ ⚠️
└── user_flow.md ← (تسکهای پیچیده) جریان کاربری
checklist.md اجباری است و ساختار ثابتی دارد:
۰. خط سرخها ۱. بکاند ۲. دیتابیس ۳. UI ۴. تست ۵. مستندات ۶. بازبینی پایانی
چکلیست — قواعد
| نماد | معنی | اجازهٔ باقیماندن در پایان تسک |
|---|---|---|
| ✅ | انجامشده و تأییدشده | بله |
| 🔄 | در حال انجام | نه |
| ⏳ | انجامنشده | نه — مگر با دلیل مکتوب و تسک مقصد |
| ⚠️ | نیازمند بررسی یا تست | نه — باید تعیین تکلیف شود |
پیش از پایان هر تسک، همهٔ ردیفهای چکلیست بازبینی میشوند و وضعیت نهایی میگیرند. هر تسک بخش «۶. بازبینی پایانی» دارد که تستها، مستندات، UI و دو کلاینت دیگر را میسنجد.
ترتیب پیشنهادی اجرا
۰۰ ── ۰۰ب
│
├─ ۰۱ ─┬─ ۰۲ ── ۰۳ ─┐
│ └─ ۰۴ ── ۰۵ ─┴─ ۰۶ ── ۰۷ ─┬─ ۰۸ ─┬─ ۰۹ ── ۱۰
│ │ └─ ۱۱ ── ۱۲
│ ├─ ۱۳
│ └─ ۱۴
فاز ۰ اختیاری نیست. اگر حالت resource (تسک ۰۶) روی حالت service نیمهکاره ساخته
شود، هر باگ موجود سرویسی به موتور جدید ارث میرسد و تشخیص منبعش غیرممکن میشود.
فاز اول قابل عرضه: ۰۰ تا ۰۸ — بعد از آن یک کلینیک زیبایی با اتاق، دستگاه و اپراتور میتواند واقعاً نوبت بگیرد.
سه حالت نوبتدهی
| حالت | مقدار WeeklySchedule.meta.booking_mode |
وضعیت |
|---|---|---|
| اسلاتی | slot |
⛔ قفل — پیشفرض، تولیدی، دستنخورده |
| سرویسی | service |
🔄 موجود ولی نیمهکاره → تسک ۰۰ و ۰۰ب کاملش میکنند |
| چندمنبعی | resource |
⏳ جدید — تسک ۰۶ به بعد |
booking_mode پس از اولین ثبت قفل میشود (WeeklySchedule::getStoredBookingMode()).
تسک ۰۶ یک استثنای کنترلشده اضافه میکند: ارتقای یکطرفه از slot/service به
resource، مشروط بر نبودِ نوبت فعال آینده. بازگشت ممنوع.
ماتریس کامل «کدام endpoint در کدام حالت» در docs/architecture/booking-modes.md
(تسک ۰۰ میسازد، تسک ۰۶ حالت سوم را اضافه میکند).
اجبار خودکار خط سرخ
هر تسک باید این را سبز نگه دارد:
ddev exec php bin/phpunit --group=slot-mode-frozen
تسک ۰۰ این تست و سه fixture آن را میسازد. fixture ها بعد از آن read-only اند: اگر تستی قرمز شد، کد باید برگردد، نه fixture.
قواعد مشترک همهٔ تسکها
از CLAUDE.md و docs/architecture/tenancy.md. فهرست کامل در _shared/definition-of-done.md:
- entity جدید یا
TenantOwnedTraitمیگیرد یا با دلیل درGlobalTablesثبت میشود entity_type, entity_idستونهای اول هر ایندکس ترکیبیِ لیست- هر uuid از request با
TenantOwnershipCheckerسنجیده میشود - timestamp ها
intیونیکس؛ نمایش شمسی فقط در UI - کنترلر نازک ·
BaseController·success/paginated/error - API جدید فقط وقتی هیچ endpoint موجودی کافی نباشد — دلیلش نوشته شود
- تست موفق + خطا + مرزی؛ بدون اجرای موفق تست، تسک تمام نیست
- هر endpoint جدید یا تغییریافته →
docs/api/*در همان نشست - رشتههای UI فارسی از i18n؛ کد و کامیت و مستندات انگلیسی
- سازگاری عقبرو:
nobat724_frontوclinic-pro-tauriدر build خطا نمیدهند — بررسی دستی اجباری است (ردیف بازبینی پایانی هر تسک) - اول commit، بعد
graphify update .