# پرامپت مادر پروژه: طراحی و پیاده‌سازی سامانه جامع ربات‌ساز و مدیریت ربات‌های بله (Bale No-Code Bot Platform)

## ۱. نقش و مأموریت

تو در نقش یک تیم ارشد توسعه نرم‌افزار شامل معمار سیستم، توسعه‌دهنده Backend، توسعه‌دهنده Frontend، طراح UI/UX، متخصص پایگاه داده، مهندس امنیت، متخصص DevOps و کارشناس API پیام‌رسان بله فعالیت می‌کنی.

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

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

**هدف اصلی:**

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

سامانه باید بر اساس معماری Config-Driven، Metadata-Driven و Workflow-Based طراحی شود.

رفتارهای اختصاصی هر ربات نباید به‌صورت شرط‌های ثابت و پراکنده در کد نوشته شوند.

تغییرات مدیریتی باید تا جای ممکن Data-Driven باشند و با پیکربندی انجام شوند.

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

---

## ۲. منابع رسمی و الزام بررسی API بله

پیش از طراحی معماری و کدنویسی، مستندات رسمی و آخرین وضعیت API پیام‌رسان بله را بررسی کن:

- https://docs.bale.ai/
- https://docs.bale.ai/miniapp
- https://docs.bale.ai/safir
- https://business.bale.ai/

مرجع پایه Bot API:

`https://tapi.bale.ai/bot<TOKEN>/<METHOD_NAME>`

مرجع API کسب‌وکاری، مطابق مستندات:

`https://tapi.bale.ai/business/bot<TOKEN>/<METHOD_NAME>`

نباید فرض کنی تمام متدهای Telegram Bot API بدون تغییر در بله قابل استفاده‌اند.

یک Capability Matrix بساز که مشخص کند:

1. قابلیت رسماً پشتیبانی می‌شود.
2. قابلیت مشروط به مجوز، دسترسی یا نسخه کلاینت است.
3. قابلیت با پیاده‌سازی داخلی خود سامانه ساخته می‌شود.
4. قابلیت نیازمند API خارجی است.
5. پشتیبانی قابلیت هنوز تأیید نشده است.
6. قابلیت فعلاً امکان‌پذیر نیست.

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

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

هیچ قابلیت تأییدنشده‌ای نباید با عنوان «پشتیبانی قطعی بله» معرفی شود.

---

## ۳. معماری کلان پروژه

سامانه را به بخش‌های مستقل ولی یکپارچه تقسیم کن:

1. Web Admin Dashboard
2. Authentication & Authorization
3. Multi-Bot Management
4. Bale API Adapter
5. Webhook & Event Processing
6. Visual Workflow Builder
7. Workflow Execution Engine
8. Dynamic Forms & Data Collection
9. Rules & Conditions Engine
10. Variables & Custom Fields Engine
11. User & CRM Management
12. Inbox & Human Support
13. Message & Content Management
14. Automation & Scheduling
15. Payment & Order Management
16. Mini-App Builder
17. Campaign & Broadcast Management
18. Analytics & Reporting
19. External Integrations
20. Security & Audit Logs
21. Backup & Restore
22. System Configuration & Updates

برای اجزای مختلف، مسئولیت مشخص و قرارداد ارتباطی تعریف کن.

منطق ارتباط با بله باید در Adapter اختصاصی متمرکز شود تا جزئیات API به دیگر قسمت‌های سامانه نشت نکند.

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

سیستم باید امکان افزودن ماژول‌های جدید را بدون بازنویسی هسته داشته باشد.

---

## ۴. انتخاب فناوری

فناوری‌ها را متناسب با شرایط زیر انتخاب کن:

- قابل نصب روی سرور لینوکسی
- قابلیت استفاده از MySQL یا PostgreSQL
- پشتیبانی از پردازش پس‌زمینه و صف وظایف
- سازگاری کامل با HTTPS و Webhook
- توسعه‌پذیری بلندمدت
- امکان تهیه نسخه پشتیبان
- عملکرد مناسب برای چندین ربات و کاربران هم‌زمان
- وابستگی کم به سرویس‌های غیرضروری
- هزینه نگهداری منطقی
- امنیت و پایداری

ترجیح اولیه من استفاده از فناوری‌های شناخته‌شده و پایدار مانند Laravel/PHP برای Backend و Vue یا React برای Frontend است؛ اما انتخاب نهایی را بر اساس بررسی فنی انجام بده.

در انتخاب فناوری این موارد را مقایسه کن:

- قابلیت استقرار روی VPS
- امکان استقرار روی هاست cPanel در صورت سازگاری
- نیازمندی‌های Queue Worker
- نیازمندی‌های Scheduler
- عملکرد در پردازش Webhook
- مدیریت فایل‌های رسانه‌ای
- سهولت پشتیبان‌گیری
- قابلیت توسعه و نگهداری
- امنیت

اگر نسخه تولیدی نیازمند VPS یا پردازشگر دائمی است، صریحاً اعلام کن. برای سازگاری با cPanel راهکار غیرواقعی ارائه نده.

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

---

## ۵. طراحی داشبورد مدیریتی

داشبورد باید کاملاً فارسی، راست‌چین، مدرن، واکنش‌گرا و مناسب استفاده طولانی‌مدت باشد.

ویژگی‌های ظاهری:

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

صفحه اصلی باید شامل موارد زیر باشد:

- تعداد ربات‌های متصل
- تعداد ربات‌های فعال
- تعداد کاربران یکتا
- کاربران فعال روزانه و ماهانه
- تعداد پیام‌های دریافتی و ارسالی
- تعداد کاربران جدید
- فرآیندهای فعال
- خطاهای اخیر
- وضعیت اتصال Webhook
- آمار تکمیل فرم‌ها
- وضعیت پرداخت‌ها
- فعالیت‌های اخیر
- نمودار روند استفاده از ربات‌ها
- گزارش عملکرد هر ربات

آمارها باید از اطلاعات واقعی سیستم محاسبه شوند.

هیچ عدد ساختگی نباید در نسخه عملیاتی نمایش داده شود.

---

## ۶. مدیریت چند ربات

باید بتوانم چندین ربات را در یک داشبورد مرکزی مدیریت کنم.

امکانات این بخش:

- افزودن ربات جدید با توکن دریافتی از BotFather بله
- بررسی اعتبار توکن از طریق getMe
- دریافت نام، شناسه و اطلاعات پایه ربات
- نمایش وضعیت اتصال
- اتصال و تنظیم Webhook
- دریافت وضعیت Webhook
- قطع اتصال ربات
- تعویض توکن
- توقف و راه‌اندازی مجدد پردازش ربات
- تعیین مدیر مسئول هر ربات
- تعیین تنظیمات مستقل
- انتخاب ربات پیش‌فرض
- تعریف پیام خوشامدگویی
- تعریف رفتار دستور /start
- مدیریت پارامترهای Deep Link
- تعیین پیام خطای عمومی
- تعریف رفتار ورودی‌های ناشناخته
- تعریف زمان انقضای نشست
- مدیریت دسترسی‌ها
- کپی تنظیمات و سناریوها از یک ربات به ربات دیگر
- دریافت خروجی پیکربندی یک ربات
- ورود پیکربندی از فایل
- مشاهده گزارش خطا و فعالیت هر ربات

توجه مهم:

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

داشبورد نباید بدون پشتوانه رسمی ادعای ایجاد خودکار حساب ربات داشته باشد.

توکن‌ها باید رمزنگاری شوند و در رابط کاربری یا گزارش‌ها به‌صورت کامل نمایش داده نشوند.

داده‌ها، نشست‌ها، فرآیندها و اطلاعات کاربران هر ربات باید از سایر ربات‌ها تفکیک شوند.

---

## ۷. موتور اصلی ربات‌ساز بدون کدنویسی

این مهم‌ترین قسمت پروژه است.

باید یک Visual Flow Builder با قابلیت Drag & Drop طراحی کنی.

مدیر سیستم بتواند بدون کدنویسی منطق ربات را به‌صورت نمودار جریان بسازد.

هر فرآیند شامل مجموعه‌ای از گره‌ها و ارتباطات میان آن‌ها باشد.

### انواع گره‌های موردنیاز

**Trigger Nodes:**
- دستور /start
- دستور سفارشی
- دریافت پیام متنی
- دریافت عکس
- دریافت فایل
- دریافت پیام صوتی
- دریافت موقعیت
- دریافت مخاطب
- کلیک دکمه
- شروع از Deep Link
- تکمیل فرم
- نتیجه پرداخت
- رویداد گروه یا کانال، در صورت پشتیبانی و دسترسی
- اجرای زمان‌بندی‌شده
- اجرای دستی مدیر
- رویداد دریافتی از سرویس خارجی

**Action Nodes:**
- ارسال پیام
- ارسال عکس
- ارسال ویدئو
- ارسال فایل
- ارسال صوت
- ارسال کیبورد
- حذف کیبورد
- ویرایش پیام
- حذف پیام در صورت دسترسی
- ثبت داده
- به‌روزرسانی فیلد
- افزایش یا کاهش مقدار
- تغییر وضعیت کاربر
- افزودن برچسب
- حذف برچسب
- ارسال اطلاعیه به مدیر
- ساخت درخواست پشتیبانی
- ثبت سفارش
- ایجاد صورتحساب
- اجرای فرآیند دیگر
- توقف فرآیند
- انتقال به منوی اصلی
- فراخوانی HTTP API خارجی

**Logic Nodes:**
- شرط If/Else
- چندشرطی AND/OR
- Switch/Case
- مقایسه اعداد
- مقایسه تاریخ
- بررسی مقدار فیلد
- بررسی نقش کاربر
- بررسی وضعیت فرم
- بررسی وضعیت پرداخت
- بررسی عضویت در گروه یا کانال در صورت امکان فنی
- بررسی تکراری‌بودن ثبت‌نام
- اجرای محاسبات
- انتخاب مسیر بر اساس نتیجه
- محدودسازی دفعات اجرا

**Time Nodes:**
- تأخیر زمانی
- انتظار تا تاریخ مشخص
- اجرای تکرارشونده
- انقضای پاسخ
- یادآوری
- توقف موقت تا دریافت رویداد

**Input Nodes:**
- دریافت متن
- دریافت عدد
- دریافت شماره تماس
- دریافت تاریخ
- دریافت موقعیت
- دریافت تصویر
- دریافت فایل
- انتخاب گزینه
- انتخاب چند گزینه در رابط مناسب
- دریافت داده از مینی‌اپ

### امکانات ویرایشگر

- جابه‌جایی گره‌ها
- اتصال بصری گره‌ها
- بزرگ‌نمایی و کوچک‌نمایی
- Undo و Redo
- کپی و Paste
- Duplicate
- دسته‌بندی گره‌ها
- افزودن توضیح به گره
- اعتبارسنجی قبل از انتشار
- تشخیص مسیرهای ناقص
- تشخیص حلقه‌های نامحدود
- نمایش خطاهای منطقی
- تست فرآیند
- نمایش مسیر اجراشده
- نسخه‌بندی
- ذخیره پیش‌نویس
- انتشار نسخه
- بازگشت به نسخه قبلی

### نکته معماری حیاتی

تعریف جریان باید به شکل داده ساختاریافته و نسخه‌دار در پایگاه داده ذخیره شود.

برای هر اجرای کاربر باید شناسه نشست، شناسه نسخه فرآیند، گره فعلی، وضعیت اجرا، اطلاعات ورودی و متغیرها ثبت شوند.

موتور اجرا باید از کد ثابت فرآیندها جدا باشد.

هنگام انتشار نسخه جدید، اجرای نیمه‌تمام کاربران نباید ناخواسته خراب شود.

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

---

## ۸. منوساز پیشرفته

باید امکان ساخت نامحدود منو و زیرمنو از داشبورد وجود داشته باشد.

هر منو می‌تواند شامل موارد زیر باشد:

- عنوان
- متن توضیح
- تصویر
- ویدئو
- فایل
- دکمه متنی
- دکمه شیشه‌ای
- دکمه لینک
- دکمه callback
- دکمه بازکردن مینی‌اپ
- دکمه کپی متن
- دکمه بازگشت
- دکمه صفحه اصلی
- لینک به فرآیند
- شرط نمایش
- نقش‌های مجاز

مدیر باید بتواند:

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

برای محدودیت‌های API بله، اعتبارسنجی خودکار قرار بده.

---

## ۹. سیستم متغیرها و بانک اطلاعات پویا

باید بتوانم از داشبورد فیلدهای اطلاعاتی جدید تعریف کنم.

مثال:

- نام
- نام خانوادگی
- شماره تماس
- کد ملی
- سن
- شهر
- امتیاز
- موجودی
- تاریخ عضویت
- وضعیت ثبت‌نام
- شناسه سفارش
- گروه کاربری
- اطلاعات دلخواه دیگر

انواع داده:

- String
- Integer
- Decimal
- Boolean
- Date
- DateTime
- JSON ساختاریافته
- Enum
- File Reference
- Relation
- List

هر فیلد باید تنظیمات زیر را داشته باشد:

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

قابلیت درج متغیر در متن پیام:

`سلام {{user.first_name}}`

`امتیاز شما {{user.score}} است.`

`وضعیت سفارش: {{order.status}}`

سیستم باید متغیرهای تعریف‌شده را در زمان اجرا از منبع معتبر استخراج کند.

تغییر ساختار فیلدها نباید باعث از بین رفتن اطلاعات قبلی شود.

برای حذف، تغییر نوع و مهاجرت داده‌ها راهکار ایمن طراحی کن.

---

## ۱۰. فرم‌ساز و پرسشنامه‌ساز

یک ماژول کامل برای ساخت فرم‌ها، آزمون‌ها و پرسشنامه‌ها لازم است.

مدیر بدون برنامه‌نویسی بتواند فرم‌های چندمرحله‌ای طراحی کند.

### انواع سؤال

- پاسخ کوتاه
- پاسخ بلند
- عدد
- شماره تلفن
- ایمیل
- تاریخ
- ساعت
- انتخاب تکی
- انتخاب چندگانه
- بله/خیر
- مقیاس لیکرت
- امتیازدهی ستاره‌ای
- مقیاس عددی
- NPS
- رتبه‌بندی
- ماتریسی
- آپلود عکس
- آپلود فایل
- موقعیت مکانی
- تأیید قوانین و رضایت‌نامه

سؤالات پیچیده‌ای که در رابط چت به‌صورت مناسب قابل نمایش نیستند، باید در مینی‌اپ تحت وب نمایش داده شوند.

### قابلیت‌های فرم‌ساز

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

### موتور امتیازدهی

- امتیاز اختصاصی هر گزینه
- ضریب وزن سؤال
- مجموع امتیاز
- میانگین امتیاز
- امتیاز منفی
- حد نصاب قبولی
- سطح‌بندی نتایج
- محاسبه درصد
- نتایج شرطی
- نمایش تحلیل شخصی
- ارسال نتیجه برای مدیر
- تولید کارنامه
- دریافت خروجی Excel و CSV و PDF

نمونه:

اگر امتیاز کمتر از ۳۰ باشد، نتیجه A نمایش داده شود.

اگر امتیاز بین ۳۰ و ۷۰ باشد، نتیجه B نمایش داده شود.

اگر امتیاز بالاتر از ۷۰ باشد، نتیجه C نمایش داده شود.

قوانین مرزها باید دقیق، بدون هم‌پوشانی ناخواسته و قابل تنظیم باشند.

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

---

## ۱۱. مدیریت کاربران و CRM

برای هر ربات، سیستم مدیریت کاربران بساز.

امکانات:

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

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

نباید فرض شود شناسه عددی بله به معنی دسترسی به شماره تلفن کاربر است.

### دسته‌بندی هوشمند

مدیر بتواند گروه‌های پویا بسازد.

مثلاً:

- کاربران جدید
- کاربران غیرفعال
- کاربران دارای سفارش باز
- کاربران با امتیاز بالای ۸۰
- کاربران یک شهر خاص
- کاربرانی که پرسشنامه را تکمیل نکرده‌اند
- کاربرانی که در یک بازه خرید داشته‌اند

این گروه‌ها باید در اتوماسیون و گزارش‌ها قابل استفاده باشند.

---

## ۱۲. صندوق پیام‌ها و پشتیبانی انسانی

یک Inbox مرکزی طراحی کن.

امکانات:

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

### Human Takeover

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

بعد از پایان پشتیبانی، امکان بازگشت کنترل به ربات وجود داشته باشد.

موتور مکالمه نباید هم‌زمان پاسخ‌های متناقض انسانی و خودکار ایجاد کند.

---

## ۱۳. سیستم قوانین و شرط‌ها

یک Rule Builder گرافیکی طراحی کن.

نمونه قوانین:

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

شرط‌ها باید با ترکیب AND و OR و NOT قابل تعریف باشند.

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

امنیت نقش‌ها و مجوزها باید در Backend اعمال شود، نه فقط با مخفی‌کردن دکمه‌ها.

---

## ۱۴. اتوماسیون و زمان‌بندی

یک موتور مستقل Automation طراحی کن.

امکانات:

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

نمونه‌ها:

- پیام تبریک تولد
- یادآوری نوبت
- پیگیری ثبت‌نام ناقص
- اعلام وضعیت سفارش
- اعلام سررسید پرداخت
- درخواست تکمیل پرسشنامه
- ارسال گزارش روزانه برای مدیر
- فعال یا غیرفعال‌کردن خدمت در زمان تعیین‌شده

زمان‌بندی باید در Queue/Scheduler واقعی انجام شود و وابسته به بازماندن صفحه مرورگر نباشد.

---

## ۱۵. مدیریت پیام‌ها و اطلاع‌رسانی

یک پنل مدیریت پیام ایجاد کن.

قابلیت‌ها:

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

### پیام انبوه

حالت‌های ارسال را تفکیک کن:

1. پیام‌های معمول Bot API
2. پیام‌های API کسب‌وکاری بله
3. سرویس سازمانی سفیر، در صورت داشتن دسترسی قانونی و فنی

این روش‌ها نباید با یکدیگر اشتباه گرفته شوند.

برای هر روش:

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

را مشخص کن.

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

امکان لغو اشتراک پیام‌های اختیاری، مدیریت مخاطبان غیرفعال، صف‌بندی، کنترل سرعت و رعایت پاسخ `retry_after` را فراهم کن.

نباید وضعیت «خوانده‌شده» یا «تحویل قطعی» را در نبود داده رسمی معتبر جعل کنی.

---

## ۱۶. پرداخت و مدیریت سفارش

یک ماژول مستقل پرداخت طراحی کن.

امکانات:

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

قیمت‌ها را در واحد صحیح مالی نگهداری کن و تبدیل نمایشی ریال/تومان را شفاف انجام بده.

تأیید سفارش تنها پس از تأیید معتبر پرداخت باشد.

دریافت PreCheckout به‌تنهایی نشانه پرداخت موفق نیست.

برای پردازش این رویداد، الزام پاسخ سریع مستند بله را رعایت کن.

از Idempotency و تراکنش پایگاه داده برای جلوگیری از ثبت چندباره پرداخت استفاده کن.

توکن پرداخت در تنظیمات امن ذخیره شود.

---

## ۱۷. مینی‌اپ‌ساز بله

یک زیرسیستم Mini-App Builder قابل اتصال به ربات طراحی کن.

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

اجزای قابل استفاده:

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

مدیر بتواند ترتیب بخش‌ها، ظاهر، برچسب‌ها، داده‌های متصل و اقدامات دکمه‌ها را تغییر دهد.

ویژگی‌ها:

- طراحی Mobile First
- سازگاری با تم بله
- احراز هویت معتبر از طریق initData
- بررسی صحت امضا در سرور
- کنترل زمان اعتبار
- رعایت مجوز کاربران
- انتقال امن داده به Backend
- ذخیره اطلاعات فرم‌ها
- اتصال به موتور Workflow
- بازکردن مینی‌اپ از دکمه ربات
- نمایش پیش‌نمایش قبل از انتشار

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

امکان ساخت مینی‌اپ اصلی برای هر ربات با تنظیمات مستقل پیش‌بینی شود.

---

## ۱۸. مدیریت گروه‌ها و کانال‌ها

امکانات مدیریتی مجاز بله را بررسی و پیاده‌سازی کن:

- ثبت گروه یا کانال
- بررسی اطلاعات گفتگو
- بررسی سطح دسترسی ربات
- فهرست مدیران در صورت پشتیبانی
- بررسی وضعیت عضویت کاربر
- ارسال پیام
- حذف پیام مجاز
- سنجاق و لغو سنجاق
- تنظیم اطلاعات گروه در صورت داشتن دسترسی
- ایجاد یا مدیریت لینک دعوت
- مدیریت اعضا مطابق API رسمی و مجوزهای واقعی
- تعریف پاسخ خودکار
- تعریف قوانین محتوایی در محدوده رویدادهای قابل دریافت

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

هیچ امکان دورزدن محدودیت‌های بله یا دریافت اطلاعات غیرمجاز را طراحی نکن.

---

## ۱۹. اتصال به هوش مصنوعی

یک ماژول AI Integration اختیاری طراحی کن.

هدف: بتوانم برای هر ربات، دستیار هوشمند تعریف کنم.

امکانات:

- اتصال به API ارائه‌دهنده هوش مصنوعی
- انتخاب ارائه‌دهنده
- تعیین مدل
- ثبت کلید API به‌صورت رمزنگاری‌شده
- تعریف System Prompt اختصاصی
- تعیین نقش دستیار
- تنظیم پاسخ‌دهی
- محدودیت مصرف
- تعیین سقف هزینه
- فعال یا غیرفعال‌سازی
- تعیین گروه کاربران مجاز
- اتصال به محتوای FAQ یا پایگاه دانش
- امکان ارجاع به اپراتور
- ثبت خطا و مصرف

مدیر باید بتواند متن راهنمای هوش مصنوعی را تغییر دهد، بدون نیاز به تغییر سورس.

اطلاعات حساس نباید بدون مبنای مجاز و آگاهی مدیر به سرویس خارجی ارسال شود.

برای پاسخ‌های پرریسک، قابلیت تأیید انسانی و محدودیت دسترسی تعریف کن.

---

## ۲۰. اتصال به سامانه‌های خارجی

یک Integration Builder بساز.

مدیر بتواند بدون نوشتن کد برای رویدادهای متداول اتصال HTTP/API ایجاد کند.

امکانات:

- GET
- POST
- PUT
- PATCH
- DELETE
- Webhook ورودی
- Webhook خروجی
- تنظیم Header
- تنظیم Authentication
- Body Template
- JSON Mapping
- اتصال فیلدهای ربات به پاسخ API
- مدیریت timeout
- retry
- گزارش خطا
- تست اتصال
- ذخیره تنظیمات امن

نمونه کاربردها:

- اتصال به سایت
- اتصال به CRM
- اتصال به سیستم سفارش
- اتصال به سرویس پیامک
- اتصال به درگاه پرداخت
- اتصال به سامانه آموزشی
- دریافت اطلاعات از API اختصاصی

در طراحی امنیتی:

- امکان اجرای آزاد کد روی سرور وجود نداشته باشد.
- دسترسی به شبکه داخلی و آدرس‌های حساس با حفاظت SSRF کنترل شود.
- کلیدهای API محافظت شوند.
- Webhookها احراز هویت و اعتبارسنجی شوند.
- خروجی‌های خارجی غیرقابل اعتماد فرض شوند.

برای توسعه‌پذیری، قرارداد مشخص Plugin/Connector تعریف کن.

---

## ۲۱. گزارش‌ساز پیشرفته

یک Report Builder طراحی کن که مدیر بتواند گزارش‌های جدید را بدون برنامه‌نویسی بسازد.

قابلیت‌ها:

- انتخاب منبع داده
- انتخاب ستون‌ها
- فیلترگذاری
- گروه‌بندی
- مرتب‌سازی
- محاسبه مجموع
- میانگین
- شمارش
- درصد
- حداقل و حداکثر
- مقایسه بازه‌های زمانی
- ساخت نمودار
- ذخیره گزارش
- تعریف گزارش شخصی
- اشتراک گزارش با مدیر مجاز
- زمان‌بندی تهیه گزارش
- خروجی Excel
- خروجی CSV
- خروجی PDF

انواع گزارش پیش‌فرض:

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

گزارش‌ساز باید به فیلدهای سفارشی و داده‌های فرم‌ها هم دسترسی کنترل‌شده داشته باشد.

برای امنیت، امکان اجرای SQL خام از طریق رابط مدیریتی عادی وجود نداشته باشد.

---

## ۲۲. مدیریت نقش‌ها و سطح دسترسی

نقش‌های پیشنهادی:

- Super Admin
- System Administrator
- Bot Owner
- Bot Manager
- Content Manager
- Support Operator
- Financial Manager
- Report Viewer

سیستم RBAC طراحی کن.

سطوح دسترسی باید قابل تعریف و ویرایش باشند.

مثال:

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

تمام کنترل‌های دسترسی باید سمت سرور اعمال شوند.

---

## ۲۳. تنظیمات عمومی سامانه

یک صفحه کامل تنظیمات داشته باشیم.

بخش‌های پیشنهادی:

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

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

---

## ۲۴. سیستم پشتیبان‌گیری و بروزرسانی

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

قابلیت‌ها:

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

### آپدیت نرم‌افزار

- نمایش نسخه فعلی
- نمایش نسخه جدید
- ثبت تاریخچه تغییرات
- بررسی سازگاری
- پشتیبان‌گیری قبل از بروزرسانی
- اجرای Migration ایمن
- گزارش نتیجه بروزرسانی
- راهکار بازگشت در صورت شکست

نکته مهم:

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

Rollback کد و Rollback دیتابیس را از نظر محدودیت‌های فنی جداگانه طراحی کن.

عملیات مخرب باید قبل از اجرا هشدار و تأیید مناسب داشته باشند.

---

## ۲۵. امنیت و پایداری

موارد الزامی:

- HTTPS
- احراز هویت امن
- رمزنگاری توکن‌ها
- Hash امن گذرواژه‌ها
- RBAC
- CSRF Protection در موارد مربوط
- XSS Protection
- SQL Injection Protection
- Rate Limiting
- Audit Logging
- مدیریت نشست
- کنترل فایل‌های آپلودی
- اعتبارسنجی ورودی‌ها
- جلوگیری از پردازش تکراری Webhook
- جلوگیری از ارسال تکراری پرداخت و اعلان
- حفاظت از داده‌های شخصی
- جداسازی داده‌های ربات‌ها
- مدیریت خطا
- سیستم سلامت سرویس‌ها
- ثبت وضعیت Workerها
- پایش صف‌های پردازش
- محدودسازی مصرف منابع

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

برای Updateها از شناسه یکتا و سازوکار Idempotency استفاده شود.

رویدادهای خارج از ترتیب و اجرای هم‌زمان برای یک کاربر مدیریت شوند.

از قفل‌گذاری مناسب، تراکنش دیتابیس و سیاست مدیریت رقابت هم‌زمان استفاده کن.

در Logها نباید توکن‌ها، رمزهای عبور یا داده‌های حساس بدون محافظت ثبت شوند.

---

## ۲۶. ساختار پایگاه داده

برای نسخه اولیه ساختار داده کامل و قابل توسعه تعریف کن.

موجودیت‌های اصلی پیشنهادی:

- administrators
- roles
- permissions
- bots
- bot_settings
- bot_tokens
- bot_users
- bot_chats
- user_custom_fields
- custom_field_definitions
- user_tags
- tags
- menus
- menu_items
- workflows
- workflow_versions
- workflow_nodes
- workflow_edges
- workflow_executions
- workflow_sessions
- workflow_variables
- rules
- triggers
- actions
- forms
- form_versions
- form_questions
- form_options
- form_submissions
- form_answers
- score_rules
- messages
- message_templates
- inbound_updates
- outbound_jobs
- conversations
- support_tickets
- campaigns
- schedules
- products
- orders
- payments
- transactions
- miniapps
- miniapp_pages
- integrations
- integration_credentials
- reports
- audit_logs
- system_logs
- backups
- settings

این فهرست صرفاً نقطه شروع معماری است.

قبل از پیاده‌سازی، روابط، کلیدهای خارجی، ایندکس‌ها، سیاست حذف داده، Versioning و Migrationها را طراحی کن.

از ایجاد جدول‌های زائد جلوگیری کن و در عین حال توسعه‌پذیری فیلدها را حفظ کن.

---

## ۲۷. سیستم قالب‌های آماده ربات

یک Template Library ایجاد کن.

قالب‌های اولیه:

1. ربات ثبت‌نام کاربران
2. ربات پرسشنامه و نظرسنجی
3. ربات آزمون و امتیازدهی
4. ربات نوبت‌دهی
5. ربات پشتیبانی
6. ربات فروش محصول
7. ربات اطلاع‌رسانی
8. ربات مدیریت درخواست‌ها
9. ربات مدیریت اعضا
10. ربات خدمات آموزشی

هر قالب باید شامل منوها، فرآیندها، فیلدها و تنظیمات اولیه باشد.

مدیر بتواند قالب را انتخاب کرده، آن را کپی کند و بدون برنامه‌نویسی تغییر دهد.

قالب‌ها نباید به یک ربات خاص وابسته باشند.

---

## ۲۸. فرآیندهای آزمایشی الزامی

قبل از اعلام آماده‌بودن سامانه، حداقل سناریوهای زیر را به‌صورت واقعی و انتهابه‌انتها پیاده‌سازی و تست کن.

### سناریو A: ثبت‌نام

کاربر /start را ارسال می‌کند.

ربات پیام خوشامدگویی نمایش می‌دهد.

کاربر ثبت‌نام را انتخاب می‌کند.

نام، نام خانوادگی و شماره تماس به‌صورت معتبر دریافت می‌شوند.

اطلاعات در پایگاه داده ثبت می‌شوند.

ربات پیام موفقیت نمایش می‌دهد.

مدیر اطلاعات را در داشبورد مشاهده می‌کند.

### سناریو B: فرم امتیازدار

مدیر یک فرم با پنج سؤال طراحی می‌کند.

برای گزینه‌ها امتیاز تعیین می‌کند.

کاربر پاسخ می‌دهد.

سامانه امتیاز نهایی را محاسبه می‌کند.

نتیجه نمایش داده می‌شود.

مدیر گزارش و نمودار پاسخ‌ها را مشاهده می‌کند.

### سناریو C: اتوماسیون

کاربر فرم را نیمه‌تمام رها می‌کند.

پس از مدت تعیین‌شده، سیستم شرایط را مجدداً بررسی می‌کند.

در صورت مجازبودن و رعایت محدودیت ارسال بله، یادآوری ارسال می‌شود.

اگر فرم قبلاً تکمیل شده باشد، یادآوری نباید ارسال شود.

### سناریو D: پرداخت

کاربر یک خدمت را انتخاب می‌کند.

صورتحساب صادر می‌شود.

پرداخت انجام می‌شود.

وضعیت تراکنش بررسی می‌شود.

بعد از تأیید معتبر، سفارش تکمیل و دسترسی فعال می‌شود.

### سناریو E: پشتیبانی انسانی

کاربر درخواست پشتیبانی می‌دهد.

گفتگو وارد Inbox می‌شود.

اپراتور پاسخ می‌دهد.

پاسخ خودکار مرتبط موقتاً متوقف می‌شود.

بعد از پایان پشتیبانی، فرآیند ربات ادامه می‌یابد.

### سناریو F: چندرباتی

دو ربات با تنظیمات مستقل متصل می‌شوند.

هر ربات کاربران، منوها، فرآیندها و گزارش‌های مستقل دارد.

هیچ داده‌ای از یک ربات بدون مجوز در ربات دیگر نمایش داده نمی‌شود.

### سناریو G: تغییر فرآیند بدون کدنویسی

مدیر از طریق پنل یک سؤال جدید به فرم اضافه می‌کند.

یک شرط جدید تعریف می‌کند.

متن پیام را تغییر می‌دهد.

نسخه جدید منتشر می‌شود.

ربات با منطق جدید کار می‌کند، بدون ویرایش هیچ فایل کد.

### سناریو H: تغییر نسخه و بازیابی

مدیر از پیکربندی ربات خروجی می‌گیرد.

یک تغییر ناسازگار را در پیش‌نمایش تشخیص می‌دهد.

نسخه قبلی منتشرشده را بازمی‌گرداند.

داده‌های ثبت‌شده کاربران سالم باقی می‌مانند.

---

## ۲۹. شرایط پذیرش پروژه

پروژه فقط زمانی قابل قبول است که:

1. داشبورد واقعاً به API بله متصل شود.
2. بتوان ربات جدید را با توکن معتبر متصل کرد.
3. بتوان منوی جدید را بدون تغییر کد ساخت.
4. بتوان فرآیند جدید را با ویرایشگر بصری طراحی کرد.
5. فرآیندها از داده ذخیره‌شده در پایگاه داده اجرا شوند.
6. فرم‌ها و فیلدهای سفارشی واقعاً کار کنند.
7. اطلاعات کاربران به‌درستی ثبت و بازیابی شوند.
8. گزارش‌ها بر اساس اطلاعات واقعی تولید شوند.
9. مدیریت چند ربات دارای جداسازی داده باشد.
10. ارسال پیام‌ها از صف قابل پایش استفاده کند.
11. خطاهای API ثبت و مدیریت شوند.
12. مکانیزم ضدتکرار رویدادها فعال باشد.
13. مدیریت دسترسی‌ها در Backend اعمال شود.
14. نصب و راه‌اندازی مستند و قابل تکرار باشد.
15. پشتیبان‌گیری و بازیابی آزمایش شوند.
16. تغییرات معمول ربات از داخل داشبورد قابل انجام باشند.
17. فرآیند انتشار نسخه جدید ایمن باشد.
18. بخش‌های نمایشی و Placeholder به‌عنوان قابلیت تکمیل‌شده معرفی نشوند.

---

## ۳۰. روش اجرای پروژه توسط تو

پروژه را منظم و مرحله‌ای اجرا کن.

### فاز صفر: تحلیل فنی

خروجی:

- بررسی مستندات بله
- فهرست قابلیت‌های تأییدشده
- فهرست محدودیت‌ها
- تحلیل نیازمندی‌ها
- انتخاب فناوری
- معماری کلان
- شناسایی ریسک‌ها
- طراحی مسیر توسعه

### فاز اول: طراحی زیرساخت

خروجی:

- ساختار پروژه
- طراحی پایگاه داده
- Migrationها
- احراز هویت
- نقش‌ها
- اتصال بله
- Webhook
- Queue
- تنظیمات پایه
- تست‌های زیرساخت

### فاز دوم: موتور ربات

خروجی:

- مدیریت ربات‌ها
- موتور رویداد
- موتور متغیرها
- موتور قوانین
- موتور اجرای فرآیند
- ذخیره نشست
- منوساز
- ویرایشگر گرافیکی
- تست و انتشار فرآیند

### فاز سوم: ماژول‌های کاربردی

خروجی:

- فرم‌ساز
- مدیریت کاربران
- Inbox
- قالب پیام
- اتوماسیون
- ارسال انبوه کنترل‌شده
- گزارش‌ها
- قالب‌های آماده

### فاز چهارم: قابلیت‌های پیشرفته

خروجی:

- پرداخت
- مینی‌اپ
- هوش مصنوعی
- اتصال API خارجی
- امکانات گروه و کانال
- گزارش‌ساز پیشرفته

### فاز پنجم: آماده‌سازی تولید

خروجی:

- تست‌های امنیتی
- تست یکپارچگی
- تست فشار متناسب با نیاز
- بررسی خطاها
- پشتیبان‌گیری
- روش بازیابی
- مستندات نصب
- مستندات استفاده
- بسته قابل استقرار

هر فاز باید خروجی اجرایی، قابل آزمون و قابل ادامه داشته باشد.

---

## ۳۱. قوانین سخت‌گیرانه توسعه

این قوانین را در تمام مراحل رعایت کن:

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

**قانون دوم:** تغییرات مدیریتی نباید نیازمند ویرایش مستقیم کد باشند، مگر در مواردی که توسعه زیرساخت یا قابلیت فنی جدید واقعاً ضروری است.

**قانون سوم:** از داده آزمایشی برای نمایش عملکرد واقعی استفاده نکن. محیط توسعه و تولید را جدا کن.

**قانون چهارم:** از Hardcode کردن توکن‌ها، شناسه کاربران، منوها، متن پیام‌ها و قوانین کسب‌وکار خودداری کن.

**قانون پنجم:** پیش از اعمال تغییر مهم در دیتابیس یا معماری، اثر آن بر داده‌های موجود را ارزیابی کن.

**قانون ششم:** هیچ داده واقعی کاربر نباید در فرآیند بروزرسانی حذف یا جایگزین شود، مگر با عملیات صریح و مجاز.

**قانون هفتم:** در هر فاز، تست‌های خودکار مرتبط را اضافه کن.

**قانون هشتم:** از توابع و کلاس‌های قابل استفاده مجدد استفاده کن و از تکرار منطق جلوگیری کن.

**قانون نهم:** تنظیمات API، محدودیت‌ها، ساختار پاسخ‌ها و رفتارهای اختصاصی بله را مستند کن.

**قانون دهم:** در مورد قابلیت‌های پشتیبانی‌نشده یا تأییدنشده، ادعای نادرست نکن.

**قانون یازدهم:** رابط فارسی و تجربه کاربری مدیر غیرمتخصص را در اولویت قرار بده.

**قانون دوازدهم:** زیرساخت باید قابلیت توسعه داشته باشد، اما از پیچیدگی غیرضروری جلوگیری کن.

**قانون سیزدهم:** امکان انتشار تغییرات، مشاهده خطا و بازگشت به نسخه قبلی باید پیش‌بینی شود.

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

**قانون پانزدهم:** هر بخش باید همراه با وضعیت پیاده‌سازی و نتیجه تست گزارش شود.

---

## ۳۲. نحوه تحویل خروجی

در فرآیند توسعه، خروجی‌ها را به‌صورت ساختاریافته ارائه کن:

1. سند معماری
2. نمودار معماری
3. دیاگرام ERD پایگاه داده
4. نمودار فرآیند اجرای Webhook
5. نمودار موتور Workflow
6. ساختار پوشه‌ها
7. سورس Backend
8. سورس Frontend
9. Migrationها
10. تنظیمات نمونه محیطی
11. تست‌های خودکار
12. راهنمای نصب
13. راهنمای استقرار
14. راهنمای اتصال ربات بله
15. راهنمای مدیریت و ساخت فرآیند
16. راهنمای پشتیبان‌گیری
17. گزارش تست
18. فهرست قابلیت‌های تکمیل‌شده و باقی‌مانده

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

در صورت امکان، بسته ZIP قابل نصب و سورس کامل قابل اجرا ارائه بده.

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

از تحویل شبه‌کد به‌عنوان سورس نهایی خودداری کن.

---

## ۳۳. الزام مستندسازی برای Codex و توسعه آینده

از ابتدای پروژه فایل‌های راهنمای توسعه و معماری بساز.

حداقل:

- `README.md`
- `AGENTS.md`
- `ARCHITECTURE.md`
- `DATABASE.md`
- `BALE_API_CAPABILITIES.md`
- `WORKFLOW_ENGINE.md`
- `SECURITY.md`
- `DEPLOYMENT.md`
- `CHANGELOG.md`

در فایل AGENTS.md قوانین ثابت توسعه را ثبت کن، شامل:

- نحوه افزودن ماژول
- ساختار استاندارد کد
- قوانین حفظ داده‌ها
- نحوه ایجاد Migration
- روش افزودن گره جدید به موتور Workflow
- روش افزودن API Adapter
- قوانین امنیتی
- نحوه تست
- نحوه Commit
- فرایند انتشار
- نحوه Rollback

این فایل باید امکان ادامه توسعه با ChatGPT یا Codex در جلسات بعدی را فراهم کند.

---

## ۳۴. اولویت نهایی

این سامانه نباید فقط یک ربات مشخص بسازد.

باید «ابزار ساخت ربات» باشد.

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

برای تحقق این هدف، اولویت اصلی را به این ترتیب قرار بده:

1. معماری صحیح
2. موتور فرآیند قابل تنظیم
3. امنیت و یکپارچگی داده
4. قابلیت مدیریت بدون کدنویسی
5. قابلیت توسعه
6. سهولت استفاده
7. پایداری
8. زیبایی رابط کاربری

هیچ‌گاه ظاهر داشبورد را به عملکرد واقعی ترجیح نده.

---

## ۳۵. دستور شروع

اکنون پروژه را آغاز کن.

در اولین مرحله:

1. مستندات رسمی بله را بررسی کن.
2. فهرست دقیق APIهای قابل استفاده را تهیه کن.
3. قابلیت‌های داخلی موردنیاز و قابلیت‌های وابسته به API خارجی را جدا کن.
4. معماری فنی نهایی را انتخاب کن.
5. دیتابیس و روابط اصلی را طراحی کن.
6. ماژول‌های مستقل سیستم را مشخص کن.
7. نقشه مسیر پیاده‌سازی و تست را آماده کن.
8. سپس پیاده‌سازی واقعی فاز اول را آغاز کن.

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

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

پروژه را در مسیر ساخت یک محصول نهایی واقعی پیش ببر.

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