---
read_when:
    - सत्र डैशबोर्ड (बोर्ड्स) सुविधा को लागू करना या उसकी समीक्षा करना
    - विजेट होस्टिंग, विजेट ब्रिज या बोर्ड स्टोरेज बदलना
summary: 'सत्र डैशबोर्ड: आर्किटेक्चर और कार्यान्वयन योजना (तकनीकी डिज़ाइन, GA-पूर्व)'
title: डैशबोर्ड आर्किटेक्चर
x-i18n:
    generated_at: "2026-07-27T20:43:09Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: a7c5da94ec19add55c6b7b530f0c17509a027e97fb301469ce48f520b325c169
    source_path: web/dashboard-architecture.md
    workflow: 16
---

<Note>
सत्र डैशबोर्ड सुविधा के लिए तकनीकी डिज़ाइन दस्तावेज़, जिसे कार्यान्वयन से पहले और
उसके दौरान लिखा गया है। यह निर्माण-विस्तार के लिए सत्य का स्रोत है। जब यह
सुविधा जारी होगी, तो `/web/dashboard` उपयोगकर्ता-दृश्य पृष्ठ बन जाएगा और यह पृष्ठ
आर्किटेक्चर संदर्भ के रूप में बना रहेगा।
</Note>

## परिकल्पना

आज किसी एजेंट के साथ काम करना एक टेक्स्ट स्ट्रीम है। डैशबोर्ड इसे एक
कार्यक्षेत्र बनाता है: एजेंट लाइव, इंटरैक्टिव विजेट रेंडर करता है; उपयोगकर्ता उन्हें
एक स्थायी सतह पर पिन करता है; चैट किनारे डॉक होती है (या छिप जाती है) और मुख्य
सामग्री बोर्ड होती है। सत्र छोड़े बिना ही आप "एजेंट से बात करने" से
"एजेंट द्वारा आपके लिए बनाए गए कंट्रोल पैनल को संचालित करने" तक पहुँच जाते हैं।

सिद्धांत:

- **बोर्ड किसी सत्र का एक रूप है, कोई नई वस्तु नहीं।** हर सत्र (थ्रेड)
  के दो रूप होते हैं: ट्रांसक्रिप्ट और बोर्ड। बिना पिन किए गए विजेट वाला सत्र
  सामान्य चैट होता है। एक विजेट पिन करते ही बोर्ड अस्तित्व में आ जाता है। बोर्ड
  सत्र की पहचान, एजेंट स्वामित्व, नामकरण, पिनिंग और जीवनचक्र प्राप्त करते हैं। कोई
  `dashboard_create` नहीं, कोई बोर्ड रजिस्ट्री नहीं, कोई अलग ACL मॉडल नहीं।
- **एजेंट समानता।** उपयोगकर्ता बोर्ड पर जो कुछ भी कर सकता है, एजेंट
  टूल्स से कर सकता है: विजेट जोड़ना/अपडेट करना/हटाना, उन्हें व्यवस्थित करना, टैब
  प्रबंधित करना, दृश्यमान टैब बदलना, चैट को डॉक करना या छिपाना।
- **नेटिव, एम्बेडेड नहीं।** बोर्ड Control UI शेल में Lit कंपोनेंट्स है
  (वही डिज़ाइन सिस्टम जो शेष ऐप में है)। केवल विजेट की _सामग्री_ को
  iframe में सैंडबॉक्स किया जाता है। कोई URL बार नहीं, कोई ब्राउज़र क्रोम नहीं।
- **छोटी एजेंट सतह।** विजेट को स्थिर नाम से संबोधित किया जाता है और
  उसी स्थान पर अपडेट किया जाता है। लेआउट एक प्रवाही, स्वतः-संकुचित होने वाला ग्रिड है;
  एजेंट आकार और एंकर बताता है, पिक्सेल या निर्देशांक कभी नहीं।
- **भरोसे के बजाय क्षमताएँ।** विजेट कोड एक कठोर सैंडबॉक्स में मनमाना,
  एजेंट-लिखित HTML/JS है। पहुँच (Gateway डेटा, क्रियाएँ, नेटवर्क) केवल घोषित,
  ऑपरेटर-द्वारा-प्रदत्त क्षमता मैनिफ़ेस्ट के माध्यम से उपलब्ध होती है।

## अवधारणाएँ

| अवधारणा             | परिभाषा                                                                                                                                                        |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| सत्र (थ्रेड)    | मौजूदा Gateway सत्र, जिसकी कुंजी स्थिर `sessionKey` है। किसी एजेंट के स्वामित्व में।                                                                                        |
| बोर्ड               | एक सत्र का विजेट रूप। केवल तभी अस्तित्व में होता है जब सत्र में विजेट/टैब हों। `/new`/`/reset` के बाद भी बना रहता है (`sessionKey` से जुड़ा है, ट्रांसक्रिप्ट से नहीं)।                 |
| टैब                 | बोर्ड का एक प्रस्तुति पृष्ठ: कौन-से विजेट, उनकी व्यवस्था और चैट डॉक स्थिति (`left`/`right`/`bottom`/`hidden`)। बोर्ड एक अंतर्निहित टैब से शुरू होते हैं। |
| विजेट              | सत्र के स्वामित्व वाला, नामित और सैंडबॉक्स किया हुआ HTML/JS प्रोग्राम। इसे `sessionKey` + `name` के रूप में संबोधित किया जाता है। नाम से उसी स्थान पर अपडेट किया जाता है।                                              |
| क्षमता मैनिफ़ेस्ट | प्रत्येक विजेट की पहुँच की घोषणा: `data` (रीड बाइंडिंग), `actions` (अनुमति-सूचीबद्ध क्रियाएँ), `prompt` (सत्र को भेजना), `net` (अनुमत ओरिजिन)।                      |
| पिन (विजेट)        | ट्रांसक्रिप्ट विजेट को सत्र के बोर्ड पर ले जाना (उपयोगकर्ता सुविधा या एजेंट टूल आर्ग्युमेंट)। अनपिन करने पर वह बोर्ड से हट जाता है।                                         |
| पिन (सत्र)       | सत्रों की मौजूदा साइडबार पिनिंग। बोर्ड वाला पिन किया हुआ सत्र अपने बोर्ड रूप में खुलता है।                                                                      |

## UX प्रवाह

- **उन्नयन:** एजेंट किसी भी चैट में `show_widget` कॉल करता है → विजेट
  ठीक आज की तरह ट्रांसक्रिप्ट में इनलाइन रेंडर होता है → होवर करने पर **डैशबोर्ड पर पिन करें** दिखता है → विजेट
  सत्र के बोर्ड पर दिखाई देता है। यही करने के लिए एजेंट `pin: true` पास कर सकता है।
- **बोर्ड दृश्य:** बोर्ड वाले सत्र को एक रूप टॉगल (चैट / डैशबोर्ड) मिलता है।
  बोर्ड दृश्य = टैब पट्टी (केवल जब >1 टैब हों) + प्रवाही ग्रिड + डॉक किया हुआ चैट पेन।
  चैट डॉक का आकार बदला जा सकता है, उसे स्थानांतरित किया जा सकता है (बाएँ/दाएँ/नीचे), और उसे ठीक
  साइडबार की तरह संक्षिप्त किया जा सकता है। प्रत्येक टैब की डॉक स्थिति याद रखी जाती है।
- **ड्रैग:** उपयोगकर्ता विजेट खींचता है; ग्रिड स्वतः संकुचित होता है (विजेट ऊपर
  तैरते हैं, पास वाले पुनः प्रवाहित होते हैं)। हैंडल से आकार बदलना आकार-चरणों पर स्नैप होता है। किसी के
  लिए भी पिक्सेल प्लेसमेंट नहीं।
- **रीसेट चेतावनी:** बोर्ड वाले सत्र पर `/new` / `/reset`
  वेब UI में पुष्टि माँगता है ("कॉन्टेक्स्ट रीसेट होता है, डैशबोर्ड बना रहता है") और
  बोर्ड को बनाए रखता है।
- **साइडबार:** पिन किए गए सत्रों में बोर्ड होने पर उनका बोर्ड रूप रेंडर होता है।
  Home सत्र का बोर्ड डिफ़ॉल्ट "एजेंट डैशबोर्ड" है।
- **इंटरैक्शन** (तीन स्तर, नीचे देखें): मौन स्थिति इवेंट, दृश्यमान
  प्रॉम्प्ट प्रेषण और ऑटोमेशन ट्रिगर।

## इंटरैक्शन स्तर

1. **स्थिति इवेंट (डिफ़ॉल्ट)।** विजेट UI इंटरैक्शन जिनके बारे में मॉडल को
   पता होना चाहिए, लेकिन प्रतिक्रिया नहीं देनी चाहिए। `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` में कभी नहीं)।

- **इनलाइन (ट्रांसक्रिप्ट) विजेट** वर्तमान कैनवस-दस्तावेज़ पाइपलाइन बनाए रखते हैं:
  स्टेट डायरेक्टरी के अंतर्गत लिखे जाते हैं, Gateway द्वारा सर्व किए जाते हैं, स्कोप के अनुसार छाँटे जाते हैं, कोई
  अनुमोदन नहीं (वे संरचनात्मक रूप से क्षमतारहित हैं — प्रॉम्प्ट प्रेषण की उपयोगकर्ता पुष्टि करता है)।
- **बोर्ड विजेट** सत्र स्थिति हैं: बाइट्स स्वामी एजेंट के SQLite
  DB (`board_widgets`) में रहती हैं, और DB पढ़ने वाला एक कोर 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 घोषित और त्रुटि पर बंद होने वाले ढंग से डीकोड किया गया), न कि किसी दूसरे
  विशेष रूप से निर्मित 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) होते हैं और बदली हुई बाइट्स अनुदान केवल तभी बनाए रखती हैं, जब
  घोषणा छोटी हुई हो।
- **लेखन शिम।** दस्तावेज़ रैपर स्थिर लेखक API के रूप में
  `window.openclaw.prompt`, `window.openclaw.state`, `window.openclaw.data` और `window.openclaw.cron`
  इंजेक्ट करता है। डैशबोर्ड कॉल एक दृश्य-टिकट-बद्ध अनुरोध चैनल साझा करते हैं;
  आकार रिपोर्टिंग और थीम टोकन अलग होस्ट सूचनाएँ बने रहते हैं।

### Plugin क्षमता घोषणाएँ

सक्षम plugins विजेट होस्ट को `dashboard.dataBindings`
और `dashboard.actionVerbs` के माध्यम से `openclaw.plugin.json` में विस्तारित कर सकते हैं। Plugin-स्थानीय आईडी
Plugin आईडी से उपसर्गित अनुदान नाम बन जाते हैं, जैसे `workboard.cards.list` और
`workboard.dispatch`; Plugin-आईडी खंड में `%` और `.` को एस्केप किया जाता है, ताकि
अलग Plugin/स्थानीय-आईडी विभाजन वही स्थायी अनुदान प्राप्त न कर सके। Plugin
पंजीकरण के दौरान OpenClaw सत्यापित करता है कि प्रत्येक बाइंडिंग उसी Plugin द्वारा
`operator.read` के साथ पंजीकृत RPC को लक्षित करती है और प्रत्येक क्रिया
`operator.write` वाले RPC को लक्षित करती है; अमान्य घोषणाएँ Plugin लोड को विफल कर देती हैं। सत्यापित
रजिस्ट्री केवल Plugin जीवनचक्र परिवर्तनों के साथ पुनर्निर्मित होती है, जबकि विजेट अनुदान
प्रत्येक विजेट के अनुसार और बाइट-तथा-संशोधन-बद्ध रहते हैं।

### मॉडल किया हुआ अवशिष्ट: WebRTC डेटा चैनल

सैंडबॉक्स CSP प्रस्तावित `webrtc 'block'` निर्देश उत्सर्जित करता है, लेकिन
[Chromium का वर्तमान CSP निर्देश समुच्चय](https://chromium.googlesource.com/chromium/src/+/main/services/network/public/mojom/content_security_policy.mojom#95)
इसे लागू नहीं करता। इसलिए स्क्रिप्ट-योग्य विजेट वर्तमान Chromium में बहिर्गमन के लिए
WebRTC डेटा चैनल का उपयोग कर सकते हैं। यही अवशिष्ट `main` पर इनलाइन
चैट विजेट और MCP Apps होस्ट के लिए पहले से जारी है।

**स्वीकृत समझौता:** OpenClaw इस
अवशिष्ट आधार पर स्क्रिप्ट-योग्य विजेट को प्रतिबंधित नहीं करता। विजेट सामग्री को संवेदनशील OpenClaw डेटा तक पहुँच केवल
ऑपरेटर द्वारा प्रदान की गई, बाइट-फ़्रीज़ की गई `data:read` क्षमता के माध्यम से मिलती है, और सैंडबॉक्स
Permissions Policy कैमरा और माइक्रोफ़ोन पहुँच को अवरुद्ध करती है। DOM API गार्ड
सर्वोत्तम-प्रयास वाली बहुस्तरीय सुरक्षा है, कोई सुरक्षा सीमा नहीं, और इसे
अनुवर्ती सुदृढ़ीकरण में शामिल किया जाना चाहिए।

### ट्रांसक्रिप्ट प्रदर्शन: एक विजेट कार्ड

इनलाइन प्रदर्शन विजेट प्रिमिटिव पर एकीकृत होता है। जब किसी टूल परिणाम में UI हो —
`show_widget` आउटपुट या ऐप संसाधन वाला MCP टूल परिणाम — तो सिस्टम
एक **अल्पकालिक, स्वतः-नामित विजेट** (सत्र-सीमित, छँटाई-योग्य) साकार करता है और
ट्रांसक्रिप्ट एकल विजेट कार्ड रेंडर करता है, जो सामग्री के प्रकार के अनुसार प्रेषण करता है।
MCP ऐप का स्वतः-प्रदर्शन ठीक वैसा ही रहता है जैसा विनिर्देश अपेक्षा करता है (मॉडल का कोई अतिरिक्त कार्य नहीं);
अंतर्निहित रूप से वह बस एक विजेट _ही है_। इससे चैट रेंडरिंग में समानांतर `mcpApp`
विशेष-मामले (सतह प्रतिबंध, अलग डीडुप्लिकेशन) हट जाते हैं, प्रत्येक
इनलाइन UI को समान पिन सुविधा मिलती है, और विजेट रजिस्ट्री प्राथमिक
पुनः-खोलने का मार्ग बनती है (कभी पिन न किए गए इतिहास के लिए ट्रांसक्रिप्ट-स्कैन पुनर्निर्माण फ़ॉलबैक बना रहता है)।
केवल-पढ़ने योग्य टिकट-आधारित स्वतंत्र होस्ट, स्थायी पुनः-खोलने की
सतह के रूप में बोर्ड से आच्छादित होता है — T6 में मूल्यांकन करने योग्य समेकन उम्मीदवार,
पूर्वधारणा नहीं।

संयोजन: v1 ग्रिड सन्निकटता है (एक टैब पर ऐप विजेट के पास एजेंट क्रोम विजेट)।
v2 में **होस्ट-प्रबंधित ऐप स्लॉट** जुड़ते हैं — एजेंट विजेट HTML एक
स्लॉट क्षेत्र घोषित करता है और होस्ट वास्तविक ऐप दृश्य को सहोदर सैंडबॉक्स के रूप में संयोजित करता है।
ऐप कभी भी एजेंट के iframe के भीतर रेंडर नहीं होता: नेस्टिंग से ब्रिज
पहचान टूटेगी और प्रदान किए गए ऐप UI की ओवरले/क्लिकजैकिंग संभव होगी, इसलिए स्लॉट
एक लेआउट अनुबंध है, एम्बेड नहीं।

### सर्वर-स्रोतित विजेट (पिन किए गए MCP ऐप)

एकीकृत होस्ट के साथ, किसी तृतीय-पक्ष MCP ऐप को पिन करना बस ऐसा विजेट है जिसकी
सामग्री संग्रहीत होने के बजाय सर्वर से प्राप्त की जाती है: `board_widgets`, HTML बाइट के बजाय
डिस्क्रिप्टर (`serverName`, `toolName`, `uiResourceUri`, मूल
`toolCallId` + `sessionKey`) रखता है, और बोर्ड चैट-टर्न की 10-मिनट TTL के बाद
व्यू लीज़ को फिर से मिंट करता है (पुराना होने पर `ui://` संसाधन पुनः प्राप्त करता है)।
चैट के इनलाइन MCP ऐप दृश्यों को एजेंट विजेट जैसी ही **डैशबोर्ड पर पिन करें**
सुविधा मिलती है। डिज़ाइन के अनुसार पुनः खोले गए दृश्य आज केवल-पढ़ने योग्य हैं;
जिन पिन किए गए ऐप को इंटरैक्टिव रहना चाहिए, उन्हें सर्वर के ऐप-दृश्य टूल पर स्थायी अनुदान मिलता है
(पिन करते समय ऑपरेटर को स्पष्ट अनुमति-सूची दिखाई जाती है), जो
मिंटिंग रन से पृथक है। अनुदान-रहित पिन केवल-पढ़ने योग्य रहते हैं — फिर भी प्रदर्शन
डैशबोर्ड के लिए उपयोगी। v1 मूल सत्र के बोर्ड पर पिन करता है; क्रॉस-सत्र पिनिंग के लिए
लीज़ ब्रोकर आवश्यक है और वह प्रतीक्षा करेगा। खुले PR #109807 (`ui/message`
कंपोज़र रूटिंग, थीम/आकार प्रसार) के साथ समन्वय करें।

### WorkBoard एकीकरण

WorkBoard एकीकरण कार्यक्रम कार्ड और बोर्ड को Plugin-स्वामित्व में रखता है, साथ ही प्रेषित कार्डों को मौजूदा `sessionKey` और `runId` के माध्यम से उनके सत्र बोर्ड से जोड़ता है, Plugin द्वारा घोषित बाइंडिंग और कार्रवाइयों के माध्यम से WorkBoard फ़ीड और प्रेषण उपलब्ध कराता है, और 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>` वैकल्पिक क्रम निर्धारण एंकर; छोड़ा गया = अंत में जोड़ें
- उपयोगकर्ता स्वतंत्र रूप से ड्रैग/आकार बदलता है; वही क्रम+आकार मॉडल राउंड-ट्रिप करता है।

## डेटा मॉडल (प्रति-एजेंट DB)

`agents/<agentId>/agent/openclaw-agent.sqlite` में नई तालिकाएँ
(**एजेंट-DB स्कीमा-संस्करण बढ़ाना आवश्यक है — इसे लागू करने से पहले ऑपरेटर की स्वीकृति
आवश्यक है**):

```sql
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 (कोर विधि तालिका, `gateway-protocol` में typebox स्कीमा):

- `board.get { sessionKey }` → टैब + विजेट मेटाडेटा (कोई बाइट नहीं) — `operator.read`
- `board.update { sessionKey, ops[] }` — टैब CRUD/पुनःक्रमण, विजेट स्थानांतरण/आकार बदलना/
  हटाना/अनपिन करना, डॉक स्थिति, फ़ोकस-टैब — `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? }` — Gateway-पक्षीय अनुमति-सूचीबद्ध
  कोर या सक्रिय-Plugin रीड बाइंडिंग समाधान — `operator.read`
- `board.action { ticket, action, ... }` — मौजूदा cron तत्काल-रन मार्ग
  या किसी सक्रिय Plugin की सत्यापित क्रिया क्रिया-पद के माध्यम से सटीक-अनुदान ऑटोमेशन प्रेषण
  — `operator.write`

इवेंट (`EVENT_SCOPE_GUARDS` में, पठन दायरा):

- `board.changed { sessionKey, revision, widget? }` — स्थायी स्थिति बदली;
  UI पुनः प्राप्त करता है (और `widget` मौजूद होने पर एक iframe पुनः लोड करता है)।
- `board.command { sessionKey, command }` — क्षणिक UI संचालन (एजेंट
  दृश्य टैब बदलता है, चैट डॉक टॉगल करता है) — `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` से कोर में जाती है।** कैनवास दस्तावेज़
  स्टोर, दस्तावेज़ रैपर, HTTP सेवा और `show_widget` टूल कोर बन जाते हैं
  (`src/canvas/`); Plugin नोड-कैनवास नियंत्रण टूल (`canvas`) और
  A2UI रखता है। `pluginSurfaceUrls["canvas"]` विज्ञापन और
  `/__openclaw__/canvas` मार्ग जारी किए गए मूल-क्लाइंट अनुबंध हैं और
  स्थिर रहते हैं। Discord सत्र Discord-स्वामित्व वाला `show_widget` संस्करण रखते हैं।

## गैर-लक्ष्य (यह कार्यक्रम)

- बहु-उपयोगकर्ता बोर्ड साझाकरण/ACL (भविष्य; सत्र साझाकरण के माध्यम से आएगा)।
- मूल macOS/iOS बोर्ड रेंडरिंग (जहाँ भी वे
  Control UI एम्बेड करते हैं, वहाँ यह उन्हें मिलता है; इनलाइन-विजेट मार्ग अपरिवर्तित है)।
- अंतर्निहित डेटा विजेट (सत्र/उपयोग/cron कार्ड) — क्षमता ब्रिज और
  एजेंट-रचित विजेट v1 को कवर करते हैं; अंतर्निहित प्रकार रजिस्ट्री बाद में आ सकती है।

## कार्यान्वयन योजना

स्वतंत्र वर्कट्री, Codex द्वारा निर्मित, समीक्षा+क्रमिक लैंडिंग। लैंड-फिर-सुधार।

| #   | शाखा                               | दायरा                                                                                                                                                                              | निर्भरता                       |
| --- | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- |
| T1  | `claude/dashboard-remove-workspaces` | workspaces Plugin + UI + दस्तावेज़ + i18n कुंजियाँ हटाएँ; doctor सफ़ाई नियम                                                                                                              | —                                |
| T2  | `claude/dashboard-canvas-core`       | विजेट होस्टिंग + `show_widget` को कोर में पदोन्नत करें; कैनवास Plugin नोड टूल रखता है; व्यवहार में शून्य परिवर्तन                                                                                | —                                |
| T3  | `claude/dashboard-domain`            | एजेंट-DB तालिकाएँ (स्कीमा वृद्धि), `board.*` RPC + इवेंट, `dashboard` टूल, `show_widget` पिन/नाम/मैनिफ़ेस्ट तर्क, टियर-1 सूचनाएँ, रीसेट-बोर्ड-रखता-है                                  | T2                               |
| T4  | `claude/dashboard-ui`                | बोर्ड स्वरूप + टैब पट्टी + तरल स्वतः-संकुचित ग्रिड + चैट डॉक (बायाँ/दायाँ/नीचे/छिपा) + ट्रांसक्रिप्ट पिन सुविधा + साइडबार बोर्ड स्वरूप + रीसेट पुष्टि                           | T3 (डेव फ़िक्स्चर के माध्यम से पहले-मॉक) |
| T5  | `claude/dashboard-capabilities`      | अनुदान स्टोर/UI + बाइट फ़्रीज़िंग; `html` विजेट को साझा सैंडबॉक्स होस्ट पर ले जाएँ; होस्ट टूल (`openclaw.prompt.send/state.emit/data.read/cron.trigger`); `net` CSP; लेखन शिम | T3, T4                           |
| T7  | `claude/dashboard-mcp-apps`          | `mcp-app` सामग्री प्रकार: इनलाइन ऐप दृश्यों पर पिन सुविधा, डिस्क्रिप्टर भंडारण, लीज़ पुनः-मिंट/रीफ़्रेश, स्थायी सर्वर-टूल अनुदान (जारी MCP Apps होस्ट का पुनः उपयोग)                   | T3, T4                           |
| T6  | परिष्करण                               | अस्थायी Gateway पर लाइव E2E (वास्तविक कुंजियाँ), स्क्रीनशॉट, सुधार, उपयोगकर्ता-केंद्रित `/web/dashboard` पुनर्लेखन, डिफ़ॉल्ट-सक्षम समीक्षा                                                     | सभी                              |

रेपो नियमों के अनुसार सत्यापन: केंद्रित vitest स्थानीय रूप से, पूर्ण गेट
Crabbox/Testbox पर, प्रत्येक लैंडिंग से पहले `$autoreview`, T6 के लिए लाइव प्रमाण।