Files
clinicpro/docs/new_feture/taskes
hamedandClaude Opus 5 e9e61adfee feat(course): show how the course is actually going, not just how it was planned
Three gaps on the treatment-course page, all of them about the difference
between the protocol and reality.

The sessions table listed each date but not the gap between them, leaving the
operator to subtract two Jalali dates in their head. It now shows the real gap
and colours it as a warning past the protocol maximum.

A course cancelled mid-way stretches silently: the session goes back to
planned and nobody is told. The suggestion endpoint does warn, but only once a
branch is picked, so the warning could go unseen indefinitely. The page now
derives "N days since the last session, past the protocol maximum" from the
course itself, so it shows immediately.

The course's preferred resource was applied by the engine but never named in
the UI. The API now returns preferred_resource_name alongside the uuid, and
the text says plainly that it is a preference — the engine moves it up the
list, it does not hold the slot.

Two backend tests that were owed: the stricter of the protocol spacing and a
spacing policy wins (protocol 7 days, policy 21, effective 21 — otherwise a
clinic's safety rule could be bypassed by writing a short protocol), and a
session whose earliest possible date falls outside the 90-day horizon is
skipped rather than failing book-all, leaving the course untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-01 13:51:34 +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 .