الف) کنسول ادمین برای چیه، و برای چی نیست

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

این کنسول یک ابزار مدیریت مالی یا سرمایه‌گذاری نیست. تصمیم‌های سرمایه‌گذاری، توصیه‌ها، و پروفایل مالی هر کاربر کاملاً در اختیار همون کاربره؛ ادمین به محتوای مالی/پرتفوی کاربران در این کنسول دسترسی ندارد.

از فاز ۴.۵C.۳، کنسول ادمین یک جهش کنترل‌شده و محدود داره: فعال/غیرفعال‌کردن یک ارائه‌دهنده و تغییر اولویت مسیریابی‌اش (به‌علاوهٔ تنظیم نرخ تورم ایران که از قبل، مستقل از این فاز، وجود داشته). هیچ دکمه‌ای برای تغییر مدل‌ها، کاربران، نقش ادمین، یا هر چیز دیگه‌ای در این کنسول وجود نداره.

ب) مرز اختیارات: ادمین در برابر کاربر

• کنترل عملیاتی مال ادمینه. یعنی این‌که چه ارائه‌دهنده‌ای تنظیم شده، وضعیت فنی چیه، و چه خطاهایی ثبت شده.
• تجربهٔ سرمایه‌گذاری مال کاربره. پروفایل مالی، دارایی‌ها، اهداف، و تحلیل‌های هوش مصنوعیِ شخصی‌شده فقط مال همون کاربره.

ادمین هیچ‌وقت نباید یک توصیهٔ سرمایه‌گذاری رو دستی بازنویسی یا لغو کنه. حقیقتِ مالی، مدل‌های کمّی، فرمول‌های ریسک، grounding، و guardrail‌های تحلیل، همه متعلق به منطق خودِ My Invest هستن — نه چیزی که ادمین از این کنسول تغییرش بده.

پ) احراز هویت در برابر تفویض اختیار

احراز هویت (Authentication) یعنی سامانه مطمئن بشه شما همونی هستید که می‌گید — با نام کاربری/رمز عبور و توکن ورود.

تفویض اختیار (Authorization) یعنی، حالا که هویتتون تأیید شده، چه کاری اجازه دارید انجام بدید.

نکتهٔ مهم: این‌که دکمهٔ «پنل ادمین» توی منو دیده بشه یا نه، فقط یک راحتیِ رابط کاربریه — مرز امنیتیِ واقعی همیشه سمت سرور است. حتی اگه یک کاربر عادی به‌نحوی همین دکمه رو ببینه، هر درخواستی که به آدرس‌های /api/admin/* بزنه، سمت سرور و مستقل از رابط کاربری، رد می‌شه.

ت) ارائه‌دهنده (Provider) در برابر مدل (Model)

ارائه‌دهنده یک سرویس‌دهندهٔ هوش مصنوعیه (مثلاً Groq) — چیزیه که کلید API و اتصال شبکه براش تنظیم می‌شه.

مدل یک نسخهٔ مشخص از قابلیت هوش مصنوعیه که زیرِ یک ارائه‌دهنده اجرا می‌شه (مثلاً یک مدل خاص زیرِ Groq). یک ارائه‌دهنده می‌تونه چند مدل داشته باشه؛ این دو مفهوم هیچ‌وقت یکی نیستن.

ث) مفاهیم عملیاتیِ ارائه‌دهنده

• Configured (تنظیم‌شده): کلید API این ارائه‌دهنده در محیط سرور تعریف شده.
• Enabled (فعال): این ارائه‌دهنده در فهرست ارائه‌دهندگانِ قابل‌استفادهٔ سامانه حضور داره.
• Priority (اولویت): ترتیبی که سامانه ارائه‌دهندگان رو برای تلاش امتحان می‌کنه.
• شواهد عملیاتی (Operational Evidence): آخرین زمان تلاش/موفقیت/شکست، و شمار محدودیت نرخ یا اتمام سهمیه — همه‌شون فقط از رویدادهای واقعیِ ثبت‌شده استخراج می‌شن.

نکتهٔ حیاتی: «Configured» به‌معنای «سالم» نیست. «Enabled» به‌معنای «در دسترس» نیست. «بدون شکستِ اخیر» هم به‌معنای «سالم» نیست — ممکنه صرفاً هنوز هیچ تلاشی ثبت نشده باشه. وقتی هیچ رویدادی برای یک ارائه‌دهنده ثبت نشده، وضعیتش نامشخص نمایش داده می‌شه، نه «سالم» و نه «صفر».

سه لایه‌ی پیکربندی (از فاز ۴.۵C.۳):

• پیش‌فرض کد (Registry Default): مقداری که خودِ کد سامانه برای این ارائه‌دهنده تعریف کرده — هیچ‌وقت از طریق کنسول ادمین تغییر نمی‌کنه.
• بازنویسیِ ادمین (Admin Override): مقداری که یک مدیر سامانه از همین کنسول برای فعال‌بودن یا اولویت این ارائه‌دهنده ثبت کرده — به‌صورت پایدار ذخیره می‌شه و مستقل از ری‌استارت سرویس باقی می‌مونه.
• وضعیت مؤثر (Effective State): چیزی که سامانه واقعاً هنگام مسیریابی درخواست‌ها استفاده می‌کنه — اگر بازنویسیِ ادمین وجود داشته باشه، همون اعمال می‌شه؛ وگرنه پیش‌فرض کد.

سازگاریِ جهش و تاریخچه: هیچ تغییری بدون ثبت یک رویداد تاریخچه (audit) موفق تلقی نمی‌شه — اگر ثبت تاریخچه با خطا مواجه بشه، خودِ تغییر هم اعمال نمی‌شه و وضعیت مؤثر دست‌نخورده می‌مونه.

ج) مفاهیم مصرف

• درخواست منطقی (Logical Request): یک درخواست واقعیِ کاربر برای تحلیل هوش مصنوعی.
• تلاش ارائه‌دهنده (Provider Attempt): یک بار تلاش برای اجرای آن درخواست روی یک ارائه‌دهندهٔ مشخص.
• رویداد مصرف (Usage Event): رکورد ثبت‌شدهٔ یک تلاشِ ارائه‌دهنده — موفق یا ناموفق.
• مصرف نرمال‌شده (Normalized Usage): واحدهای ورودی/خروجی/کل، به‌شکلی مستقل از قرارداد خاص هر ارائه‌دهنده.

یک درخواست منطقی می‌تونه در آینده (وقتی fallback بین چند ارائه‌دهنده فعال بشه) چند تلاش ارائه‌دهنده داشته باشه — مثلاً یکی محدودیت نرخ بخوره و بعدی موفق بشه. به همین دلیل، شمارشِ «رویداد مصرف» هیچ‌وقت معادل شمارشِ «درخواست کاربر» نیست؛ همیشه بزرگ‌تر یا مساوی‌شه.

چ) مفاهیم هزینه

• اندازه‌گیریِ مصرف ≠ صورت‌حساب مشتری. ثبت مصرف یک رویداد فنیه، نه یک رویداد مالی.
• هزینهٔ ارائه‌دهنده ≠ مبلغ دریافتی از کاربر. این سامانه فعلاً هیچ مدل تجاری/قیمت‌گذاری‌ای برای کاربران نداره.
• رویداد مصرف ≠ رویداد صورت‌حساب. این دو مفهوم کاملاً جداگانه‌ان و در آینده هم ادغام نمی‌شن مگر با طراحی جداگانه.

جدول قیمت‌گذاری این استقرار فعلاً خالیه. وقتی قیمت تنظیم نشده، هزینهٔ برآوردی نامشخص نمایش داده می‌شه — هیچ‌وقت به‌صورت «۰» یا «رایگان» نمایش داده نمی‌شه، چون نبودِ اندازه‌گیری با اندازه‌گیریِ صفر یکی نیست.

ح) تله‌متری و کدهای وضعیت

• RATE_LIMITED: ارائه‌دهنده موقتاً محدودیت نرخ درخواست اعمال کرده.
• QUOTA_EXHAUSTED: سهمیهٔ تخصیصی نزد ارائه‌دهنده تمام شده.
• TIMEOUT: پاسخ ارائه‌دهنده در زمان مجاز نرسیده.
• PROVIDER_UNAVAILABLE: خطای شبکه/در‌دسترس‌نبودن ارائه‌دهنده.
• AUTH_ERROR: خطای احراز هویت با ارائه‌دهنده (مثلاً کلید نامعتبر).
• CONFIG_ERROR: خطای پیکربندی سمت سامانهٔ ما (مثلاً کلید اصلاً تنظیم نشده).
• RESPONSE_ERROR: پاسخ ارائه‌دهنده قابل‌اعتماد/معتبر نبود.

نبودِ تله‌متری برای یک رویداد به‌معنای «سالم» نیست — به‌معنای اینه که آن ارائه‌دهنده در آن تلاشِ خاص، هیچ دادهٔ عملیاتیِ قابل‌استنادی برنگردونده. چنین مواردی همیشه نامشخص باقی می‌مونن.

خ) اسرار و امنیت

• کلید API و هر مقدار محرمانه‌ای هیچ‌وقت در کنسول ادمین نمایش داده نمی‌شه — نه به‌صورت کامل، نه بخشی از آن.
• مقادیر محرمانه هیچ‌وقت در لاگ‌های سامانه ثبت نمی‌شن.
• چرخش (Rotate) کلید یک رویهٔ امنیتیِ عملیاتیه که فعلاً به‌صورت دستی و مستقیم روی سرور انجام می‌شه — نه از طریق این کنسول.
• هر قابلیت مدیریت اسرار در آینده (مثلاً چرخش از داخل کنسول) نیازمند یک طراحی امنیتیِ صریح و جداگانه‌ست، پیش از هر پیاده‌سازی.

د) حریم خصوصی: عملیاتی در برابر مالی/شخصی در برابر محرمانه

• دادهٔ عملیاتی (مثلاً شمار تلاش‌های ارائه‌دهنده، وضعیت تله‌متری) — قابل‌مشاهده برای ادمین، چون به سلامت خودِ سامانه مربوطه.
• دادهٔ مالی/شخصیِ کاربر (پرتفوی، درآمد/هزینه، اهداف، متن کامل تحلیل هوش مصنوعی) — این کنسول عمداً به این داده‌ها دسترسی نمی‌ده.
• دادهٔ محرمانه (کلید API، هدرهای خام، Authorization، کوکی) — هیچ‌وقت، در هیچ بخشی از این کنسول، نمایش داده نمی‌شه.

ذ) محدودیت‌های فعلی

• تنها جهش‌های ادمینِ پیاده‌سازی‌شده، فعال/غیرفعال‌کردن و تغییر اولویتِ یک ارائه‌دهنده‌ست (از فاز ۴.۵C.۳) — همین دو مورد.
• هیچ جهشی روی مدل، کاربر، نقش ادمین، طرح/اشتراک، یا قیمت‌گذاری پیاده‌سازی نشده.
• هیچ پایشِ فعال (polling) روی ارائه‌دهندگان انجام نمی‌شه؛ هیچ مسیریابیِ خودکارِ مبتنی‌بر سلامت هم وجود نداره.
• هیچ گزینهٔ «دور زدنِ اضطراری» برای محافظِ آخرین ارائه‌دهنده وجود نداره — این محافظ همیشه فعاله.
• برآورد هزینه وقتی جدول قیمت‌گذاری تنظیم نشده، در دسترس نیست (نامشخص، نه صفر).
• خلاصهٔ مصرف فقط روی ۵٬۰۰۰ رویدادِ اخیر محاسبه می‌شه، نه کل تاریخچه.
• وضعیت عملیاتی هر ارائه‌دهنده کاملاً وابسته به شواهد واقعیِ ثبت‌شده‌ست — بدون شواهد، وضعیت نامشخص می‌مونه.
• نمای تاریخچهٔ تغییرات (audit) فقط عملیات ارائه‌دهنده رو پوشش می‌ده، نه یک سامانهٔ عمومیِ حسابرسی.

ر) رویهٔ عملیاتی: فعال/غیرفعال‌کردن امن یک ارائه‌دهنده

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

«فعال (Enabled)» یعنی چه: این ارائه‌دهنده در فهرست ارائه‌دهندگانِ قابل‌انتخابِ سامانه حضور داره. غیرفعال‌کردن، ارائه‌دهنده رو از مسیریابی زندهٔ درخواست‌ها خارج می‌کنه — کلید API یا تعریف مدل‌هاش حذف نمی‌شه.

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

الزام دلیل: برای غیرفعال‌کردن، وارد کردن دلیل الزامیه — این دلیل در تاریخچهٔ تغییرات ثبت می‌شه و بعداً قابل‌بازبینیه. برای فعال‌کردن دوباره، دلیل اختیاریه.

اثر روی مسیریابی: بلافاصله بعد از ثبت موفق، وضعیت مؤثر عوض می‌شه و مسیریابیِ درخواست‌های بعدی از همون لحظه طبق وضعیت جدید انجام می‌شه — نیازی به ری‌استارت سرویس نیست.

محافظِ آخرین ارائه‌دهنده: اگر غیرفعال‌کردن باعث بشه هیچ ارائه‌دهندهٔ قابل‌استفاده‌ای (فعال و دارای کلید تنظیم‌شده) باقی نمونه، سرور خودش عملیات رو رد می‌کنه — هیچ راه دور زدنی برای این محافظ در این کنسول وجود نداره.

تأیید پس از تغییر: بعد از ثبت، فهرست ارائه‌دهندگان و تاریخچهٔ تغییرات هر دو خودکار به‌روزرسانی می‌شن — از همون‌جا وضعیت مؤثر جدید رو تأیید کن.

بازگردانی به حالت قبل: کافیه دوباره همین رویه رو با جهت مخالف انجام بدی (فعال‌کردن به‌جای غیرفعال‌کردن یا برعکس) — هر تغییر، خودش یک رویداد تاریخچهٔ جدید و مستقل ثبت می‌کنه.

ز) رویهٔ عملیاتی: تغییر اولویت مسیریابی ارائه‌دهنده

اولویت یک ترجیح عملیاتیِ مسیریابیه — عددی بین ۰ تا ۱۰۰ که تعیین می‌کنه سامانه کدوم ارائه‌دهنده رو زودتر امتحان کنه (عدد کمتر = اولویت بالاتر). این عدد هیچ ربطی به کیفیت تحلیل یا اعتبار مدل نداره.

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

اثر روی مسیریابیِ قطعی: مرتب‌سازی ارائه‌دهندگان و مدل‌ها هم‌چنان کاملاً معین (deterministic) باقی می‌مونه — تغییر اولویت فقط ترتیبِ همون مرتب‌سازیِ معین رو عوض می‌کنه، هیچ عنصر تصادفی یا امتیازدهیِ هوشمندی وارد نمی‌شه.

تأیید پس از تغییر: فهرست ارائه‌دهندگان بلافاصله اولویت جدید رو نشون می‌ده؛ تاریخچهٔ تغییرات هم مقدار قبل/بعد رو ثبت می‌کنه.

بازگردانی به حالت قبل: مقدار قبلی رو از همون تاریخچهٔ تغییرات پیدا کن و دوباره همون عدد رو ثبت کن.

ژ) تاریخچهٔ تغییرات (Audit)

هر تغییر موفقِ فعال/غیرفعال یا اولویتِ یک ارائه‌دهنده، یک رویداد تاریخچهٔ جدید و تغییرناپذیر ثبت می‌کنه — شامل زمان، مدیرِ انجام‌دهنده، وضعیت قبل و بعد، و دلیل (در صورت وجود).

این تاریخچه فقط‌خواندنیه — هیچ راهی برای ویرایش یا حذف یک رویداد ثبت‌شده از این کنسول وجود نداره. نمای فعلی محدود به رویدادهای عملیاتِ ارائه‌دهنده‌ست؛ یک صفحهٔ عمومیِ «حسابرسی و لاگ‌ها» برای انواع دیگهٔ رویداد هنوز پیاده‌سازی نشده (هنوز در نوار ادمین «به‌زودی» علامت خورده).

سازگاریِ جهش و تاریخچه: هیچ تغییری بدون ثبت موفقِ رویداد تاریخچه، موفق تلقی نمی‌شه — اگر ثبت تاریخچه با خطا مواجه بشه، خودِ تغییر عملیاتی هم لغو می‌شه و وضعیت مؤثر دست‌نخورده می‌مونه.

س) ساختار رویه‌های عملیاتی (Runbook) — نقشهٔ کلی

این فهرست، نقشهٔ کلیِ رویه‌های ادمینه؛ هر موردی که این‌جا «هنوز فعال نیست» علامت خورده، امروز از این کنسول قابل‌انجام نیست.