Files
clinicpro/docs/new_feture/taskes
hamedandClaude Opus 5 4bca659939 feat(admin): price lists and the appointment invoice card
Task 08's pricing chain was reachable only through the API, so a clinic could
not define a price list or see what a booked appointment was actually charged.

Price lists
- Draft / active / expired are shown as three states because they mean three
  different things operationally: a draft has no effect on today's price at all
- Activation is a separate action rather than a checkbox in the form, matching
  the backend rule that creating a list must not change anything
- "Copy" seeds a new list from an existing one starting the day the old one
  ends, since most lists are last quarter's with a few numbers moved
- "All branches" is an explicit option, not an empty field

Invoice card
- Renders the recorded chain down to the final amount, hiding zero rows so the
  card stays readable
- A missing invoice renders as a normal state, not an error: an appointment
  that was never confirmed has no invoice
- Says outright that the numbers are from the appointment's own date and later
  tariff changes do not move them — otherwise someone who edited a price
  yesterday reads today's older number as a bug

Also corrects task 08's checklist: its test section carried a copy-pasted "no
UI was built" note against rows whose tests have existed since the task
shipped. Replaced with the real test names and the two that genuinely are not
covered.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-31 19:58:29 +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 .