بازبینی زیرساخت ربات معامله‌گر

نقش تو: مهندس قابلیت اطمینان سیستم‌های معاملاتی.

وظیفه: زیرساخت ربات زیر را از منظر ریسک عملیاتی بازبینی کن.

داده ورودی:
- توصیف معماری ربات: {{ARCHITECTURE}}
- محل اجرا (سرور، خانگی، ابری): {{HOSTING}}
- صرافی یا کارگزار و نوع API: {{VENUE}}
- استراتژی و فرکانس معامله: {{STRATEGY}}
- سرمایه تحت مدیریت ربات: {{CAPITAL}}

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

ساختار خروجی:

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

■ ۲. سازگاری وضعیت
- ربات از کجا می‌فهمد پوزیشن واقعی‌اش چیست؟ از حافظه خودش یا از صرافی؟
- بعد از ریستارت، چطور وضعیت را بازیابی می‌کند؟
- اگر وضعیت ربات و صرافی اختلاف داشت، کدام مرجع است؟
پاسخ درست همیشه «صرافی مرجع است» است. اگر معماری {{ARCHITECTURE}} این را رعایت نمی‌کند، این جدی‌ترین یافته بازبینی است.

■ ۳. جلوگیری از سفارش تکراری
آیا هر سفارش شناسه یکتای سمت مشتری دارد؟ اگر پاسخ API گم شود، ربات چطور می‌فهمد سفارش ثبت شده یا نه؟

■ ۴. سوئیچ اضطراری
- آیا راهی برای توقف فوری همه فعالیت وجود دارد؟
- آیا می‌شود بدون دسترسی به سرور اصلی اجرا شود؟
- بعد از توقف اضطراری، پوزیشن‌های باز چه می‌شوند؟

■ ۵. سقف‌های سخت
| سقف | مقدار پیشنهادی | بر چه اساسی |
حداکثر اندازه سفارش، حداکثر تعداد سفارش در دقیقه، حداکثر زیان روزانه، و حداکثر انحراف قیمت سفارش از قیمت بازار.
این‌ها باید در کد باشند، نه در تنظیمات قابل تغییر در لحظه.

■ ۶. رصد و هشدار
| رویداد | چطور اطلاع داده شود | فوریت |
مهم‌ترین هشدار، «ربات ساکت است» است — سیستمی که خراب شده معمولاً هیچ خطایی نمی‌فرستد.

■ ۷. ثبت وقایع
چه چیزی باید لاگ شود تا بتوان یک روز بد را بعداً بازسازی کرد؟

■ ۸. سه ضعف اصلی
مرتب بر اساس ترکیب احتمال و اثر، با اقدام مشخص برای هر کدام.