हम ट्रैफ़िक आँकड़ों के लिए Google Analytics का उपयोग करते हैं। Analytics कुकी तभी सेट होती हैं जब आप स्वीकार करें। सहमति के बिना, आँकड़े कुकी-रहित संकेतों से अनुमानित किए जाते हैं। कुकी नीति.
PDS · डिज़ाइन सिस्टम
PDS, Protocore की अपनी डिज़ाइन भाषा है, जो हमारे बनाए प्रोडक्ट से निकली और प्रोडक्शन में परखी गई है। Dark-first, टोकन-आधारित और शुरू से अंत तक दस्तावेज़ीकृत — वही कंपोनेंट जो हमारे प्रोडक्ट और क्लाइंट dashboard रेंडर करते हैं, इस तरह पैक किए गए कि कोई टीम उन्हें एक दोपहर में अपना ले।
फ़ीचर्स
प्रिमिटिव से लेकर पूरे पेज कंपोज़िशन तक — 101 कॉम्पोनेंट, हर एक हमारे शिप किए गए प्रोडक्ट से निकाला गया, अलग-थलग डिज़ाइन नहीं किया गया। अगर कोई कॉम्पोनेंट PDS में है, तो वह असली काम कर चुका है: यह साइट, प्रोडक्ट डेमो और हमारे क्लाइंट dashboards सब इसी पर रेंडर होते हैं।
रंग, टाइप, स्पेस और मोशन, सब एक ही token लेयर से तय होते हैं। एक token बदलिए और हर कॉम्पोनेंट उसके साथ बदल जाता है — न कॉम्पोनेंट-स्तर के override, न प्रोडक्ट्स के बीच भटकाव।
एक डार्क और एक लाइट थीम, पाँच accent रंग, सब एक ही tokens से चलते हैं। ब्रांड बदलाव बस token की अदला-बदली है, fork नहीं — परिवार का हर प्रोडक्ट इसी सिस्टम से रेंडर होता है।
कॉन्ट्रास्ट, elevation और रंग पहले डार्क थीम पर तय किए जाते हैं; लाइट थीम उन्हीं tokens से बनती है। नतीजा एक ऐसा डार्क मोड है जो नेटिव लगता है, उलटा किया हुआ नहीं।
बटन, इनपुट, सेलेक्ट, स्विच, स्लाइडर और फ़ील्ड स्कैफ़ोल्डिंग — लेबल, हिंट और एरर समेत। स्टेट पहले से डिज़ाइन हैं: focus, disabled, invalid और loading हर प्रोडक्ट में एक जैसा व्यवहार करते हैं।
स्टैक, ग्रिड, डिवाइडर और पेज शेल बिना ad-hoc CSS के स्क्रीन बनाते हैं। सबसे बड़े कॉम्पोनेंट पूरे पेज कंपोज़िशन हैं — हमारे शिप किए गए पेजों से लिए गए hero, section और footer पैटर्न।
हेडर, टैब, ब्रेडक्रम्ब और मेन्यू, जिनमें रेस्पॉन्सिव और कीबोर्ड व्यवहार पहले से शामिल है। इस साइट का नेविगेशन ख़ुद वही कॉम्पोनेंट है, उसकी नक़ल नहीं।
मोडल, शीट, ड्रॉअर, पॉपओवर और टूलटिप एक ही लेयरिंग मॉडल पर — फ़ोकस ट्रैपिंग, डिसमिसल और स्टैकिंग एक बार, केंद्रीय रूप से सँभाले गए। कोई प्रोडक्ट अपना z-index का हिसाब नहीं लगाता।
टेबल, लिस्ट, stat tiles, बैज और टाइमलाइन, उन प्रोडक्ट्स के लिए जो आँकड़ों पर चलते हैं। परिवार भर के ऑपरेटर कंसोल अपनी सघनता इन्हीं कॉम्पोनेंट से पाते हैं।
टोस्ट, बैनर, खाली स्टेट, प्रोग्रेस और स्केलेटन — वे बेरौनक स्टेट जो शुरू में ही डिज़ाइन कर लिए जाते हैं। PDS पर बने प्रोडक्ट के पास loading, empty और failed, तीनों का सोचा-समझा जवाब होता है।
तकनीकी रजिस्टर के लिए mono लेबल के साथ एक editorial type scale — वही आवाज़ जो आप हर Protocore सतह पर देखते हैं। यह स्केल tokens है, इसलिए प्रोडक्ट सिस्टम से बाहर गए बिना उसे ट्यून कर सकते हैं।
अवधि और easing tokens के रूप में आते हैं, और कॉम्पोनेंट उन्हें पहले से इस्तेमाल करते हैं। प्रोडक्ट्स में इंटरफ़ेस एक जैसे चलते हैं क्योंकि कोई एनिमेशन की टाइमिंग हाथ से दोबारा नहीं बैठाता।
कॉन्ट्रास्ट, फ़ोकस स्टेट और कीबोर्ड व्यवहार कॉम्पोनेंट में ही बने हैं, किसी के भरोसे छोड़े नहीं गए। डिफ़ॉल्ट शिप कीजिए और एक्सेसिबिलिटी साथ आ जाती है।
स्टाइलिंग स्टैटिक CSS है जो build के समय तय हो जाती है — न CSS-in-JS runtime, न ब्राउज़र में कोई गणना। स्टाइलिंग लेयर पेज में शून्य JavaScript जोड़ती है।
सिस्टम एक सादे CSS पैकेज के रूप में भी आता है — tokens और utility क्लासेज़, बिना React के। सर्वर-रेंडर्ड पेज, ईमेल और non-React स्टैक सब उसी single source of truth से लेते हैं।
Tokens वेब के लिए CSS variables और Tailwind preset के रूप में, और मोबाइल प्लेटफ़ॉर्म के लिए नेटिव फ़ॉर्मैट में एक्सपोर्ट होते हैं। ब्रांड की एक ही परिभाषा, प्रोडक्ट जहाँ भी चले वहाँ इस्तेमाल होती है।
React लेयर ऐप्स को एक provider में लपेटती है और hooks के ज़रिए tokens उपलब्ध कराती है — कॉम्पोनेंट वैल्यू हार्डकोड करने के बजाय सक्रिय थीम और accent पढ़ते हैं। थीम बदलना बस state है, rebuild नहीं।
जो मैकेनिज़्म PDS को पाँच accent देता है, वही whitelabel प्रोडक्ट को उसका ब्रांड देता है: token वैल्यू बदलिए, कॉम्पोनेंट वही रखिए। परिवार का हर whitelabel ऐप इसके काम करने का सबूत है।
पूरे सिस्टम का मशीन-रीडेबल मैप — कॉम्पोनेंट, tokens, पैटर्न — llms.txt के रूप में प्रकाशित। किसी LLM को इसकी ओर इशारा कीजिए और जेनरेट किया कोड मनगढ़ंत, सुनने में सही लगने वाले कॉम्पोनेंट की जगह असली PDS कॉम्पोनेंट इस्तेमाल करेगा।
एक MCP server सिस्टम को कोडिंग एजेंट्स के सामने सीधे खोल देता है: कॉम्पोनेंट, props और tokens, एजेंट के बनाते समय क्वेरी करने योग्य। डिज़ाइन सिस्टम सवालों के जवाब देता है, प्रॉम्प्ट में पेस्ट नहीं करना पड़ता।
हर कॉम्पोनेंट pds.protocore.io पर लाइव उदाहरण, props और कॉपी-पेस्ट कोड के साथ मौजूद है। डॉक्स ख़ुद PDS पर रेंडर होते हैं — जो आप पढ़ते हैं, वही आप शिप करते हैं।
PDS सेमांटिक वर्ज़न और changelog के साथ वर्ज़न वाले पैकेज के रूप में शिप होता है। अपग्रेड सोच-समझकर होते हैं: टीम जब चाहे तब आगे बढ़ती है, और changelog बताता है कि ठीक क्या बदला।
पैकेज Protocore की private npm registry से इंस्टॉल होते हैं, .npmrc में प्रति-टीम token के साथ — मानक npm वर्कफ़्लो, जो लाइसेंस प्राप्त टीमों तक सीमित है। न vendored zip फ़ाइलें, न कॉपी-पेस्ट इंस्टॉल।
हस्ताक्षरित लाइसेंस कुंजी लोकल रूप से सत्यापित होती है — न phone-home, न आपकी build में कोई नेटवर्क जाँच। लाइसेंस की समस्याएँ डेवलपमेंट के समय चेतावनी के रूप में दिखती हैं और प्रोडक्शन ऐप को कभी नहीं तोड़तीं।
PDS प्रोप्राइटरी है और प्रति टीम लाइसेंस किया जाता है। एक्सेस का अनुरोध कीजिए और हम आपको सेट अप कर देंगे — पैकेज, डॉक्स और token स्रोत — ताकि टीम इसे एक दोपहर में अपना सके।
FAQ
प्रति टीम, प्रति सीट या प्रति प्रोजेक्ट नहीं। एक लाइसेंस टीम में PDS पर बनाने वाले सभी को कवर करता है: tokens, components और docs। लागत केवल अपनाने वाली टीमों की संख्या के साथ बढ़ती है, और हम आपके लिए जो whitelabel प्रोडक्ट बनाते हैं वे पहले से इसी पर चलते हैं।
npm.protocore.io की प्राइवेट registry से। एक्सेस क्रेडेंशियल से आपका बिल्ड @protocore पैकेज खींच सकता है, और उसके बाद tokens और components किसी भी आम dependency की तरह इंस्टॉल होते हैं।
Tokens वेब, .NET और नेटिव के लिए तैयार होते हैं, इसलिए एक रंग या radius हर प्लेटफ़ॉर्म पर एक ही मायने रखता है। Components React के लिए उपलब्ध हैं, और जो टीमें React पर नहीं हैं उनके लिए framework-agnostic CSS लेयर वही tokens और classes देती है।
डिफ़ॉल्ट रूप से dark-first और accessible: दो थीम, पाँच accents, सब tokens से चलते हैं, और zero-runtime CSS के कारण स्टाइलिंग लोड पर कोई लागत नहीं जोड़ती। यही components हमारे प्रोडक्ट्स और क्लाइंट dashboards दोनों को रेंडर करते हैं।
इसे इसी के लिए बनाया गया है: llms.txt मैप और MCP सर्वर से एजेंट सिस्टम को पढ़कर उसके साथ सही ढंग से बना सकते हैं, और pds.protocore.io पर हर component और token के लिए लाइव उदाहरण, props और कॉपी-पेस्ट कोड मौजूद हैं।
प्राइसिंग
PDS का लाइसेंस प्रति टीम है, प्रति सीट या प्रति प्रोजेक्ट नहीं। एक लाइसेंस उस टीम में PDS पर काम करने वाले सभी को कवर करता है: tokens, components और docs।
एक टीम से शुरू करें और अपनाने के साथ और टीमों तक बढ़ाएँ। लागत केवल इस पर निर्भर है कि कितनी टीमें PDS पर बना रही हैं, और किसी चीज़ पर नहीं।
हम आपके लिए जो whitelabel प्रोडक्ट बनाते हैं, वे पहले से PDS पर चलते हैं। स्टैंडअलोन लाइसेंस उन टीमों के लिए है जो इसे अपने प्रोडक्ट्स पर अपनाना चाहती हैं।
लाइसेंस टीमों के आधार पर तय होता है, कर्मचारियों की संख्या या उपयोग के आधार पर नहीं। एक्सेस का अनुरोध करें, हम उन टीमों के अनुसार स्कोप तय कर देंगे जो इसके साथ बनाएँगी।
परखें
पूरा सिस्टम pds.protocore.io पर देखें: हर component और token के लिए लाइव उदाहरण, props और कॉपी-पेस्ट कोड।
वेब, .NET और नेटिव के लिए तैयार किए गए design tokens, ताकि एक रंग या radius आपके हर प्लेटफ़ॉर्म पर एक ही मायने रखे।
PDS का लाइसेंस प्रति टीम है। एक लाइसेंस इसके साथ बनाने वाले सभी को कवर करता है, चाहे tokens हों, components या docs।
npm.protocore.io पर प्राइवेट registry के क्रेडेंशियल, ताकि आपका बिल्ड ज़रूरी @protocore पैकेज इंस्टॉल कर सके।
PDS प्रोप्रायटरी है और प्रति टीम लाइसेंस पर मिलता है। एक्सेस का अनुरोध करें, सेटअप हम कर देंगे।
ऊपर का सब कुछ प्रोडक्शन डेमो में चलता है, जिसे हम आपको दिखा सकते हैं: स्टैंडअलोन, whitelabel या एक प्लेटफ़ॉर्म के रूप में। बताइए आप क्या बना रहे हैं, हम सबसे छोटा रास्ता दिखाएँगे।
