Gemini 3 Flash ट्यूटोरियल: फ़ंक्शन कॉलिंग के साथ UI Studio बनाएं

अधिकांश AI डैशबोर्ड बिल्डर डेमो एक जैसे चलते हैं: यूज़र एक प्रॉम्प्ट देता है, मॉडल UI कोड का एक बड़ा हिस्सा जनरेट करता है, और फिर यूज़र बाकी समय टूटी हुई लेआउट, गायब स्टेट्स, और आधे-अधूरे जुड़े कॉम्पोनेंट्स को ठीक करने में बिताता है।

यह ट्यूटोरियल एक अलग तरीका अपनाता है। हम UI Studio बनाएंगे—एक टूल-कॉलिंग डैशबोर्ड फ़ैक्टरी जहाँ Gemini 3 Flash 100 UI कॉम्पोनेंट्स को कॉल करने योग्य टूल्स की तरह समन्वित करता है। 

एक बड़ा React फ़ाइल लिखने के बजाय, Flash छोटे, संरचित चरणों का क्रम बनाता है—जैसे नेवबार बनाना, फ़िल्टर्स जोड़ना, डेटा को टेबल से बाँधना, इनसाइट चार्ट बनाना, और एकल UISpec JSON फ़ाइल एक्सपोर्ट करना। यह स्टेप-बाय-स्टेप प्रोसेस करता है, और हर स्टेप पूरा होते ही UI अपडेट होता है।

अंत तक, आपके पास एक स्टूडियो-सा ऐप होगा जो कई डैशबोर्ड टेम्पलेट्स (Customer Feedback Triage, Sales Pipeline, SRE Incident Command, Finance Spend Tracker, Product Analytics Funnel, आदि) जनरेट कर सकता है और दूसरे व्यू मोड, थीम वगैरह पर तेज़ी से इटरेट कर सकता है। 

नोट: यह डेमो एक आधार देता है; अपने विशेष लक्ष्यों और आउटपुट प्राथमिकताओं के अनुरूप प्रॉम्प्ट्स को निखारने के लिए स्वतंत्र महसूस करें।

यदि आप Google इकोसिस्टम का उपयोग करके AI एजेंट्स बनाना सीखना चाहते हैं, तो मैं इस कोर्स को देखने की सलाह देता हूँ, Building AI Agents with Google ADK। मैं हमारा Gemini 3.8 Flash गाइड भी सुझाता हूँ।

Gemini 3 Flash क्या है?

Google का Gemini 3 Flash मॉडल स्पीड-फ़र्स्ट, एजेंटिक वर्कफ़्लोज़ के लिए बना है जहाँ आपको एक परफेक्ट जवाब नहीं, बल्कि बिल्ड–इंस्पेक्ट–ट्वीक–रिबिल्ड जैसा तगड़ा इटरेशन लूप चाहिए। Flash Gemini 3 Pro जैसी रीजनिंग को Flash-स्तरीय लेटेंसी, एफिशिएंसी, और लागत के साथ मिमिक करता है, जिससे यह हाई-फ़्रीक्वेंसी इंटरैक्टिव ऐप्स के लिए बढ़िया फ़िट बनता है। 

स्रोत: Gemini 3 Flash DeepMind 

UI Studio जैसे बिल्डर ऐप्स के लिए Flash को प्रासंगिक बनाने वाली दो बातें हैं:

• यह एक बड़े, समग्र रेस्पॉन्स देने के बजाय, अनेक संरचित चरणों को विश्वसनीय रूप से निष्पादित करने के लिए डिज़ाइन किया गया है।
• यह स्ट्रक्चर्ड आउटपुट्स, फ़ंक्शन कॉलिंग, कोड एक्ज़ीक्यूशन, और सर्च-एज़-ए-टूल का भी समर्थन करता है, जिससे हम पूरी पाइपलाइन को डिटerministic और इंस्पेक्टेबल रख सकते हैं।

सिद्धांततः, Gemini 3 Flash (प्रीव्यू) 1M इनपुट टोकन्स और 64K आउटपुट टोकन्स सपोर्ट करता है, जो तब उपयोगी होते हैं जब बिल्ड ट्रेस और UISpec बड़े हो जाते हैं। 

Gemini 3 Flash आर्किटेक्चर 

Gemini 3 Flash, Gemini 3 परिवार का एजेंटिक वर्कफ़्लो मॉडल है, जिसे लो-लेटेंसी, हाई-थ्रूपुट ऐप्लिकेशन्स के लिए ट्यून किया गया है जहाँ आपको तेज़ इटरेशन्स, टूल प्रयोग, और मल्टी-स्टेप प्लान चाहिए। इस मॉडल की कुछ मुख्य विशेषताएँ:

• रीजनिंग लेवल्स (thinking_level): Gemini 3 Flash एक thinking_level सेटिंग (minimal, low, medium, high) एक्सपोज़ करता है, जिसे हम लेटेंसी/कॉस्ट बनाम गहराई के लिए ट्रेड-ऑफ कर सकते हैं। यह सेटिंग UI बिल्ड्स के लिए परफ़ेक्ट है जहाँ अधिकांश चरण नियमित होते हैं, पर कुछ को गहरी प्लानिंग चाहिए।
• टूल उपयोग: Gemini 3 का टूल उपयोग मल्टी-स्टेप लूप्स के लिए डिज़ाइन किया गया है, जहाँ मॉडल टूल कॉल्स एमिट करता है, हम उन्हें एक्ज़ीक्यूट करते हैं, नतीजे वापस देते हैं, और यह टर्न पूरा होने तक जारी रहता है। यही वह चीज़ है जो हमें स्टूडियो UI के लिए चाहिए, जो बिल्ड के साथ रियल-टाइम में अपडेट होता रहे।
• थॉट सिग्नेचर्स: Gemini 3 एन्क्रिप्टेड थॉट सिग्नेचर्स का उपयोग करता है ताकि टर्न्स के बीच रीजनिंग कॉन्टेक्स्ट संरक्षित रहे। टूल लूप को उन्हें बिल्कुल वैसा ही वापस पास करना चाहिए, वरना फ़ंक्शन कॉलिंग फेल हो सकती है (4xx/400 वेलिडेशन एरर), भले ही thinking_level="minimal" हो।
• मल्टीमोडैलिटी: Gemini 3 Flash टेक्स्ट, कोड, इमेज, ऑडियो, वीडियो, और PDF इनपुट स्वीकार करता है। Vertex AI पर, हम media_resolution ट्यून कर सकते हैं ताकि मल्टीमॉडल कॉस्ट बनाम लेटेंसी का संतुलन बने, और ज़रूरत होने पर मल्टीमॉडल टूल आउटपुट भी लौटाए जा सकते हैं ताकि नियंत्रण और कसा रहे।

Gemini 3 Flash उदाहरण: UI Studio डैशबोर्ड बनाएं

इस सेक्शन में, हम Gemini 3 Flash का इस्तेमाल कर एक सिंगल प्रॉम्प्ट से UI Studio बनाएंगे। ऐप टूल कॉल्स के जरिए UIs असेंबल करता है और एक एक्सपोर्ट करने योग्य UISpec JSON आउटपुट करता है।

ऊपरी स्तर पर, अंतिम ऐप यह करेगा:

• एक टेम्पलेट कैटलॉग दिखाएगा, जैसे Customer Feedback Triage, Product Analytics Funnel, Sales Pipeline, आदि।
• यूज़र को Start Build क्लिक करने देगा ताकि टूल-कॉलिंग बिल्ड लूप ट्रिगर हो, जहाँ Flash डैशबोर्ड को स्टेप-बाय-स्टेप कंपोज़ करता है।
• जेनरेट किया गया डैशबोर्ड प्रिव्यू मोड में रेंडर करेगा, साथ में एक UISpec इंस्पेक्टर और एक एक्ज़ीक्यूशन ट्रेस होगा।
• अंतिम डैशबोर्ड स्पेक को JSON के रूप में एक्सपोर्ट करेगा।
• सरल प्रॉम्प्ट्स के साथ तेज़ इटरेशन का समर्थन करेगा, जैसे कॉम्पैक्ट डेंसिटी, डार्क मोड, डिफ़ॉल्ट सॉर्ट बाय SLA रिस्क, या कानबन पर स्विच।

प्रॉम्प्ट अवलोकन

इस सेक्शन में, हम Google AI Studio में Gemini 3 Flash के साथ UI Studio बनाने के लिए इस्तेमाल प्रॉम्प्ट को देखेंगे। एक ही बार में डैशबोर्ड जनरेट करने की बजाय, Flash स्टूडियो का ब्रेन बनकर चलता है। यह टूल कॉल्स का समन्वय करता है, आउटपुट्स को वैलिडेट और रिपेयर करता है, और एकल रेंडरेबल आर्टिफैक्ट बनाता है। 

यह वह प्रॉम्प्ट है जो मैंने इस डेमो के लिए इस्तेमाल किया:

SYSTEM / DEVELOPER PROMPT — Gemini 3 Flash (UI STUDIO ORCHESTRATOR)
You are UI_STUDIO_ORCHESTRATOR inside an app called “UI Studio”.
Goal: Build a reusable “dashboard builder studio” that can generate many different dashboards (Sales, Support, Ops, Finance, Product Analytics, etc.) by orchestrating 80–150 callable UI component tools (agents). 
Each UI component (navbar, cards, table, filters, auth, charts, drawers, modals, etc.) is represented as a tool/function that returns structured JSON. 
You must reliably sequence many tool calls and output a valid UISpec JSON that renders the Studio UI and the generated dashboards.
HIGH-LEVEL BEHAVIOR
UI Studio itself is a dashboard-like app (the “builder”), not just a single dashboard.
Users can select a dashboard type/template to build (e.g., “Customer Feedback Triage”, “Sales Pipeline”, “SRE Incident”, “Finance Spend”, “Product Analytics”).
The Studio exposes a catalog of components (count ~100) and a tool registry (count 80–150), plus specialized agents for different template families.
Gemini 3 Flash must:
Render the UI Studio builder UI
Provide template selection and “Start Build” for a chosen dashboard
Use different specialist agents for different dashboard templates
Assemble the requested dashboard via many component tool calls
Iterate rapidly based on feedback (A/B knobs)
ABSOLUTE RULES
TOOL-FIRST: Build everything via tools. Do not “describe” UIs in prose.
MANY CALLS: On first build, make 30–80 tool calls. This is expected.
STRUCTURED OUTPUT ONLY: Final response must be ONE valid JSON object (UISpec). No markdown or commentary.
VALIDATE + REPAIR: Always run validate_uispec and repair until ok=true.
CONSTRAINTS: Only call enabled tools and only instantiate allowed components (if lists are provided).
ITERATION: Patch minimal deltas using update tools; preserve stable IDs.
INPUTS YOU RECEIVE (RunContext)
The user (or the app) provides a JSON RunContext each run:
{
"studioGoal": string,
"selectedTemplate": string | null,
"requestPrompt": string,
"knobs": { ... },
"allowedComponents": string[],
"enabledTools": string[],
"availableTemplates": string[] | null,
"agents": [{ "name": string, "role": string, "specialty": string }]
}
Use this as the constraints. If missing, assume reasonable defaults and proceed.
TOOLS AVAILABLE (CONCEPTUAL)
You can call tools returning JSON. Only call tool names included in enabledTools.
set_agent_status(agentName, status, note) -> ok
emit_trace(eventName, payload) -> ok
list_templates() -> { templates: TemplateMeta[] }
choose_template(userIntent) -> { templateId, rationale }
define_data_model(domain, templateId, constraints) -> DataModel
compose_layout(layout_type, regions, responsive_rules) -> LayoutSpec
create_component(type, variant, region, intent, theme_tokens, data_contract, constraints) -> ComponentSpec
update_component(component_id, patch) -> ComponentSpec
bind_data(component_id, bindings) -> BindingSpec
define_workflow(name, steps, triggers) -> WorkflowSpec
validate_uispec(uispec) -> { ok: boolean, issues: Issue[] }
repair_uispec(uispec, issues) -> UISpec
create_ab_variant(base_uispec, knob_changes) -> { variants: [{name, uispec}], metricPlan }
save_template(templateId, uispec) -> ok
export_dashboard(uispec, format) -> { artifactRef }
UISPEC OUTPUT CONTRACT (STRICT)
Return ONE JSON object:
{
"app": { "name": "UI Studio", "description": string, "routes": [...] },
"theme": { "mode": "light"|"dark", "density": "compact"|"comfortable", "tokens": {...} },
"studio": {
"templateCatalog": TemplateMeta[],
"selectedTemplate": string|null,
"componentCatalog": { "count": number, "items": string[] },
"toolRegistry": { "count": number, "items": string[] },
"agents": [{ "name": string, "role": string, "specialty": string }]
},
"dataModel": DataModel,
"layout": LayoutSpec,
"components": ComponentSpec[],
"workflows": WorkflowSpec[],
"states": { "loading": {...}, "empty": {...}, "error": {...} },
"generatedDashboards": [
{ "templateId": string, "name": string, "uispecRef": string }
],
"abTests": [ ... ] // optional
}
UI STUDIO BUILDER UI (MUST INCLUDE)
The Studio UI must include:
A) Header + Hero Banner
Title “UI Studio”
Subtitle: “Build dashboards via function-calling components”
Buttons: “Start Build”, “Iterate”, “Export”
B) REQUESTS (cards like “Orders”)
Preset request cards (Easy/Intermediate/Difficult) for different dashboard types
“Add New Request” card
Each request card has Start + status
C) COMPONENTS panel (count ~100)
Searchable list of UI components (navbar, cards, table, filter, auth, charts, drawer, modal, etc.)
Allow/prefer/disable toggles (optional)
Shows count
D) TOOLS panel (count 80–150)
Searchable list of callable tools/functions
Shows call counters for the current run and “recently called”
Shows count
E) AGENTS panel
3–8 specialist agent cards (all powered by Flash, but role-separated):
Template Selector Agent (chooses dashboard template from user intent)
IA/UX Planner Agent (information architecture)
Data Modeler Agent (schemas + bindings)
Component Composer Agent (creates component specs)
Chart Builder Agent (insights widgets)
QA/A11y Gatekeeper Agent (validation + fixes)
Experimentation Agent (A/B variants + knobs)
Agent cards show status: Idle / Working / Waiting / Done
F) Preview Drawer
Tabs: Preview | UISpec JSON | Trace
Preview renders either the Studio or the generated dashboard spec
TEMPLATE SYSTEM (MUST INCLUDE)
Provide at least 8 templates in templateCatalog with metadata:
id, name, category, difficulty, primaryComponents, dataEntities, defaultKnobs
Examples:
customer_feedback_triage
sales_pipeline
support_ticket_ops
sre_incident_command
finance_spend_tracker
product_analytics_funnel
marketing_campaign_performance
inventory_warehouse_ops
Selecting a template should:
set selectedTemplate
populate default knobs
drive which specialist agents become active
drive which components/tools are preferred during build
A/B KNOBS (FIRST-CLASS)
Studio must support knob-driven iterations:
density: compact|comfortable
navigation: topbarOnly|leftRail
defaultSort: template-specific enum
viewMode: table|inboxList|kanban|gridCards
insightFocus: overviewFirst|triageFirst|trendsFirst
themeMode: light|dark
BUILD ALGORITHM
When user requests “create UI studio …” (this message), you must:
emit_trace("start_studio_build", {...})
set_agent_status(...) as you plan/build/validate
Create the UI Studio builder UI (sections A–F above) via MANY create_component calls
Define templateCatalog and agent roster
Implement template selection workflow:
choose_template from user intent
build_dashboard workflow that triggers component creation for the chosen template
Implement “Start Build” workflow:
picks template
defines dataModel
composes layout
creates components for the generated dashboard
validates + repairs
stores in generatedDashboards with uispecRef
validate_uispec and repair until ok
Output ONLY the UISpec JSON
ITERATION BEHAVIOR
If user later asks: “build a Sales dashboard” or “change to dark mode, compact density”:
update Studio state (selectedTemplate/knobs)
call update_component and rebuild only the generated dashboard region
re-validate and output updated UISpec JSON only
NOW EXECUTE
User intent: Create a UI Studio that can build numerous dashboards, with 100 UI components as callable tools/agents, dashboard selection, and specialist agents for different templates.
Start building immediately via tools, then output a single valid UISpec JSON.

प्रॉम्प्ट का लक्ष्य एक प्रेडिक्टेबल बिल्ड लूप लागू करना है ताकि Gemini 3 Flash बिल्डर की तरह बर्ताव करे, चैटबॉट की तरह नहीं। इसके लिए, प्रॉम्प्ट में शामिल होना चाहिए:

• पहले बिल्ड पर टूल उपयोग के लिए स्पष्ट टार्गेट, सामान्यतः 30 से 80 टूल कॉल्स, ताकि Flash एक बड़ा आउटपुट बनाने के बजाय UI को कई छोटे कॉम्पोनेंट-बिल्डिंग चरणों में तोड़ दे।
• आवश्यक वैलिडेट-फिर-रिपेयर लूप जब तक स्पेक पास न हो जाए, ताकि अंतिम UISpec रेंडरेबल रहे और टूटे हुए स्टेट्स से बचे।
• इटरेशन के दौरान पैच-स्टाइल अपडेट्स ताकि कॉम्पोनेंट IDs संरक्षित रहें और फ़ुल रिबिल्ड से बचा जा सके। यह UI को एडिट्स के बीच स्थिर रखता है और इटरेशन्स को तेज़ बनाता है।
• एक हाई-लेवल UISpec कॉन्ट्रैक्ट जिसमें थीम, लेआउट, कॉम्पोनेंट्स, बाइंडिंग्स, वर्कफ़्लोज़, स्टेट्स, टेम्पलेट कैटलॉग, एजेंट्स, और ट्रेस शामिल हों। यह Flash को एक सख्त टार्गेट फ़ॉर्मैट देता है ताकि हर बिल्ड एक सुसंगत, संरचित आर्टिफैक्ट पैदा करे।
• एक टेम्पलेट कैटलॉग और विशेषज्ञ एजेंट रोल्स का आबंटन, ताकि हर डैशबोर्ड प्रकार डिफ़ॉल्ट्स—जैसे लेआउट, नॉब्स, और पसंदीदा कॉम्पोनेंट्स—से शुरू हो, और Flash योजना, निर्माण, और वैलिडेशन में काम बाँट सके।

यह इसलिए काम करता है क्योंकि मॉडल एकल स्ट्रक्चर्ड UISpec आउटपुट करता है जिसे आप वैलिडेट कर सकते हैं, छोटे पैचेस से ठीक कर सकते हैं, और पूरे UI को फिर से बनाए बिना तेज़ी से अपडेट कर सकते हैं।

प्रोजेक्ट अवलोकन

हालाँकि Gemini 3 Flash इस डेमो के लिए पूरा कोडबेस जनरेट करता है, फिर भी यह समझना उपयोगी है कि हर फ़ाइल की जिम्मेदारी क्या है। Studio UI, प्रिव्यू डैशबोर्ड, और Gemini API लेयर के बीच स्पष्ट विभाजन है। एक बार जब आप समझ लें कि दोनों AI लूप्स कहाँ चलते हैं, तो बाकी रेपॉज़िटरी को फॉलो करना आसान हो जाता है।

यहाँ UI Studio ऐप Gemini 3 Flash को कैसे ट्रिगर करता है और जेनरेट किया हुआ डैशबोर्ड कैसे रेंडर करता है—इसका हाई-लेवल फ़्लो है:

• ऐप लोड होने पर, App.tsx Studio व्यू खोलता है और mockData.ts से शुरुआती टेम्पलेट कैटलॉग, टूल रजिस्ट्र्री, कॉम्पोनेंट कैटलॉग, और एजेंट सूची खींचता है।
• इस चरण पर टेम्पलेट चयन पूरी तरह क्लाइंट-साइड स्टेट में हैंडल होता है, इसलिए अभी कोई Gemini रिक्वेस्ट ट्रिगर नहीं होता।
• जब आप Start Build क्लिक करते हैं, ऐप पिछले रन ट्रेस को क्लियर करता है, “बिल्डिंग” स्टेट में स्विच करता है, और प्रगति को दृश्य बनाने के लिए एजेंट कार्ड्स और ट्रेस इवेंट्स अपडेट करना शुरू करता है।
• स्टेज्ड UI अपडेट्स के बाद, ऐप मुख्य बिल्ड रिक्वेस्ट services/geminiService.ts के माध्यम से करता है।
• मॉडल का JSON रेस्पॉन्स UISpec में पार्स होता है, स्टेट में स्टोर होता है, और UI Preview मोड में स्विच हो जाता है।
• प्रिव्यू में, जेनरेट किया गया डैशबोर्ड मानक React कॉम्पोनेंट्स जैसे टेबल्स, फ़िल्टर्स, और इनसाइट्स का उपयोग करके रेंडर होता है।
• PreviewDrawer.tsx एक इंस्पेक्टर पैनल की तरह काम करता है, जहाँ आप UISpec JSON और बेसिक बिल्ड आँकड़े देख सकते हैं।
• एक दूसरा Gemini लूप DetailDrawer.tsx के अंदर रहता है और व्यक्तिगत रो स्तर पर चलता है।
• जब यूज़र कोई फ़ीडबैक आइटम खोलता है और AI मदद मांगता है, तो geminiService.ts में analyzeFeedback() और suggestResolution() Gemini को फिर कॉल करते हैं ताकि स्ट्रक्चर्ड क्लासीफिकेशन और सुझाए गए एक्शन्स पैदा किए जा सकें।
• कुल मिलाकर, ऐप दो पाइपलाइन्स चलाता है—एक डैशबोर्ड स्पेक बिल्डिंग के लिए और एक डैशबोर्ड के भीतर यूज़र्स की सहायता के लिए।

यदि आप डेमो की वायरिंग समझने के लिए अन्य प्रमुख प्रोजेक्ट फ़ाइलों में रुचि रखते हैं, तो यहाँ कुछ और विवरण हैं:

रूट डायरेक्टरी

ये फ़ाइलें प्रोजेक्ट सेटअप, टाइप कॉन्ट्रैक्ट्स, और सीड डेटा परिभाषित करती हैं जो डेमो को सुसंगत और रन करने योग्य रखती हैं।

• package.json: डिपेंडेंसीज़ और स्क्रिप्ट्स को परिभाषित करता है, जहाँ React, Recharts, और @google/genai SDK, साथ ही vite, build, और preview जैसे डेव स्क्रिप्ट्स दिखते हैं।
• tsconfig.json: यह React और बंडलर रेज़ॉल्यूशन के लिए TypeScript कंपाइलर सेटिंग्स रखता है। यह प्रोजेक्ट को टाइप-सेफ रखता है बिना डेवलपमेंट के दौरान संकलित TS एमिट किए।
• vite.config.ts: Vite dev और बिल्ड कॉन्फ़िग—पोर्ट सेटअप और एन्वायरनमेंट वायरिंग समेत। यह फ़ाइल GEMINI_API_KEY को process.env.API_KEY में मैप करती है, ताकि GenAI SDK ब्राउज़र बिल्ड में इसे पढ़ सके।
• metadata.json: ऐप मेटाडेटा AI Studio द्वारा होस्टिंग में उपयोग होता है। यह ऐप को नाम, विवरण, और आवश्यक परमिशन्स देता है।
• types.ts: यह पूरे ऐप के लिए कॉन्ट्रैक्ट लेयर की तरह कार्य करता है, जो टेम्पलेट्स, एजेंट्स, टूल्स, फ़ीडबैक रोज़, और UISpec आकार के लिए टाइप्स परिभाषित करता है ताकि UI और मॉडल आउटपुट्स सुसंगत रहें।
• mockData.ts: यह फ़ाइल Studio और प्रिव्यू अनुभव के लिए सीड डेटा रखती है। यह टेम्पलेट कैटलॉग, शुरुआती एजेंट रोस्टर, टूल रजिस्ट्र्री, और मॉक फ़ीडबैक रोज़ परिभाषित करती है ताकि UI किसी भी मॉडल कॉल से पहले भी काम करे।

Services(services/)

यह लेयर Gemini इंटीग्रेशन रखती है और यहीं सभी मॉडल कॉल्स और स्ट्रक्चर्ड रेस्पॉन्स हैंडल होते हैं।

• geminiService.ts: इसमें तीन कोर कॉल्स हैं: orchestrateBuild() फ़ंक्शन जो UISpec जनरेट करता है, और analyzeFeedback(), suggestResolution() फ़ंक्शन कॉल्स जो AI असिस्टेंस चलाते हैं।
• नोट: orchestrateBuild() वर्तमान में gemini-3-pro-preview को टार्गेट करता है, जबकि अन्य दो कॉल्स gemini-3-flash-preview का उपयोग करते हैं, तो यदि आप पूरा डेमो केवल Flash-आधारित बनाना चाहते हैं, तो इसे स्वैप करेंगे।

Studio UI कॉम्पोनेंट्स(components/)

ये React कॉम्पोनेंट्स Studio बिल्डर UI और जेनरेट किए गए डैशबोर्ड प्रिव्यू को रेंडर करते हैं, जिसमें JSON इंस्पेक्टर और डिटेल फ़्लोज़ शामिल हैं।

• StudioHeader.tsx: यह Studio हेडर और बिल्ड शुरू करने वाला CTA रेंडर करने में मदद करता है। यह बिल्ड स्टेट प्रतिबिंबित करता है ताकि यूज़र देख सके कि पाइपलाइन कब चल रही है।
• TemplateCatalog.tsx: यह टेम्पलेट कार्ड्स दिखाता है और यूज़र को चुनने देता है कि वह कौन-सा डैशबोर्ड बनाना चाहता है। चयन App.tsx में लोकल स्टेट अपडेट करता है।
• AgentPanel.tsx: एजेंट पैनल “स्पेशलिस्ट एजेंट्स” को स्टेटस कार्ड्स के रूप में दिखाता है। इस डेमो में, स्टेटस प्रोग्रेशन App.tsx में स्टेज्ड अपडेट्स से संचालित है ताकि वर्कफ़्लो दृश्य हो।
• ToolPanel.tsx: टूल पैनल mockData.ts से टूल रजिस्ट्र्री सूची को रेंडर करने में मदद करता है। यह टूल उपलब्धता और कॉल काउंटर्स दिखाने के लिए UI प्लेसहोल्डर है।
• ComponentPanel.tsx: यह “कंपोनेंट्स ऐज़ टूल्स” का UI प्रतिनिधित्व है, और आगे चलकर यहीं अलाउ/डिनाय टॉगल्स जोड़ना स्वाभाविक है।
• PreviewDrawer.tsx: यह आपको UISpec JSON और बेसिक आँकड़े देखने देता है, जिससे बिल्ड ट्रेस डिबग करने योग्य बनता है।

• Topbar.tsx: यह फ़ाइल डैशबोर्ड टॉप नेविगेशन और सर्च बार रखती है। यह दिखाती है कि डैशबोर्ड-स्तरीय कंट्रोल्स स्टूडियो-स्तरीय नॉब्स के साथ कैसे सह-अस्तित्व रख सकते हैं।
• Sidebar.tsx: यह रेंडर किए गए डैशबोर्ड के लिए लेफ्ट रेल नेविगेशन हैंडल करता है।
• FilterBar.tsx: यह एक फ़िल्टर स्ट्रिप की तरह काम करता है जिसका उपयोग फ़ीडबैक डेटा को स्लाइस करने के लिए होता है। 
• FeedbackTable.tsx: यह फ़ीडबैक आइटम्स के लिए मुख्य टेबल व्यू है, जहाँ किसी रो पर क्लिक करने से चयन ट्रिगर होता है और डिटेल ड्रॉअर अनुभव खुलता है।
• DetailDrawer.tsx: यह analyzeFeedback() और suggestResolution() को कॉल करता है और AI टैब के तहत मॉडल आउटपुट रेंडर करता है।
• InsightsSection.tsx: यह फ़ाइल Recharts का उपयोग करके चार्ट्स और समरी इनसाइट्स व्यू रेंडर करने में मदद करती है।

यहाँ एक छोटा डेमो वीडियो है जो पूरे UI Studio वर्कफ़्लो से गुज़रता है—टेम्पलेट चयन, Start Build फ़्लो, और जेनरेटेड डैशबोर्ड प्रिव्यू सहित: