hamed
158dcb58aa
- Add task for completing service mode in clinicpro with detailed objectives and acceptance criteria. - Create architecture documentation for task 00b, outlining involved components and necessary changes. - Develop checklist for task 00b to ensure all requirements are met. - Document implementation notes for task 00b, emphasizing API contract checks and design system adherence. - Update task documentation for task 00b, specifying goals and current issues with service mode.
تسکهای موتور نوبتدهی چندمنبعی Clinic Pro
پیادهسازی تدریجی clinic-pro-mostanad-sade.md روی کد موجود. گزارش وضعیت فعلی و تحلیل شکاف: 00-current-state-report.md
پیشفرض کلیدی: بازنویسی نداریم. نوبتدهی اسلاتی (
booking_mode=slot) و نوبتدهی سرویسیِ فعلی (booking_mode=service) تا آخر این مسیر بدون تغییر رفتار کار میکنند. حالت جدیدbooking_mode=resourceکنارشان اضافه میشود.
لیست تسکها
| تسک | ماژول | Endpoint جدید | وابستگی | زمان |
|---|---|---|---|---|
| ۰۱ | شعبه و اتاق | ۸ | — | ۱۰-۱۲h |
| ۰۲ | منبع، نوع منبع، مهارت، استخر | ۱۴ | ۰۱ | ۱۴-۱۸h |
| ۰۳ | تقویم منبع، مرخصی، تعطیلات ملی | ۹ | ۰۱، ۰۲ | ۱۲-۱۴h |
| ۰۴ | کاتالوگ خدمات v2 (گروه آیتم، دو نوع زمان) | ۱۰ | ۰۱ | ۱۴-۱۶h |
| ۰۵ | بخشهای نوبت و سازندهٔ برنامه | ۳ | ۰۲، ۰۴ | ۱۶-۲۰h |
| ۰۶ | موتور جستجوی وقت چندمنبعی | ۲ | ۰۳، ۰۵ | ۲۰-۲۴h |
| ۰۷ | رزرو موقت و ثبت نهایی چندمنبعی | ۴ | ۰۶ | ۱۶-۲۰h |
| ۰۸ | لیست قیمت بازهدار و snapshot فاکتور | ۷ | ۰۴، ۰۷ | ۱۲-۱۴h |
| ۰۹ | موتور قوانین ششدستهای | ۶ | ۰۵، ۰۶، ۰۸ | ۲۰-۲۴h |
| ۱۰ | فرم ساخت قانون + محیط آزمایش | ۲ | ۰۹ | ۱۰-۱۲h |
| ۱۱ | پکیج و دفتر اعتبار جلسات | ۸ | ۰۸ | ۱۰-۱۲h |
| ۱۲ | دوره درمان | ۹ | ۰۷، ۱۱ | ۱۶-۲۰h |
| ۱۳ | سیاست لغو، عدم حضور، لیست انتظار | ۷ | ۰۷ | ۱۰-۱۲h |
| ۱۴ | رویدادهای دامنه و گزارش بهرهوری | ۳ | ۰۷ | ۸-۱۰h |
مجموع endpoint جدید: ~۹۲ · مجموع زمان: ۱۹۰ تا ۲۲۸ ساعت
ساختار هر تسک
task-XX-name/
├── task.md ← شرح، دامنه، endpoint ها، معیار پذیرش، زمان
├── architecture.md ← فایلها، entity ها، سرویسها، لایهها
├── database.md ← جداول، ستونها، ایندکسها، migration
├── implementation_notes.md ← نکات فنی، edge case، سازگاری عقبرو، تست
└── user_flow.md ← (تسکهای پیچیده) جریان کاربری
ترتیب پیشنهادی اجرا
۰۱ ─┬─ ۰۲ ── ۰۳ ─┐
└─ ۰۴ ── ۰۵ ─┴─ ۰۶ ── ۰۷ ─┬─ ۰۸ ─┬─ ۰۹ ── ۱۰
│ └─ ۱۱ ── ۱۲
├─ ۱۳
└─ ۱۴
فاز اول (هستهٔ قابل عرضه): ۰۱ تا ۰۸ — بعد از آن یک کلینیک زیبایی با اتاق، دستگاه و اپراتور میتواند واقعاً نوبت بگیرد.
قواعد مشترک همهٔ تسکها
قواعد پروژه در CLAUDE.md و docs/architecture/tenancy.md بر همهٔ این تسکها حاکماند. مواردی که در هر تسک باید رعایت شوند:
- هر entity جدید یا
TenantOwnedTraitمیگیرد یا درGlobalTablesبا دلیل ثبت میشود؛TenantSchemaCoverageTestرا اجرا کن. entity_type, entity_idستونهای اول هر ایندکس ترکیبی لیست.- هر uuid که از request میآید باید با
TenantOwnershipCheckerسنجیده شود؛TenantLookupInventoryTestشمارنده دارد. - timestamp ها
int(Unix)، نهDateTime. نمایش شمسی فقط در UI. - کنترلر نازک،
extends BaseController، پاسخ باsuccess()/paginated()/error(). - هر endpoint جدید یا تغییر یافته → بهروزرسانی
docs/api/*.mdدر همان نشست. - تست موفق + خطا + مرزی برای هر تسک، وگرنه تسک تمام نیست.
- رشتههای UI فارسی، کد و کامیت انگلیسی.
- سازگاری عقبرو:
nobat724_frontوclinic-pro-tauriمصرفکنندهٔ همین APIها هستند و در build خطا نمیدهند — هر تغییر قرارداد باید دستی بررسی شود.
سازگاری با نوبتدهی فعلی
| حالت | منبع تنظیم | چه زمانی |
|---|---|---|
slot |
WeeklySchedule.meta.booking_mode |
اسلات ثابت duration_per_patient — رفتار پیشفرض امروز |
service |
همان | طول = جمع مدت سرویسها + buffer — پیادهشده، تکمنبعی |
resource |
همان | جدید — برنامهٔ چندبخشی + چند منبع (تسک ۰۵ به بعد) |
booking_mode پس از اولین ثبت قفل میشود (WeeklySchedule::getStoredBookingMode()).
تسک ۰۶ باید مسیر ارتقای داوطلبانهٔ service → resource را باز کند، بدون اجبار.