ریگ‌ها

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

سطوح و بک‌اندها

سطح	می‌راند	بک‌اند	مقدار	خروج مهارشده
ترمینال (exec)	پوستهٔ روی کانال exec ماشین مجازی	microVM	smolvm	بله
مرورگر	Chromium بی‌سر (CDP)، Firefox (WebDriver BiDi) یا WebKit (W3C WebDriver)	microVM	smolvm	بله
رایانه	میزکار X11: ورودی از طریق هایپروایزر، ضبط از طریق عامل مهمان	QEMU	qemu-hvf (macOS)، qemu-kvm (Linux)، qemu-tcg (جایگزین بدون شتاب‌دهی، هرگز خودکار انتخاب نمی‌شود)	بله
Android	Android روی ADB	شبیه‌ساز Google	android-emulator	خیر — شبیه‌ساز شبکهٔ خودش را مدیریت می‌کند
iOS	شبیه‌ساز iOS از طریق WebDriverAgent	CoreSimulator	ios-simulator	خیر — شبکه از Mac میزبان تبعیت می‌کند

ترمینال و سطح computer_use مقدار سطح computer را به اشتراک می‌گذارند؛ ترمینال با نشانگر تصویر exec خودش متمایز می‌شود و هرگز به‌عنوان یک میزکار قابل‌رانده دوباره به کار گرفته نمی‌شود (یا برعکس). یک گفتگو همان یک ماشین ترمینال را دوباره به کار می‌گیرد.

موتورهای مرورگر

موتور	مقدار	پروتکل	نمای زنده	عکس‌های ثابت
Chromium	chromium (پیش‌فرض)	Chrome DevTools Protocol	اسکرین‌کست — مرورگر هنگام بازترسیم صفحه فریم‌ها را هل می‌دهد	JPEG
Firefox	firefox	WebDriver BiDi	عکس‌های ثابت دوره‌گیری‌شده (BiDi اسکرین‌کست ندارد)، حداکثر ۶ فریم بر ثانیه	JPEG
WebKit	webkit	W3C WebDriver (کلاسیک)	عکس‌های ثابت دوره‌گیری‌شده، ترنس‌کدشده با ffmpeg میزبان	PNG

یک ریگ در سراسر عمرش یک موتور را می‌راند. یک گفتگو می‌تواند به‌ازای هر موتور یک ریگ داشته باشد، و همین مقایسهٔ کنار‌به‌کنار را ممکن می‌کند: باز کردن «Firefox (VM)» در کنار «Chromium (VM)» دو ماشین است، و بستن یکی دیگری را در حال اجرا رها می‌کند.

engine را به rig.open یا به ابزار browser_use بدهید. نام ناشناخته رد می‌شود نه اینکه به پیش‌فرض برگردد — درخواست یک مرورگر و بی‌صدا گرفتن مرورگری دیگر، به یک پرسش سازگاری پاسخ اشتباه می‌دهد.

محدودیت‌های مخصوص هر موتور، به‌جای دور زدن، بیان می‌شوند:

• Firefox بارگذاری مجدد با دور زدن کش ندارد (ignoreCache در BiDi را یکسره رد می‌کند)، پس بارگذاری سخت همان بارگذاری معمولی است.
• WebKit هم بارگذاری مجدد با دور زدن کش ندارد و خوراک کنسول هم ندارد (خروجی با قلاب‌انداختن به console.* پس از هر پیمایش گرفته می‌شود، پس هر چیزی که هنگام بارگذاری ثبت شود از دست می‌رود — هر استخراج کنسول همین را می‌گوید)، و برای نمای زنده‌اش به ffmpeg روی میزبان نیاز دارد.
• هیچ‌کدام درخت دسترس‌پذیری سکو را از طریق پروتکلشان ارائه نمی‌دهند، پس extract (a11y) تقریبی برگرفته از DOM را برمی‌گرداند، با برچسب اینکه چنین است.
• هیچ‌کدام نمی‌توانند رهاکردن فایل واقعی بپذیرند؛ همچنان می‌توان ورودی فایل را به مسیرهایی درون ماشین اشاره داد.

تصاویر ماشین

سطح	تصویر	واکشی
ترمینال	ubuntu:24.04، پین‌شده با دایجست	به‌طور خودکار در نخستین بوت، از طریق شبکهٔ دروازه‌بانی‌شدهٔ خودِ ماشین
مرورگر (Chromium، Firefox، WebKit)	debian:trixie-slim، پین‌شده با دایجست، به‌همراه بسته‌های خودِ موتور	به‌طور خودکار در نخستین بوت، سپس به‌صورت یک بستهٔ گرم‌شده کش می‌شود
رایانه	یک تصویر میزکار qcow2 با Chromium، Firefox، WebKit و همان سطح پایهٔ CLI رانر میزبانی‌شدهٔ GitHub که ترمینال گرم می‌کند	وارد کردن زیر تنظیمات → سرور → ریگ‌ها (دانلودهای پین‌شده با چک‌سام در جایی که منتشر شده‌اند)
Android	تصاویر سیستمی Google	از طریق Android SDK
iOS	یک رانتایم شبیه‌ساز Xcode به‌همراه WebDriverAgent پین‌شده با چک‌سام	رانتایم از طریق Xcode؛ پل خودکارسازی از تنظیمات → سرور → ریگ‌ها

پس از نخستین بوت هر نوع microVM، سرور یک نسخهٔ ازپیش‌استخراج‌شده را زیر پوشهٔ داده کش می‌کند و هر ماشین بعدی را از آن بوت می‌کند — از جمله تصاویر ازپیش‌گرم‌شده با بسته‌های ازپیش‌نصب‌شده. ترمینال یک مجموعه‌ابزار CLI به سبک رانر میزبانی‌شدهٔ GitHub را گرم می‌کند (git، gcc، python3، jq، rsync، ابزارهای بایگانی و باقی سطح پایهٔ apt؛ نه Docker و نه کش‌های ابزار زبان‌ها). تصویر qcow2 سطح رایانه همان نام‌های CLI را هنگام ساخت تصویر درون خود می‌پزد، کنار XFCE و آن سه مرورگر. هر مرورگر موتور خودش را گرم می‌کند. هر سه موتور یک پایهٔ Debian را به اشتراک می‌گذارند اما هرگز یک بسته را به اشتراک نمی‌گذارند: کلید کش روی تصویر، موتور و یک بازبینی صوتی (audio-v1-<engine>) است، چون ماشینی که برای یک موتور گرم شده — یا پیش از آنکه PulseAudio و ffmpeg بخشی از بار کاری باشند — هیچ‌کدام از آن دیگری را در خود ندارد. بستهٔ ترمینال هم به همین دلیل کلیدش روی یک بازبینی مجموعه‌ابزار (tools-v1) است: بسته‌ای که پیش از بخشی از تصویر شدن کامپایلر گرم شده نباید به ماشینی سرویس بدهد که قرار است کامپایلر داشته باشد.

هیچ تصویر خودکارسازی ازپیش‌پخته‌ای ارزش برداشتن ندارد — chromedp/headless-shell مربوط به Chromium هم ALSA و هم PulseAudio را بیرون می‌گذارد، پس هرگز نمی‌تواند صدا تولید کند؛ تنها تصویر نگهداری‌شدهٔ Firefox ۳۳ برابر پایهٔ Debian است و همچنان socat ندارد؛ و اصلاً تصویر نگهداری‌شده‌ای برای WebKit وجود ندارد. پس هر موتور در نخستین راه‌اندازی نصب می‌شود (chromium، firefox-esr یا webkit2gtk-driver) و در همین حین به آرشیوهای Debian (deb.debian.org، security.debian.org، cloudfront.debian.net) دسترسی می‌یابد. Chromium همان باینری توزیع است که به‌صورت chromium --headless=new اجرا می‌شود.

تصاویر سفارشی به‌ازای هر فضای کاری

کلید تنظیم	بازنویسی می‌کند
rigs.smolvm.execImage	تصویر ترمینال (VM)
rigs.smolvm.browserImage	تصویر مرورگر Chromium (VM)

از طریق مخزن تنظیمات فضای کاریِ دروازه‌بانی‌شده با مدیر نوشته می‌شود (تنظیمات → سرور → ریگ‌ها → تصاویر سفارشی (این فضای کاری)). مقدار باید یک ارجاع رجیستری باشد — مسیرهای محلی، بایگانی‌ها و رشته‌های شبیه فلگ رد می‌شوند، هم در همان فیلد و هم دوباره هنگام بوت. مقدار نامعتبرِ ذخیره‌شده با صدای بلند نادیده گرفته می‌شود و در عوض پیش‌فرض بوت می‌شود. رجیستری خودِ تصویر (به‌همراه همراهان شناخته‌شدهٔ blob-CDN برای Docker Hub، GHCR، Quay، GitLab و GCR) برای واکشی از دروازهٔ خروج پذیرفته می‌شود.

قرارداد تصویر ترمینال — bash موجود؛ git، curl، socat ازپیش‌نصب یا یک پایهٔ apt از Debian/Ubuntu (محفظه در نخستین راه‌اندازی آن سه را به‌همراه یک مجموعه‌ابزار CLI به سبک رانر میزبانی‌شدهٔ GitHub نصب می‌کند: کامپایلرها، Python 3، jq، ابزارهای بایگانی، rsync. کش‌های ابزار زبان‌ها و Docker نصب نمی‌شوند).

قرارداد تصویر مرورگر — یک پایهٔ apt از Debian/Ubuntu (یا بسته‌های ازپیش‌نصب) با bash و socat، به‌همراه یک باینری chromium که خود سرور آن را به‌صورت chromium --headless=new با DevTools روی لوپ‌بک مهمان 9223 اجرا می‌کند و به پورت مهمان 9222 رله می‌شود. PulseAudio و ffmpeg در نخستین راه‌اندازی برای مسیر صدا نصب می‌شوند. FROM chromedp/headless-shell را نسازید: headless.gn بالادست هم ALSA و هم PulseAudio را بیرون می‌گذارد، پس آن باینری نمی‌تواند صدا تولید کند. این بازنویسی فقط برای ریگ‌های Chromium اعمال می‌شود — فرمان بار کاری‌ای که بوت می‌کند مالِ Chromium است، و دادنش به Firefox یا WebKit باینری‌ای را اجرا می‌کند که آنجا نیست. یک ریگ Firefox یا WebKit با صدای بلند نادیده‌اش می‌گیرد و تصویر پین‌شدهٔ خودش را بوت می‌کند.

پورت‌های خودکارسازی — هر ماشین مرورگر دقیقاً یک پورت لوپ‌بک میزبان را به 9222 مهمان فوروارد می‌کند. پشت آن: DevTools کروم و عامل راه دور Firefox روی لوپ‌بک مهمان 9223 می‌نشینند و یک رلهٔ socat جلویشان است (هر دو بی‌قیدوشرط به لوپ‌بک متصل می‌شوند)؛ درایور WebKit یک --host می‌گیرد و خودش به کارت شبکهٔ مهمان متصل می‌شود. Firefox به‌علاوه سرآیند Host را با پورت خودش اعتبارسنجی می‌کند، پس کلاینت authority سمت مهمان را می‌فرستد، نه آن‌که با آن تماس گرفته است.

فعل‌های کنش

هر کنش به‌طور کامل تجزیه می‌شود: بار داده‌ای بدشکل پیامی برمی‌گرداند که نام فیلد را می‌گوید، هرگز استثنا نمی‌دهد. فعل‌های مشاهده (نشان‌دار با ○) تا وقتی یک انسان کنترل را در دست دارد مجاز می‌مانند؛ فعل‌های تغییردهنده رد می‌شوند.

computer_use

screenshot○، cursor_position○، mouse_move، left_click، right_click، middle_click، double_click، triple_click، left_mouse_down، left_mouse_up، left_click_drag، scroll، key، hold_key (۰–۶۰ ثانیه)، type، wait○ (۰–۶۰ ثانیه)، set_display، clipboard_read○، clipboard_write.

مختصات بر حسب پیکسل‌های مهمان در حالت کنونی مهمان است؛ هر نماگرفت اندازهٔ نمایشگر را ذکر می‌کند. ترکیب‌های کلید از املای X11 استفاده می‌کنند (ctrl+s، alt+Tab، Return).

clipboard_read یک selection می‌گیرد: clipboard (آنچه ctrl+C پر می‌کند، پیش‌فرض)، primary (انتخاب-برای-کپی در X11) یا xdnd (یک کشیدن در جریان). نتیجهٔ خالی برای هر سه پاسخ عادی است. clipboard_write فقط text می‌گیرد — تصاویر و فایل‌ها از مسیر فایل سفر می‌کنند، چون آرگومان‌های یک کنش در گزارش حسابرسی ماندگار می‌شوند و بایت‌های تصویر جایشان آنجا نیست. محتوای بریده‌دان حصارشده به‌عنوان دادهٔ نامطمئن برمی‌گردد.

browser_use

navigate (فقط http/https)، reload (hard اختیاری)، stop_loading، click (سلکتور یا مختصات)، fill، type، key (نام‌های کلید DOM)، scroll، mouse_move، drag، left_mouse_down، left_mouse_up، extract○ (a11y | dom | console)، screenshot○ (full_page اختیاری)، set_viewport (حداقل ۳۲۰×۲۴۰)، history، wait_for○ (سلکتور، ۰.۱–۳۰ ثانیه)، clipboard_read○، clipboard_write.

محتوای استخراج‌شدهٔ صفحه حصارشده به‌عنوان دادهٔ نامطمئن برمی‌گردد.

مرورگر دقیقاً یک بریده‌دان دارد، پس clipboard_read هیچ selection نمی‌گیرد. هر دو فعل بریده‌دان به یک بافت امن نیاز دارند: صفحه‌ای که روی http:// ساده سرو شود اصلاً API بریده‌دان ندارد، و فعل همین را می‌گوید نه اینکه خالی بودنش را گزارش کند — آنجا از type استفاده کنید، که بدون عبور از بریده‌دان در محل نشانگر درج می‌کند.

mobile_use

tap، swipe (۵۰–۵۰۰۰ میلی‌ثانیه)، type، key (نام‌های مستعار back، home، recents، enter، delete، backspace، tab، escape، search، menu، volume_up، volume_down، power، یا هر KEYCODE_*)، screenshot○، ui_dump○، install_apk (محدود به worktree ریگ و پوشهٔ دادهٔ سرور)، start_app، stop_app، clear_app_data، uninstall_app، open_url و shell. shell یک فهرست argv می‌گیرد و درون Android اجرا می‌شود، هرگز از پوستهٔ میزبان؛ تشخیص‌های توسعه‌دهنده مانند logcat، dumpsys و pm grant را پوشش می‌دهد.

mobile_use هیچ فعل بریده‌دانی ندارد. از Android 10 به بعد فقط برنامهٔ دارای تمرکز می‌تواند بریده‌دان را بخواند.

ios_use

tap، swipe (۵۰–۵۰۰۰ میلی‌ثانیه)، type، key (enter، backspace، tab، escape، کلیدهای جهت یا یک نویسهٔ قابل‌چاپ؛ اصلاح‌کننده‌های اختیاری command، control، option و shift)، home، lock، unlock، screenshot○، ui_dump○، install_app (یک پوشهٔ .app شبیه‌ساز، محدود به worktree ریگ یا پوشهٔ دادهٔ سرور)، start_app، stop_app، uninstall_app، open_url و spawn. spawn آرگومان‌های argv را می‌گیرد و از طریق simctl درون شبیه‌ساز اجرا می‌کند؛ هرگز پوستهٔ میزبان را فرا نمی‌خواند.

مختصات بر حسب پوینتهای صفحهٔ iOS است، نه پیکسل‌های نماگرفت. جریان زنده اندازهٔ ثابت شبیه‌ساز را حفظ می‌کند و به‌جای تغییر اندازهٔ دستگاه، آن را در قابی با نوارهای کناری (letterbox) جای می‌دهد. انتقال متنی بریده‌دان از میزبان به شبیه‌ساز و از شبیه‌ساز به میزبان از همان سیاست مجوز به‌ازای هر کاربر و هر جهت سایر ریگ‌ها استفاده می‌کند؛ فایل‌ها و تصاویر را مسیر pasteboard در iOS نمی‌پذیرد.

هر ریگ یک دستگاه CoreSimulator و یک نشست WebDriverAgent تحت مالکیت خود می‌سازد. بستن آن، WebDriverAgent را متوقف می‌کند، آن دستگاه را خاموش و حذف می‌کند و ورودی رجیستری‌اش را برمی‌دارد. ریگ‌های iOS فقط روی یک سرور macOS با Xcode، یک رانتایم iOS نصب‌شده و پل خودکارسازی پین‌شده اجرا می‌شوند. هیچ صدا، میکروفون، رهاکردن فایل، پوستهٔ میزبان یا تضمین شبکهٔ محصور ارائه نمی‌دهند.

ابزارهای مدیریت

ابزار	توضیح
rig_list	ریگ‌های یک فضای کاری را با سطح، وضعیت، نمایشگر و کنترل‌کننده فهرست می‌کند
rig_close	یک ریگ را نابود و دیسکش را دور می‌اندازد

چرخهٔ عمر

مرحله	معنا
provisioning	در حال بوت؛ جزئیات وضعیت، گام کنونی را عیناً حمل می‌کند
ready	قابل‌دسترس و پذیرای کنش‌ها
parked	پارک‌شده در بیکاری: vCPUها متوقف، RAM همچنان مقیم؛ کنش بعدی بیدارش می‌کند
closing	در حال خاموش شدن
closed	رفته؛ سطر برای رد حسابرسی باقی می‌ماند
failed	مرده یا هرگز بالا نیامده؛ قابل تشخیص تا رابط کاربری بتواند تلاش مجدد پیشنهاد دهد

دلیل بستن	زمان فعال‌شدن
requested	یک شخص یا عامل درخواست کرد
idleTimeout	بیکاری بیش از ۲ برابر پنجرهٔ بیکاری، یا بیرون رانده‌شده به‌خاطر حافظه
ttlExpired	عمر سخت به‌پایان رسید
conversationEnded	گفتگوی مالک به پایان رسید
workspaceGone	فضای کاری حذف شد یا عضویت از دست رفت
serverShutdown	سرور در حال توقف است
backendFailure	هایپروایزر زیرش مرد

پیش‌فرض‌ها و سقف‌ها

مقدار	ترمینال	مرورگر	رایانه	موبایل
حافظه	۵۱۲ مگابایت	۲۰۴۸ مگابایت (Chromium)؛ ۲۵۶۰ مگابایت (Firefox، WebKit)	۴۰۹۶ مگابایت	۴۰۹۶ مگابایت
vCPUها	۲	۲	۴	۴
TTL سخت	۸ ساعت	۲ ساعت	۲ ساعت	۲ ساعت
پنجرهٔ بیکاری	۴۵ دقیقه	۱۵ دقیقه	۱۵ دقیقه	۱۵ دقیقه
نمایشگر بوت	—	۱۲۸۰×۸۰۰	۱۲۸۰×۸۰۰	۱۰۸۰×۱۹۲۰

• عکس‌های ثابت مسیر عامل حداکثر ۱۲۸۰×۸۰۰ هستند؛ مسیر انسان تا ۲۵۶۰×۱۶۰۰ مذاکره می‌کند.
• بودجهٔ حافظهٔ مقیم میزبان برای همهٔ ریگ‌ها به‌طور پیش‌فرض ۱۲ گیگابایت است، بر حسب مگابایت مقیم شمرده می‌شود (یک VM پارک‌شده همچنان RAMش را نگه می‌دارد). بیرون راندن بر پایهٔ کمترین استفادهٔ اخیر است و هرگز ماشینی را که کسی آن را می‌راند، تماشا می‌کند یا ترمینالی در آن باز دارد نمی‌گیرد.
• یک ترمینال باز یا مسیر تماشا، ریگ را در برابر پارک شدن و پاک‌سازی بیکاری میخکوب می‌کند؛ TTL سخت همچنان اعمال می‌شود.

پورت‌ها و دامنه‌های dev

پورت	کجا	رزرو برای
7911	مهمان ترمینال	مالتی‌پلکسر پورتی که هر فورواردی سوارش می‌شود
9222، 9223	مهمان مرورگر	رله و نقطهٔ پایانی خودکارسازی (WebKit مستقیم به 9222 متصل می‌شود و از رله‌ای استفاده نمی‌کند)
80، 443	لوپ‌بک مهمان مرورگر	مسیرهای HTTP/HTTPS دامنهٔ dev

• کشف، هر ~۴ ثانیه یک‌بار سمت سرور، پورت‌های TCP در حال شنیدن مهمان ترمینال را بررسی می‌کند.
• حداکثر ۱۶ پورت به‌ازای هر ریگ خودکار فوروارد می‌شوند؛ بیشتر از آن در لاگ فهرست می‌شود، نه فوروارد.
• فوروارد سمت میزبان به لوپ‌بک متصل می‌شود و شمارهٔ پورت خودِ مهمان را ترجیح می‌دهد؛ اشتراک در شبکهٔ محلی یک پورت LAN تخصیص‌داده‌شده توسط سیستم‌عامل اضافه می‌کند.
• دامنه‌های dev باید با name.test یا name.localhost مطابقت کنند (حروف کوچک، برچسب حداکثر ۶۳ نویسه). یک دامنه به یک پورت نگاشت می‌شود.
• HTTPS دامنهٔ dev از یک CA محلی سرور استفاده می‌کند (EC P-256، زیر <dataDir>/rigs/tls/، کلیدها با 0600 و هرگز درون هیچ مهمانی) با یک برگ wildcard برای *.test / *.localhost. نبودِ openssl روی میزبان یعنی نبود مسیر HTTPS؛ HTTP ساده همچنان مسیریابی می‌شود.

پیش‌فرض‌های خروج

سطح	فهرست مجاز پیش‌فرض
ترمینال	سطح پایهٔ توسعه‌دهندهٔ سندباکس (میزبان‌های کد، رجیستری‌های بسته، ارائه‌دهندگان مدل) + آینه‌های apt مربوط به Ubuntu + میزبان کد خودِ worktree
مرورگر	usectrl.dev (سایت محصول) — به‌علاوهٔ آرشیوهای Debian در نخستین بوت هر موتور، وقتی بسته‌هایش را نصب می‌کند. صفحهٔ خانه یک سند محلی file:// است و به خروج نیازی ندارد
رایانه	خالی — همه‌چیز را رد کن — تا وقتی فراخواننده‌ای میزبان‌ها را اعطا کند
موبایل	اعمال نمی‌شود (شبکهٔ مدیریت‌شده توسط شبیه‌ساز)

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

بریده‌دان و انتقال فایل

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

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

مسیر انتقال	مسیر	محموله
بریده‌دان	GET/POST /rig/clipboard/<rigId>	متن، یک PNG/JPEG (≤۱۶ مگابایت)، و مسیرهای مهمانِ فایل‌های روی بریده‌دان
فایل‌ها	POST /rig/files/<rigId>	حداکثر ۶۴ فایل، هر یک ≤۲۵۶ مگابایت و ≤۵۱۲ مگابایت در هر رهاسازی، با یک نقطهٔ رهاسازی اختیاری بر حسب پیکسل مهمان
فایل‌ها	GET /rig/files/<rigId>?p=<base64url path>	بایت‌های یک فایل، به سمت بیرون

• HTTP، نه RPC. سوکت RPC روی فریمی ورودی بیش از ۲۵۶ کیلوبایت اتصال را می‌بندد — یک نگهبان DoS که برای فرمان‌های JSON درست است و برای یک نماگرفت جای‌گذاری‌شده مرگبار. بایت‌ها از همان نوع مسیری سوار می‌شوند که فریم‌های ریگ و صدای جلسه از قبل استفاده می‌کنند.
• احراز هویت همان هدف امضاشدهٔ rig-files:<workspaceId>/<rigId> به‌همراه عضویت فضای کاری است — هدفی مستقل، پس URL‌ای که برای تماشای یک ماشین صادر شده نمی‌تواند هم‌زمان فایل‌هایی در آن بنویسد.
• تصاحب کنترل اعمال می‌شود. نوشتن بریده‌دان و رها کردن فایل تغییردهنده‌اند و تا وقتی کس دیگری کنترل را در دست دارد رد می‌شوند؛ خواندن بریده‌دان و خواندن یک فایل به بیرون مشاهده‌اند و این‌طور نیستند.
• رهاسازی‌ها کجا می‌نشینند: ~/Drops (میزکار)، ~/drops (ترمینال — کنار worktree، هرگز درونش، تا یک رهاسازی هرگز به‌صورت یک تغییر ردیابی‌نشده ظاهر نشود)، /tmp/cc-drops (مرورگر). پوشه را سرور انتخاب می‌کند؛ فراخواننده نمی‌تواند نامش را ببرد. فایل‌های موجود هرگز بازنویسی نمی‌شوند — نام برخوردی به‌صورت 2-name.ext می‌نشیند.
• به مهمان چه گفته می‌شود: یک صفحهٔ مرورگر در نقطهٔ درخواستی یک رویداد رهاسازی واقعی می‌گیرد (Input.dispatchDragEvent)؛ یک میزکار فایل‌ها را به‌همراه URIهایشان روی بریده‌دانش می‌گیرد، چون هیچ میزبانی نمی‌تواند بدون یک سرویس‌دهندهٔ ممتاز درون مهمان، یک کشیدن XDND را در یک جعبه‌ابزار دلبخواه بسازد. پاسخ می‌گوید کدام‌یک رخ داده است.
• کشیدن به بیرون فقط روی میزکار است و هنگام زنده بودن یک کشیدن، XdndSelection مهمان را می‌خواند. بار داده‌ای یکسان با آنچه مهمان هنگام آغاز فشار از قبل نگه داشته بود، یک انتخاب کهنه از یک کشیدن تمام‌شده تلقی می‌شود، نه یک تازه — X گامِ «کشیدن تمام شد» ندارد.
• الزامات تصویر: تصویر میزکار باید پروتکل ۲ یا بالاتر باشد (ساخته‌شده پس از افزوده شدن پشتیبانی بریده‌دان). یک تصویر قدیمی‌تر ۴۰۴ پاسخ می‌دهد و برنامه می‌گوید بازسازی‌اش کنید، نه اینکه یک ماشین خراب گزارش کند.
• گزارش حسابرسی شکل را ثبت می‌کند، هرگز محتوا را: سطرهای clipboard_read، clipboard_write، drop_files و read_file شمارها، اندازه‌ها و مسیرها را حمل می‌کنند. بریده‌دان جایی است که اعتبارنامه‌ها هر بار چند ثانیه زندگی می‌کنند، و هیچ‌کدامش نوشته نمی‌شود.

گاردریل‌ها، رویدادها، ذخیره‌سازی

• ابزارهای ریگ کلاس کنش enclosureControl را تعریف می‌کنند (به‌همراه networkEgress و processSpawn روی ابزارهای use؛ mobile_use و ios_use هم packageInstall را تعریف می‌کنند). rig_close کلاس enclosureControl را تعریف می‌کند؛ rig_list هیچ‌کدام را تعریف نمی‌کند. به‌طور پیش‌فرض مجاز؛ حالت‌های فقط‌خواندنی آن را یکسره رد می‌کنند؛ درجهٔ خودمختاری هر فضا می‌تواند آن را به «اول بپرس» تنزل دهد.
• رویدادهای دامنه: RigClosedEvent (به‌همراه دلیل بستنش)، RigControlChanged (تصاحب / بازگرداندن کنترل)، RigReaped (بیرون راندن بیکاری، TTL یا حافظه، به‌همراه عامل راننده). باز کردن یک ریگ رویداد نیست. رویدادهای دامنه را ببینید.
• ذخیره‌سازی: rig_sessions و rig_action_log در پایگاه‌دادهٔ هر فضای کاری. گزارش کنش هر رویداد ورودی را با کنشگرش و یک دنبالهٔ یکنوای هر ریگ ثبت می‌کند؛ متن تایپ‌شده پیش از نوشته‌شدن به یک طول و هش تبدیل می‌شود.
• پوشهٔ داده: rigs/images/ (تصاویر qcow2 واردشده)، rigs/smolvm/ (وضعیت رانتایم هر ریگ)، rigs/smolvm-packs/ (بسته‌های ماشین ازپیش‌استخراج‌شده)، rigs/tls/ (CA دامنهٔ dev)، rigs/run/ (overlayها و بذرهای QEMU).
• مسیرها: نمای زنده یک زبانه در یک فضا یا صفحهٔ PR است؛ /settings/server/rigs صفحهٔ تنظیمات ریگ‌هاست.