محیط آزمایش

محیط آزمایشی در /app/agents/{id}/playground یک محیط امن کامل برای تست دستیار فروش قبل از انتشار است. مکالمات در اینجا با is_playground علامت‌گذاری می‌شوند و هرگز در کنتور صورتحساب، تحلیل‌های مکالمات یا صندوق ورودی محاسبه نمی‌شوند.

چه چیزی را می‌توانید تست کنید

• نوع سایت — بین ecommerce، saas، documentation، help_center، marketing، internal_kb یا generic بدون تغییر ستون ذخیره‌شده دستیار فروش جابه‌جا شوید. برای این مفید است که "دستیار فروش من اگر به‌عنوان فروشگاهی در نظر گرفته شود در مقابل مستندات، چه می‌گوید؟".
• زمینه صفحه — یک آدرس و فراداده (عنوان، توضیحات، تگ‌های og، JSON-LD، h1/h2، متن بدنه قابل مشاهده) را وارد کنید تا دستیار فروش طوری پاسخ دهد که گویی بازدیدکننده در یک صفحه خاص است. شش قالب آماده (محصول شاپیفای، قیمت‌گذاری SaaS، مستندات Docusaurus، مقاله مرکز راهنما، صفحه فرود بازاریابی، خالی) اشکال رایج را پوشش می‌دهند.
• زبان پاسخ — هر زبانی را که فضای کاری برای آن ترجمه دارد انتخاب کنید (۱۳۲ زبان به‌طور پیش‌فرض، به‌طور خودکار از lang/*.json کشف می‌شوند). برای بررسی اینکه دستیار فروش به زبان صحیح پاسخ می‌دهد و اسکریپت‌های RTL آینه می‌شوند، مفید است.
• پیام‌های نمونه — پیام‌های تست واقع‌گرایانه برای خریداران به ازای هر عمودی (۵–۶ تراشه به ازای هر نوع سایت) تا بتوانید با یک کلیک یک سوال معمولی را ارسال کنید.
• حالت مقایسه — آن را تغییر دهید تا چت به دو ستون تقسیم شود و همان سوال را در برابر دو نوع سایت مختلف کنار هم اجرا کنید. برای انتخاب عمودی مناسب مفید است.

زبانه‌های سمت راست

سناریو

لغو نوع سایت + زبان پاسخ + پیام‌های نمونه. نشان‌های قابلیت در زیر انتخابگر نوع سایت نشان می‌دهند که کدام بلوک‌های غنی (product_card، pricing_card، case_study_card، escalation_button) را عمودی انتخاب‌شده می‌تواند منتشر کند.

زمینه صفحه

ویرایشگر فرم‌محور برای page_context که بازدیدکننده ارسال می‌کند. از منوی کشویی استفاده از قالب برای قرار دادن یک صفحه محصول شاپیفای واقع‌گرایانه یا صفحه قیمت‌گذاری Stripe استفاده کنید، سپس فیلدهای URL / عنوان / og را تنظیم کنید. JSON-LD JSON چسبانده‌شده را می‌پذیرد.

تشخیص

بررسی فقط خواندنی آخرین نوبت:

• تأخیر — زمان اولین توکن و کل زمان.
• اطمینان — قوی‌ترین سیگنال زمینه (شباهت بازیابی یا پایه زمینه صفحه ۰.۸۵).
• منابع بازیابی‌شده — بهترین تکه‌ها با امتیازهای ANN و رتبه‌بندی مجدد به همراه یک قطعه، به ترتیبی که هوش مصنوعی آنها را دیده است.
• فراخوانی ابزار — هر ابزار سمت سروری که در طول نوبت فعال شده است، با آرگومان‌ها.
• بلوک‌های درون‌خطی — تعداد و انواع بلوک‌های غنی که هوش مصنوعی منتشر کرده است (مانند product_card).
• راهنمای سیستم — پیام کامل سیستمی که استفاده شده است، از جمله بخش عمودی و هر راهنمای سیستم سفارشی. برای گسترش کلیک کنید.

نقاط پایانی

هر سه با نشست احراز هویت شده‌اند و توسط AgentPolicy::update محدود می‌شوند:

• GET /app/agents/{agent}/playground — نمایش اینرسی با نقشه پیش‌نمایش عمودی‌ها که با نامک کلیدگذاری شده است.
• POST /app/agents/{agent}/playground/stream — پخش SSE. بدنه: {message, conversation_id?, site_type_override?, language_override?, page_context?}. رویدادهای start، retrieval، prompt، token، block، tool_call، done را منتشر می‌کند.
• POST /app/agents/{agent}/playground/reset — تاریخچه مکالمه کش‌شده را پاک می‌کند. بدنه: {conversation_id}.

نکات

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

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

نقش‌ها

چهار نقش، به ترتیب سطح دسترسی:

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

نقش‌ها در جدول اتصال workspace_users ذخیره می‌شوند؛ enum WorkspaceRole متدهای قابلیت را در معرض دید قرار می‌دهد — canManageAgents() (مالک / مدیر / ویرایشگر)، canManageMembers() (مالک / مدیر)، canManageBilling() (فقط مالک)، canViewAnalytics() (همه) — که توسط لایه سیاست‌ها استفاده می‌شود.

دعوت کردن

از /app/members، یک مالک یا مدیر می‌تواند با ایمیل دعوت کند. دعوت‌نامه با یک لینک توکن‌دار به /invitations/{token} ایمیل می‌شود. با کلیک روی آن:

1. پیش‌نمایش دعوت‌نامه (نام فضای کاری، دعوت‌کننده، نقش) نمایش داده می‌شود.
2. از بازدیدکننده خواسته می‌شود در صورت عدم ورود، وارد یا ثبت‌نام کند.
3. پس از پذیرش، عضو با نقش تعیین‌شده به فضای کاری متصل شده و به داشبورد هدایت می‌شود.

دعوت‌نامه‌ها پس از ۷ روز منقضی می‌شوند. مالکان و مدیران می‌توانند یک دعوت‌نامه در انتظار را از بخش دعوت‌نامه‌های در انتظار در /app/members لغو کنند — روی لغو کلیک کنید، تأیید کنید و ردیف حذف می‌شود. لغو، یک ورودی invitation.revoked در گزارش حسابرسی ثبت می‌کند. دعوت‌نامه‌های پذیرفته‌شده قابل لغو نیستند — به‌جای آن، عضو را از لیست اعضای فعلی حذف کنید.

تغییر نقش

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

حذف

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

انتقال مالکیت

هر فضای کاری دقیقاً یک مالک دارد. انتقال مالکیت یک فرآیند دو مرحله‌ای است:

1. مالک فعلی یک عضو هدف را انتخاب کرده و روی انتقال کلیک می‌کند.
2. هدف در اعلان‌های خود می‌پذیرد. تا زمانی که بپذیرد، انتقال در حالت انتظار است.

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

کاربران چند فضای کاری

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

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

گزارش حسابرسی

تغییرات اعضا — دعوت‌نامه‌های ارسال‌شده، پذیرفته‌شده، لغو‌شده، تغییرات نقش، انتقال مالکیت، حذف‌ها — ردیف‌هایی را در جدول audit_logs برای قابلیت ردیابی قانونی ثبت می‌کنند. در نسخه v1 صفحه‌ای برای مرور گزارش حسابرسی وجود ندارد؛ در صورت نیاز به بررسی، مستقیماً از جدول پرس‌وجو کنید.