Rigs

Chỉ dữ kiện mà thôi. Để hiểu mô hình đằng sau chúng, hãy đọc Rigs và môi trường cách ly; để mở một cỗ máy, hãy theo hướng dẫn.

Bề mặt và backend

Bề mặt	Điều khiển	Backend	Giá trị	Egress được cô lập
Terminal (exec)	Một shell qua kênh exec của VM	microVM	smolvm	Có
Trình duyệt	Chromium không giao diện (CDP), Firefox (WebDriver BiDi) hoặc WebKit (W3C WebDriver)	microVM	smolvm	Có
Máy tính	Desktop X11: đầu vào qua hypervisor, ảnh chụp qua agent trong hệ thống khách	QEMU	qemu-hvf (macOS), qemu-kvm (Linux), qemu-tcg (phương án dự phòng không tăng tốc, không bao giờ được chọn tự động)	Có
Android	Android qua ADB	Trình giả lập của Google	android-emulator	Không — trình giả lập tự quản lý mạng của mình
iOS	Trình mô phỏng iOS qua WebDriverAgent	CoreSimulator	ios-simulator	Không — mạng đi theo máy Mac chủ

Terminal và bề mặt computer_use dùng chung giá trị bề mặt computer; terminal được phân biệt bằng dấu đánh dấu image exec của nó và không bao giờ được tái sử dụng như một desktop có thể điều khiển (hay ngược lại). Một cuộc hội thoại tái sử dụng một cỗ máy terminal.

Engine trình duyệt

Engine	Giá trị	Giao thức	Chế độ xem trực tiếp	Ảnh tĩnh
Chromium	chromium (mặc định)	Chrome DevTools Protocol	Screencast — trình duyệt đẩy khung hình khi trang vẽ lại	JPEG
Firefox	firefox	WebDriver BiDi	Ảnh tĩnh thăm dò định kỳ (BiDi không có screencast), giới hạn ở 6 fps	JPEG
WebKit	webkit	W3C WebDriver (cổ điển)	Ảnh tĩnh thăm dò định kỳ, được ffmpeg của máy chủ chuyển mã	PNG

Một rig chạy một engine duy nhất trong suốt vòng đời của nó. Một cuộc hội thoại có thể giữ một rig cho mỗi engine, và chính điều đó khiến việc so sánh song song trở nên khả thi: mở “Firefox (VM)” bên cạnh “Chromium (VM)” là hai cỗ máy, và đóng một cái sẽ để cái kia tiếp tục chạy.

Truyền engine cho rig.open hoặc cho công cụ browser_use. Một tên không xác định sẽ bị từ chối thay vì được thay bằng giá trị mặc định — yêu cầu một trình duyệt rồi âm thầm nhận một trình duyệt khác là trả lời sai cho một câu hỏi về khả năng tương thích.

Các giới hạn riêng của từng engine, được nói rõ thay vì tìm cách lách qua:

• Firefox không có thao tác tải lại bỏ qua bộ nhớ đệm (nó từ chối thẳng ignoreCache của BiDi), nên một lần tải lại cứng chỉ là một lần tải lại bình thường.
• WebKit cũng không có thao tác tải lại bỏ qua bộ nhớ đệm, không có luồng console (đầu ra được thu lại bằng cách móc vào console.* sau mỗi lần điều hướng, nên mọi thứ được ghi log trong lúc tải đều bị bỏ sót — mọi lần trích xuất console đều nói rõ điều đó), và cần ffmpeg trên máy chủ cho chế độ xem trực tiếp của nó.
• Cả hai đều không phơi ra cây trợ năng của nền tảng qua giao thức của mình, nên extract (a11y) trả về một kết quả gần đúng suy ra từ DOM, được dán nhãn đúng như vậy.
• Cả hai đều không thể nhận một thao tác thả tệp thật; một ô nhập tệp vẫn có thể được trỏ tới các đường dẫn bên trong cỗ máy.

Image của máy

Bề mặt	Image	Được lấy
Terminal	ubuntu:24.04, ghim theo digest	Tự động ở lần khởi động đầu tiên, qua mạng có cổng kiểm soát của chính cỗ máy
Trình duyệt (Chromium, Firefox, WebKit)	debian:trixie-slim, ghim theo digest, cùng các gói riêng của engine	Tự động ở lần khởi động đầu tiên, rồi được lưu vào bộ nhớ đệm dưới dạng một pack đã được hâm nóng
Máy tính	Một image desktop qcow2 với Chromium, Firefox, WebKit và đúng bộ CLI nền tảng kiểu runner do GitHub vận hành mà terminal hâm nóng	Nhập trong Cài đặt → Máy chủ → Rigs (các lượt tải được ghim bằng checksum khi có bản công bố)
Android	Các system image của Google	Qua Android SDK
iOS	Một runtime Xcode Simulator cùng WebDriverAgent được ghim bằng checksum	Runtime qua Xcode; cầu nối tự động hóa từ Cài đặt → Máy chủ → Rigs

Sau lần khởi động đầu tiên của mỗi loại microVM, máy chủ lưu vào bộ nhớ đệm một bản sao đã giải nén sẵn trong thư mục dữ liệu và khởi động mọi cỗ máy về sau từ đó — kể cả những image đã được hâm nóng với các gói đã cài đặt. Terminal hâm nóng một bộ công cụ CLI kiểu runner do GitHub vận hành (git, gcc, python3, jq, rsync, các công cụ lưu trữ, và phần còn lại của nền tảng apt; không gồm Docker hay toolcache ngôn ngữ). Image qcow2 của Máy tính đưa sẵn đúng những tên CLI đó vào từ lúc dựng image, bên cạnh XFCE và ba trình duyệt. Mỗi trình duyệt hâm nóng engine của mình. Cả ba engine dùng chung một nền Debian nhưng không bao giờ dùng chung một pack: bộ nhớ đệm được khóa theo image, theo engine và theo một bản sửa đổi âm thanh (audio-v1-<engine>), bởi một cỗ máy được hâm nóng cho một engine — hoặc trước khi PulseAudio và ffmpeg trở thành một phần của khối lượng công việc — thì không có gì của engine kia trong đó. Pack của terminal được khóa theo một bản sửa đổi bộ công cụ (tools-v1) vì cùng lý do: một pack được hâm nóng trước khi trình biên dịch trở thành một phần của image không được phục vụ một cỗ máy lẽ ra phải có trình biên dịch.

Không có image tự động hóa dựng sẵn nào đáng dùng — chromedp/headless-shell của Chromium loại bỏ cả ALSA lẫn PulseAudio khi biên dịch, nên nó không bao giờ phát ra âm thanh; image Firefox duy nhất còn được bảo trì có kích thước gấp 33 lần nền Debian mà vẫn không kèm socat; còn một image WebKit được bảo trì thì hoàn toàn không có. Vậy nên mỗi engine tự cài đặt ở lần khởi động đầu tiên (chromium, firefox-esr, hoặc webkit2gtk-driver) và trong lúc đó phải tiếp cận được các kho Debian (deb.debian.org, security.debian.org, cloudfront.debian.net). Chromium là tệp nhị phân của bản phân phối, được khởi chạy dưới dạng chromium --headless=new.

Image tùy chỉnh theo từng không gian làm việc

Khóa cài đặt	Ghi đè
rigs.smolvm.execImage	Image Terminal (VM)
rigs.smolvm.browserImage	Image Browser (VM)

Được ghi qua kho cài đặt không gian làm việc có cổng quản trị (Cài đặt → Máy chủ → Rigs → Image tùy chỉnh (không gian làm việc này)). Giá trị phải là một tham chiếu registry — đường dẫn cục bộ, tệp lưu trữ và chuỗi dạng cờ đều bị từ chối, cả tại trường nhập lẫn một lần nữa lúc khởi động. Một giá trị đã lưu không hợp lệ sẽ bị bỏ qua một cách ồn ào và image mặc định sẽ được khởi động thay thế. Registry của chính image đó (cùng các CDN blob đi kèm đã biết cho Docker Hub, GHCR, Quay, GitLab và GCR) được cho qua cổng egress để thực hiện lượt kéo.

Hợp đồng image Terminal — có bash; git, curl, socat được cài sẵn hoặc một nền apt Debian/Ubuntu (môi trường cách ly cài ba thứ đó cùng một bộ công cụ CLI kiểu runner do GitHub vận hành ở lần khởi động đầu tiên: các trình biên dịch, Python 3, jq, các công cụ lưu trữ, rsync. Toolcache ngôn ngữ và Docker không được cài).

Hợp đồng image Trình duyệt — một nền apt Debian/Ubuntu (hoặc các gói đã được cài sẵn) với bash và socat, cùng một tệp nhị phân chromium mà máy chủ tự khởi chạy dưới dạng chromium --headless=new với DevTools trên loopback của hệ thống khách 9223, được chuyển tiếp tới cổng 9222 của hệ thống khách. PulseAudio và ffmpeg được cài ở lần khởi động đầu tiên cho làn âm thanh. Đừng dựng FROM chromedp/headless-shell: headless.gn thượng nguồn loại bỏ cả ALSA lẫn PulseAudio khi biên dịch, nên tệp nhị phân đó không thể phát ra âm thanh. Phần ghi đè chỉ áp dụng cho các rig Chromium — lệnh khối lượng công việc mà nó khởi động là của Chromium, và đưa nó cho Firefox hay WebKit sẽ khởi chạy một tệp nhị phân không tồn tại ở đó. Một rig Firefox hay WebKit sẽ bỏ qua nó một cách ồn ào và khởi động image được ghim của mình.

Cổng tự động hóa — mỗi cỗ máy trình duyệt chuyển tiếp đúng một cổng loopback của máy chủ tới cổng 9222 của hệ thống khách. Đằng sau nó: DevTools của Chromium và remote agent của Firefox nằm trên loopback 9223 của hệ thống khách với một relay socat phía trước (cả hai đều bind loopback vô điều kiện); driver của WebKit nhận một --host và tự bind NIC của hệ thống khách. Firefox còn kiểm tra tiêu đề Host so với cổng của chính nó, nên client gửi authority phía hệ thống khách thay vì authority mà nó đã gọi tới.

Động từ hành động

Mọi hành động đều được phân tích một cách toàn phần: một payload sai định dạng trả về một thông báo nêu tên trường, không bao giờ là một ngoại lệ. Các động từ quan sát (đánh dấu ○) vẫn được phép khi một người đang giữ quyền điều khiển; các động từ làm thay đổi dữ liệu bị từ chối.

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 (0–60 s), type, wait○ (0–60 s), set_display, clipboard_read○, clipboard_write.

Tọa độ là pixel của hệ thống khách theo chế độ hiện tại của hệ thống khách; mọi ảnh chụp đều ghi rõ kích thước màn hình. Các tổ hợp phím dùng cách viết của X11 (ctrl+s, alt+Tab, Return).

clipboard_read nhận một selection: clipboard (thứ mà ctrl+C đưa vào, mặc định), primary (chọn-để-sao-chép của X11) hoặc xdnd (một thao tác kéo đang diễn ra). Một kết quả rỗng là câu trả lời bình thường cho cả ba. clipboard_write chỉ nhận text — hình ảnh và tệp đi theo làn tệp, bởi các đối số của một hành động được lưu vào nhật ký kiểm toán và byte hình ảnh không có việc gì ở đó. Nội dung bảng nhớ tạm quay về được bao lại như dữ liệu không đáng tin cậy.

browser_use

navigate (chỉ http/https), reload (hard tùy chọn), stop_loading, click (bộ chọn hoặc tọa độ), fill, type, key (tên phím DOM), scroll, mouse_move, drag, left_mouse_down, left_mouse_up, extract○ (a11y | dom | console), screenshot○ (full_page tùy chọn), set_viewport (tối thiểu 320×240), history, wait_for○ (bộ chọn, 0,1–30 s), clipboard_read○, clipboard_write.

Nội dung trang được trích xuất quay về được bao lại như dữ liệu không đáng tin cậy.

Trình duyệt chỉ có đúng một bảng nhớ tạm, nên clipboard_read không nhận selection. Cả hai động từ bảng nhớ tạm đều cần một ngữ cảnh bảo mật: một trang được phục vụ qua http:// thuần không có API bảng nhớ tạm nào cả, và động từ nói rõ điều đó thay vì báo về một bảng nhớ tạm rỗng — hãy dùng type trong trường hợp đó, nó chèn tại con trỏ mà không đi qua bảng nhớ tạm.

mobile_use

tap, swipe (50–5000 ms), type, key (bí danh back, home, recents, enter, delete, backspace, tab, escape, search, menu, volume_up, volume_down, power, hoặc bất kỳ KEYCODE_* nào), screenshot○, ui_dump○, install_apk (bị giới hạn trong worktree của rig và thư mục dữ liệu của máy chủ), start_app, stop_app, clear_app_data, uninstall_app, open_url, và shell. shell nhận một danh sách argv và chạy bên trong Android, không bao giờ qua shell của máy chủ; nó bao quát các chẩn đoán dành cho nhà phát triển như logcat, dumpsys và pm grant.

mobile_use không có động từ bảng nhớ tạm nào. Từ Android 10, chỉ ứng dụng đang được lấy nét mới được đọc bảng nhớ tạm.

ios_use

tap, swipe (50–5000 ms), type, key (enter, backspace, tab, escape, các phím mũi tên hoặc một ký tự in được; các bổ ngữ tùy chọn command, control, option và shift), home, lock, unlock, screenshot○, ui_dump○, install_app (một thư mục .app của trình mô phỏng bị giới hạn trong worktree của rig hoặc thư mục dữ liệu của máy chủ), start_app, stop_app, uninstall_app, open_url, và spawn. spawn nhận argv và thực thi bên trong trình mô phỏng thông qua simctl; nó không bao giờ gọi shell của máy chủ.

Tọa độ là điểm trên màn hình iOS, không phải pixel của ảnh chụp. Luồng trực tiếp giữ nguyên kích thước cố định của trình mô phỏng và thêm viền đen cho vừa khung thay vì đổi kích thước thiết bị. Việc truyền bảng nhớ tạm văn bản từ máy chủ sang trình mô phỏng và ngược lại dùng cùng chính sách quyền theo từng người dùng, theo từng chiều như các rig khác; tệp và hình ảnh không được làn pasteboard của iOS chấp nhận.

Mỗi rig tạo một thiết bị CoreSimulator và một phiên WebDriverAgent thuộc sở hữu của nó. Đóng rig sẽ dừng WebDriverAgent, tắt và xóa thiết bị đó, đồng thời xóa mục đăng ký của nó. Các rig iOS chỉ chạy trên một máy chủ macOS có Xcode, một runtime iOS đã cài đặt và cầu nối tự động hóa được ghim. Chúng không phơi ra âm thanh, micrô, thao tác thả tệp, shell của máy chủ, cũng không đảm bảo về mạng khép kín.

Công cụ quản lý

Công cụ	Mô tả
rig_list	Liệt kê các rig của một không gian làm việc kèm bề mặt, trạng thái, màn hình và bộ điều khiển
rig_close	Hủy một rig và xóa đĩa của nó

Vòng đời

Giai đoạn	Ý nghĩa
provisioning	Đang khởi động; phần chi tiết trạng thái mang nguyên văn bước hiện tại
ready	Có thể truy cập và sẵn sàng nhận hành động
parked	Đỗ do nhàn rỗi: vCPU dừng, RAM vẫn thường trú; hành động kế tiếp sẽ đánh thức nó
closing	Đang tắt
closed	Đã biến mất; hàng dữ liệu vẫn tồn tại để phục vụ nhật ký kiểm toán
failed	Đã chết hoặc không bao giờ khởi động được; có thể phân biệt để giao diện có thể đề nghị thử lại

Lý do đóng	Kích hoạt khi
requested	Một người hoặc agent yêu cầu
idleTimeout	Nhàn rỗi quá 2× khoảng thời gian nhàn rỗi, hoặc bị loại bỏ vì bộ nhớ
ttlExpired	Thời gian sống cứng đã hết
conversationEnded	Cuộc hội thoại sở hữu đã kết thúc
workspaceGone	Không gian làm việc bị xóa hoặc bị mất tư cách thành viên
serverShutdown	Máy chủ đang dừng
backendFailure	Hypervisor bên dưới đã chết

Giá trị mặc định và giới hạn trên

Giá trị	Terminal	Trình duyệt	Máy tính	Di động
Bộ nhớ	512 MB	2048 MB (Chromium); 2560 MB (Firefox, WebKit)	4096 MB	4096 MB
vCPUs	2	2	4	4
TTL cứng	8 h	2 h	2 h	2 h
Khoảng nhàn rỗi	45 min	15 min	15 min	15 min
Màn hình khi khởi động	—	1280×800	1280×800	1080×1920

• Ảnh tĩnh ở làn dành cho agent bị giới hạn ở 1280×800; làn dành cho người thương lượng lên tới 2560×1600.
• Ngân sách bộ nhớ thường trú của máy chủ cho tất cả các rig mặc định là 12 GB, được tính bằng megabyte thường trú (một VM đã đỗ vẫn giữ nguyên RAM). Việc loại bỏ theo nguyên tắc ít được dùng gần đây nhất và không bao giờ lấy đi một cỗ máy đang có người điều khiển, đang xem, hoặc đang mở terminal.
• Một terminal đang mở hoặc một làn xem sẽ ghim rig lại, không cho đỗ và không cho thu hồi khi nhàn rỗi; TTL cứng vẫn được áp dụng.

Cổng và tên miền dev

Cổng	Ở đâu	Dành riêng cho
7911	Hệ thống khách terminal	Bộ ghép kênh cổng mà mọi chuyển tiếp đều đi qua
9222, 9223	Hệ thống khách trình duyệt	Relay và điểm cuối tự động hóa (WebKit bind trực tiếp 9222 và không dùng relay)
80, 443	Loopback của hệ thống khách trình duyệt	Các làn HTTP/HTTPS của tên miền dev

• Việc dò tìm thăm dò các cổng TCP đang lắng nghe của hệ thống khách terminal khoảng 4 giây một lần, ở phía máy chủ.
• Tối đa 16 cổng được tự động chuyển tiếp cho mỗi rig; nhiều hơn thì chỉ được liệt kê trong log, không được chuyển tiếp.
• Chuyển tiếp phía máy chủ bind loopback, ưu tiên đúng số cổng của hệ thống khách; Chia sẻ trên mạng cục bộ thêm một cổng LAN do hệ điều hành chỉ định.
• Tên miền dev phải khớp với name.test hoặc name.localhost (chữ thường, nhãn tối đa 63 ký tự). Một tên miền ánh xạ tới một cổng.
• HTTPS của tên miền dev dùng một CA cục bộ trên máy chủ (EC P-256, nằm dưới <dataDir>/rigs/tls/, khóa 0600 và không bao giờ nằm trong hệ thống khách) với một chứng thư lá wildcard cho *.test / *.localhost. Không có openssl trên máy chủ nghĩa là không có làn HTTPS; HTTP thuần vẫn được định tuyến.

Giá trị mặc định của egress

Bề mặt	Danh sách cho phép mặc định
Terminal	Nền tảng dành cho nhà phát triển của sandbox (các máy chủ mã, registry gói, nhà cung cấp mô hình) + các mirror apt của Ubuntu + máy chủ mã của chính worktree
Trình duyệt	usectrl.dev (site của sản phẩm) — cộng với các kho Debian ở lần khởi động đầu tiên của mỗi engine, trong lúc nó cài các gói của mình. Trang chủ là một tài liệu file:// cục bộ và không cần egress
Máy tính	Rỗng — từ chối mọi thứ — cho tới khi một bên gọi cấp máy chủ
Di động	Không được thực thi (mạng do trình giả lập quản lý)

Mỗi microVM còn nhận thêm các máy chủ registry của image mình, chỉ cho lượt kéo. Tập máy chủ được phép của broker thông tin xác thực được suy ra từ chính danh sách cho phép đó: không token nào được phát hành cho một máy chủ mà hệ thống khách không thể tiếp cận.

Bảng nhớ tạm và truyền tệp

Cả hai chiều sao chép/dán, và việc kéo tệp vào rồi ra. Dành cho một người đang điều khiển rig; agent nhận bảng nhớ tạm qua các động từ ở trên và không có chút truyền tệp nào (nó vốn đã có một shell bên trong môi trường cách ly).

Việc qua ranh giới của bảng nhớ tạm được kiểm soát riêng theo từng người dùng và từng chiều. Dán từ máy chủ vào rig được cho phép theo mặc định; sao chép từ rig ra máy chủ sẽ hỏi trước (một quyền trong mười phút, hoặc luôn cho phép trong Cài đặt → Máy chủ → Rigs → Quyền truy cập bảng nhớ tạm). Hai lựa chọn này độc lập với nhau và không bao giờ là một cài đặt của không gian làm việc.

Làn	Tuyến	Mang theo
Bảng nhớ tạm	GET/POST /rig/clipboard/<rigId>	Văn bản, một ảnh PNG/JPEG (≤16 MB), và đường dẫn phía hệ thống khách của các tệp trên bảng nhớ tạm
Tệp	POST /rig/files/<rigId>	Tối đa 64 tệp, mỗi tệp ≤256 MB và ≤512 MB mỗi lần thả, kèm một điểm thả theo pixel hệ thống khách tùy chọn
Tệp	GET /rig/files/<rigId>?p=<base64url path>	Byte của một tệp, theo chiều ra

• HTTP, không phải RPC. Socket RPC đóng kết nối khi có một khung gửi vào vượt quá 256 KB — một biện pháp phòng chống DoS đúng đắn cho các lệnh JSON nhưng lại chí mạng với một ảnh chụp được dán. Byte đi theo đúng kiểu tuyến mà khung rig và âm thanh cuộc họp vốn đã dùng.
• Xác thực là đích được ký rig-files:<workspaceId>/<rigId> cộng với tư cách thành viên không gian làm việc — một đích riêng, nên một URL được phát hành để xem một cỗ máy không thể đồng thời ghi tệp vào nó.
• Việc chiếm quyền điều khiển vẫn áp dụng. Ghi vào bảng nhớ tạm và thả tệp là hành vi làm thay đổi dữ liệu nên bị từ chối khi người khác đang giữ quyền điều khiển; đọc bảng nhớ tạm và đọc một tệp ra là hành vi quan sát nên không bị từ chối.
• Tệp thả rơi vào đâu: ~/Drops (desktop), ~/drops (terminal — bên cạnh worktree, không bao giờ ở trong đó, nên một tệp được thả không bao giờ xuất hiện như một thay đổi chưa được theo dõi), /tmp/cc-drops (trình duyệt). Máy chủ chọn thư mục; bên gọi không thể đặt tên cho nó. Tệp đã tồn tại không bao giờ bị ghi đè — một tên bị trùng sẽ rơi vào dưới dạng 2-name.ext.
• Hệ thống khách được cho biết điều gì: một trang trình duyệt nhận một sự kiện thả thật tại điểm được yêu cầu (Input.dispatchDragEvent); một desktop nhận các tệp cùng URI của chúng trên bảng nhớ tạm, vì không máy chủ nào có thể tạo giả một thao tác kéo XDND vào một bộ toolkit bất kỳ mà không có một daemon đặc quyền bên trong hệ thống khách. Phản hồi nói rõ trường hợp nào trong hai đã xảy ra.
• Kéo ra chỉ có trên desktop và đọc XdndSelection của hệ thống khách trong lúc thao tác kéo đang diễn ra. Một payload giống hệt thứ mà hệ thống khách đã đang giữ khi thao tác nhấn bắt đầu sẽ bị coi là một vùng chọn cũ từ một thao tác kéo đã kết thúc, chứ không phải một vùng chọn mới — X không có bước “thao tác kéo đã kết thúc”.
• Yêu cầu về image: image desktop phải theo giao thức 2 trở lên (được dựng sau khi tính năng bảng nhớ tạm ra đời). Một image cũ hơn sẽ trả về 404 và ứng dụng khuyên dựng lại nó thay vì báo rằng cỗ máy bị hỏng.
• Nhật ký kiểm toán ghi lại hình dạng, không bao giờ ghi nội dung: các hàng clipboard_read, clipboard_write, drop_files và read_file mang số lượng, kích thước và đường dẫn. Bảng nhớ tạm là nơi thông tin xác thực tồn tại trong vài giây một lần, và không có gì trong đó bị ghi lại.

Rào chắn, sự kiện, lưu trữ

• Các công cụ rig khai báo lớp hành động enclosureControl (cùng với networkEgress và processSpawn trên các công cụ use; mobile_use và ios_use còn khai báo packageInstall). rig_close khai báo enclosureControl; rig_list không khai báo gì. Được cho phép theo mặc định; các chế độ chỉ đọc từ chối toàn bộ; nút chỉnh tự chủ theo từng space có thể hạ nó xuống mức hỏi trước.
• Sự kiện miền: RigClosedEvent (kèm lý do đóng), RigControlChanged (chiếm quyền / trả quyền), RigReaped (thu hồi do nhàn rỗi, TTL hoặc bộ nhớ, kèm agent đang điều khiển). Việc mở một rig không phải là một sự kiện. Xem sự kiện miền.
• Lưu trữ: rig_sessions và rig_action_log trong cơ sở dữ liệu của mỗi không gian làm việc. Nhật ký hành động ghi lại mọi sự kiện đầu vào cùng chủ thể và một số thứ tự đơn điệu theo từng rig; văn bản được gõ sẽ được che đi thành một độ dài và một mã băm trước khi được ghi.
• Thư mục dữ liệu: rigs/images/ (các image qcow2 đã nhập), rigs/smolvm/ (trạng thái runtime theo từng rig), rigs/smolvm-packs/ (các pack máy đã giải nén sẵn), rigs/tls/ (CA của tên miền dev), rigs/run/ (các overlay và seed của QEMU).
• Tuyến: chế độ xem trực tiếp là một tab trong một space hoặc trang PR; /settings/server/rigs là màn hình cài đặt Rigs.