# پرامپت جامع طراحی و توسعه «باشگاه مشتریان سایت ساز زرین»

نسخهٔ ۱ — سند قابل‌کپی برای ارائه به تیم توسعه یا دستیار برنامه‌نویسی

این سند شامل نیازمندی‌های اعلام‌شده و پیشنهادهای تکمیلی برای رفع ابهام‌های اجرایی است. مواردی که با «پیش‌فرض پیشنهادی» مشخص شده‌اند، تصمیم قطعی کسب‌وکار نیستند. قیمت‌ها باید توسط مدیر تعیین شوند. متن زیر را به‌عنوان دستور کار پروژه استفاده کن.

---

## ۱. نقش تو، هدف محصول و روش شروع

در نقش تحلیلگر محصول، طراح تجربه کاربری و توسعه‌دهنده ارشد، سامانه‌ای تحت وب با نام دقیق «باشگاه مشتریان سایت ساز زرین» طراحی کن. این سامانه محل ارتباط مشتریان با مجموعه زرین، مدیریت پروژه‌های منتورینگ سایت‌های وردپرسی، دریافت اطلاعات راه‌اندازی سایت، پیگیری خدمات، خرید خدمات تکمیلی و کسب امتیاز وفاداری است.

مخاطب اصلی، مشتری غیرمتخصص است؛ کسی که ممکن است با وردپرس، ووکامرس، دسته‌بندی، ویژگی محصول یا تنظیمات سایت آشنا نباشد. مشتری باید بداند اکنون چه کاری انجام دهد، چرا این اطلاعات لازم است، مسئول پروژه‌اش کیست و چقدر از زمان خدمت باقی مانده است.

در پاسخ نخست وارد کدنویسی نشو. ابتدا نیازمندی‌ها، پیشنهادهای قابل‌تغییر، گردش کار، نقشه صفحات، مدل داده و معیارهای پذیرش را ارائه کن. فقط ابهام‌های واقعاً مؤثر و حل‌نشده را سؤال کن. پس از تأیید طرح توسط کارفرما وارد پیاده‌سازی شو. هیچ قابلیت درخواستی را بدون اعلام از محدوده حذف نکن.

اصل محصول: دریافت مرحله‌ای اطلاعات، انجام کار توسط کارکنان، مشاهده پیشرفت توسط مشتری و ثبت قابل‌پیگیری همه تعاملات. اتصال خودکار به وردپرس و انتشار مستقیم اطلاعات، قابلیت جداگانه‌ای است و در نسخه اولیه فرض نشود؛ در نسخه اولیه منتور اطلاعات را دریافت و در سایت مشتری درج می‌کند و نتیجه را ثبت می‌کند.

## ۲. محدوده و ماژول‌ها

ماژول‌های اصلی عبارت‌اند از: عضویت و ورود، کاربران و نقش‌ها، بخش‌های سازمانی، مشتریان، منتورها، پلن‌های منتورینگ، پروژه‌ها و دوره‌های خدمت، فرم مرحله‌ای اطلاعات سایت، محصولات، فایل‌ها، وظایف و فعالیت‌ها، تیکت‌ها، پیامک و اعلان‌ها، سفارش‌ها و پرداخت‌ها، طراحی لوگو، تمدید منتورینگ، نظرسنجی و امتیازهای باشگاه.

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

## ۳. نقش‌ها و دسترسی‌ها

چهار نقش اصلی تعریف کن: مدیر سامانه، مدیر داخلی، منتور/کارمند و مشتری. نقش کارمند با ثبت‌نام عمومی فعال نشود. دسترسی‌ها هم در رابط و هم در سرور، درخواست‌ها، جست‌وجو، خروجی‌ها و دریافت فایل اعمال شوند.

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

پیش‌فرض پیشنهادی: یک هویت یکتا برای هر شماره موبایل؛ افزودن نقش دوم فقط توسط مدیر. برای کارمندی که خودش مشتری نیز هست، محیط کاری و محیط مشتری با تغییر نمای مشخص جدا شود. نقش‌های مدیریتی به‌طور ناخواسته مشمول محدودیت‌های مشتری یا منتور نشوند.

## ۴. ثبت‌نام، ورود و حساب کاربری

- مشتری با نام و نام خانوادگی و موبایل ثبت‌نام کند؛ ایمیل و نام کسب‌وکار قابل‌تکمیل باشند. مالکیت موبایل با رمز یکبار مصرف تأیید شود.
- ورود برای مشتریان و کارکنان از دو روش «موبایل و رمز ثابت» و «موبایل و رمز یکبار مصرف» پشتیبانی کند. بازیابی رمز ثابت با تأیید مالکیت موبایل انجام شود.
- کارکنان بتوانند درخواست عضویت ثبت کنند یا از طریق دعوت مدیر وارد شوند. حساب در انتظار تأیید، به پروژه‌ها و اطلاعات کارکنان دسترسی نداشته باشد. کاربر نتواند از فرم ثبت‌نام، نقش مدیر یا منتور فعال بگیرد.
- مدیر بتواند مشتری ایجاد کند و پیام دعوت بفرستد؛ اتصال حساب به مشتری ایجادشده فقط بعد از تأیید موبایل انجام شود. رمز ثابت در پیامک ارسال نشود.
- پیش‌فرض پیشنهادی OTP: اعتبار ۳ دقیقه، فاصله درخواست مجدد ۶۰ ثانیه، حداکثر ۵ تلاش برای هر کد، محدودیت ارسال بر اساس شماره و IP. مقادیر قابل‌تنظیم باشند و کد مصرف‌شده یا قدیمی دوباره پذیرفته نشود.
- شماره‌های فارسی، عربی و انگلیسی و قالب‌های متداول موبایل به یک قالب داخلی یکتا تبدیل شوند. پیام خطا، وضعیت ارسال و زمان درخواست مجدد روشن باشد.
- حساب غیرفعال، کارمند تأییدنشده و مشتری فاقد پروژه، صفحه مناسب خود را ببینند. عدم دریافت پیامک نباید باعث از دست‌رفتن روش ورود با رمز ثابت شود.
- تغییر موبایل و عملیات حساس حساب نیازمند احراز هویت مجدد باشد. کاربر امکان مشاهده و خروج از نشست‌های فعال را داشته باشد.

## ۵. تعریف بخش‌ها و پلن‌های منتورینگ

مدیر سامانه بتواند بخش‌های سازمانی، کارکنان هر بخش و مجوز مدیر داخلی را تعریف کند. نمونه بخش‌ها صرفاً پیشنهادی‌اند: منتورینگ سایت، محتوا، طراحی گرافیک و پشتیبانی.

برای هر پلن این موارد تعریف شود:

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

پلن‌های نمایشی مانند «شروع»، «رشد» و «حرفه‌ای» قابل‌تعریف باشند؛ هیچ قیمت یا تعهدی به‌عنوان تعرفه واقعی زرین اختراع نشود. پلن بدون قیمت معتبر برای پرداخت عمومی فعال نشود.

مشخص کن «یک محصول» و «یک تنوع محصول» چگونه شمرده می‌شوند. پیش‌فرض پیشنهادی: محصول والد یک واحد محصول است و ترکیب‌های قابل‌خرید آن از سهمیه تنوع مصرف می‌کنند. تعداد ارسالی، تأییدشده، درج‌شده و باقی‌مانده جدا نمایش داده شوند. درج‌کردن کمتر از سقف، مجاز باشد؛ سقف پلن حداقل اجباری نیست.

نسخه پلن و تعهدات هنگام تخصیص یا خرید در دوره خدمت ثبت شود. تغییر تعرفه یا حذف پلن، تعهد پروژه‌ها و سفارش‌های موجود را عوض نکند. پلن دارای سابقه، غیرفعال/بایگانی شود.

## ۶. ساخت و ارجاع پروژه

دو مسیر ایجاد پروژه وجود داشته باشد:

۱. مدیر سامانه یا مدیر داخلی مشتری را انتخاب و پروژه را مستقیماً تعریف و فعال می‌کند.

۲. مشتری پس از ثبت‌نام درخواست پروژه منتورینگ ثبت می‌کند. درخواست شامل نام پروژه/کسب‌وکار، آدرس سایت در صورت وجود و توضیح کوتاه است. پیش‌فرض پیشنهادی: تخصیص پلن استحقاقی، مسئول و تاریخ خدمت با تأیید مدیر انجام شود؛ ثبت درخواست به‌تنهایی خدمت رایگان یا تاریخ قطعی ایجاد نکند.

فرم مدیریتی ایجاد پروژه شامل موارد زیر باشد:

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

هر مشتری بتواند چند پروژه مستقل داشته باشد و میان آن‌ها جابه‌جا شود. هر پروژه یک مسئول اصلی داشته باشد. فهرست انتخاب مسئول، حجم پروژه‌های فعال هر منتور را نشان دهد.

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

## ۷. چرخه پروژه، اعتبار خدمت و زمان‌بندی

سه مفهوم را جدا نگه دار:

| محور | وضعیت‌ها |
|---|---|
| وضعیت اجرای پروژه | درخواست جدید، تأییدشده، در انتظار اطلاعات، در حال اجرا، در انتظار مشتری، آماده تحویل، تحویل‌شده، لغوشده، بایگانی‌شده |
| اعتبار دوره خدمت | شروع‌نشده، فعال، متوقف با مجوز، منقضی |
| وضعیت فرم | پیش‌نویس، ارسال‌شده، نیازمند تکمیل مشخص، تأییدشده، دارای اصلاحیه |

تغییر وضعیت اجرای پروژه نباید به‌طور پنهانی زمان خدمت را تغییر دهد. «تحویل‌شده» با «مهلت تمام‌شده» یکسان نیست؛ پیش‌فرض پیشنهادی، تیکت تا پایان اعتبار خریداری‌شده باز بماند حتی اگر کار زودتر تحویل شود.

تاریخ‌ها در رابط شمسی و منطقه زمانی کسب‌وکار Asia/Tehran باشند؛ لحظه‌ها در پایگاه داده UTC ذخیره شوند. تاریخ شروعِ بدون ساعت از ابتدای روز تهران و پایانِ بدون ساعت تا پایان روز انتخاب‌شده معتبر باشد. در محاسبات سرور، پایان به‌صورت مرز ابتدای روز بعد و شرط زمان فعلی کمتر از آن پیاده شود.

پیش‌فرض پیشنهادی: مدت پلن بر اساس روز تقویمی است؛ روز شروع روز اول محسوب می‌شود. برای پلن N روزه، پایان نمایشی N−۱ روز پس از شروع است. در صورت تغییر دستی مدیر، بازه نهایی ثبت‌شده ملاک است.

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

توقف زمان، قابلیت مدیریتی پیشنهادی است: فقط با دلیل، تاریخ شروع توقف و ثبت پایان توقف؛ اثر جبران زمان پس از رفع توقف مشخص و ثبت شود. مشتری زمان باقی‌مانده و وضعیت توقف را ببیند. از توقف باز و نامشخص بدون گزارش جلوگیری شود.

انقضا در خود درخواست‌های سرور بررسی شود و به اجرای زمان‌بند وابسته نباشد. وظیفه زمان‌بندی فقط وضعیت‌های نمایشی و اعلان‌ها را به‌روز کند. کاربری که صفحه را قبل از انقضا باز کرده، بعد از انقضا نتواند با همان صفحه درخواست غیرمجاز بفرستد.

## ۸. داشبورد مشتری و تایم‌لاین

داشبورد مشتری باید در نگاه اول این سؤال‌ها را پاسخ دهد: «پروژه من کجاست؟»، «الان چه کاری باید انجام دهم؟»، «چقدر زمان دارم؟» و «چطور با منتور ارتباط بگیرم؟»

- کارت پروژه با نام سایت، مسئول و بخش، پلن، وضعیت، تاریخ شروع و پایان شمسی، روز/ساعت باقی‌مانده و دکمه اقدام بعدی.
- نمایش شمارنده به‌صورت روشن؛ قبل از شروع «شروع در ...»، هنگام توقف «زمان متوقف شده»، پس از پایان «مهلت به پایان رسیده». زمان منفی نشان داده نشود.
- درصد تکمیل فرم، تعداد اقلام تحویل‌شده و پیشرفت انجام کار جدا از درصد زمان سپری‌شده باشند؛ گذشت زمان به معنی پیشرفت کار نیست.
- نمایش «X محصول از Y محصول» و ظرفیت باقی‌مانده؛ تعداد فرصت ویرایش باقی‌مانده.
- معرفی منتور شامل نام نمایشی، تصویر اختیاری، بخش و روش ارتباط از طریق سامانه؛ شماره شخصی کارمند بدون تصمیم مدیر منتشر نشود.
- تایم‌لاین رویدادهای قابل‌نمایش به مشتری: ایجاد، معرفی منتور، شروع خدمت، ارسال اطلاعات، بازبینی، تکمیل بخش‌ها، درج محصولات، تحویل، تمدید و ثبت نظر.
- نمایش تیکت‌های منتظر پاسخ، اعلان‌ها، سفارش لوگو، پرداخت‌ها و امتیازهای کسب‌شده.
- در انتهای مهلت، توضیح روشن و دکمه «مشاهده پلن‌ها و تمدید منتورینگ»؛ سوابق قبلی همچنان خواندنی باشند.

## ۹. اصول تجربه فرم مرحله‌ای

فرم باید شبیه گفت‌وگویی راهنمایی‌شده باشد، با یک موضوع مشخص در هر مرحله. مشتری مجبور به شناخت اصطلاحات فنی نباشد.

- مسیر مراحل، عنوان واضح، پیشرفت واقعی، دکمه‌های قبلی/بعدی و «ذخیره و ادامه در زمان دیگر».
- ذخیره خودکار سمت سرور با وضعیت «در حال ذخیره / ذخیره شد / ذخیره نشد»؛ نمایش موفقیت فقط پس از تأیید سرور. بازیابی از دستگاه دیگر و پس از ورود مجدد.
- هر بخش: توضیح کوتاه «چه چیزی لازم است و چرا»، مثال ایرانیِ ساختگی، راهنمای بازشونده و نمونه تصویری در صورت نیاز.
- عبارت‌های ساده مثل «محصول شما رنگ یا اندازه‌های مختلف دارد؟» به‌جای نمایش صرف اصطلاح Variation.
- علامت‌گذاری دقیق فیلدهای ضروری؛ گزینه‌های «ندارم»، «هنوز آماده نیست»، «به سایت من مربوط نیست» و «نیاز به راهنمایی منتور دارم» در جاهای مناسب.
- پاسخ نامعلوم به‌صورت وضعیت مشخص ثبت شود، نه متن بی‌معنی یا قیمت صفر. اطلاعات ضروریِ مسدودکننده در بازبینی نهایی مشخص و برای منتور وظیفه پیگیری ایجاد کنند.
- سؤال‌های شرطی: سایت غیر فروشگاهی مراحل فروشگاه را نبیند؛ محصول غیر فیزیکی نیاز به وزن نداشته باشد مگر شرایط آن اقتضا کند؛ مرحله نامرتبط از پیشرفت حذف شود.
- اعتبارسنجی تدریجی با حفظ داده‌ها؛ امکان ثبت پیش‌نویس ناقص. استفاده از اعداد فارسی یا انگلیسی و ورود متن راست‌به‌چپ پشتیبانی شود.
- فایل‌ها پیش‌نمایش، ترتیب، توضیح و امکان جایگزینی داشته باشند. محدودیت حجم و نوع قبل از ارسال نمایش داده شود.
- پیش‌نویس اطلاعات ورود سایت در حافظه محلی ناامن مرورگر ذخیره نشود.
- از ابتدا توضیح داده شود: «تا قبل از ارسال نهایی می‌توانید آزادانه تغییر دهید. پس از ارسال نهایی، در مدت فعال بودن منتورینگ، دو نوبت ویرایش اطلاعات دارید.»

## ۱۰. مراحل جامع دریافت اطلاعات سایت

### مرحله ۱: آشنایی با کسب‌وکار و هدف سایت

نام کسب‌وکار، نام صاحب/نماینده، حوزه فعالیت، معرفی یک‌پاراگرافی، نوع سایت (شرکتی، فروشگاهی، خدماتی، شخصی یا ترکیبی)، مخاطب اصلی، شهر/محدوده فعالیت، هدف اصلی سایت و مهم‌ترین اقدام موردانتظار بازدیدکننده دریافت شود. آدرس سایت و اطلاعات شناخته‌شده از پروژه پیش‌پر شوند.

راهنمای نمونه: «چه کاری انجام می‌دهید و دوست دارید بازدیدکننده سایت چه کاری انجام دهد؟ مثلاً خرید محصول، تماس یا ثبت درخواست.»

### مرحله ۲: هویت و ظاهر برند

عنوان سایت، شعار کوتاه اختیاری، املای فارسی/انگلیسی برند در صورت وجود، رنگ‌های دلخواه از پالت ساده، سبک بصری (رسمی، دوستانه، مینیمال یا پرانرژی)، نمونه سایت‌های پسندیده با توضیح دلیل و موارد نامطلوب دریافت شود.

لوگو، نسخه روشن/تیره در صورت وجود و آیکون مرورگر اختیاری دریافت شود. مشتری برای رنگ به دانستن کد HEX نیاز نداشته باشد. اطلاعات هویت شامل عنوان، شعار، لوگو و آیکون با ساختار وردپرس سازگار در نظر گرفته شود. [مرجع وردپرس](https://wordpress.org/documentation/article/site-editor/)

سه انتخاب لوگو: «لوگو دارم»، «بعداً ارسال می‌کنم»، «می‌خواهم سفارش طراحی بدهم». انتخاب سفارش، بسته‌های قیمت‌گذاری‌شده مدیر را نمایش دهد؛ بازگشت از پرداخت کاربر را به همین مرحله و پیش‌نویس ذخیره‌شده برگرداند. خرید لوگو اجباری نباشد.

### مرحله ۳: ساختار سایت، دسته‌بندی‌ها و منوها

با پرسش «دوست دارید چه بخش‌هایی در سایتتان وجود داشته باشد؟» صفحات پیشنهادی نمایش داده شوند: خانه، فروشگاه/خدمات، درباره ما، تماس با ما، مقالات، سؤالات متداول و نمونه‌کارها.

دسته‌بندی محصولات و دسته‌بندی مقالات جدا باشند. هر دسته نام، توضیح اختیاری، تصویر اختیاری و دسته مادر داشته باشد. منوی اصلی و منوی پایین سایت با انتخاب صفحه، دسته یا لینک دلخواه ساخته شوند؛ مرتب‌سازی ساده و زیرمنو پشتیبانی شود. امکان «چیدمان پیشنهادی منتور» وجود داشته باشد.

### مرحله ۴: محتوای صفحه اصلی

تیتر اصلی، توضیح کوتاه، متن دکمه اقدام، تصاویر یا بنرها، خدمات/محصولات منتخب، مزیت‌های کسب‌وکار، پیام‌های تبلیغاتی معتبر و بخش‌های دلخواه دریافت شود. در صورت نیاز، تیم، نمونه‌کار، برندهای همکار و نظرات واقعی موجود نیز به‌صورت اختیاری دریافت شوند.

برای نداشتن متن، پرسش‌های کوتاه کمک‌کننده ارائه کن؛ سامانه یا منتور نباید مشتری، آمار فروش، گواهی، سابقه یا نظر رضایت ساختگی تولید کند.

### مرحله ۵: درباره ما، تماس و صفحات اعتماد

برای «درباره ما»: داستان کوتاه شروع فعالیت، سابقه‌ای که مشتری تأیید می‌کند، خدمات، مزیت‌ها، تصاویر و اعضای تیم در صورت تمایل.

برای «تماس با ما»: تلفن کاری، موبایل قابل‌انتشار، ایمیل کاری، نشانی، کدپستی در صورت نیاز، ساعات پاسخ‌گویی، لینک موقعیت نقشه، شبکه‌های اجتماعی و پیام‌رسان‌ها. مشخص شود کدام اطلاعات عمومی و کدام فقط برای ارتباط داخلی است.

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

مجوزها، گواهی‌ها و نشان‌های اعتماد فقط در صورت وجود و نیاز دریافت شوند؛ انتشارشان انتخاب جداگانه داشته باشد. برای سایت خدماتی، محدوده خدمت، روند ثبت درخواست و روش برآورد قیمت پرسیده شود.

### مرحله ۶: تنظیمات ساده فروشگاه — شرطی

نوع کالا یا خدمت، واحد پول، روش نمایش قیمت، روش مدیریت موجودی، نحوه ارسال، محدوده ارسال، زمان آماده‌سازی، هزینه یا قواعد ارسال، تحویل حضوری، شرایط مرجوعی و کانال پاسخ‌گویی فروشگاه دریافت شود. وضعیت داشتن درگاه و نیاز به راه‌اندازی آن پرسیده شود؛ رمز بانکی یا اطلاعات کارت دریافت نشود.

اطلاعات تکمیلی مالیاتی یا پیکربندی تخصصی فقط در صورت نیاز واقعی از مسیر مناسب دریافت و توسط فرد مسئول تأیید شود. انتخاب واحد پول با قیمت‌های محصول سازگار باشد. [مرجع مدیریت محصولات ووکامرس](https://woocommerce.com/document/managing-products/)

### مرحله ۷: افزودن محصولات یا خدمات

فهرست محصولات به‌صورت کارت‌های قابل‌فهم باشد: افزودن، ذخیره ناقص، تکثیر برای ورود مشابه، حذف پیش‌نویس و تکمیل هر محصول. ظرفیت باقی‌مانده پلن همیشه دیده شود. تکثیر یا حذف پس از ارسال نهایی مشمول قواعد تغییر اطلاعات و سهمیه باشد.

برای هر محصول، نام، دسته، تصویر اصلی، گالری مرتب‌شده، معرفی کوتاه، توضیح کامل، قیمت عادی، قیمت ویژه و بازه آن در صورت نیاز، وضعیت موجودی، تعداد در صورت مدیریت موجودی و کد کالا در صورت وجود دریافت شود. برند، جنس، ابعاد، وزن، راهنمای استفاده و ضمانت فقط در صورت ارتباط با محصول نمایش داده شوند. [مرجع محصولات ووکامرس](https://woocommerce.com/document/managing-products/)

پرسش‌های نوع محصول ساده باشند: «کالای ارسالی است یا خدمت/فایل؟» و «خریدار باید رنگ، اندازه یا مدل انتخاب کند؟». برای محصول دانلودی، فایل مجاز و شرایط دریافت؛ برای خدمت، جزئیات ارائه و نیاز یا عدم نیاز به هماهنگی دریافت شود.

ویژگی توصیفی مثل جنس، با گزینه قابل‌انتخاب هنگام خرید فرق داشته باشد. برای محصول متغیر، مقادیر رنگ/اندازه/مدل و فقط ترکیب‌های واقعاً موجود دریافت شوند. هر ترکیب بتواند قیمت، موجودی، کد و تصویر مستقل داشته باشد؛ مقادیر مشترک قابل‌اعمال به چند ترکیب باشند. ترکیب تکراری و ترکیب بدون قیمت معتبر برای درج نهایی پذیرفته نشود. [مرجع محصولات متغیر ووکامرس](https://woocommerce.com/document/variable-product/)

راهنمای نمونه: «اگر این تیشرت را در دو رنگ و سه اندازه می‌فروشید، مشخص کنید کدام مدل‌ها موجودند و آیا قیمتشان متفاوت است.»

اگر محصولات آماده نیستند، به‌جای قیمت یا تصویر ساختگی، وضعیت نیازمند تکمیل ثبت شود. واردکردن انبوه محصولات با فایل اکسل/CSV قابلیت پیشنهادی آینده است و جای فرم ساده را نگیرد.

### مرحله ۸: محتوای تکمیلی و نیازهای راه‌اندازی

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

نیاز به اتصال ابزار آمار، چت یا شبکه اجتماعی صرفاً پرسیده شود. شناسه و تنظیم تخصصی فقط اگر در تعهد پلن است دریافت شود. اطلاعات ورود سایر حساب‌ها در متن عادی فرم درخواست نشود.

### مرحله ۹: دسترسی امن و آمادگی اجرا

نشانی سایت و صفحه ورود، حساب مخصوص همکاری و روش دسترسی دریافت/تأیید شود. راهنمای ساده ساخت حساب مناسب برای منتور ارائه شود؛ درخواست دسترسی بیش از نیاز خدمت انجام نشود.

اطلاعات هاست یا دامنه پیش‌فرض اجباری نباشد؛ فقط برای کار مشخص و با توضیح علت دریافت شود. مشتری بتواند مشکلات دسترسی را اعلام و اطلاعات محرمانه را از بخش امن به‌روزرسانی کند. این به‌روزرسانی امنیتی از سهمیه دو ویرایش محتوایی کم نکند و ثبت سابقه شود.

### مرحله ۱۰: بازبینی، اعلام محدودیت و ارسال نهایی

خلاصه همه مراحل به تفکیک، موارد ناقص، تصمیم‌های واگذارشده به منتور، تعداد محصولات و ظرفیت‌ها نمایش داده شود. خلاصه قابل چاپ باشد و رمزها در چاپ/خروجی درج نشوند.

مشتری تأیید کند اطلاعات متعلق به کسب‌وکار او یا دارای اجازه استفاده‌اند و محدوده خدمت، زمان باقی‌مانده و دو نوبت ویرایش را دیده است. ارسال نهایی فقط برای پروژه با دوره فعال انجام شود؛ پروژه شروع‌نشده امکان آماده‌سازی پیش‌نویس داشته باشد.

پس از ارسال موفق، نسخه اولیه اطلاعات قفل و برای منتور اعلان ایجاد شود. دکمه «گفت‌وگو و ثبت تیکت با منتور» فعال شود. تکمیل مراحل و ورود به تیکت در مسیر پیشرفت مشخص باشد.

## ۱۱. قانون دقیق دو نوبت ویرایش

این قانون در پایگاه داده و سرور اعمال شود، نه فقط با پنهان‌کردن دکمه:

۱. قبل از اولین ارسال نهایی، ذخیره و تغییر پیش‌نویس نامحدود است و سهمیه مصرف نمی‌کند.

۲. پس از ارسال اولیه، مشتری حداکثر دو «نوبت ثبت نهایی اصلاحیه» برای اطلاعات اصلی پروژه دارد. هر نوبت می‌تواند چند فیلد، فایل، صفحه یا محصول را در بر بگیرد؛ هر ذخیره خودکار یک ویرایش محسوب نشود.

۳. مشتری «شروع ویرایش» را می‌زند، روی نسخه پیش‌نویس اصلاحیه کار می‌کند و در پایان تفاوت‌ها را می‌بیند. سهمیه فقط با ثبت موفق تغییر واقعی و تأیید نهایی کم شود. انصراف، خطا یا ارسال بدون تغییر سهمیه مصرف نکند.

۴. بعد از دو اصلاحیه، اطلاعات اصلی فقط خواندنی شود. متن‌ها: «۲ نوبت ویرایش باقی مانده»، «۱ نوبت ویرایش باقی مانده» و «فرصت‌های ویرایش شما استفاده شده است».

۵. نسخه‌های قبلی، زمان، ثبت‌کننده و تفاوت تغییرات حفظ شوند. به منتور اطلاع داده شود کدام بخش‌ها تغییر کرده‌اند؛ موارد قبلاً انجام‌شده که تغییر می‌کنند نیازمند بازبینی شوند.

۶. ثبت همزمان در دو تب نباید سهمیه را دور بزند یا اطلاعات جدیدتر را بازنویسی کند. کنترل نسخه و کاهش اتمی شمارنده لازم است.

۷. ویرایش مشتری فقط در دوره فعال مجاز است. پایان مهلت، حتی با سهمیه باقی‌مانده، امکان ثبت اصلاحیه را می‌بندد. پیش‌نویس حفظ شود تا پس از تمدید یا مجوز معتبر قابل‌ادامه باشد.

۸. پیش‌فرض پیشنهادی: اصلاح نقصی که منتور به‌طور مشخص برای همان فیلد بازگردانده، «تکمیل نقص» است و از سهمیه کم نمی‌کند؛ فقط همان فیلدها باز شوند. تغییر آزاد بخش‌های دیگر از این مسیر مجاز نباشد.

۹. پیش‌فرض پیشنهادی: مدیر سامانه بتواند استثنائاً یک فرصت اضافه با دلیل اعطا کند؛ قاعده عمومی مشتری همچنان دو نوبت است. هر استثنا در سابقه و رابط کاربر مشخص باشد.

۱۰. تمدید، شمارنده دو ویرایش اطلاعات اصلی پروژه را خودکار صفر نکند. اگر پلن تمدید شامل محصولات/محتوای تازه است، فرم الحاقی برای ظرفیت جدید ایجاد شود؛ ارسال اولیه الحاقیه تغییر اطلاعات قبلی نیست، اما اصلاح محتوای ارسال‌شده تابع سهمیه باقی‌مانده پروژه است.

تیکت راه دورزدن محدودیت محتوایی نیست: مشتری می‌تواند سؤال یا درخواست بدهد، اما تغییر رسمی اطلاعات باید در مسیر اصلاحیه یا استثنای ثبت‌شده انجام شود. اصلاح اشتباه اجرایی کارکنان از سهمیه مشتری کم نشود.

## ۱۲. پنل منتور، فعالیت‌ها و هشدار عدم پیگیری

منتور فهرست پروژه‌های فعال، شروع‌نشده، منتظر مشتری، نزدیک انقضا و خاتمه‌یافته خود را ببیند. جست‌وجو و فیلتر بر اساس مشتری، سایت، وضعیت و موعد وجود داشته باشد. مرتب‌سازی پیش‌فرض، پروژه‌های نیازمند اقدام را بالاتر قرار دهد.

هر کارت/ردیف پروژه نام مشتری، نام و آدرس سایت، پلن، تاریخ پایان، زمان باقی‌مانده، آخرین فعالیت، آخرین اقدام منتور، تعداد تیکت‌های منتظر پاسخ، درصد تکمیل اطلاعات و کار بعدی را نمایش دهد.

پیش‌فرض پیشنهادی برای سلامت پیگیری در دوره فعال:

| وضعیت | شرط | نمایش و اقدام |
|---|---|---|
| پیگیری مناسب | کمتر از ۷ روز کامل از آخرین فعالیت مؤثر | سبز همراه با متن |
| نیازمند پیگیری | از ۷ تا کمتر از ۱۴ روز بدون فعالیت مؤثر | نارنجی، برچسب «نیاز به پیگیری» و اعلان به منتور |
| پیگیری عقب‌افتاده | از ۱۴ روز به بعد بدون فعالیت مؤثر | قرمز، اعلان منتور و مدیر داخلی |
| نزدیک پایان | زمان باقی‌مانده در آستانه مصوب، مثلاً ۳ روز | نشان مستقل زمان، حتی اگر فعالیت مناسب باشد |
| شروع‌نشده/متوقف/منقضی | بر اساس اعتبار خدمت | برچسب روشن جدا از سلامت پیگیری |

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

فعالیت مؤثر شامل ارسال نهایی اطلاعات یا اصلاحیه، پیام محتوایی مشتری/منتور، ثبت نتیجه تماس یا پیگیری واقعی، تکمیل وظیفه، درج محصول با ثبت نتیجه و تحویل خروجی است. پیگیری بدون پاسخ هم با ثبت نتیجه مشخص و موعد بعدی قابل‌ثبت باشد. یادداشت خالی یا تکراری برای سبزکردن پروژه پذیرفته نشود.

برای پروژه بدون فعالیت، مبدأ محاسبه شروع واقعی خدمت باشد. آخرین فعالیت مشتری و آخرین اقدام منتور جدا ثبت شوند تا پیام مکرر مشتری، بی‌عملی منتور را پنهان نکند. هشدار مستقل «مشتری منتظر پاسخ منتور است» وجود داشته باشد. در نسخه اولیه، فعالیت داخل خود وردپرس فقط با ثبت منتور شناخته می‌شود؛ رصد خودکار سایت ادعا نشود.

منتور بتواند اطلاعات هر بخش را بازبینی، تأیید یا با علت مشخص برای تکمیل بازگرداند؛ وظیفه و موعد پیگیری بسازد؛ چک‌لیست اجرای پلن را تکمیل کند؛ نام/لینک محصول یا صفحه درج‌شده را ثبت کند؛ و خلاصه قابل‌نمایش به مشتری بنویسد. یادداشت داخلی هرگز به مشتری یا پیامک منتقل نشود.

## ۱۳. تیکت و ارتباط با مسئول پروژه

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

## ۱۴. فایل‌ها و اطلاعات محرمانه سایت

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

پیش‌فرض پیشنهادی قابل‌تغییر برای هر فایل: تصویر تا ۱۰ مگابایت، سند تا ۲۰، صوت تا ۵۰ و ویدئو تا ۲۰۰ مگابایت؛ سقف کل پروژه، کاربر و فضای سرویس نیز تعریف شود. محدودیت‌های واقعی هاست و پردازش با این مقادیر سازگار شوند.

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

نوع واقعی فایل و اندازه در سرور بررسی شود؛ نام تصادفی و ذخیره خارج از مسیر اجرای عمومی، کنترل دسترسی دانلود و جلوگیری از اجرای فایل لازم است. SVG و فایل‌های فعال فقط پس از پاک‌سازی مناسب پذیرفته/نمایش داده شوند. لینک عمومی دائمی برای مدارک، صوت/ویدئوی خصوصی یا فایل پروژه ایجاد نشود.

رمز ثابت حساب باشگاه با الگوریتم امن هش شود. رمز سایت مشتری، چون منتور باید بتواند با مجوز آن را استفاده کند، با رمزگذاری قابل‌بازیابی و کلیدی خارج از پایگاه داده نگهداری شود. کلیدها و اسرار در کد، مخزن، پیامک، گزارش خطا، خروجی یا متن تیکت ثبت نشوند.

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

## ۱۵. سفارش و پرداخت طراحی لوگو

مدیر بسته‌های طراحی لوگو را با نام، توضیح، قیمت، زمان تحویل، اقلام خروجی و تعداد اصلاحات طراحی تعریف کند. این تعداد اصلاحات مربوط به خدمت لوگو است و با دو نوبت ویرایش اطلاعات اصلی سایت مخلوط نشود.

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

پس از پرداخت تأییدشده، سفارش لوگو با ارتباط به مشتری و پروژه ایجاد/فعال شود. هزینه، شماره سفارش، شناسه پرداخت و تاریخ ثبت شوند؛ اعلان و پیامک پرداخت به مسئول پروژه و مدیر سامانه ارسال شود و رسید برای مشتری قابل‌مشاهده باشد. اگر مسئول هنوز تعیین نشده، مدیر/مسئول بخش گیرنده جایگزین باشد.

سفارش گردش کار مستقل داشته باشد: منتظر پرداخت، پرداخت‌شده، نیازمند تکمیل سفارش، در حال طراحی، پیش‌نمایش، درخواست اصلاح در محدوده بسته، تأیید مشتری و تحویل نهایی. فرم کوتاه سفارش شامل نام برند، سبک، رنگ، حوزه فعالیت و نمونه دلخواه باشد و اطلاعات موجود دوباره پرسیده نشوند.

اگر سفارش قبلاً پرداخت شده یا در حال طراحی است، به‌جای تشویق به پرداخت دوباره همان سفارش نمایش داده شود. پایان زمان منتورینگ، سفارش لوگوی پرداخت‌شده و امکان دریافت خروجی آن را نبندد.

## ۱۶. سفارش‌ها و اتصال به درگاه زیبال

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

چرخه پرداخت: ایجاد سفارش در سرور با قیمت و تعهد ثابت → درخواست پرداخت → هدایت به زیبال → بازگشت → تأیید از سرور → ثبت نتیجه و اعمال خدمت دقیقاً یک بار. دریافت callback به‌تنهایی دلیل موفقیت نیست؛ تأیید پرداخت در جریان زیبال پیش‌بینی شده است. [مرجع اتصال زیبال](https://help.zibal.ir/ipg/)

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

Endpoint، پاسخ نمونه و کلید واقعی را حدس نزن. اگر اطلاعات اتصال هنوز ارائه نشده، حالت آزمایشی به‌وضوح مشخص باشد و ارسال پیامک یا دریافت پول واقعی ادعا نشود.

## ۱۷. تمدید منتورینگ

مشتری پیش از پایان و پس از پایان زمان خدمت بتواند پلن‌های تمدید مجاز، مدت، قیمت و تعهدات را ببیند. روشن باشد که هر پلن فقط زمان و پشتیبانی را افزایش می‌دهد یا ظرفیت محصولات و خدمات جدید هم دارد.

پیش‌فرض پیشنهادی برای شروع تمدید: اگر اعتبار فعلی باقی است، مدت جدید از مرز پایان اعتبار فعلی اضافه شود؛ اگر خدمت منقضی است، از لحظه تأیید پرداخت آغاز شود. افزودن N روز در تقویم منطقه زمانی تهران با ساعت شروع همان دوره انجام و ساعت دقیق پایان در رسید نشان داده شود. روزهای باقی‌مانده با تمدید زودهنگام از بین نروند.

هر تمدید دوره خدمت و نسخه تعهد مستقل با ارتباط به همان پروژه بسازد؛ سوابق دوره‌های قبلی حفظ شوند. در تمدید پیش از پایان، دسترسی جاری ادامه دارد و ظرفیت جدید از شروع دوره جدید فعال می‌شود، مگر خرید صریح افزونه فوری جداگانه‌ای تعریف شده باشد.

تخصیص منتور فعلی حفظ شود اگر هنوز فعال و مجاز است. در غیر این صورت، پیش از پذیرش خرید، مسیر مسئول جایگزین و زمان شروع خدمت برای مشتری مشخص شود؛ مشتری هزینه زمانِ بدون مسئول مشخص را متحمل نشود.

پرداخت همزمان برای تمدیدهای متفاوت باید به ترتیب معتبر به انتهای اعتبار اضافه شود، نه اینکه تاریخ‌ها روی هم بازنویسی شوند. دو تأیید برای یک سفارش فقط یک بار تمدید ایجاد کنند.

پس از تأیید تمدید، زمان و تایم‌لاین به‌روزرسانی، تیکت در دوره معتبر دوباره فعال و پیامک به مشتری و مسئول ارسال شود. اعلان‌های انقضای قبلی که دیگر موضوعیت ندارند از صف خارج یا هنگام ارسال دوباره بررسی شوند.

شماره دوره، تاریخ‌های قبل/بعد، پلن، ظرفیت، مبلغ و ثبت‌کننده در سابقه تمدید نگهداری شوند. تمدید دستی/هدیه مدیر با دلیل و بدون تراکنش بانکی ساختگی قابل‌ثبت باشد. توقف، لغو یا انتقال پروژه در حین پرداخت قبل از اعمال خدمت دوباره کنترل و موارد ناسازگار برای رسیدگی ثبت شوند.

## ۱۸. سیستم پیامکی IPPanel و مدیریت اعلان‌ها

ارسال پیامک با IPPanel و قالب‌های آماده قابل‌ویرایش پیاده شود. تنظیمات شامل کلید دسترسی، خط فرستنده، شناسه پترن‌ها، نگاشت متغیرها، رویدادها، گیرندگان، زمان‌بندی، فعال/غیرفعال‌کردن و ارسال آزمایشی کنترل‌شده باشد.

در ارسال پترنی، متن و متغیرها باید با الگوی تأییدشده سرویس هماهنگ باشند. ویرایش متن داخل باشگاه به‌تنهایی به معنی فعال‌شدن نسخه جدید در سرویس پیامکی نیست؛ وضعیت الگو و نیاز به تأیید/همگام‌سازی در تنظیمات مشخص شود. [مرجع پترن‌های IPPanel](https://ippanelcom.github.io/Edge-Document/fa/docs/pattern/)

مدیر کنترل کامل قواعد داخلی ارسال، گیرندگان هر نقش و قالب‌ها را داشته باشد. متن پیش‌نمایش، متغیرهای ضروری، تاریخچه نسخه و خطای متغیر ناقص نمایش داده شوند. شیوه ارسال باید با API حساب و پترن موجود سازگار باشد. [مرجع ارسال IPPanel](https://ippanelcom.github.io/Edge-Document/fa/docs/send/)

جدول رویدادهای پایه:

| رویداد | گیرندگان پیش‌فرض | قاعده |
|---|---|---|
| کد ورود/بازیابی | همان موبایل درخواست‌کننده | فوری و مشمول محدودیت OTP |
| تأیید عضویت کارکنان | کارمند | یک بار هنگام تأیید |
| ثبت درخواست پروژه توسط مشتری | مدیر داخلی/مسئول پذیرش | پس از ثبت معتبر |
| ایجاد پروژه مصوب | مشتری و منتور تعیین‌شده | پس از ثبت موفق |
| معرفی یا تغییر منتور | مشتری و منتور جدید | با حفظ سابقه تخصیص |
| شروع دوره خدمت | مشتری و منتور | یک بار برای هر دوره |
| ارسال فرم اولیه/اصلاحیه | مسئول پروژه | پس از ثبت نهایی |
| درخواست تکمیل نقص | مشتری | به تفکیک درخواست معتبر |
| پیام جدید تیکت | طرف منتظر پاسخ | قابل‌تجمیع برای جلوگیری از تکرار |
| عدم فعالیت | منتور؛ سپس مدیر داخلی | پیش‌فرض ۷ و ۱۴ روز |
| نزدیک پایان | مشتری و منتور | پیش‌فرض ۳ و ۱ روز قبل |
| پایان زمان منتورینگ | مشتری و منتور | یک بار برای پایان مؤثر هر دوره |
| پرداخت موفق لوگو | مشتری، مسئول پروژه و مدیر سامانه | فقط پس از تأیید پرداخت |
| تمدید موفق | مشتری و مسئول؛ مدیر طبق تنظیم | فقط پس از اعمال خدمت |
| تحویل پروژه/خروجی لوگو | مشتری | برای تحویل معتبر |
| درخواست ثبت نظر | مشتری | پس از تحویل نهایی یا پایان دوره با جلوگیری از تکرار |
| تأیید نظر و اعطای امتیاز | مشتری | قابل‌غیرفعال‌کردن |

قالب‌های اولیه زیر متن پیشنهادی محصول‌اند؛ مدیر بتواند آن‌ها را با پترن‌های حساب خود تطبیق دهد. نام متغیرها در همه رویدادها یکسان و مقدارهای حساس از فهرست مجاز خارج باشند.

| کاربرد | متن آماده پیشنهادی |
|---|---|
| OTP | «کد ورود شما به باشگاه مشتریان سایت ساز زرین: {otp}. اعتبار: {minutes} دقیقه. این کد را در اختیار دیگران قرار ندهید.» |
| تأیید کارمند | «{staff_name} عزیز، عضویت کاری شما در باشگاه مشتریان زرین تأیید شد. ورود: {login_url}» |
| درخواست پروژه | «درخواست منتورینگ {customer_name} برای {project_name} ثبت شد و منتظر بررسی است: {project_url}» |
| پروژه برای مشتری | «{customer_name} عزیز، پروژه {project_name} در باشگاه مشتریان زرین ثبت شد. بازه منتورینگ: {start_date} تا {end_date}. مشاهده و تکمیل اطلاعات: {project_url}» |
| پروژه برای منتور | «{mentor_name} عزیز، پروژه {project_name} برای مشتری {customer_name} به شما ارجاع شد. پایان خدمت: {end_date}. {project_url}» |
| معرفی منتور | «{customer_name} عزیز، {mentor_name} مسئول منتورینگ سایت شماست. ارتباط و مشاهده پروژه: {project_url}» |
| شروع خدمت | «دوره منتورینگ پروژه {project_name} آغاز شد و تا {end_date} اعتبار دارد. مشاهده اقدام بعدی: {project_url}» |
| دریافت اطلاعات | «اطلاعات پروژه {project_name} توسط مشتری ارسال شد. لطفاً بررسی کنید: {project_url}» |
| اصلاح اطلاعات | «اصلاحیه شماره {revision_number} پروژه {project_name} ثبت شد. مشاهده تغییرات: {project_url}» |
| نقص اطلاعات | «{customer_name} عزیز، برای ادامه پروژه {project_name} چند مورد نیاز به تکمیل دارد. راهنما و موارد لازم: {project_url}» |
| پاسخ تیکت | «پیام جدیدی برای تیکت {ticket_number} در باشگاه مشتریان زرین ثبت شده است. مشاهده: {ticket_url}» |
| عدم فعالیت | «پروژه {project_name} به مدت {inactive_days} روز فعالیت ثبت‌شده ندارد. لطفاً پیگیری و نتیجه را ثبت کنید: {project_url}» |
| نزدیک پایان | «{customer_name} عزیز، {remaining_days} روز از منتورینگ {project_name} باقی مانده است. پیگیری یا تمدید: {project_url}» |
| پایان خدمت | «مهلت منتورینگ {project_name} به پایان رسید. سوابق در دسترس شماست. مشاهده پلن‌های تمدید: {renewal_url}» |
| پرداخت برای مدیر/مسئول | «پرداخت {service_name} برای {customer_name}، پروژه {project_name}، به مبلغ {amount_toman} تومان تأیید شد. سفارش {order_number}؛ پیگیری {tracking_code}.» |
| رسید مشتری | «{customer_name} عزیز، پرداخت {service_name} به مبلغ {amount_toman} تومان تأیید شد. سفارش {order_number}. رسید: {receipt_url}» |
| تمدید | «منتورینگ {project_name} تمدید شد. پایان اعتبار جدید: {end_date}. مشاهده جزئیات: {project_url}» |
| تحویل | «{customer_name} عزیز، خروجی {service_name} برای پروژه {project_name} آماده مشاهده است: {delivery_url}» |
| نظرسنجی | «{customer_name} عزیز، تجربه منتورینگ زرین برای شما چگونه بود؟ نظر متنی، صوتی یا ویدئویی خود را ثبت کنید: {review_url}» |
| امتیاز | «{customer_name} عزیز، بابت {action_title} تعداد {points} امتیاز به باشگاه شما اضافه شد. مشاهده: {club_url}» |

در پنل مدیر، متغیر گیرنده برای پیام یادآوری به منتور با نسخه مشتری هماهنگ شود؛ یک قالب دارای خطاب مشتری بی‌تغییر برای کارمند ارسال نشود. در رویداد ایجاد پروژه و معرفی همزمان منتور، امکان ترکیب پیام برای جلوگیری از دو پیام مشابه وجود داشته باشد.

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

برای هر رویداد، گیرنده و دوره یک شناسه یکتا تعریف کن. اگر یک نفر هم مدیر و هم مسئول است، پیام یکسان دوبار نگیرد. تاریخ و مبلغ از داده معتبر سرور تولید شوند. لینک‌ها روی دامنه تنظیم‌شده سامانه باشند و هیچ رمز سایتی داخل پیامک قرار نگیرد.

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

## ۱۹. پایان پروژه، تحویل و ثبت نظر

منتور برای تحویل، چک‌لیست تعهدات پلن، اقلام انجام‌شده، لینک‌های مرتبط، راهنمای کوتاه استفاده و موارد باز را ثبت کند. مشتری بتواند تحویل را ببیند و تأیید یا در دوره معتبر ایراد مشخص اعلام کند. انقضای زمان به‌تنهایی به معنی انجام همه تعهدات نیست؛ موارد انجام‌نشده در گزارش مدیر باقی بمانند.

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

فرم شامل امتیاز کلی، کیفیت اجرا، برخورد منتور، پاسخ‌گویی، میزان رضایت از فرایند و توضیح آزاد اختیاری باشد. همه سؤالات طولانی و اجباری نباشند؛ کاربر بتواند به‌سادگی تجربه اصلی را ثبت کند.

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

لینک نظر به مشتری، پروژه و دوره مشخص مرتبط و دارای توکن تصادفی محدود به همان فرم باشد؛ دسترسی به پروژه یا اطلاعات محرمانه از طریق آن ممکن نباشد. پیش‌فرض پیشنهادی: اعتبار لینک ۳۰ روز، امکان صدور مجدد کنترل‌شده و امکان ورود از داشبورد. ثبت نظر پس از انقضای منتورینگ نیز مجاز باشد.

نظر ابتدا خصوصی باشد. رضایت برای انتشار نام، تصویر، صدا یا ویدئو جدا از ثبت بازخورد گرفته شود؛ ندادن اجازه انتشار موجب محرومیت از امتیاز بازخورد معتبر نشود. هیچ محتوایی خودکار عمومی نشود.

مدیر وضعیت در انتظار بررسی، پذیرفته‌شده، نیازمند اصلاح فایل یا رد با علت را ببیند. نقد منفی معتبر نیز امتیاز بگیرد؛ امتیاز به نمره بالا وابسته نباشد. منتور نتواند نظر منفی مربوط به خود را حذف یا امتیازش را مستقلاً رد کند. امتیازها و نظرهای ویرایش‌شده تاریخچه داشته باشند.

## ۲۰. گیمیفیکیشن و امتیازهای باشگاه

باشگاه بخشی مستقل با «امتیاز من»، «کارهایی که می‌توانم انجام دهم»، «نشان‌ها/سطح» و «تاریخچه امتیازها» داشته باشد. مدیر عنوان فعالیت، شرایط دریافت، امتیاز، سقف تکرار، نیاز به تأیید، تاریخ اجرا و فعال/غیرفعال‌بودن را تعیین کند.

نمونه قواعد زیر صرفاً پیشنهاد اولیه قابل‌ویرایش هستند، نه مقادیر قطعی کسب‌وکار:

| فعالیت | امتیاز نمونه | شرط پیشنهادی |
|---|---:|---|
| تکمیل پروفایل پایه | ۲۰ | یک بار برای هر حساب |
| ارسال و پذیرش اطلاعات اولیه سایت | ۸۰ | یک بار برای هر پروژه |
| تکمیل یک مأموریت معتبر ارسال مدرک کسب‌وکار | ۲۰ | یک بار برای هر مأموریت؛ سقف نمونه ۶۰ برای این گروه در هر پروژه |
| ثبت نظر متنی معتبر | ۳۰ | یک بار برای هر دوره |
| ثبت نظر صوتی معتبر | ۶۰ | مطابق قاعده جایگزینی نوع نظر |
| ثبت نظر ویدئویی معتبر | ۱۰۰ | مطابق قاعده جایگزینی نوع نظر |

مأموریت ارسال مدرک فقط برای اطلاعات واقعاً لازم کسب‌وکار تعریف شود؛ صرف دریافت امتیاز دلیل جمع‌آوری مدارک هویتی حساس نیست. برای هر مأموریت، نوع فایل/اطلاعات، علت نیاز، بررسی‌کننده و خصوصی یا قابل‌انتشاربودن روشن باشد. تأیید مدارک در باشگاه به معنی ادعای احراز هویت قانونی نیست.

پیش‌فرض پیشنهادی: در هر دوره، بالاترین امتیاز نوع نظر پذیرفته‌شده محاسبه شود، نه جمع سه نوع. اگر مشتری ابتدا متن با ۳۰ امتیاز و بعد ویدئو با ۱۰۰ امتیاز ثبت کرد، فقط ۷۰ امتیاز اضافه شود. ارتقای نوع نظر با همان نظر مرتبط باشد و نظر جدیدِ تکراری نسازد. اگر مدیر سیاست تجمیعی انتخاب کرد، قواعد و سقف آن باید پیش از مشارکت قابل‌مشاهده و نسخه‌بندی شوند.

امتیازها دفتر رویداد داشته باشند: شخص، فعالیت، مرجع پروژه/دوره/نظر، مقدار، نسخه قانون، زمان، تأییدکننده و دلیل. تغییر قانون نباید امتیازهای گذشته را بی‌صدا بازنویسی کند. ارسال مجدد فرم، اجرای دوباره صف یا تأیید دوباره نظر امتیاز دوباره ندهد.

وضعیت امتیازهای در انتظار بررسی، قطعی و برگشت‌خورده روشن باشد. مدیر بتواند با دلیل امتیاز اصلاحی ثبت کند؛ اصلاح با رویداد جبرانی انجام شود و سابقه پاک نشود. در ابطال یک نظر، سایر نظرهای معتبر همان دوره دوباره برای بالاترین امتیاز بررسی شوند.

سطح‌ها و نشان‌ها قابل‌تنظیم باشند، مثلاً «شروع همراهی»، «همراه فعال» و «همراه طلایی»؛ آستانه‌های کسب هرکدام نمایش داده شوند. امتیاز نقد قابل‌برداشت تلقی نشود.

بخش «مصرف امتیاز و پاداش» پیشنهاد مرحله بعد است: مدیر می‌تواند تخفیف خدمات یا جایزه تعریف کند. تا زمانی که پاداش واقعی و شرایطش فعال نشده، وعده تخفیف یا قابلیت مصرف نمایش داده نشود. رتبه‌بندی عمومی نیز اختیاری و وابسته به انتخاب کاربر باشد.

## ۲۱. پنل مدیریتی و گزارش‌ها

پنل مدیر شامل کاربران، تأیید کارکنان، مشتریان، بخش‌ها، تخصیص منتورها، پروژه‌ها، پلن‌ها، فرم‌ها و راهنماها، لوگو، سفارش‌ها، پرداخت‌ها، تیکت‌ها، فعالیت‌ها، نظرها، امتیازها، پیامک و تنظیمات باشد.

گزارش‌های اصلی با فیلتر تاریخ شمسی، بازه دلخواه، منتور، بخش، پلن و وضعیت ارائه شوند:

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

مدیر بتواند مشتری یا منتور را انتخاب و جزئیات همان محدوده را ببیند. خروجی گزارش‌ها بدون رمزها و با رعایت مجوز داده‌ها باشد. نمودارها ساده، دارای برچسب و متناسب با داده واقعی باشند؛ نمودار تزئینی و عدد ساختگی نمایش داده نشود.

مدیر راهنمای هر مرحله، مثال‌ها و الزامی‌بودن فیلدهای قابل‌تنظیم را ویرایش کند. نسخه فرم برای پروژه موجود ثابت بماند مگر مهاجرت آگاهانه؛ تغییر فرم پروژه‌های قبلی را ناقص یا غیرقابل‌خواندن نکند. ساخت فرم‌ساز پیچیده و نامحدود شرط نسخه اول نیست.

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

## ۲۲. طراحی بصری و تجربه SaaS

رابط مدرن، خلوت و حرفه‌ای، با زبان فارسی، چیدمان راست‌به‌چپ و فونت خوانا مانند Vazirmatn طراحی شود. هویت بصری باید با زرین سازگار باشد؛ پیشنهاد اولیه رنگ طلایی/کهربایی به‌عنوان تأکید، رنگ خنثی روشن برای زمینه و متن تیره خواناست. رنگ واقعی برند از کارفرما گرفته یا به‌عنوان پیشنهاد مشخص شود.

ناوبری مشتری کوتاه و مبتنی بر کار او باشد: خانه، پروژه‌های من، پیام‌ها، سفارش‌ها و پرداخت‌ها، امتیازهای من و حساب کاربری. تنظیمات فنی و جزئیات پیاده‌سازی در مسیر مشتری نمایش داده نشوند.

پنل مدیر و منتور متناسب با نقش طراحی شود. استفاده از کارت، جدول، تب و نمودار هدفمند باشد. روی موبایل جدول‌های عریض به نمایش قابل‌خواندن تبدیل شوند؛ منوی کناری باز و بسته شود و محتوا را نپوشاند.

برای بارگذاری، خطا، نبود داده، موفقیت، انقضا و نبود مجوز طراحی واقعی ارائه کن. پیام «چه کاری باید انجام دهید» از کد خطای فنی مهم‌تر است. به‌ویژه ذخیره ناقص فرم، شکست بارگذاری فایل، مشکل پرداخت و عدم دریافت OTP مسیر بازیابی روشن داشته باشند.

کنتراست، اندازه مناسب نوشته و کنترل لمسی، فوکوس صفحه‌کلید، برچسب فرم، اتصال خطا به فیلد و همراه‌بودن رنگ وضعیت با متن/آیکون رعایت شوند. کاربر فقط از روی سبز/نارنجی مجبور به تشخیص وضعیت نباشد.

آدرس‌ها، رمزها و شناسه‌های فنی در محیط RTL به‌درستی چپ‌به‌راست نمایش داده شوند. اعداد مبلغ، جداکننده هزارگان، واحد تومان، تاریخ شمسی و ساعت تهران در همه صفحات سازگار باشند. وابستگی فونت و استایل‌های اصلی به بارگذاری موفق منبع خارجی ضروری نباشد.

## ۲۳. معماری و الزامات فنی برای فاز توسعه

پیش از انتخاب نهایی فناوری، محل استقرار، محدودیت‌های هاست، حجم فایل، تعداد کاربران و نیاز به صف/زمان‌بند مشخص شوند. پیش‌فرض پیشنهادی، یک سامانه مستقل با معماری ماژولار یکپارچه و پایگاه داده رابطه‌ای است؛ میکروسرویس برای نیاز اولیه تحمیل نشود.

اگر استقرار روی هاست PHP انتخاب شد، بک‌اند PHP با ساختار روشن یا فریم‌ورک سبک، MySQL، رابط HTML/CSS/JavaScript و ابزار RTL مناسب پیشنهاد شود. نسخه‌ها در زمان پیاده‌سازی از میان نسخه‌های دارای پشتیبانی و سازگار با هاست انتخاب شوند؛ در این سند نسخه منقضی یا وابستگی به یک فریم‌ورک خاص قطعی نشود.

ماژول پیامک و پرداخت Adapter مستقل داشته باشند؛ فرم، تیکت و دوره خدمت بدون وابستگی مستقیم به پاسخ لحظه‌ای سرویس خارجی کار کنند. آزمون بدون پول و پیامک واقعی با شبیه‌ساز کنترل‌شده ممکن باشد.

حداقل الزامات فنی:

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

مستندات APIهای زیبال و IPPanel هنگام پیاده‌سازی دوباره بررسی شوند. نمونه‌های قدیمی، endpoint حدسی یا پاسخ جعلی به‌عنوان اتصال عملیاتی ارائه نشوند. هیچ ارسال واقعی یا پرداخت واقعی در فاز طراحی انجام نشود.

## ۲۴. مدل داده پیشنهادی

نام دقیق جدول‌ها در طراحی نهایی قابل‌تغییر است، اما این مسئولیت‌ها و ارتباط‌ها پوشش داده شوند:

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

روابط اصلی: مشتری چند پروژه دارد؛ پروژه چند دوره خدمت و چند نسخه اطلاعات دارد؛ هر دوره یک نسخه پلن را مرجع می‌گیرد؛ هر پرداخت به یک سفارش و هر سفارش به خدمت مشخص متصل است؛ هر امتیاز مرجع یکتا دارد. نام مشتری یا منتور به‌جای کلید ارتباطی استفاده نشود.

قیدهای مهم: شماره موبایل نرمال‌شده یکتا، مسئول اصلی همزمان معتبر برای هر پروژه، ترتیب نسخه فرم، کلید یکتای اعمال پرداخت، رویداد امتیاز و ارسال پیامک. تاریخچه نقش/تخصیص در گزارش‌های گذشته حفظ شود.

## ۲۵. معیارهای پذیرش و سناریوهای ضروری آزمون

این معیارها برای ارزیابی پیاده‌سازی‌اند؛ در فاز نوشتن پرامپت به معنی انجام‌شدن آزمون یا ساخته‌شدن سامانه نیستند.

| شناسه | سناریو | نتیجه موردانتظار |
|---|---|---|
| A01 | ثبت‌نام مشتری و ورود با هر دو روش | موبایل تأیید شود و هر دو روش به همان حساب متصل باشند |
| A02 | ثبت‌نام کارمند بدون تأیید | هیچ پروژه یا مجوز کاری دریافت نکند |
| A03 | OTP منقضی، استفاده‌شده و تلاش بیش از حد | رد کنترل‌شده؛ روش رمز ثابت سالم بماند |
| A04 | مشتری یا منتور شناسه پروژه/فایل فرد دیگر را حدس بزند | دسترسی در سرور رد شود |
| A05 | مدیر پروژه با تاریخ شمسی و مشتری جست‌وجوشده بسازد | پلن، مسئول، بخش، تاریخ‌ها و پیامک‌های مربوط صحیح ثبت شوند |
| A06 | تغییر منتور | مسئول جدید دسترسی بگیرد، مسئول قبلی دسترسی نامعتبر نداشته باشد و تاریخچه حفظ شود |
| A07 | قطع اینترنت یا خروج وسط فرم | فقط ذخیره تأییدشده «ذخیره شد» نشان دهد و داده از آخرین ذخیره بازیابی شود |
| A08 | مشتری غیر فروشگاهی فرم را پر کند | سؤال‌های نامرتبط حذف شوند و درصد تکمیل درست باشد |
| A09 | افزودن محصول متغیر | فقط ترکیب‌های معتبر با قیمت/موجودی مرتبط ثبت شوند و سقف تنوع رعایت شود |
| A10 | عبور از سهمیه محصول با چند تب یا درخواست مستقیم | سرور از عبور جلوگیری کند |
| A11 | دو اصلاحیه موفق و تلاش سوم | دو بار پذیرفته شود؛ سوم رد شود؛ پیش‌نویس و خطا سهمیه نسوزانند |
| A12 | تکمیل نقص بازگردانده‌شده توسط منتور | فقط فیلدهای مشخص قابل‌تغییر باشند و ویرایش آزاد دور زده نشود |
| A13 | بازبودن فرم در لحظه انقضا | ثبت جدید رد و داده پیش‌نویس حفظ شود |
| A14 | گذشت ۷ روز بدون فعالیت مؤثر | وضعیت نارنجی و یادآوری مناسب ایجاد شود؛ بازدید صفحه آن را سبز نکند |
| A15 | مشتری پیام می‌دهد ولی منتور پاسخ نمی‌دهد | هشدار انتظار پاسخ منتور همچنان دیده شود |
| A16 | انقضا هنگام بازبودن تیکت | نوشتن مشتری متوقف شود؛ سوابق بماند؛ تیکت خودکار حل‌شده نشود |
| A17 | تحویل کار پیش از پایان خدمت | تیکت تا پایان اعتبار مصوب در دسترس بماند |
| A18 | انتخاب نداشتن لوگو | بسته‌ها دیده شوند؛ عدم خرید مانع ادامه فرم نشود |
| A19 | callback پرداخت دستکاری‌شده یا ناموفق | هیچ خدمت یا تمدید فعال نشود |
| A20 | callback تکراری و اجرای دوباره کار پس‌زمینه | یک پرداخت فقط یک خدمت، یک تمدید و اعلان مجاز ایجاد کند |
| A21 | پرداخت موفق با قطع بازگشت مرورگر | نتیجه قابل‌تطبیق و خدمت قابل‌بازیابی باشد؛ خرید گم نشود |
| A22 | تمدید قبل و بعد از انقضا | زمان طبق قاعده درست افزوده و سابقه قبلی حفظ شود |
| A23 | تغییر قیمت پلن پس از ایجاد سفارش معتبر | مبلغ و تعهد ثبت‌شده سفارش عوض نشود |
| A24 | پرداخت موفق لوگو | مدیر سامانه و مسئول پروژه اطلاع بگیرند؛ نقش مشترک پیام یکسان دوبار نگیرد |
| A25 | قطع IPPanel | فرم، پروژه و پرداخت حفظ شوند؛ خطا و تلاش ارسال قابل‌پیگیری باشد |
| A26 | تحویل و سپس انقضای همان دوره | دعوت اولیه نظر تکراری صادر نشود |
| A27 | ثبت نظر پس از پایان منتورینگ | با لینک معتبر یا حساب خود مجاز باشد؛ به داده پروژه دیگر دسترسی ندهد |
| A28 | نظر منفی معتبر یا بدون رضایت انتشار | امکان دریافت امتیاز داشته باشد و خصوصی بماند |
| A29 | تبدیل نظر متنی به ویدئویی و تأیید مجدد | فقط اختلاف امتیاز تعلق گیرد و عملیات تکراری امتیاز نسازد |
| A30 | بارگذاری فایل غیرمجاز یا لینک مستقیم فایل خصوصی | رد امن بدون افشای اطلاعات دیگران |
| A31 | موبایل، صفحه‌کلید و متن فارسی | ناوبری، فرم، شمارنده و پیام‌ها خوانا و قابل‌استفاده باشند |
| A32 | مرز روز، تغییر ماه/سال شمسی و تاریخ نامعتبر | بازه و شمارنده درست؛ تاریخ نامعتبر رد شود |
| A33 | پروژه متوقف، لغوشده یا در حال انتقال هنگام پرداخت | خدمت متناقض اعمال نشود و رسیدگی مالی مشخص باشد |
| A34 | انقضای منتورینگ همراه سفارش لوگوی باز | پشتیبانی سفارش و دریافت فایل لوگوی پرداخت‌شده برقرار باشد |

آزمون خودکار برای قواعد حساس دسترسی، سهمیه، پرداخت، تمدید و امتیاز بنویس. ارزیابی UX فرم، موبایل و پیام‌ها با بازبینی عملی انجام شود. داده‌های آزمون ساختگی و مشخص باشند؛ اطلاعات واقعی مشتری در نمونه عمومی استفاده نشود.

## ۲۶. خروجی موردانتظار و ترتیب تحویل

خروجی مرحله طراحی، قبل از هر کدنویسی:

۱. شرح کوتاه محصول، محدوده نسخه اولیه و پیشنهادهای آینده.

۲. فهرست تصمیم‌های پیشنهادی قابل‌تغییر و فقط پرسش‌های مؤثر باقی‌مانده، مانند زیرساخت استقرار، تعرفه‌ها و تعهد پلن‌ها، رنگ برند و ساعات خدمت.

۳. جدول نقش‌ها، وضعیت‌ها و قواعد مجوز؛ گردش کار مشتری، منتور و مدیر.

۴. نقشه صفحات و وایرفریم صفحات اصلی، با تمرکز بر داشبورد مشتری، فرم مرحله‌ای، کارت پروژه منتور، تیکت و تمدید.

۵. فرهنگ فیلدهای فرم: نوع داده، الزامی/اختیاری، شرط نمایش، راهنما، مثال و قواعد اعتبارسنجی.

۶. مدل داده و روابط، مرز ماژول‌ها، برنامه اتصال IPPanel و زیبال، زمان‌بند و شیوه نگهداری فایل.

۷. برنامه مرحله‌ای اجرا و ماتریس پوشش همه نیازمندی‌ها؛ هیچ قابلیت اصلی به‌صورت بی‌اطلاع به «بعداً» منتقل نشود.

پس از تأیید طراحی، تحویل توسعه به این ترتیب پیشنهاد شود: هویت و نقش‌ها → پلن و پروژه → فرم و سهمیه ویرایش → پنل منتور و تیکت → پیامک و زمان‌بند → پرداخت و لوگو و تمدید → نظر و گیمیفیکیشن → گزارش و تکمیل تجربه کاربری. هر مرحله باید کاربرد واقعی و قابل‌بررسی داشته باشد.

بسته نهایی توسعه شامل سورس کامل، ساختار پایگاه داده و مهاجرت‌ها، راهنمای نصب متناسب با هاست منتخب، تنظیمات نمونه بدون کلید واقعی، داده نمایشی اختیاری، راهنمای Cron/صف و فایل‌ها، راهنمای مدیر/منتور/مشتری، فهرست قالب‌های پیامک و گزارش آزمون باشد. اگر نصب‌گر ساخته شد، بعد از نصب قفل شود و مدیر اولیه به‌صورت امن ایجاد شود.

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

معیار موفقیت نهایی این است که مشتری غیرمتخصص بتواند بدون سردرگمی پروژه خود را پیدا کند، اطلاعات واقعی سایتش را مرحله‌ای بفرستد، محدودیت دو ویرایش را بفهمد، با منتور ارتباط بگیرد، زمان و پیشرفت را ببیند، لوگو یا تمدید بخرد و پس از خدمت تجربه خود را ثبت کند؛ همزمان کارکنان و مدیران بتوانند تعهدات، فعالیت‌ها، پرداخت‌ها و کیفیت خدمت را دقیق پیگیری کنند.

---

### یادداشت مراجع

ارجاع‌های وردپرس و ووکامرس برای ساختار هویت سایت و اطلاعات محصولات استفاده شده‌اند؛ قواعد کسب‌وکار مانند دو ویرایش، نحوه تمدید و امتیازها طراحی پیشنهادی این سامانه‌اند و از آن مستندات نقل نشده‌اند. بخش اتصال زیبال و IPPanel مشخصات موردنیاز پیاده‌سازی است؛ تطبیق نهایی قرارداد API، دسترسی حساب، پترن‌های تأییدشده و آزمون عملی اتصال در فاز توسعه انجام می‌شود.
