Workcell एक मल्टी-एजेंट ऑपरेशन्स प्लेटफ़ॉर्म है जो विकास परियोजनाओं को चलाने में विशेषज्ञ है: एक मानव बोर्ड दिशा तय करता है, और AI टीम — Orchestrator, Developer, Designer, QA — इसे प्रमाण के साथ पूरा करती है।
English · 한국어 · 日本語 · 简体中文 · 繁體中文 · Español · Français · Deutsch · Português (BR) · Русский · हिन्दी · العربية · Bahasa Indonesia · Italiano
आप बोर्ड बने रहते हैं: आपके पास दिशा, अनुमोदन और नीति का स्वामित्व है। एजेंट कार्यात्मक भूमिकाएँ निभाते हैं, इश्यू उठाते हैं, और काम के परिणामों के साथ-साथ प्रमाण भी छोड़ते हैं कि काम वास्तव में पूरा हुआ। कंट्रोल प्लेन संगठन चलाता है — परियोजनाएँ, इश्यू, बजट, गवर्नेंस, और एक अपरिवर्तनीय ऑडिट ट्रेल — जबकि आप अपना समय उन निर्णयों पर लगाते हैं जो वास्तव में महत्वपूर्ण हैं।
कंपनी की तरह संचालन करें · इश्यू की तरह क्रियान्वयन करें · डिज़ाइन को सत्य का स्रोत बनाएं · मनुष्यों को निर्णय लेने दें।
Workcell इस बारे में सुस्पष्ट दृष्टिकोण रखता है कि एक विकास परियोजना को कैसे चलना चाहिए। चार प्रतिबद्धताएँ पूरे उत्पाद को आकार देती हैं:
यहाँ कोई "शून्य-मानव कंपनी" नहीं है। मनुष्य के पास दिशा, अनुमोदन और नीति का स्वामित्व है; एजेंटों के पास क्रियान्वयन है। हर महत्वपूर्ण गेट — डिज़ाइन अनुमोदन, प्रमाण समीक्षा, बजट, नियुक्ति — एक मानवीय निर्णय पर समाप्त होता है, जो एक अपरिवर्तनीय ऑडिट लॉग में दर्ज होता है।
Workcell में डिफ़ॉल्ट रूप से चार सीटें हैं — Orchestrator, Designer, Developer, QA। यह एक जानबूझकर की गई दार्शनिक सोच है, कोई टेम्पलेट नहीं: ये चार सबसे छोटी टीम हैं जो एक विचार को इरादे से सिद्ध तक ले जा सकती है — डिज़ाइन-फर्स्ट, हर गेट के लिए एक स्पष्ट स्वामी के साथ।
| सीट | भूमिका | स्वामित्व |
|---|---|---|
| Orchestrator | रूटिंग और समन्वय | प्राकृतिक भाषा को संरचित इश्यू में बदलता है, काम को सही भूमिका तक रूट करता है, और अटके हुए रन्स को देखता है |
| Designer | designer |
डिज़ाइन सिस्टम — रेंडर किया गया मॉकअप/ड्राफ्ट प्रस्तावित करता है, अनुमोदित स्रोत-सत्य डिज़ाइन बनाए रखता है (डिज़ाइन पहले आता है) |
| Developer | engineer |
कार्यान्वयन, डीबगिंग, परीक्षण — अनुमोदित डिज़ाइन के विरुद्ध बनाता है, उससे आगे कभी नहीं |
| QA | qa |
Done का फैसला — पुनरुत्पादन, सत्यापन और प्रमाण पर हस्ताक्षर |
ऑनबोर्डिंग Orchestrator को सीड करती है; Agents पेज लापते सीटों को एक-क्लिक भर्ती के रूप में दिखाता है। Orchestrator का चार्टर कोड को इंजीनियरों, UX को डिज़ाइनरों, और सत्यापन को QA को रूट करता है — इसलिए टीम का आकार केवल दस्तावेज़ीकरण नहीं है, यह काम कैसे बहता है इसका तरीका है।
चार सीटें एक ढाँचा हैं, सीमा नहीं — उन पर स्वतंत्र रूप से विस्तार करें। काम की माँग के अनुसार अतिरिक्त कार्यात्मक भूमिकाएँ भर्ती करें — Lead, PM, Researcher, Writer, Security, DevOps, या एक सामान्य-उद्देश्य एजेंट — और किसी भी एजेंट को Capability Registry से स्कोप किए गए स्किल्स, प्लगइन्स, MCP सर्वर, और डिज़ाइन सिस्टम से लैस करें। एक इश्यू के स्वामी को एकल एजेंट के रूप में चलाएं या — प्रयोगात्मक, ऑप्ट-इन — dual-brain (दो मॉडल समानांतर में उत्पन्न करते हैं, फिर एक सिंथेसाइज़र उन्हें मर्ज करता है) के रूप में। डिफ़ॉल्ट एक नई परियोजना को दिन एक से सुसंगत रखता है; फिर संगठन परियोजना के अनुसार बढ़ता है — न कि उल्टे।
हर परियोजना में एक App Blueprint होता है: पूरे ऐप की स्क्रीनों का एक फ्लो-फर्स्ट, Figma-स्टाइल दृश्य, ताकि योजना और डिज़ाइन एक ही स्थान पर रहें।
- स्क्रीन + योजना, एक जोड़ी के रूप में। प्रत्येक स्क्रीन एक शुद्ध रेंडर किया गया मॉकअप है जो अपनी स्क्रीन योजना से जुड़ी है — उद्देश्य, अवस्थाओं, इंटरैक्शन और डेटा के लिए विनिर्देश। मॉकअप दिखाता है क्या एक स्क्रीन है; योजना इसे वर्णित करती है। वे एक साथ लिखे और स्थानांतरित होते हैं (एक स्क्रीन = एक मॉकअप + एक योजना)।
- फ्लो-फर्स्ट। ब्लूप्रिंट फ्लो पर खुलता है: स्क्रीन नोड्स लेबल किए गए नेविगेशन तीरों द्वारा जुड़े हुए हैं, ताकि पूरे ऐप की संरचना एक नज़र में पढ़ी जा सके। नोड्स ड्रैग-पुनर्स्थापन योग्य हैं और स्थिति बनाए रखते हैं, कैनवास कर्सर पर ज़ूम करता है, और एक स्क्रीन पर क्लिक करना उसकी स्क्रीन योजना विवरण खोलता है — मॉकअप अपनी योजना के साथ, उस स्क्रीन के आने वाले/जाने वाले लिंक के साथ।
- डिज़ाइन सत्य का स्रोत है। स्क्रीन-सामना कार्य के लिए, कार्यान्वयन डिज़ाइन का अनुसरण करता है — कभी उल्टा नहीं। एक इश्यू का प्राथमिक मॉकअप एक समीक्षा गेट से गुज़रता है (
needs_board_review → approved | changes_requested); जब तक बोर्ड अनुमोदन नहीं देता, एजेंट विकास रोकते हैं; अनुमोदन के बाद डिज़ाइन को कार्यान्वयन लक्ष्य के रूप में इंजेक्ट किया जाता है। नई टीमें डिफ़ॉल्ट रूप से डिज़ाइन-फर्स्ट हैं (गैर-दृश्य इश्यू प्रति-इश्यू एक कारण के साथ ऑप्ट आउट करते हैं)। - डिज़ाइनर एजेंट प्रत्येक स्क्रीन को शुद्ध मॉकअप और उसकी योजना के रूप में लिखता है, और विरासत डिज़ाइनों को उसी जोड़ी मॉडल में फिर से लिखा जा सकता है।
issueflow अनुशासन से उधार लेते हुए, हर इश्यू में स्वीकृति मानदंड, गैर-लक्ष्य और एक प्रमाण सतह होती है। एक इश्यू प्रमाण बंडल के बिना Done तक नहीं पहुँच सकता, QA भूमिका फैसले की मालिक है, और एक इश्यू को पूरा करना एक यौगिक शिक्षण चक्र शुरू करता है (ऑटो-चेकलिस्ट → वैकल्पिक LLM ऑटो-फिल → अनुवर्ती इश्यू)। ज्ञान वाष्पित होने की बजाय यौगिक होता है।
Workcell Paperclip (paperclipai, MIT-लाइसेंसशुदा) के एक फोर्क के रूप में शुरू हुआ — AI एजेंटों की टीमों को ऑर्केस्ट्रेट करने के लिए एक अच्छी तरह से बनाया गया ओपन-सोर्स कंट्रोल प्लेन: संगठन चार्ट, हार्टबीट, बजट, गवर्नेंस, एक टिकट सिस्टम, एक अपरिवर्तनीय ऑडिट लॉग, और सच्ची मल्टी-कंपनी अलगाव। वह कंट्रोल प्लेन वास्तविक, ठोस इंजीनियरिंग है, और Workcell इसे अपनी नींव के रूप में रखता है। हम इसके आभारी हैं, और Paperclip का मूल कॉपीराइट और MIT अनुमति नोटिस NOTICE में संरक्षित है।
हमने फोर्क किया क्योंकि हमारा उत्पाद दर्शन अलग हो गया — Paperclip में अपने लक्ष्यों के लिए कुछ भी गलत नहीं था। Paperclip खुद को शून्य-मानव कंपनियों के इर्द-गिर्द तैयार करता है: एक स्वायत्त AI कार्यबल जिसे आप CEO/CTO संगठन चार्ट में "भर्ती" करते हैं और बड़े पैमाने पर पीछे हट जाते हैं। Workcell मानव की भूमिका पर विपरीत रुख अपनाता है और लक्ष्य को "कोई भी व्यवसाय चलाएं" से विकास परियोजनाओं को अच्छी तरह से चलाएं तक सीमित करता है। वह अंतर डोमेन मॉडल, UX और "done" की परिभाषा को बदलने के लिए काफी गहरा है:
- CEO-कंपनी रूपक → बोर्ड + ऑर्केस्ट्रेटर + कार्यात्मक-भूमिकाएँ मॉडल। मनुष्य बोर्ड है; शीर्ष एजेंट एक Orchestrator है जो रूट और समन्वय करता है। एजेंट कार्यात्मक भूमिकाएँ हैं (orchestrator, lead, PM, engineer, designer, researcher, writer, QA, security, devops, general), C-suite शीर्षक नहीं।
- डिज़ाइन-फर्स्ट + प्रमाण-गेटेड क्रियान्वयन अनुशासन। डिज़ाइन अनुमोदन कार्यान्वयन को गेट करता है; प्रमाण Done को गेट करता है; QA फैसले का मालिक है; यौगिक शिक्षण लूप बंद करता है। इनमें से कुछ भी स्टॉक Paperclip में नहीं है — यह फोर्क का सबसे महत्वपूर्ण व्यवहार परिवर्तन है।
- Open Design + Graphify, एकीकृत। Workcell Open Design-स्टाइल डिज़ाइन ऑपरेशन (डिज़ाइन आर्टिफैक्ट, समीक्षा गेट, एक डिज़ाइन डैशबोर्ड प्लगइन) और Graphify कोड-ग्राफ प्रोड्यूसर द्वारा फ़ीड किया गया एक Knowledge Graph एकीकृत करता है — ताकि एजेंट इश्यू, कोड, निर्णयों और डिज़ाइनों को एक जुड़े इंडेक्स के रूप में नेविगेट करें बजाय हर रन में रेपो को फिर से खोजने के।
- नेट-नए ऑर्केस्ट्रेशन सबसिस्टम। एक Capability Registry (स्किल्स / प्लगइन्स / MCP / डिज़ाइन सिस्टम स्कोप, दृश्यता और विश्वास स्तरों के साथ), dual-brain deliberation (एक एजेंट दो मॉडलों में खुद को स्व-समीक्षा करता है), एक आउटबाउंड MCP bridge, और एक वॉचडॉग/रिकवरी परत जो पूरे-लेकिन-अटके रन्स को फोल्ड करती है।
- मल्टी-टेनेंट / i18n उत्पादीकरण। कठोर टेनेंट अलगाव, पूर्ण delete-cascade ऑडिट, प्रथम-श्रेणी अंतर्राष्ट्रीयकरण, डिफ़ॉल्ट रूप से डार्क थीम।
Workcell एक स्वतंत्र फोर्क है और Paperclip से संबद्ध या समर्थित नहीं है।
- प्राकृतिक भाषा → इश्यू। बोर्ड पर एक फीचर का वर्णन करें और Orchestrator स्वीकृति मानदंड, गैर-लक्ष्य और एक प्रमाण सतह के साथ एक संरचित इश्यू का मसौदा तैयार करता है।
- डिज़ाइन गेट। स्क्रीन-सामना इश्यू तब तक रुकते हैं जब तक बोर्ड एक स्रोत-सत्य डिज़ाइन को अनुमोदित नहीं करता; अनुमोदित डिज़ाइन एजेंट रन्स में इंजेक्ट किया गया कार्यान्वयन लक्ष्य बन जाता है।
- प्रमाण-गेटेड Done + QA साइनऑफ। इश्यू केवल प्रमाण साक्ष्य के साथ Done तक पहुँचते हैं; एक क्रियान्वयन नीति पहले "done" को स्वचालित रूप से QA समीक्षा में रूट करती है।
- Knowledge Graph + Graphify। इश्यू, कोड, निर्णयों और योजनाओं पर एक पॉइंटर-ओनली ग्राफ;
workcell code-graphएक Graphify एक्सपोर्ट को इंजेस्ट करता है ताकि कोड संरचना ग्राफ में शामिल हो। - App Blueprint। ऐप की हर स्क्रीन का एक फ्लो-फर्स्ट, Figma-स्टाइल दृश्य — शुद्ध मॉकअप एक स्क्रीन योजना के साथ जोड़ा गया, ड्रैग करने योग्य स्थायी नोड्स, कर्सर ज़ूम, लेबल किए गए नेविगेशन तीर, और प्रत्येक स्क्रीन की योजना पर क्लिक-थ्रू। प्रति परियोजना; अनुमोदित मॉकअप कार्यान्वयन लक्ष्य है। (Open Design प्लगइन अभी भी एक समर्पित
/designपेज पर आर्टिफैक्ट, संस्करण अंतर और सैंडबॉक्स्ड प्रीव्यू रेंडर करता है।) - Dual-brain deliberation (प्रयोगात्मक, ऑप्ट-इन)। एक एजेंट, दो मॉडल: दोनों समानांतर में एक उम्मीदवार उत्पन्न करते हैं, फिर एक सिंथेसाइज़र ब्रेन उन्हें अंतिम उत्तर में मर्ज करता है (OpenRouter-Fusion स्टाइल); लाइव रन एक फ्लैग के पीछे हैं (डिफ़ॉल्ट रूप से बंद)।
- अपना एजेंट लाएं। Claude और Codex स्थानीय एडाप्टर (और HTTP/प्रक्रिया) एक ही संगठन चार्ट के अंतर्गत।
- Capability Registry। स्किल्स, प्लगइन्स, MCP सर्वर, और डिज़ाइन सिस्टम कंपनी या प्रति-एजेंट स्कोप पर असाइन किए गए, विश्वास स्तरों, दृश्यता अवस्थाओं और बोर्ड अनुमोदन के साथ।
- MCP bridge (इन + आउट)। एक इनबाउंड MCP सर्वर Workcell के API को टूल्स के रूप में उजागर करता है; एक आउटबाउंड MCP क्लाइंट Workcell को बाहरी साइडकार्स को कॉल करने देता है (capability-gated, tenant-scoped)।
- लागत नियंत्रण और गवर्नेंस। हार्ड स्टॉप के साथ प्रति-एजेंट बजट,
Exact / Synced / Estimatedसटीकता बैज के साथ एक Usage Center, बोर्ड अनुमोदन गेट, और एक अपरिवर्तनीय, कंपनी-स्कोप्ड ऑडिट लॉग। - मल्टी-कंपनी अलगाव और i18n। एक डिप्लॉयमेंट, कई पूरी तरह से अलग कंपनियाँ; उपयोगकर्ता-सामना UI अंतर्राष्ट्रीयकृत; डिफ़ॉल्ट रूप से डार्क थीम।
एक विस्तृत, हमेशा-अपडेट फीचर इन्वेंटरी ([Paperclip] / [Changed] / [New] टैग के साथ) docs/FEATURES.md में रहती है।
एक इश्यू स्वामी को दो दिमागों वाले एक एजेंट के रूप में चलाया जा सकता है — दो स्वतंत्र रूप से कॉन्फ़िगर किए गए मॉडल — OpenRouter-Fusion स्टाइल में जोड़े। दोनों दिमाग समानांतर और स्वतंत्र रूप से एक उम्मीदवार उत्तर उत्पन्न करते हैं (न तो दूसरे का ड्राफ्ट देखता है); फिर एक सिंथेसाइज़र ब्रेन (डिफ़ॉल्ट रूप से दिमाग A) दोनों को एक मज़बूत अंतिम उत्तर में समेटता है — प्रत्येक को सही रखना, बाकी को छोड़ना, संघर्षों को हल करना। दो अलग मॉडल चुनें और आप सिंथेसिस के ऊपर मॉडल विविधता जोड़ते हैं।
यह क्यों काम करता है: अधिकांश लाभ सिंथेसिस चरण से ही आता है, केवल मॉडल विविधता से नहीं। जब OpenRouter ने Perplexity के DRACO डीप-रिसर्च बेंचमार्क पर अपने Fusion दृष्टिकोण को मापा, Claude Opus 4.8 को खुद के साथ दो-मॉडल पैनल के रूप में जोड़ने से स्कोर 58.8% से 65.5% तक बढ़ा — क्योंकि यहाँ तक कि उसी मॉडल के दो पास अलग होते हैं, और एक सिंथेसाइज़र जो उन्हें सुलझाता है वह एकल शॉट को मात देता है। (write-up, OpenRouter.)
स्थिति: ऑप्ट-इन, डिफ़ॉल्ट रूप से बंद। फ्यूज़न इंजन — समानांतर उत्पन्न + सिंथेसाइज़ — कार्यान्वित और परीक्षित है, लेकिन वास्तविक मॉडलों के साथ इसे चलाना एक फ्लैग (WORKCELL_PAIR_LIVE_LLM, ताकि dev/CI कभी दुर्घटनावश खर्च न हो) के पीछे गेट किया गया है और एक समर्पित, पोल करने योग्य agent-deliberation रन के रूप में चलता है। सटीक, flag-by-flag स्कोप के लिए docs/FEATURES.md देखें।
Workcell एक pnpm workspace है (Node 20+, pnpm 9.15+):
| पथ | पैकेज | भूमिका |
|---|---|---|
server/ |
@workcell/server |
Express REST API + ऑर्केस्ट्रेशन सेवाएँ (heartbeat, runs, design gate, governance, audit) |
ui/ |
@workcell/ui |
React + Vite बोर्ड UI (dev में API द्वारा सर्व किया गया) |
cli/ |
workcell |
CLI / workcell बाइनरी — onboard, configure, code-graph, cloud sync |
packages/shared/ |
@workcell/shared |
साझा प्रकार, स्थिरांक, वैलिडेटर, API पथ अनुबंध |
packages/db/ |
@workcell/db |
Drizzle स्कीमा, माइग्रेशन, DB क्लाइंट (dev में एम्बेडेड Postgres) |
packages/adapters/ |
— | एजेंट एडाप्टर (claude / codex / …) |
packages/adapter-utils/ |
@workcell/adapter-utils |
साझा एडाप्टर यूटिलिटीज़ (MCP injection, cost mapping) |
packages/mcp-server/ |
@workcell/mcp-server |
इनबाउंड MCP सर्वर (Workcell API → tools) |
packages/mcp-bridge/ |
@workcell/mcp-bridge |
आउटबाउंड MCP क्लाइंट (Workcell → external MCP sidecars) |
packages/plugins/ |
— | प्लगइन सिस्टम, SDK, सैंडबॉक्स प्रोवाइडर, उदाहरण प्लगइन (Open Design डैशबोर्ड सहित) |
एक एकल Node प्रक्रिया API, एक एम्बेडेड PostgreSQL, और development में स्थानीय फ़ाइल स्टोरेज चलाती है; production में आप इसे अपने Postgres पर पॉइंट करते हैं।
आवश्यकताएँ: Node.js 20+, pnpm 9.15+।
pnpm install
pnpm dev # API + UI वॉच मोड मेंdevelopment में एक एम्बेडेड PostgreSQL डेटाबेस स्वचालित रूप से बनाया जाता है — इसे उपयोग करने के लिए DATABASE_URL को अनसेट छोड़ें। सामान्य स्क्रिप्ट (package.json से):
pnpm dev # पूर्ण dev (API + UI, watch)
pnpm dev:server # केवल सर्वर
pnpm typecheck # workspace-wide type check
pnpm test # स्थिर Vitest रन (Playwright नहीं चलाता)
pnpm build # सभी पैकेज बिल्ड करें
pnpm test:e2e # Playwright ब्राउज़र सूट (ऑप्ट-इन)
pnpm db:generate # DB माइग्रेशन उत्पन्न करें
pnpm db:migrate # माइग्रेशन लागू करेंपहला रन: ऑनबोर्डिंग विज़ार्ड आपकी टीम बनाता है (डिफ़ॉल्ट रूप से डिज़ाइन-फर्स्ट), Orchestrator को सीड करता है, और आपका पहला इश्यू खोलता है। फिर Agents पेज से अनुशंसित टीम के बाकी सदस्यों को भर्ती करें — Engineer, Designer, QA — (प्रत्येक लापते सीट के लिए एक-क्लिक)।
योगदानकर्ता वर्कफ़्लो और इंजीनियरिंग नियमों के लिए AGENTS.md देखें।
| क्षेत्र | फ़ाइल |
|---|---|
| विस्तृत उत्पाद विनिर्देश | PRODUCT_SPEC.md |
| फीचर इन्वेंटरी (Paperclip की तुलना में) | docs/FEATURES.md |
| सक्रिय योजना / रोडमैप / निर्णय | docs/plan/PLAN.md · docs/plan/ROADMAP.md · docs/plan/DECISIONS.md |
| पुन: प्रयोज्य समाधान / रोकथाम नियम | docs/solutions/INDEX.md |
Workcell MIT License (© 2026 Workcell) के अंतर्गत जारी किया गया है।
Workcell के कुछ भाग Paperclip (paperclipai), © 2025 Paperclip AI से व्युत्पन्न हैं, जो MIT-लाइसेंसशुदा भी है। MIT License द्वारा आवश्यकतानुसार, Paperclip का मूल कॉपीराइट और अनुमति नोटिस NOTICE में पुनरुत्पादित है और पुनर्वितरण में बनाए रखा जाना चाहिए।