معماری داشبورد

چشم‌انداز

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

اصول:

• بورد چهره‌ای از یک نشست است، نه شیئی جدید. هر نشست (رشته) دو چهره دارد: رونوشت و بورد. نشست بدون ویجت سنجاق‌شده صرفاً گفت‌وگو است. با سنجاق کردن یک ویجت، بورد به‌وجود می‌آید. بوردها هویت، مالکیت عامل، نام‌گذاری، سنجاق‌شدن و چرخه عمر نشست را به ارث می‌برند. هیچ dashboard_create، رجیستری بورد یا مدل ACL جداگانه‌ای وجود ندارد.
• برابری عامل. هر کاری که کاربر بتواند روی بورد انجام دهد، عامل نیز می‌تواند با ابزارها انجام دهد: افزودن/به‌روزرسانی/حذف ویجت‌ها، چیدمان آن‌ها، مدیریت زبانه‌ها، تغییر زبانه قابل‌مشاهده و لنگر دادن یا پنهان کردن گفت‌وگو.
• بومی، نه تعبیه‌شده. بورد از مؤلفه‌های Lit در پوسته Control UI تشکیل شده است (همان سیستم طراحی دیگر بخش‌های برنامه). فقط محتوای ویجت در iframeها ایزوله می‌شود. نوار URL یا تزئینات مرورگر وجود ندارد.
• سطح کوچک عامل. ویجت‌ها با نام پایدار آدرس‌دهی و درجا به‌روزرسانی می‌شوند. چیدمان، شبکه‌ای سیال با فشرده‌سازی خودکار است؛ عامل اندازه‌ها و لنگرها را بیان می‌کند، نه پیکسل‌ها یا مختصات را.
• قابلیت‌ها به‌جای اعتماد. کد ویجت، HTML/JS دلخواهِ نوشته‌شده توسط عامل در محیط ایزوله سخت‌گیرانه است. دسترسی (داده Gateway، کنش‌ها، شبکه) فقط از طریق مانیفست قابلیتِ اعلام‌شده و اعطاشده توسط اپراتور وجود دارد.

مفاهیم

جریان‌های تجربه کاربری

• ارتقا: عامل در هر گفت‌وگو show_widget را فراخوانی می‌کند ← ویجت دقیقاً مانند امروز به‌صورت درون‌خطی در رونوشت رندر می‌شود ← نگه‌داشتن نشانگر، سنجاق به داشبورد را نشان می‌دهد ← ویجت روی بورد نشست ظاهر می‌شود. عامل می‌تواند برای انجام همین کار pin: true را ارسال کند.
• نمای بورد: نشستی که بورد دارد، کلید تغییر چهره (گفت‌وگو / داشبورد) دریافت می‌کند. نمای بورد = نوار زبانه (فقط وقتی بیش از 1 زبانه وجود دارد) + شبکه سیال + پنل گفت‌وگوی لنگرشده. لنگر گفت‌وگو دقیقاً مانند نوار کناری قابل تغییر اندازه، جابه‌جایی (چپ/راست/پایین) و جمع‌شدن است. وضعیت لنگر برای هر زبانه به‌خاطر سپرده می‌شود.
• کشیدن: کاربر ویجت‌ها را می‌کشد؛ شبکه خودکار فشرده می‌شود (ویجت‌ها بالا می‌روند و همسایه‌ها بازچینی می‌شوند). تغییر اندازه با دستگیره روی گام‌های اندازه می‌چسبد. هیچ جای‌گذاری پیکسلی وجود ندارد — برای هیچ‌کس.
• هشدار بازنشانی: /new / /reset در نشستی دارای بورد، در رابط وب تأیید می‌خواهد («زمینه بازنشانی می‌شود، داشبورد باقی می‌ماند») و بورد را حفظ می‌کند.
• نوار کناری: نشست‌های سنجاق‌شده، در صورت داشتن بورد، چهره بورد خود را رندر می‌کنند. بورد نشست Home، «داشبورد عامل» پیش‌فرض است.
• تعامل‌ها (سه سطح، پایین را ببینید): رویدادهای وضعیت بی‌صدا، ارسال‌های قابل‌مشاهده درخواست، و محرک‌های خودکارسازی.

سطوح تعامل

1. رویدادهای وضعیت (پیش‌فرض). تعامل‌های رابط ویجت که مدل باید از آن‌ها آگاه باشد اما نباید پاسخ دهد. bridge.emitState({...}) یک اعلان ساختاریافته به نشست می‌افزاید (همان سازوکار اعلان‌های فعالیت گروهی). هیچ نوبت عاملی آغاز نمی‌شود؛ مدل اعلان‌های انباشته‌شده را در اجرای بعدی خود می‌بیند.
2. پرامپت‌ها (گفت‌وگوی صریح). bridge.sendPrompt(text) — به فعال‌سازی کاربر نیاز دارد؛ یک پیام قابل‌مشاهده کاربر را به نشست می‌فرستد (گفت‌وگوی لنگرشده آن را نشان می‌دهد). دارای محدودیت نرخ است؛ هر ارسال توسط کاربر تأیید می‌شود، مگر اینکه ویجت اعطای قابلیت prompt را داشته باشد.
3. خودکارسازی. bridge.runAction(name, args) — کنشی اعلام‌شده در مانیفست را اجرا می‌کند. مجموعه فعل اولیه: cron.trigger (همین حالا یک کار Cron موجود را اجرا کن) و binding.refresh. کارهای Cron از قبل در نشست‌های اجرای قابل‌مشاهده و ایزوله اجرا می‌شوند و می‌توانند از مدل ارزان‌تری استفاده کنند: این همان مسیر «مدل کوچک ویجت را به‌کار می‌اندازد» است. هیچ نشست پنهانی در هیچ‌جا وجود ندارد.

مدل و میزبانی ویجت

HTML/JS ویجت توسط عامل نوشته می‌شود (معمولاً از طریق show_widget)، در پوسته استاندارد سند (متای CSP، گزارشگر اندازه، راه‌انداز پل) قرار می‌گیرد و در <iframe sandbox="allow-scripts"> رندر می‌شود (هرگز allow-same-origin).

• ویجت‌های درون‌خطی (رونوشت) پایپ‌لاین فعلی سند canvas را حفظ می‌کنند: در پوشه وضعیت نوشته می‌شوند، توسط Gateway ارائه می‌شوند، به‌ازای هر محدوده پاک‌سازی می‌شوند، بدون تأیید (طبق ساختار، بدون قابلیت هستند — ارسال پرامپت‌ها توسط کاربر تأیید می‌شود).
• ویجت‌های بورد وضعیت نشست هستند: بایت‌ها در پایگاه داده SQLite عامل مالک (board_widgets) نگه‌داری می‌شوند و از طریق مسیر اصلی Gateway (/__openclaw__/board/<agentId>/<sessionKey>/<name>/) که پایگاه داده را می‌خواند ارائه می‌شوند. سنجاق‌کردن ویجت رونوشت، بایت‌ها را کپی می‌کند. سقف‌ها: 256 KB برای هر ویجت، 48 ویجت برای هر بورد.
• به‌روزرسانی درجا: انتشار دوباره ویجتی با همان name، بایت‌ها را جایگزین می‌کند، revision را افزایش می‌دهد، board.changed را پخش می‌کند و نماهای زنده فقط همان iframe را بارگذاری مجدد می‌کنند.
• انجماد بایت: قابلیت‌های اعطاشده به sha256 بایت‌های ویجت متصل می‌شوند. تغییر بایت‌ها، اعطاهای data/net/actions را فقط زمانی حفظ می‌کند که بازبینی جدید زیرمجموعه‌ای از مانیفست اعطاشده را اعلام کند؛ مانیفست گسترده‌تر دوباره از اپراتور درخواست تأیید می‌کند.

ویجت‌ها میزبان محتوا هستند؛ برنامه‌های MCP یک نوع محتوا هستند

ویجت عنصر پایه OpenClaw است: سلول بورد نام‌دار، سنجاق‌شده، اندازه‌دار، متعلق به نشست و دارای رکورد اعطا. آنچه درون آن رندر می‌شود، یک نوع محتوا است:

• html — نوشته‌شده توسط عامل از طریق show_widget، با بایت‌ها در فضای ذخیره‌سازی بورد.
• mcp-app — نمای برنامه MCP شخص ثالث (منبع ui:// از سرور پیکربندی‌شده) که درون سلول ویجت میزبانی می‌شود.

برنامه‌های MCP مدل ویجت را تعریف نمی‌کنند؛ ویجت‌ها توانایی میزبانی آن‌ها را به‌دست آورده‌اند. هویت، جای‌گذاری، سنجاق‌کردن، اعطاها و API مربوط به نویسنده متعلق به OpenClaw باقی می‌مانند — بنابراین کد show_widget به کوتاهی امروز باقی می‌ماند و هرگز لازم نیست از وجود مشخصات MCP Apps آگاه باشد.

زیرساخت مشترک زیرین (ساده‌سازی در اینجا رخ می‌دهد):

• یک میزبان ایزوله. ویجت‌های html از همان پایپ‌لاین سخت‌سازی‌شده‌ای رندر می‌شوند که برنامه‌های MCP با آن منتشر شدند (iframe دوتایی در مبدأ اختصاصی محیط ایزوله، با CSP اعلام‌شده برای هر ویجت که به‌صورت fail-closed رمزگشایی می‌شود)، نه از یک میزبان iframe سفارشی دوم. پراکسی HTML را به‌صورت مقدار دریافت می‌کند، بنابراین محتوای محلی حالت طبیعی است.
• یک مدل مجوزدهی. دسترسی ویجت، صرف‌نظر از نوع آن، یک فهرست مجاز اعطاشده است: برای ویجت‌های html، ابزارهای میزبان؛ برای ویجت‌های mcp-app، ابزارهای قابل‌مشاهده برای برنامه در سرور (از طریق سازوکار موجود allowedAppToolNames که به‌جای هر اجرای ایجادکننده، برای هر ویجت ماندگار می‌شود).
• ابزارهای میزبان برای ویجت‌های html (از طریق پل ویجت در دسترس و در برابر اعطا بررسی می‌شوند):
  • openclaw.prompt.send — سطح 2؛ از طریق ویرایشگر قابل‌مشاهده مسیریابی می‌شود، مگر در صورت اعطا، توسط کاربر تأیید می‌شود
  • openclaw.state.emit — اعلان‌های نشست سطح 1 (ادغام‌شده، با سقف اندازه)
  • openclaw.data.read — اتصال‌های فقط‌خواندنی پارامتردار (مجموعه موجود RPCهای خواندنی فهرست مجاز) که در سمت Gateway حل می‌شوند
  • openclaw.cron.trigger — خودکارسازی سطح 3
• net = CSP. دسترسی شبکه از اعلامیه CSP موجود و منتشرشده برای هر ویجت (connect-src مبدأ) استفاده می‌کند — ویجت آب‌وهوای خودبه‌روزرسان، API خود را مستقیماً از محیط ایزوله واکشی می‌کند و Gateway دخالتی ندارد.
• اعطاها. ویجتی که چیزی اعلام نمی‌کند، بی‌درنگ رندر می‌شود (ایزوله، default-src 'none'، با تأیید جداگانه ارسال پرامپت‌ها) — همان سطح اعتماد ویجت‌های درون‌خطی گفت‌وگوی امروز. ابزارها/مبدأهای اعلام‌شده، ویجت را در بورد به pending می‌برند: کارت جای‌نگهدار آن‌ها را به‌صورت خوانا برای انسان فهرست می‌کند و دکمه‌های تک‌ضربه‌ای اجازه دادن/رد کردن را ارائه می‌دهد. اعطاها به‌ازای نام ویجت هستند؛ برای ویجت‌های html آن‌ها با بایت منجمد می‌شوند (sha256) و بایت‌های تغییریافته فقط زمانی اعطا را حفظ می‌کنند که اعلامیه محدودتر شده باشد.
• لایه سازگاری نویسندگی. پوشش سند، window.openclaw.prompt، window.openclaw.state، window.openclaw.data و window.openclaw.cron را به‌عنوان API پایدار نویسنده تزریق می‌کند. فراخوانی‌های داشبورد یک کانال درخواست متصل به view-ticket مشترک دارند؛ گزارش اندازه و توکن‌های پوسته همچنان اعلان‌های جداگانه میزبان باقی می‌مانند.

اعلام قابلیت‌های Plugin

Pluginهای فعال می‌توانند میزبان ویجت را از طریق dashboard.dataBindings و dashboard.actionVerbs در openclaw.plugin.json گسترش دهند. شناسه‌های محلی Plugin به نام‌های اعطا با پیشوند شناسه Plugin تبدیل می‌شوند، مانند workboard.cards.list و workboard.dispatch؛ % و . در بخش شناسه Plugin escape می‌شوند تا تقسیم متفاوت Plugin/شناسه محلی نتواند همان اعطای ماندگار را به ارث ببرد. هنگام ثبت Plugin، OpenClaw تأیید می‌کند که هر اتصال، RPC ثبت‌شده توسط همان Plugin با operator.read را هدف قرار می‌دهد و هر کنش، موردی با operator.write را هدف می‌گیرد؛ اعلامیه‌های نامعتبر باعث شکست بارگذاری Plugin می‌شوند. رجیستری اعتبارسنجی‌شده فقط با تغییرات چرخه عمر Plugin بازسازی می‌شود، درحالی‌که اعطاهای ویجت برای هر ویجت و وابسته به بایت و بازبینی باقی می‌مانند.

محدودیت باقی‌مانده مدل‌سازی‌شده: کانال‌های داده WebRTC

CSP محیط ایزوله دستورالعمل پیشنهادی webrtc 'block' را منتشر می‌کند، اما مجموعه فعلی دستورالعمل‌های CSP در Chromium آن را پیاده‌سازی نمی‌کند. بنابراین ویجت‌های قابل‌اسکریپت در Chromium فعلی می‌توانند از کانال‌های داده WebRTC برای خروج داده استفاده کنند. همین محدودیت باقی‌مانده هم‌اکنون برای ویجت‌های درون‌خطی گفت‌وگو و میزبان MCP Apps روی main منتشر شده است.

موازنه پذیرفته‌شده: OpenClaw ویجت‌های اسکریپت‌پذیر را بر اساس این ریسک باقی‌مانده محدود نمی‌کند. محتوای ویجت تنها از طریق قابلیت data:read که اپراتور اعطا کرده و در سطح بایت ثابت شده است، به داده‌های حساس OpenClaw دسترسی پیدا می‌کند و Permissions Policy محیط ایزوله، دسترسی به دوربین و میکروفون را مسدود می‌کند. محافظ DOM API یک دفاع عمقی با بهترین تلاش است، نه یک مرز امنیتی، و باید در سخت‌سازی‌های بعدی انجام شود.

نمایش رونوشت: یک کارت ویجت

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

ترکیب‌بندی: v1 مجاورت شبکه‌ای است (ویجت پوسته عامل در کنار یک ویجت برنامه در یک زبانه). v2 جایگاه‌های برنامه مدیریت‌شده توسط میزبان را اضافه می‌کند — HTML ویجت عامل یک ناحیه جایگاه تعریف می‌کند و میزبان، نمای واقعی برنامه را به‌صورت یک محیط ایزوله هم‌سطح ترکیب می‌کند. برنامه هرگز داخل iframe عامل رندر نمی‌شود: تودرتوسازی، هویت پل را مختل می‌کند و امکان هم‌پوشانی/کلیک‌ربایی رابط کاربری برنامه‌ای را که مجوز گرفته فراهم می‌کند؛ بنابراین جایگاه یک قرارداد چیدمان است، نه جاسازی.

ویجت‌های تأمین‌شده از سرور (برنامه‌های MCP سنجاق‌شده)

با میزبان یکپارچه، سنجاق‌کردن یک برنامه MCP شخص ثالث صرفاً ویجتی است که محتوایش به‌جای ذخیره‌شدن، از سرور دریافت می‌شود: board_widgets به‌جای بایت‌های HTML، توصیفگر (serverName، toolName، uiResourceUri، toolCallId + sessionKey مبدأ) را نگه می‌دارد و برد، اجاره نما را پس از TTL ده‌دقیقه‌ای نوبت چت دوباره صادر می‌کند (در صورت کهنگی، منبع ui:// دوباره دریافت می‌شود). نماهای درون‌خطی برنامه MCP در چت، همان امکان سنجاق‌کردن به داشبورد ویجت‌های عامل را دریافت می‌کنند. نماهای بازگشایی‌شده، امروز طبق طراحی فقط‌خواندنی هستند؛ برنامه‌های سنجاق‌شده‌ای که باید تعاملی بمانند، مجوزی پایدار برای ابزارهای قابل‌مشاهده برنامه در سرور دریافت می‌کنند (فهرست مجاز صریح هنگام سنجاق‌کردن به اپراتور نمایش داده می‌شود) که از اجرای صادرکننده مستقل است. سنجاق‌های بدون مجوز فقط‌خواندنی باقی می‌مانند — و همچنان برای داشبوردهای نمایشی مفیدند. v1 به برد نشست مبدأ سنجاق می‌کند؛ سنجاق‌کردن میان‌نشستی به کارگزار اجاره نیاز دارد و منتظر می‌ماند. با Pull request باز #109807 (ui/message، مسیریابی سازنده، انتشار تم/اندازه) هماهنگ شود.

یکپارچه‌سازی WorkBoard

برنامه یکپارچه‌سازی WorkBoard، مالکیت کارت‌ها و بردها را در Plugin نگه می‌دارد و هم‌زمان کارت‌های ارسال‌شده را از طریق sessionKey و runId موجود به بردهای نشستشان متصل می‌کند، خوراک‌ها و ارسال WorkBoard را از طریق اتصال‌ها و کنش‌های اعلام‌شده توسط Plugin در دسترس قرار می‌دهد و به‌جای معرفی یک نوع ویجت ویژه WorkBoard، این نتایج را با انواع ویجت html و mcp-app موجود ترکیب می‌کند.

چیدمان: شبکه سیال

12 ستون، ارتفاع سطر ثابت، فشرده‌سازی خودکار (جاذبه رو به بالا، کنارزدن هنگام کشیدن — معناشناسی gridstack، پیاده‌سازی‌شده به‌صورت بومی؛ محاسبات شبکه خالص و بدون DOM باقی می‌ماند). وضعیت چیدمان ویجت برای هر زبانه: { name, w (1-12), h (rows) } به‌علاوه ترتیب. واژگان عامل:

• size: sm (3×3) · md (6×4) · lg (8×6) · xl (12×8) · full (زبانه تک‌ویجتی)
• after: <widgetName> لنگر اختیاری ترتیب؛ حذف آن = افزودن به انتها
• کاربر آزادانه می‌کشد/تغییر اندازه می‌دهد؛ همان مدل ترتیب+اندازه رفت‌وبرگشت کامل دارد.

مدل داده (پایگاه داده هر عامل)

جدول‌های جدید در agents/<agentId>/agent/openclaw-agent.sqlite (نیازمند افزایش نسخه شِمای پایگاه داده عامل است — پیش از ادغام، تأیید اپراتور الزامی است):

CREATE TABLE board_tabs (  session_key TEXT NOT NULL,  tab_id      TEXT NOT NULL,           -- slug  title       TEXT NOT NULL,  position    INTEGER NOT NULL,  chat_dock   TEXT NOT NULL DEFAULT 'right',  -- left|right|bottom|hidden  created_by  TEXT NOT NULL,           -- 'user' | 'agent'  PRIMARY KEY (session_key, tab_id)) STRICT; CREATE TABLE board_widgets (  session_key  TEXT NOT NULL,  name         TEXT NOT NULL,          -- stable widget name  tab_id       TEXT NOT NULL,  title        TEXT,  html         BLOB NOT NULL,          -- wrapped document source  sha256       TEXT NOT NULL,  revision     INTEGER NOT NULL,  size_w       INTEGER NOT NULL,  size_h       INTEGER NOT NULL,  position     INTEGER NOT NULL,       -- order within tab (auto-compact input)  manifest     TEXT NOT NULL DEFAULT '{}',  -- capability manifest JSON  grant_state  TEXT NOT NULL DEFAULT 'none', -- none|pending|granted|rejected  granted_sha  TEXT,                   -- byte-frozen grant  created_by   TEXT NOT NULL,  created_at   INTEGER NOT NULL,  updated_at   INTEGER NOT NULL,  PRIMARY KEY (session_key, name)) STRICT;

وجود برد = هرگونه ردیف برای sessionKey. حذف یک نشست، ردیف‌های برد آن را حذف می‌کند. /new//reset به آن‌ها دست نمی‌زند.

سطح پروتکل

RPCها (جدول متدهای هسته، شِماهای typebox در gateway-protocol):

• board.get { sessionKey } ← زبانه‌ها + فراداده ویجت (بدون بایت) — operator.read
• board.update { sessionKey, ops[] } — ایجاد/خواندن/به‌روزرسانی/حذف و مرتب‌سازی مجدد زبانه، جابه‌جایی/تغییر اندازه/ حذف/برداشتن سنجاق ویجت، وضعیت جایگاه چت، تمرکز روی زبانه — operator.write
• board.widget.put { sessionKey, name, html, manifest, placement } — operator.write (مسیر ابزار عامل و مسیر سنجاق‌کردن)
• board.widget.grant { sessionKey, name, decision } — operator.approvals
• board.event { ticket, payload } — دریافت رویداد وضعیت سطح 1 وابسته به بلیت؛ قالب قدیمی میزبان مورداعتماد { sessionKey, widget, payload } باقی می‌ماند — operator.write
• board.prompt.authorize { ticket } — مشخص می‌کند آیا ارسال درخواست قابل‌مشاهده همچنان به تأیید در هر کلیک نیاز دارد — operator.read
• board.data.read { ticket, bindingId, params? } — تفکیک اتصال خواندن هسته یا Plugin فعالِ فهرست‌مجازشده در سمت Gateway — operator.read
• board.action { ticket, action, ... } — ارسال خودکارسازی با مجوز دقیق از طریق مسیر اجرای فوری Cron موجود یا فعل کنش اعتبارسنجی‌شده یک Plugin فعال — operator.write

رویدادها (در EVENT_SCOPE_GUARDS، دامنه خواندن):

• board.changed { sessionKey, revision, widget? } — وضعیت ماندگار تغییر کرد؛ رابط کاربری دوباره دریافت می‌کند (و در صورت وجود widget، یک iframe را دوباره بارگیری می‌کند).
• board.command { sessionKey, command } — هدایت گذرای رابط کاربری (عامل زبانه قابل‌مشاهده را تغییر می‌دهد، جایگاه چت را فعال/غیرفعال می‌کند) — الگوی ui.command.

بایت‌های ویجت از طریق سطح HTTP احراز هویت‌شده ارائه می‌شوند، نه سوکت.

ابزارهای عامل

در مجموع سه ابزار (هسته، همیشه ثبت‌شده؛ رندر همانند امروز بر اساس قابلیت کلاینت inline-widgets محدود می‌شود):

• show_widget { title, widget_code, name?, pin?, size?, tab?, after?, capabilities? } — ایجاد/به‌روزرسانی بر اساس نام؛ pin آن را روی برد قرار می‌دهد. بدون name/pin دقیقاً مانند امروز رفتار می‌کند (درون‌خطی، موقت).
• dashboard { action, ... } — افعال مدیریت برد: read، tab_create، tab_update، tab_delete، tabs_reorder، widget_move، widget_remove، unpin، focus_tab، set_chat_dock.
• ابزارهای cron موجود، سطح خودکارسازی را پوشش می‌دهند؛ ابزار جدیدی لازم نیست.

توضیحات ابزار، واژگان اندازه/لنگر و مدل سطح‌بندی را آموزش می‌دهد. عامل از طریق اعلان‌های نشست از رویدادهای سطح 1 کاربر مطلع می‌شود، برای نمونه [dashboard] user clicked "Refresh" on widget weather (tab main).

مواردی که این جایگزین می‌کند

• extensions/workspaces حذف می‌شود. آزمایشی، enabledByDefault: false، هرگز در نسخه پایدار نبوده است (نخستین بار در نسخه‌های بتای 2026.7.2 ظاهر شد). بدون مهاجرت؛ یک قانون doctor، <stateDir>/workspaces/ منسوخ را در صورت وجود حذف می‌کند. ایده‌های برداشت‌شده: محاسبات خالص شبکه، مدل امنیتی پل (راه‌اندازی پورت، محدودسازی اتصال، محدودیت نرخ)، تأیید ثابت‌شده در سطح بایت.
• میزبانی ویجت از extensions/canvas به هسته منتقل می‌شود. مخزن سند canvas، پوشش سند، ارائه HTTP و ابزار show_widget به هسته منتقل می‌شوند (src/canvas/)؛ Plugin ابزار کنترل node-canvas (canvas) و A2UI را نگه می‌دارد. اعلان pluginSurfaceUrls["canvas"] و مسیرهای /__openclaw__/canvas قراردادهای عرضه‌شده کلاینت بومی هستند و پایدار باقی می‌مانند. نشست‌های Discord گونه show_widget تحت مالکیت Discord را نگه می‌دارند.

خارج از اهداف (این برنامه)

• اشتراک‌گذاری چندکاربره برد/ACLها (آینده؛ از طریق اشتراک‌گذاری نشست ارائه خواهد شد).
• رندر بومی برد در macOS/iOS (هر جا Control UI را جاسازی کنند آن را دریافت می‌کنند؛ مسیر ویجت درون‌خطی بدون تغییر است).
• ویجت‌های داده داخلی (کارت‌های نشست‌ها/مصرف/Cron) — پل قابلیت به‌علاوه ویجت‌های تألیف‌شده توسط عامل، v1 را پوشش می‌دهند؛ رجیستری نوع داخلی می‌تواند بعداً اضافه شود.

برنامه پیاده‌سازی

درخت‌های کاری مستقل، ساخته‌شده با Codex، بازبینی+ادغام به‌ترتیب. ابتدا ادغام، سپس اصلاح.

اعتبارسنجی طبق قواعد مخزن: vitest متمرکز به‌صورت محلی، کنترل‌های کامل روی Crabbox/Testbox، اجرای $autoreview پیش از هر ادغام، اثبات زنده برای T6.