मैंने OpenClaw के साथ 5-भूमिकाओं वाला AI सहयोगी ऑपरेटिंग सिस्टम बनाया: एक पूर्ण तकनीकी विवरण

मैंने OpenClaw को एक सिंगल असिस्टेंट से मल्टी-रोल कोलैबोरेटिव ऑपरेटिंग सिस्टम में बदलने में काफी समय बिताया। यह सिर्फ "कुछ बॉट्स को अलग-अलग चैट करने के लिए खोलना" नहीं है।

5 AI भूमिकाएँ, एक गेटवे साझा करती हैं, Discord और Telegram डुअल चैनलों पर चलती हैं, जिनमें कार्यों का स्पष्ट विभाजन, रूटिंग, मेमोरी आइसोलेशन और सहयोग के नियम हैं, जो एक टीम की तरह रिले में काम करने में सक्षम हैं।

इस लेख में, मैं पूरी निर्माण प्रक्रिया, प्रत्येक परत पर डिज़ाइन निर्णय, विशिष्ट कॉन्फ़िगरेशन और उन समस्याओं को तोड़ता हूँ जिनका मुझे सामना करना पड़ा।

यदि आप भी OpenClaw का उपयोग कर रहे हैं या "कई AI को वास्तव में सहयोग करने का तरीका" में रुचि रखते हैं, तो यह लेख आपको कई चक्करों से बचने में मदद करेगा।

निष्कर्ष पहले: यह "मल्टी-बॉट" नहीं है, यह एक सिंगल गेटवे के तहत एक मल्टी-एजेंट OS है

जब बहुत से लोग "5 AI भूमिकाएँ" सुनते हैं, तो उनकी पहली प्रतिक्रिया होती है: आप 5 स्वतंत्र बॉट चला रहे हैं, है ना?

हाँ, लेकिन नहीं भी।

मेरी आर्किटेक्चर इस प्रकार है:

• 1 गेटवे प्रक्रिया, चैनल एक्सेस और रूटिंग को एकीकृत करना
• 5 स्वतंत्र एजेंट: कमांडर, स्ट्रैटेजिस्ट, इंजीनियर, क्रिएटर, थिंकर
• प्रत्येक एजेंट का अपना स्वतंत्र वर्कस्पेस है (व्यक्तित्व, नियम, मेमोरी और सत्र सभी पृथक हैं)
• Discord + Telegram डुअल चैनल एक साथ चलाना (कई प्लेटफ़ॉर्म चला सकते हैं, लेकिन मैं केवल Discord का उपयोग करता हूँ), सटीक संदेश वितरण के लिए बाइंडिंग का उपयोग करना
• प्राइवेट और ग्रुप चैट पूरी तरह से अलग तंत्र का उपयोग करते हैं

एक सादृश्य: यह 5 लोगों को काम पर रखने और उन्हें एक कमरे में स्वतंत्र रूप से कार्य करने के लिए फेंकने जैसा नहीं है। यह एक कंपनी बनाने जैसा है—एक संगठनात्मक संरचना, नौकरी विवरण, संचार प्रोटोकॉल, स्वतंत्र कार्यालय और बैठक के नियमों के साथ।

OpenClaw अपने आप में एक ओपन-सोर्स पर्सनल AI असिस्टेंट फ्रेमवर्क है जो कई प्लेटफ़ॉर्म (Discord, Telegram, WhatsApp, आदि) और कई मॉडलों (Claude, GPT, Gemini, आदि) को सपोर्ट करता है, जिसमें पूरी तरह से स्थानीयकृत डेटा है।

इसकी मल्टी-एजेंट क्षमता मुख्य कारण है जिसने मुझे इसे चुना—नेटिव सपोर्ट मल्टी-एजेंट स्वतंत्र वर्कस्पेस + बाइंडिंग रूटिंग के लिए, जिसने मुझे इसके ऊपर एक वास्तविक सहयोगी प्रणाली बनाने की अनुमति दी।

1. समग्र आर्किटेक्चर: सिंगल गेटवे + मल्टी-एजेंट + मल्टी-वर्कस्पेस + मल्टी-चैनल

सबसे पहले, बात करते हैं सबसे निचले स्तर के आर्किटेक्चरल निर्णयों की।

1) सिंगल गेटवे के माध्यम से एकीकृत होस्टिंग

मेरे पास वर्तमान में एक OpenClaw गेटवे प्रक्रिया है जो सभी क्षमताओं को वहन करती है—मैसेज एक्सेस, रूटिंग, सेशन मैनेजमेंट, टूल कॉल, मेमोरी इंडेक्सिंग और स्टेट मैनेजमेंट, सभी एक गेटवे में।

प्रत्येक भूमिका के लिए सेवाओं का एक सेट क्यों नहीं चलाते? तीन कारण:

• केंद्रीकृत रखरखाव: बनाए रखने के लिए केवल एक गेटवे, प्रत्येक भूमिका के लिए स्वतंत्र सेवाएं चलाने की आवश्यकता नहीं है।
• एकीकृत कॉन्फ़िगरेशन: एक मास्टर कॉन्फ़िग वैश्विक रणनीतियों का प्रबंधन करता है, और मॉनिटरिंग/समस्या निवारण भी केंद्रीकृत है।
• सहयोग की नींव: भूमिकाओं के सहयोग के लिए, उन्हें कुशल संचार के लिए एक ही रनटाइम में होना चाहिए।

2) 5 समानांतर एजेंट, 5 ढीले बॉट नहीं

मेरी 5 निश्चित भूमिकाएँ:

• कमांडर (zongzhihui): वैश्विक स्थितिजन्य जागरूकता, कार्य विघटन, असाइनमेंट, सुधार और समापन।
• स्ट्रैटेजिस्ट (junshi): रणनीतिक विश्लेषण, प्रस्ताव मूल्यांकन और जोखिम पूर्वानुमान।
• इंजीनियर (engineer): तकनीकी निष्पादन, कोड कार्यान्वयन और सिस्टम रखरखाव।
• क्रिएटर (creator): सामग्री निर्माण, अभिव्यक्ति अनुकूलन और बाहरी आउटपुट।
• थिंकर (zhiku): ज्ञान ऑडिट, गुणवत्ता नियंत्रण और अनुपालन जाँच।

प्रत्येक एजेंट का अपना कार्यक्षेत्र है, जैसे workspace-engineer, workspace-junshi, आदि। व्यक्तित्व फ़ाइलें, नियम फ़ाइलें, मेमोरी फ़ाइलें और स्क्रिप्ट संपत्तियाँ सभी स्वतंत्र हैं और एक दूसरे को दूषित नहीं करती हैं।

3) मल्टी-चैनल डुअल-स्टैक एक्सेस: Discord + Telegram

एक ही गेटवे Discord और Telegram दोनों से जुड़ा है। प्रत्येक भूमिका में दोनों चैनलों पर accountId-स्तरीय बाइंडिंग हैं। बेशक, आप इसी कॉन्फ़िगरेशन फ़ाइल का उपयोग करके अधिक प्लेटफ़ॉर्म जैसे Lark, WeChat आदि को एकीकृत कर सकते हैं।

यह "प्लेटफ़ॉर्म पर डुप्लिकेट तैनाती" नहीं है, बल्कि "एक ही मस्तिष्क क्लस्टर, विभिन्न एक्सेस लेयर" है। मैंने Discord को मुख्य सहयोग युद्धक्षेत्र के रूप में कॉन्फ़िगर किया है।

यदि आप चाहते हैं कि कई एजेंट एक समूह के भीतर सहयोग करें और सहयोग करें, तो बस Discord चुनें; एक प्लेटफ़ॉर्म पर्याप्त है। अन्य सही नहीं हैं, मैंने उन्हें आज़माया है!!!

2. रूटिंग लेयर: बाइंडिंग्स "अकाउंट्स" को "रोल्स" से मैप करना

यह पूरे सिस्टम का एंट्री लॉजिक है।

मैंने डुअल चैनलों के लिए एक स्पष्ट बाइंडिंग रणनीति कॉन्फ़िगर की: channel + accountId -> agentId।

विशेष रूप से:

• discord + zongzhihui -> zongzhihui
• discord + engineer -> engineer
• telegram + creator -> creator
• ... कुल 10 मैपिंग (5 भूमिकाएँ × 2 चैनल)

ऐसा क्यों?

क्योंकि सिस्टम एंट्री लेयर पर तय करता है "इस संदेश को किसे संभालना चाहिए", न कि सभी एजेंटों को इसे सुनने और फिर जवाब देने के लिए होड़ करने देता है। यदि यह कदम अच्छी तरह से नहीं किया गया, तो बाद का सारा सहयोग अव्यवस्थित होगा।

आप बाइंडिंग्स को इस सिस्टम के "फ्रंट डेस्क ट्राइएज" के रूप में सोच सकते हैं। जब कोई संदेश आता है, तो यह पहले जाँचता है कि उसे किस चैनल और खाते से प्राप्त हुआ है, फिर इसे सीधे संबंधित भूमिका पर रूट करता है—स्वच्छ और कुशल।

3. सेशन आइसोलेशन: प्राइवेट चैट क्यों पार नहीं करतीं और ग्रुप चैट अव्यवस्थित नहीं होतीं

यह मेरे सिस्टम में सबसे महत्वपूर्ण इंजीनियरिंग बिंदुओं में से एक है।

कोर कॉन्फ़िगरेशन: session.dmScope = per-account-channel-peer

इस पैरामीटर का अर्थ है: प्राइवेट चैट कॉन्टेक्स्ट तीन आयामों द्वारा पृथक है: "खाता + चैनल + पीयर उपयोगकर्ता।"

यह विकल्प क्यों चुनें?

• यदि एक ही व्यक्ति Discord और Telegram के माध्यम से एक ही भूमिका से संपर्क करता है, तो कॉन्टेक्स्ट पार नहीं होंगे।
• यदि विभिन्न उपयोगकर्ता एक ही भूमिका से संपर्क करते हैं, तो कॉन्टेक्स्ट पूरी तरह से पृथक हैं।
• मल्टी-एजेंट + मल्टी-अकाउंट परिदृश्यों में, "क्रॉस-टॉक" का जोखिम कम से कम होता है।

दूसरे शब्दों में, मैंने केवल "मल्टी-रोल्स" नहीं बनाए; मैंने "कॉन्टेक्स्ट आइसोलेशन स्ट्रैटेजी इंजीनियरिंग" भी की।

बहुत से लोग मल्टी-एजेंट सिस्टम बनाते हैं जहाँ भूमिकाएँ स्पष्ट रूप से विभाजित होती हैं, लेकिन कॉन्टेक्स्ट प्रबंधन गड़बड़ होता है—उपयोगकर्ता A की प्राइवेट चैट सामग्री उपयोगकर्ता B के उत्तर में समाप्त हो जाती है, या Discord वार्तालाप मेमोरी Telegram कॉन्टेक्स्ट को दूषित कर देती है।

per-account-channel-peer मल्टी-अकाउंट परिदृश्यों के लिए OpenClaw द्वारा अनुशंसित आइसोलेशन रणनीति है, और मेरे परीक्षण से पता चलता है कि यह वास्तव में सबसे स्थिर विकल्प है।

4. ग्रुप चैट ऑर्केस्ट्रेशन: नियम-संचालित सहयोग, मुक्त चैट नहीं

यह हिस्सा सबसे दिलचस्प है और इसमें सबसे अधिक समस्याएँ हैं।

कोर रणनीति: कमांडर ग्लोबल लिसनिंग + अन्य भूमिकाएँ @ ट्रिगर्ड

Discord पक्ष पर मेरी ग्रुप चैट रणनीति इस प्रकार है:

कमांडर: requireMention = false (ग्लोबल लिसनिंग)

• डिफ़ॉल्ट रूप से समूह में सभी संदेशों को देख सकता है।
• वैश्विक स्थिति को समझने, यह निर्णय लेने के लिए जिम्मेदार है कि क्या सहयोग की आवश्यकता है, कार्य विघटन करने और कार्य सौंपने के लिए।

अन्य 4 भूमिकाएँ: `requireMention = true` (@ ट्रिगर्ड)

• केवल तभी कार्य करें जब स्पष्ट रूप से @मेंशन किया जाए।
• शोर को कम करता है और एक दूसरे पर बात करने से बचाता है।

प्रत्येक भूमिका `mentionPatterns` के साथ कॉन्फ़िगर की गई है

• उदाहरण के लिए, इंजीनियर को @Engineer या [@engineer](https://x.com/@engineer) द्वारा ट्रिगर किया जा सकता है।
• समूह में सम्मन को अधिक स्थिर और पूर्वानुमेय बनाता है।

इस संयोजन का सार क्या है?

• कमांडर "बड़ी तस्वीर देखता है", एक टीम में PM की तरह।
• विशेषज्ञ भूमिकाएँ "आवश्यकतानुसार ट्रिगर होती हैं", विभिन्न पदों पर विशेषज्ञों की तरह।
• समूह भाषण "मुक्त-रूप" से "नियंत्रित रिले" में बदल जाता है।

वास्तविक प्रभाव: आप समूह में एक प्रश्न पूछते हैं, कमांडर पहले यह आंकता है कि यह किस प्रकार का कार्य है, फिर इसे संभालने के लिए संबंधित भूमिका को @मेंशन करता है। एक बार भूमिका समाप्त हो जाने के बाद, कमांडर लूप को बंद कर देता है। पूरी प्रक्रिया एक वास्तविक टीम की बैठक की तरह है।

5. Discord बनाम Telegram: Discord मुख्य युद्धक्षेत्र क्यों है

सख्ती से कहें तो, ऐसा नहीं है कि "केवल Discord ही सहयोग कर सकता है।" बात बस इतनी है कि मेरे वर्तमान कॉन्फ़िगरेशन के तहत, Discord मल्टी-रोल सार्वजनिक सहयोग ऑर्केस्ट्रेशन के लिए सबसे उपयुक्त है।

विशिष्ट कारण:

1. मैंने Discord पर 5 समानांतर खाते + एक स्पष्ट @सहयोग तंत्र कॉन्फ़िगर किया है।
2. भूमिका पहचान, वार्तालाप श्रृंखलाएँ और रिले प्रक्रिया सभी दृश्यमान हैं—यह एक टीम चर्चा की तरह दिखता है।
3. कमांडर ग्लोबल लिसनिंग + अन्य भूमिकाओं के मेंशन गेट की रणनीति ग्रुप चैट परिदृश्यों में अधिक सहज है।
4. मैंने वर्तमान में Discord groupPolicy को open पर सेट किया है, जो उच्च लचीलापन प्रदान करता है।

Telegram पक्ष पर, मेरी रणनीति allowlist + mention gate की ओर झुकती है, जो अधिक विवश और सुरक्षित है, जो "नियंत्रित उत्पादन चैनलों" के लिए उपयुक्त है।

तो सारांश यह है: Discord सहयोग का मंच है।

6. कॉन्फ़िगरेशन लेयर + प्रॉम्प्ट लेयर: डुअल-ट्रैक गवर्नेंस

यह इस सिस्टम और "सिर्फ खिलवाड़ करने" के बीच सबसे बड़ा अंतर है।

मैं न तो केवल कॉन्फ़िगरेशन पर निर्भर हूँ, न ही केवल प्रॉम्प्ट पर। मैं दो ओवरलैपिंग ट्रैक का उपयोग करता हूँ।

A. कॉन्फ़िगरेशन ट्रैक (प्लेटफ़ॉर्म-स्तरीय नियंत्रण)

ये OpenClaw प्लेटफ़ॉर्म स्तर पर हार्ड कॉन्फ़िगरेशन हैं:

• चैनल नीति: groupPolicy, dmPolicy, ग्रुप और प्राइवेट चैट के लिए बुनियादी रणनीतियों को नियंत्रित करना।
• requireMention: किसे डिफ़ॉल्ट रूप से जवाब देने के लिए @मेंशन किया जाना चाहिए।
• bindings: संदेश रूटिंग मैपिंग।
• dmScope: सत्र आइसोलेशन ग्रैन्युलैरिटी।
• agentToAgent पिंग-पोंग सीमा: मैंने इसे 0 पर सेट किया, सीधे एजेंटों के बीच अर्थहीन आगे-पीछे को दबाते हुए।

अंतिम बिंदु महत्वपूर्ण है—यदि आप एजेंट-टू-एजेंट पिंग-पोंग को सीमित नहीं करते हैं, तो आप एक समूह में दो AI को एक-दूसरे के साथ विनम्रता से पुष्टि करते हुए, अनंत रूप से लूप करते हुए देखेंगे। इसे 0 पर सेट करना सिस्टम को बताता है: एजेंटों को एक-दूसरे को स्वचालित रूप से पिंग नहीं करना चाहिए।

B. नियम ट्रैक (व्यवहार-स्तरीय नियंत्रण)

ये नियम फ़ाइलें हैं जो मैंने प्रत्येक कार्यक्षेत्र में लिखी हैं:

• SOUL.md: भूमिका की आत्मा फ़ाइल—व्यक्तित्व, लहजा, जिम्मेदारियाँ और आउटपुट गुणवत्ता तल।
• AGENTS.md: संचालन नियमावली—सहयोग जाँच प्रक्रियाएँ, मेमोरी रीड/राइट मानदंड और लेज़ी लोडिंग रणनीतियाँ।
• ROLE-COLLAB-RULES.md: भूमिका-विशिष्ट सहयोग सीमाएँ और रेड लाइनें।
• TEAM-RULEBOOK.md: टीम के लिए एकीकृत हार्ड नियम (सभी भूमिकाओं द्वारा साझा)।
• TEAM-DIRECTORY.md: वास्तविक आईडी के लिए भूमिकाओं की मैपिंग तालिका ताकि गलत व्यक्ति को @मेंशन करने से बचा जा सके।

इन दो ट्रैकों को ओवरलैप करने का प्रभाव है: प्लेटफ़ॉर्म लेयर प्रवाह को सीमित करता है + व्यवहार लेयर बाधाएँ जोड़ता है।

यह सब कुछ मॉडल की "आत्म-जागरूकता" पर नहीं डालना है। मॉडल गलतियाँ करते हैं, बह जाते हैं और नियम भूल जाते हैं। इसलिए, पहले कॉन्फ़िगरेशन लेयर पर हार्ड बाधाएँ निर्धारित की जानी चाहिए, उसके बाद प्रॉम्प्ट लेयर पर नरम मार्गदर्शन। डबल इंश्योरेंस।

7. वर्कस्पेस फ़ाइल सिस्टम: प्रत्येक भूमिका का "स्वतंत्र कार्यालय"

प्रत्येक कार्यक्षेत्र का फ़ाइल ढाँचा मूल रूप से सुसंगत है, जो महत्वपूर्ण है—यह दर्शाता है कि मैं मानकीकरण कर रहा हूँ, न कि प्रत्येक भूमिका के लिए बेतरतीब ढंग से फ़ाइलें जमा कर रहा हूँ।

मानक फ़ाइल संरचना

8. मेमोरी सिस्टम: लेज़ी लोडिंग + लेयरिंग + आर्काइविंग

मेमोरी प्रबंधन मल्टी-एजेंट सिस्टम का सबसे अधिक अनदेखा किया जाने वाला लेकिन सबसे समस्याग्रस्त हिस्सा है।

मेरी रणनीति "जितना संभव हो उतना याद रखना" नहीं है, बल्कि स्पष्ट लेयरिंग है:

1) अल्पकालिक लॉग (दैनिक मेमोरी)

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

2) दीर्घकालिक मेमोरी (MEMORY.md)

• स्थिर प्राथमिकताओं, दीर्घकालिक निर्णयों, पुन: प्रयोज्य अनुभव और हार्ड नियमों को आसवित करता है।
• सब कुछ अंदर नहीं जाता; केवल सत्यापित, स्थिर जानकारी लिखी जाती है।

3) समूह दीर्घकालिक मेमोरी (GROUP_MEMORY.md)

• केवल समूह से पुन: प्रयोज्य और सुरक्षित जानकारी रखता है।
• प्राइवेट चैट सामग्री को मिश्रित नहीं करता; यह एक गोपनीयता रेड लाइन है।

4) कोल्ड आर्काइविंग (archive)

• पुराने डेटा को समय-समय पर संग्रहीत किया जाता है ताकि सक्रिय संदर्भ को नियंत्रण से बाहर फैलने से रोका जा सके।
• इसे हटाया नहीं जाता, बल्कि कम-प्राथमिकता वाले संग्रहण में ले जाया जाता है।

5) पुनर्प्राप्ति तंत्र (memory_search + memory_get)

• पहले अर्थपूर्ण स्मरण, फिर सटीक पढ़ना।
• पूर्ण लोडिंग से बचता है—संदर्भ विंडो एक सीमित संसाधन है और इसे बर्बाद नहीं किया जा सकता।

इस लेयरिंग का मूल मूल्य:

• प्राइवेट चैट गुणवत्ता ग्रुप चैट इतिहास से दूषित नहीं होती है।
• समूह सहयोग व्यक्तिगत निजी संदर्भ से हस्तक्षेप नहीं करता है।
• संदर्भ विंडो "आवश्यकतानुसार लोड" होती है, न कि "पूरी तरह से डाली जाती है।"

मैं संदर्भ बजट को एक संसाधन प्रबंधन समस्या के रूप में मानता हूँ। टोकन सीमित हैं; हर टक की गई मेमोरी अनुमान स्थान घेरती है। इसलिए, प्रत्येक बिट की सावधानीपूर्वक गणना की जानी चाहिए।

9. प्राइवेट मोड बनाम ग्रुप मोड: एक ही भूमिका के लिए दो रणनीतियाँ

यह ऐसी चीज़ है जिसके बारे में बहुत से लोग नहीं सोचते: एक ही भूमिका को प्राइवेट और ग्रुप चैट में अलग-अलग व्यवहार करना चाहिए।

मैं प्रत्येक भूमिका के SOUL.md में दोनों मोड को स्पष्ट रूप से अलग करता हूँ:

प्राइवेट मोड:

• प्रत्येक भूमिका एक एकल विशेषज्ञ के रूप में कार्य करती है, उपयोगकर्ता की समस्याओं को अंत-से-अंत तक संभालती है।
• किसी सहयोग प्रक्रिया की आवश्यकता नहीं है; सीधे पूर्ण उत्तर प्रदान करें।
• गुणवत्ता मानक "एक व्यक्ति इसे संभाल सकता है" है।

ग्रुप मोड:

• टीम सहयोग प्रोटोकॉल के अनुसार वृद्धिशील रिले करता है।
• प्रत्येक भूमिका केवल उसी के लिए जिम्मेदार है जिसमें वह अच्छी है।
• कमांडर लिंकिंग और समापन के लिए जिम्मेदार है।

प्रत्येक भूमिका के लिए विशिष्ट:

• कमांडर: समूहों में डिफ़ॉल्ट रूप से चुप रहता है और निरीक्षण करता है, केवल आवश्यकता पड़ने पर दृढ़ता से हस्तक्षेप करता है ताकि दूसरों पर बात करने से बचा जा सके।
• इंजीनियर: डिलीवरेबल्स निष्पादन योग्य, सत्यापन योग्य और रोल-बैक योग्य होने चाहिए—न कि केवल एक विचार प्रदान करना।
• स्ट्रैटेजिस्ट: निष्कर्षों के साथ धारणाएँ और सत्यापन पथ होने चाहिए—न कि केवल मनमाना विचार।
• थिंकर: ऑडिट में समस्या ग्रेडिंग + मरम्मत योजनाएँ प्रदान करनी चाहिए—न कि केवल "एक समस्या है" कहना।
• क्रिएटर: अभिव्यक्ति प्रामाणिकता और निष्पादन क्षमता का त्याग नहीं कर सकती—न कि केवल सौंदर्यशास्त्र का पीछा करना।

यह "एक ही भूमिका के विभिन्न परिदृश्यों में अलग-अलग प्रदर्शन" का स्रोत है। यह मॉडल के अपने निर्णय पर निर्भर नहीं करता है, बल्कि नियम फ़ाइलों के माध्यम से स्पष्ट रूप से बताया जाता है।

अंतिम शब्द

मल्टी-एजेंट केवल कुछ और बॉट खोलना नहीं है। यह एक संपूर्ण इंजीनियरिंग सिस्टम है—आर्किटेक्चरल डिज़ाइन, रूटिंग रणनीतियों, सेशन आइसोलेशन, सहयोग ऑर्केस्ट्रेशन, मेमोरी प्रबंधन और नियम गवर्नेंस से लेकर स्वचालित जाँच तक; प्रत्येक परत को सावधानीपूर्वक डिज़ाइन की आवश्यकता है।

OpenClaw एक महान नींव प्रदान करता है, लेकिन "चलाने योग्य" से "अच्छी तरह से चलने" तक इंजीनियरिंग की मात्रा अधिकांश लोगों की कल्पना से कहीं अधिक है।

यदि आप कुछ ऐसा ही कर रहे हैं, तो मुझे उम्मीद है कि यह लेख आपको कुछ संदर्भ देगा। बेशक, यह सामग्री केवल शुरुआत है; मैं बाद में कई और लेख जारी करूँगा ताकि अधिक "विशिष्ट और परिष्कृत" मुद्दों को साझा किया जा सके।