# پرامپت جامع طراحی و پیاده‌سازی «بیوتی پل» — SaaS مدیریت سالن زیبایی

تو در نقش معمار نرم‌افزار، توسعه‌دهنده ارشد Laravel، طراح محصول فارسی و مهندس امنیت عمل کن. یک محصول واقعی، قابل نگهداری، قابل آزمایش و آماده توسعه برای مدیریت چندین سالن زیبایی مستقل بساز. نام موقت محصول «بیوتی پل» است و باید قابل تغییر باشد. هدف تنها داشبورد ظاهری نیست؛ فرایندهای رزرو، فروش، مالی، اشتراک و کنترل دسترسی باید یکپارچه و قابل اعتماد باشند.

## ۱. قرارداد خروجی و روش اجرا

- پیش از کدنویسی، دامنه پروژه، فرض‌ها، ERD، ماتریس دسترسی، نقشه صفحات، قرارداد API و معیارهای پذیرش را ارائه کن. برای تصمیم‌های برگشت‌پذیر با فرض مستند پیش برو؛ مسائل مسدودکننده کسب‌وکار را مشخص کن.
- توسعه را مرحله‌ای انجام بده؛ هر مرحله باید فایل‌های واقعی، migration، seed، تست معنادار و دستور اجرای روشن داشته باشد. به شبه‌کد، TODO به جای منطق اصلی یا صفحات خالی اکتفا نکن.
- نسخه اولیه UI مستقل با HTML معنایی، CSS و JavaScript ساده برای مرور تمام مسیرهای اصلی و داخلی تهیه کن. داده آزمایشی و عملیات شبیه‌سازی‌شده را مشخص کن. سپس UI تأییدشده را به Blade و اجزای قابل استفاده مجدد انتقال بده.
- خروجی نهایی: مخزن پروژه، README فارسی، راهنمای نصب و استقرار، env.example بدون کلید واقعی، مستند نقش‌ها و API، نقشه پایگاه داده، تست‌ها، داده نمایشی، مجوز دارایی‌ها، راهنمای پشتیبان‌گیری و بازیابی.

## ۲. فناوری و معماری

- PHP 8.4 و نسخه پایدار و پشتیبانی‌شده Laravel سازگار با PHP 8.4؛ نسخه و سازگاری همه وابستگی‌ها را هنگام شروع از مستندات رسمی بررسی و در lockfile تثبیت کن. Laravel 13 نامزد فعلی است؛ وابستگی ناسازگار را بدون بررسی نصب نکن.
- معماری Modular Monolith با مرزهای Identity، Tenancy، Authorization، Subscription، Booking، Staff، CRM، Finance، Affiliate، Commerce، CMS، Messaging، Support و Audit.
- Blade برای رندر سمت سرور؛ JavaScript محلی برای تعامل؛ Vite فقط هنگام build، دارایی خروجی در سرور خود پروژه. Livewire یا Alpine فقط در صورت نیاز مستند و به صورت محلی.
- PostgreSQL برای ذخیره پایدار، Redis برای صف و کش و قفل کوتاه‌مدت، Laravel Queue/Scheduler، پردازشگر صف تحت supervisor. مخزن فایل خصوصی برای داده حساس و عمومی برای تصاویر منتشرشده.
- Controllers باریک، FormRequest برای اعتبارسنجی، Policy برای مجوز، Action/Service برای منطق دامنه، Transaction برای تغییرات اتمی، Events و Jobs بعد از commit. از انتزاع‌های بی‌دلیل و Repository عمومی بدون نیاز خودداری کن.
- API نسخه‌بندی‌شده برای مصرف آینده اپلیکیشن؛ pagination، خطای استاندارد، rate limit و احراز هویت مناسب. اسرار پیامک، پرداخت و DNS هرگز در مرورگر نباشند.

## ۳. چندمستاجری و جداسازی اطلاعات

- هر سالن یک Tenant مستقل است. پیش‌فرض یک پایگاه داده مشترک و tenant_id اجباری برای داده‌های متعلق به سالن. داده‌های مدیر SaaS مرکزی هستند.
- Tenant از دامنه تأییدشده یا عضویت معتبر کاربر تعیین شود؛ هرگز صرف tenant_id دریافتی از فرم معتبر محسوب نشود. کاربر چندسالن باید عضویت هر سالن را داشته باشد.
- جداسازی در query، policy، relation، search، export، cache key، queue job، notification، فایل، log و گزارش رعایت شود. Global Scope تنها لایه دفاعی نباشد.
- unique و foreign key مرکب یا قیدهای معادل مانع ارتباط رکورد دو Tenant شوند. Row Level Security در صورت انتخاب PostgreSQL با سناریوهای connection pool و worker بررسی شود.
- Jobها context سالن را صریح حمل و بعد از اجرا پاک کنند. لینک دانلود فایل خصوصی مدت‌دار و دارای بررسی عضویت باشد.
- زیردامنه اختصاصی هر سالن؛ دامنه سفارشی با اثبات مالکیت، TLS، اعتبارسنجی Host و جلوگیری از تصاحب دامنه. slugهای رزروشده و یکتا مدیریت شوند.
- ساخت سالن، آزمایش رایگان، فعال‌سازی، تعلیق، محدودیت مصرف، خروجی اطلاعات، بازیابی و حذف با دوره نگهداری مشخص؛ تعلیق به معنی حذف داده نیست.

## ۴. هویت و سه قلمرو دسترسی

سه قلمرو اصلی داریم، نه سه نقش ثابت. هر قلمرو نقش‌ها و مجوزهای قابل توسعه دارد:
۱) مدیر کل SaaS و همکاران او، از جمله بازاریاب؛ ۲) مدیر سالن و کارکنان؛ ۳) مشتری نهایی.

- نقش و مجوز granular با عملیات مشاهده، ایجاد، ویرایش، حذف، خروجی، تأیید، تسویه و تنظیمات. محدودیت رکوردهای خود/تمام سالن و شعبه در صورت توسعه آتی.
- مدیر کل همکار بسازد، نقش بدهد و دسترسی منو و عملیات را تغییر دهد؛ مدیر سالن فقط در سالن خود و فقط تا سقف مجوز قابل واگذاری کارمند اضافه کند.
- مخفی‌کردن منو صرفاً UX است؛ تمام endpointها و دانلودها باید سمت سرور مجوزسنجی شوند. جلوگیری از privilege escalation، self-demotion آخرین مالک، mass assignment و IDOR الزامی است.
- نقش بازاریاب از مجوز مدیریت مستقل باشد؛ یک همکار می‌تواند هر دو را داشته باشد. بازاریاب به اطلاعات خصوصی مشتریان سالن دسترسی پیش‌فرض ندارد.
- ورود مشتری و کارمند با شماره موبایل و OTP با انقضا، محدودیت تلاش و ارسال، پیام خطای غیرقابل استفاده برای کشف شماره، خروج از دستگاه‌ها. احراز هویت قوی و مرحله دوم برای مدیران و عملیات حساس.
- اعداد فارسی/عربی ورودی normalize شوند؛ موبایل به قالب واحد تبدیل شود. اطلاعات پروفایل، رضایت‌ها و حذف حساب با سیاست نگهداری مالی سازگار باشد.

## ۵. پنل مدیر کل SaaS

- داشبورد: سالن‌های فعال، اشتراک‌های رو به انقضا، درآمد اشتراک، MRR با تعریف شفاف، نرخ ریزش، ثبت‌نام و فروش، سلامت صف پیامک و پرداخت.
- لیست/جست‌وجو/فیلتر سالن‌ها، ثبت، جزئیات، ویرایش، فعال/تعلیق، پلن، صورتحساب و تاریخچه مصرف. مشاهده داده سالن توسط پشتیبان فقط با دسترسی صریح و Audit.
- مدیریت پلن‌ها: دوره ماهانه/سالانه، سقف کارکنان، رزرو، فضای فایل، دامنه و قابلیت‌های مجاز، آزمایش رایگان، کد تخفیف، ارتقا/تنزل و سهم مدت باقی‌مانده با قانون مشخص.
- اشتراک و فاکتور، تراکنش درگاه، بازپرداخت، تمدید، مهلت پرداخت و جلوگیری از قطع ناگهانی داده؛ سهمیه پیامک جدا و شفاف.
- همکاران، دعوت، نقش‌ها، ماتریس دسترسی، تاریخچه تغییر مجوز؛ لغو دعوت و مسدودسازی نشست.
- بازاریاب‌ها، لینک/کد معرف، انتساب سالن، فروش، نرخ پورسانت و دفتر کیف پول، درخواست برداشت و تسویه.
- پشتیبانی و تیکت‌ها، پیام‌های عمومی، تنظیمات برند، درگاه، پیامک، نسخه قالب‌ها، رویدادهای امنیتی و Audit، پایش و گزارش خروجی با محدودیت دسترسی.

## ۶. بازاریابی، پورسانت و تسویه

- قانون انتساب مشخص و قابل تنظیم: معرف معتبر در خرید اول؛ پنجره انتساب، اولویت کد/لینک، تمدید مشمول یا غیرمشمول و منع خودمعرفی. هنگام سفارش قانون و نرخ به صورت snapshot ذخیره شود.
- مبنای محاسبه: مبلغ خالص واقعاً دریافت‌شده بابت اشتراک پس از تخفیف و بدون مالیات/هزینه درگاه، مگر مدیر قانون دیگری تعریف کند. محاسبه با عدد صحیح ریال و rounding تعریف‌شده.
- رویداد webhook تأییدشده پرداخت تنها یک بار اعتبار ایجاد کند. وضعیت pending تا پایان مهلت برگشت، سپس available. برداشت از available به reserved و پس از تأیید پرداخت به settled.
- کیف پول با دفتر append-only و سند دوطرفه یا ledger متوازن؛ مانده از گردش محاسبه یا با آن reconcile شود. تغییر دستی مانده مستقیم ممنوع.
- بازپرداخت کامل/جزئی سند معکوس متناسب بسازد؛ اگر قبلاً تسویه شده، بدهی و سیاست تهاتر مشخص باشد. رکورد تاریخی پورسانت پاک نشود.
- برداشت، حداقل مبلغ، حساب مقصد، تأیید مدیر مجاز، شناسه بانکی و جلوگیری از تسویه تکراری. منظور از «واریز با هر فروش» ابتدا ثبت اعتبار پورسانت است؛ انتقال بانکی فقط پس از فرایند تأیید و اتصال واقعی سرویس پرداخت انجام شود.
- پنل بازاریاب: لینک معرف، فروش‌های منتسب، نرخ هر فروش، موجودی در انتظار/قابل برداشت/تسویه‌شده، درخواست و تاریخچه برداشت. شناسه مشتریان به حداقل لازم محدود شود.

## ۷. مدیریت سالن و کارکنان

- راه‌اندازی گام‌به‌گام سالن: نام، لوگو، درباره، شماره‌ها، آدرس و مختصات، ساعت کار، تعطیلات، قوانین رزرو، خدمات، کارکنان و روش دریافت وجه.
- خدمت دارای دسته، توضیح، مدت، قیمت، بیعانه، buffer قبل/بعد، ظرفیت و کارکنان مجاز؛ تغییر قیمت نباید رزرو قبلی را عوض کند.
- کارکنان: دعوت/پروفایل، تخصص، برنامه هفتگی، مرخصی، استراحت، دسترسی، مشاهده رزروهای خود، پورسانت خدمت و گزارش عملکرد. حذف کارمند دارای سابقه به غیرفعال‌سازی تبدیل شود.
- قانون دستمزد/درصد خدمت و کسورات فقط با سطح مجاز؛ گردش مالی مشتری با تسویه کارکنان و پورسانت بازاریاب SaaS مخلوط نشود.

## ۸. نوبت‌دهی آنلاین

- مسیر: انتخاب خدمت → متخصص یا اولین فرد آزاد → روز شمسی و ساعت → مشخصات و قوانین → بیعانه/پرداخت → تأیید و رسید.
- تقویم روزانه/هفتگی/ماهانه فارسی برای مدیر با فیلتر متخصص و وضعیت؛ لیست، رزرو دستی، جزئیات، تغییر زمان، لغو، عدم مراجعه و ثبت انجام خدمت.
- زمان آزاد از ساعت کار سالن و کارمند، مرخصی، تعطیلی، مدت خدمت و buffer، ظرفیت منابع و رزروهای قطعی/موقت محاسبه شود. تاریخ گذشته، رزرو خارج ساعات و هم‌پوشانی ممنوع.
- نگه‌داشت موقت slot با زمان انقضا؛ پرداخت موفق پس از انقضای slot باید در فرایند reconciliation تعیین تکلیف شود، نه تأیید کورکورانه.
- جلوگیری از double booking با transaction و قفل/قید دیتابیس؛ قفل Redis به تنهایی کافی نیست. درخواست تکراری و callback تکراری idempotent باشد.
- وضعیت‌ها: draft/held، awaiting_payment، confirmed، checked_in، completed، cancelled، no_show، expired؛ transitionها و عامل مجاز روشن باشند. وضعیت پرداخت جدا از وضعیت رزرو است.
- قوانین زمان لغو/تغییر، بازپرداخت بیعانه، حداقل فاصله رزرو و سقف رزرو فعال قابل تنظیم. نمایش هزینه و شرایط قبل از تأیید.
- تمام timestampها UTC ذخیره، با Asia/Tehran نمایش؛ انتخابگر جلالی باید به datetime معتبر تبدیل شود. تاریخ نمایشی شمسی در دیتابیس جایگزین زمان استاندارد نشود.

## ۹. پیامک و اعلان

- Adapter قابل تعویض برای ارائه‌دهنده داخلی؛ کلید فقط سرور؛ ارسال از Queue با backoff، retry محدود، failed job و گزارش delivery.
- قالب OTP، تأیید رزرو، یادآوری مثلاً ۲۴ و ۲ ساعت قبل، تغییر زمان، لغو و رسید. زمان و متن یادآوری قابل تنظیم و با تغییر رزرو باززمان‌بندی شود.
- deduplication key شامل tenant/booking/type/version؛ لغو و تغییر رزرو پیامک قدیمی را بی‌اثر کند. اعتبار حساب/سهمیه و محدودیت ارسال رعایت شود.
- تفکیک پیام خدماتی و تبلیغاتی، رضایت و لغو دریافت تبلیغ؛ ساعات مجاز ارسال. داده حساس و OTP در log خام ثبت نشود.
- صفحه مانده اعتبار، شارژ، قالب‌ها، تاریخچه ارسال/تحویل/خطا، ارسال مجدد مجاز؛ موفقیت API برابر تحویل واقعی به گوشی نیست.

## ۱۰. مشتریان و CRM

- پروفایل هر مشتری در محدوده سالن: اطلاعات تماس، تاریخچه رزرو/خرید، مجموع پرداخت، بدهی، علایق ثبت‌شده، برچسب، یادداشت با دسترسی محدود و رضایت بازاریابی.
- جست‌وجو، فیلتر مشتری جدید/وفادار/غیرفعال، ادغام رکورد تکراری با Audit، import با اعتبارسنجی و export امن.
- پیگیری پس از خدمت، یادآوری مراجعه، تولد شمسی، کمپین برای افراد دارای رضایت، تخفیف و باشگاه امتیاز با ledger مستقل.
- داده‌های حساس مراقبتی فقط با ضرورت، رضایت صریح و حداقل دسترسی؛ جزئیات مشتری سالن دیگر حتی با موبایل یکسان آشکار نشود.

## ۱۱. مالی سالن

- درآمد خدمت و محصول، نقد/کارت/درگاه، هزینه، صندوق، بدهکار/بستانکار مشتری، بیعانه، تخفیف، بازپرداخت و تسویه کارکنان.
- تمام مبالغ در دیتابیس integer ریال؛ UI پیش‌فرض تومان با برچسب ثابت و تبدیل دقیق ×۱۰. floating point برای پول ممنوع.
- فاکتور شماره یکتا و line item با snapshot نام/قیمت/مالیات/تخفیف؛ وضعیت پیش‌نویس/صادرشده/پرداخت‌شده/ابطال و credit note برای اصلاح مالی.
- ثبت پرداخت و سند مرتبط اتمی؛ پرداخت درگاه با امضای callback، استعلام سروربه‌سرور و تطبیق مبلغ/سفارش/ارز/گیرنده. برگشت مرورگر مدرک پرداخت نیست.
- گزارش روزانه/ماهانه شمسی، درآمد هر خدمت/متخصص، روش پرداخت، هزینه و سود با تعریف مشخص، گزارش مقایسه‌ای و CSV/PDF فارسی با فونت محلی.
- این بخش گزارش مدیریتی است؛ ادعای انطباق مالیاتی/حسابداری قانونی بدون بررسی الزامات نداشته باش.

## ۱۲. فروشگاه هر سالن

- محصول، دسته، تصویر محلی، SKU، قیمت، موجودی، حد هشدار، ویژگی/گونه، فعال/ناموجود؛ ledger موجودی برای خرید/فروش/مرجوعی/اصلاح.
- سایت: دسته و فیلتر، جزئیات محصول، سبد، آدرس و روش تحویل حضوری/ارسال، هزینه ارسال، پرداخت، رسید، پیگیری سفارش.
- سبد و سفارش فقط یک Tenant؛ قیمت و موجودی سمت سرور دوباره بررسی شود. رزرو موجودی با انقضا و جلوگیری از overselling در خرید هم‌زمان.
- وضعیت سفارش و وضعیت پرداخت جدا؛ مدیریت آماده‌سازی، تحویل، مرجوعی و بازپرداخت جزئی. محصولات حذف‌شده تاریخچه فاکتور را تغییر ندهند.

## ۱۳. سایت اختصاصی و CMS

- برای هر سالن: خانه، درباره ما، خدمات/جزئیات، تیم/پروفایل، رزرو، فروشگاه/محصول، تماس با ما، نظرات، قوانین و حریم خصوصی، صفحات محتوایی.
- CMS با بلاک‌های محدود و امن: متن، تصویر، خدمات، تیم، گالری و تماس؛ پیش‌نویس/پیش‌نمایش/انتشار، ترتیب منو، عنوان و متا، slug، لوگو و رنگ برند در چارچوب دسترس‌پذیری.
- HTML ورودی sanitize شود؛ اسکریپت دلخواه مشتری مجاز نباشد. آپلود محدود به MIME معتبر، اندازه، اسکن و نام امن؛ SVG کاربر بدون پاکسازی قبول نشود.
- سئوی هر سالن، canonical، sitemap، robots، structured data معتبر و صفحات ۴۰۴؛ جلوگیری از ایندکس پنل‌ها و محتوای خصوصی.
- نقشه تماس: مختصات دقیق قابل تنظیم؛ کتابخانه نقشه و CSS محلی. طبق شرط عدم بارگیری خارجی، داده/کاشی نقشه باید self-hosted یا same-origin سرویس‌دهی شود با مجوز و attribution مناسب. iframe گوگل و CDN ممنوع. در UI اولیه نقشه شماتیک با برچسب نمایشی استفاده شود و ادعای نقشه زنده نشود.
- نظرات فقط پس از خدمت/خرید معتبر، امتیاز، متن، پاسخ سالن، گزارش تخلف، وضعیت moderation و Audit. سیاست انتشار شفاف باشد و صرف امتیاز منفی دلیل حذف نباشد.

## ۱۴. پنل مشتری

- ثبت‌نام/ورود OTP، پروفایل، رزروهای آینده و گذشته، جزئیات و رسید، لغو و تغییر زمان طبق قانون، سفارش‌ها/جزئیات، نشانی‌ها، نظرات خود، امتیاز/اعتبار و تنظیم اعلان.
- در سایت هر سالن فقط عضویت و داده همان سالن نشان داده شود؛ امکان داشبورد سراسری مشتری فقط با طراحی و مجوز صریح آینده.
- امکان بازیابی جریان رزرو پس از ورود و نمایش دقیق تاریخ شمسی/هزینه/بیعانه/باقیمانده.

## ۱۵. طراحی و دسترس‌پذیری

- فارسی کامل، html lang=fa و dir=rtl، چینش راست‌به‌چپ واقعی، CSS logical properties و پشتیبانی درست از موبایل/ایمیل/شناسه لاتین با bidi isolation.
- پس‌زمینه سفید؛ رنگ اصلی گرادینت بنفش #7C3AED تا سرخابی #DB2777 در CTA و هویت؛ سطوح فرعی بسیار روشن، متن تیره خوانا، مرز ظریف و سایه محدود.
- فونت Vazirmatn واقعی با فایل WOFF2 محلی و مجوز همراه؛ هیچ فونت، CSS، JS، آیکون، تصویر یا کتابخانه‌ای از CDN یا origin خارجی در زمان اجرا بارگیری نشود. آیکون SVG محلی، فونت از @font-face داخلی. source و مجوز دارایی‌ها مستند شود.
- اعداد و تاریخ‌ها فارسی و شمسی، واحد مبلغ تومان، روزهای هفته از شنبه؛ ساعت ۲۴ ساعته و timezone تهران. در export ماشینی قالب استاندارد جدا باشد.
- طراحی واکنش‌گرا از ۳۶۰ تا ۱۴۴۰+ پیکسل، sidebar دسکتاپ و drawer موبایل، جدول قابل پیمایش بدون شکستن صفحه، هدف لمسی مناسب.
- keyboard navigation، focus نمایان، label فرم، aria، کنتراست مناسب، feedback خطا نزدیک فیلد، status غیرمتکی به رنگ، modal با مدیریت focus و Escape، رعایت reduced motion.
- برای هر صفحه loading/empty/error/success/permission denied طراحی کن؛ جست‌وجو بدون نتیجه، پرداخت ناموفق، رزرو پرشده، اشتراک منقضی و نبود اعتبار پیامک پوشش داده شود.

## ۱۶. نقشه حداقل صفحات و اجزای داخلی

- عمومی SaaS: معرفی، پلن‌ها و خرید اشتراک، ثبت سالن، ورود و تأیید کد.
- SaaS: داشبورد، سالن‌ها، ایجاد/جزئیات/ویرایش سالن، اشتراک‌ها، پلن‌ها/ویرایش، فاکتورها/جزئیات، پرداخت‌ها، همکاران/دعوت/ویرایش، نقش‌ها/ماتریس، بازاریاب‌ها/جزئیات، کیف پول/فروش/برداشت/تسویه، تیکت/جزئیات، تنظیمات و Audit.
- سالن: داشبورد، تقویم/لیست رزرو، ایجاد/جزئیات/تغییر رزرو، خدمات/ویرایش، کارکنان/پروفایل/برنامه/دسترسی، مشتریان/پروفایل، کمپین‌ها/ساخت، مالی/فاکتور/هزینه/تسویه، محصولات/ویرایش/موجودی، سفارش/جزئیات، CMS/ویرایش/پیش‌نمایش، نظرات/پاسخ، پیامک/قالب/اعتبار، اشتراک، تنظیمات.
- مشتری: داشبورد، رزروها/جزئیات، سفارش‌ها/جزئیات، نظرات، پروفایل/نشانی، اعلان.
- سایت سالن: خانه، خدمات/جزئیات، متخصص، مراحل رزرو و نتیجه، فروشگاه/محصول/سبد/تسویه/نتیجه، درباره، تماس/نقشه، نظرات، محتوا/قوانین.
- مشترک: ۴۰۳، ۴۰۴، ۵۰۰، تعمیرات، حالت خالی، شبکه ناموفق؛ عملیات حذف حساس با تأیید، حذف soft برای موجودیت مناسب و عدم حذف اسناد مالی.

## ۱۷. مدل داده پیشنهادی

Central: users, tenants, domains, memberships, roles, permissions, role_permissions, membership_roles, plans, plan_features, subscriptions, subscription_invoices, payments, refunds, affiliate_profiles, referrals, commissions, wallet_accounts, ledger_entries, payout_requests, support_tickets, audit_logs.
Tenant: salon_profiles, staff_profiles, staff_services, services, service_categories, working_hours, breaks, leaves, closures, customers, customer_consents, customer_tags, customer_notes, appointments, appointment_items, appointment_status_events, slot_holds, invoices, invoice_items, receipts, expenses, staff_commissions, products, product_variants, inventory_movements, stock_reservations, carts, orders, order_items, addresses, reviews, cms_pages, cms_blocks, media, notification_templates, message_logs, campaigns, loyalty_entries.

- برای هر جدول مالکیت، FK، index، unique، حساسیت اطلاعات، چرخه عمر و retention را مشخص کن؛ مدل را مطابق نیاز ساده نگه دار.
- همه اسناد مالی immutable یا دارای سند اصلاحی؛ وضعیت‌ها enum روشن و تاریخچه transition. optimistic locking برای ویرایش هم‌زمان تنظیمات/محتوا در صورت نیاز.

## ۱۸. امنیت، بهره‌برداری و کیفیت

- CSRF، XSS، SQL injection، IDOR، SSRF، upload، session fixation و brute force را پوشش بده. Content Security Policy با منابع خودی، کوکی امن HttpOnly و SameSite و TLS.
- داده شخصی و کلیدها رمزنگاری مناسب و logها redacted؛ audit actor/tenant/action/subject/time/request_id و before/after محدود و امن داشته باشد.
- backup رمزنگاری‌شده، restore تمرین‌شده، migration برگشت‌پذیر یا forward fix مستند، health check، صف ناموفق، هشدار payment mismatch و پایش خطا.
- لیست‌ها pagination و eager loading؛ کش tenant-scoped، ایندکس هدفمند و اندازه‌گیری queryها. SLA و هدف کارایی را به عنوان فرض قابل اندازه‌گیری اعلام کن.
- import/export بزرگ در queue، لینک کوتاه‌عمر، جلوگیری از CSV formula injection؛ secrets و اطلاعات واقعی مشتری وارد seed نشوند.

## ۱۹. معیارهای پذیرش اجباری

۱. کاربر سالن الف با دستکاری شناسه یا URL به داده/فایل/گزارش سالن ب دسترسی نداشته باشد؛ تست خواندن، نوشتن، export و queue.
۲. حذف دسترسی عملیات در backend اعمال شود حتی با درخواست مستقیم؛ تغییر نقش کارمند از سقف مدیر واگذارکننده بیشتر نشود.
۳. دو رزرو هم‌زمان برای یک متخصص/بازه فقط یک موفقیت داشته باشند؛ مرخصی، buffer و پرداخت دیررس تست شود.
۴. callback تکراری پرداخت یک فاکتور/پورسانت/گردش موجودی ایجاد کند؛ مبلغ نامعتبر رد و ثبت شود.
۵. refund جزئی و کامل، ledger پورسانت و صندوق را درست اصلاح کند؛ درخواست برداشت هم‌زمان موجودی را منفی نکند.
۶. لغو یا تغییر رزرو پیامک قدیمی نفرستد؛ retry باعث ارسال تکراری نشود.
۷. فروش هم‌زمان آخرین موجودی oversell نکند؛ سبد دو سالن ترکیب نشود.
۸. تاریخ‌های انتهای اسفند، سال کبیسه، تبدیل جلالی، تهران/UTC و مرز روز تست شوند.
۹. تمام صفحات روی موبایل/دسکتاپ، کیبورد، بزرگنمایی ۲۰۰٪ و بدون درخواست دارایی خارجی قابل استفاده باشند.
۱۰. جریان کامل ثبت سالن→خرید پلن→تعریف خدمت/کارمند→رزرو مشتری→پرداخت→یادآوری→انجام خدمت→فاکتور→نظر و جریان فروش محصول با تست E2E پوشش داده شود.

## ۲۰. ترتیب تحویل

فاز A: UI تمام صفحه‌های ذکرشده، داده نمایشی، نقشه مسیر و بازبینی تجربه.
فاز B: هویت، tenant، مجوز، خدمات، کارکنان و رزرو با تست جداسازی/هم‌زمانی.
فاز C: پرداخت، مالی، پیامک و اشتراک با webhook قابل اعتماد.
فاز D: CRM، CMS، فروشگاه، نظرات و سایت هر سالن.
فاز E: بازاریاب، پورسانت، تسویه، گزارش، سخت‌سازی و استقرار.
در پایان هر فاز، دقیقاً بگو چه چیزی واقعی و قابل استفاده است، چه چیزی شبیه‌سازی‌شده است و چه مواردی باقی مانده‌اند. هیچ اتصال به سرویس بیرونی را بدون کلید و آزمون واقعی «فعال» اعلام نکن.