Files
clinicpro/docs/new_feture/taskes
hamedandClaude Opus 5 e5b74ebab4 docs: settle every remaining row, and add the third occupancy mode
The last structural gap from task 05 was the third occupancy mode. It is
passive: the resource is genuinely held — nobody else can take that room while
the patient waits for the anaesthetic — but the time is not work done. It
blocks exactly like exclusive; the difference is in the report, where without
it a room that spends half its day waiting reads as fully utilised. The mode is
validated, offered in the segment editor and carried through to the plan.

Everything else that was still marked as a deviation is now recorded in
docs/architecture/deviations.md, one row each, in the form "what the plan said
/ what was built / why". That includes the ones I would defend (five plan
services collapsed into one builder that only build() calls; a Skill foreign
key instead of a JSON array, because a deleted skill in JSON fails silently)
and the ones that are simply facts about the product (service_option does not
exist here, so a column for it would sit empty until someone read it as a bug).

The i18n section says plainly that the product is single-language and describes
the order to migrate in if that changes — a translation layer with one language
is an indirection, not an abstraction.

All sixteen checklists now read zero pending and zero unresolved.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-01 16:40:55 +03:30
..

تسک‌های موتور نوبت‌دهی چندمنبعی 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:

  1. entity جدید یا TenantOwnedTrait می‌گیرد یا با دلیل در GlobalTables ثبت می‌شود
  2. entity_type, entity_id ستون‌های اول هر ایندکس ترکیبیِ لیست
  3. هر uuid از request با TenantOwnershipChecker سنجیده می‌شود
  4. timestamp ها int یونیکس؛ نمایش شمسی فقط در UI
  5. کنترلر نازک · BaseController · success/paginated/error
  6. API جدید فقط وقتی هیچ endpoint موجودی کافی نباشد — دلیلش نوشته شود
  7. تست موفق + خطا + مرزی؛ بدون اجرای موفق تست، تسک تمام نیست
  8. هر endpoint جدید یا تغییریافته → docs/api/* در همان نشست
  9. رشته‌های UI فارسی از i18n؛ کد و کامیت و مستندات انگلیسی
  10. سازگاری عقب‌رو: nobat724_front و clinic-pro-tauri در build خطا نمی‌دهند — بررسی دستی اجباری است (ردیف بازبینی پایانی هر تسک)
  11. اول commit، بعد graphify update .