Tanrei कैसे बनता है
दो सोर्स ऑफ़ ट्रुथ, स्पेक-फ़र्स्ट वर्कफ़्लो और ड्रिफ़्ट जाँचें, जो पाँच प्लैटफ़ॉर्म, दस्तावेज़ और स्थिति मैट्रिक्स को आपस में मिलाकर रखती हैं।
Tanrei एक ही रिपॉज़िटरी से एक डिज़ाइन सिस्टम पाँच प्लैटफ़ॉर्म तक पहुँचाता है। यह तभी चल सकता है जब रिपॉज़िटरी ख़ुद ग़लत होना मुश्किल बना दे: एक जगह किया गया बदलाव या तो हर जगह पहुँचे, या खुलकर विफल हो। यह पेज उस व्यवस्था का वर्णन करता है जो यह काम करती है।
फ़ैसले सिर्फ़ दो डायरेक्टरी में हैं:
| डायरेक्टरी | इसमें क्या है | फ़ॉर्मैट |
|---|---|---|
tokens/ |
हर डिज़ाइन मान | Design Tokens Community Group फ़ॉर्मैट, 2025.10 |
specs/ |
हर कंपोनेंट का कॉन्ट्रैक्ट | JSON, जिसे specs/component.schema.json वैलिडेट करता है |
बाक़ी सब व्युत्पन्न है: हर प्लैटफ़ॉर्म के लिए जनरेट की गई टोकन फ़ाइलें, प्लैटफ़ॉर्म के इम्प्लीमेंटेशन, इन दस्तावेज़ों की टेबल और स्थिति मैट्रिक्स। जब कोई व्युत्पन्न चीज़ सोर्स ऑफ़ ट्रुथ से मेल न खाए, तो परिभाषा से ही व्युत्पन्न चीज़ ग़लत है।
कंपोनेंट स्पेक प्लैटफ़ॉर्म से स्वतंत्र होता है। उसमें दर्ज होता है: कंपोनेंट की संरचना, प्रॉपर्टी, स्लॉट, इवेंट और स्टेट; नंबर वाली आवश्यकताओं के रूप में उसका व्यवहार; उसका सुलभता कॉन्ट्रैक्ट, जिसमें रोल, कीबोर्ड टेबल और लेबलिंग शामिल हैं; वह टोकन ग्रुप जिससे वह बँधता है; फ़िक्स्चर का एक सेट, यानी वे मानक रेंडरिंग जिनका स्नैपशॉट हर प्लैटफ़ॉर्म एक ही id से लेता है; और एक platforms ब्लॉक, जो प्लैटफ़ॉर्म से स्वतंत्र नामों को हर प्लैटफ़ॉर्म के अपने तरीक़े से मैप करता है।
व्यवहार EARS रूप में लिखा जाता है, जो वाक्य का एक बँधा हुआ ढाँचा है और जिसके आधार पर टेस्ट करना आसान है:
WHEN the user activates the button by pointer, touch, Enter or Space
THE button SHALL emit click exactly once.हर आवश्यकता का BTN-1 जैसा एक id होता है, और हर प्लैटफ़ॉर्म के टेस्ट इन्हीं id का हवाला देते हैं।
- प्रस्ताव रखें। स्पेक लिखें या बदलें, और ज़रूरत हो तो टोकन भी। नए कंपोनेंट और ब्रेकिंग बदलावों का फ़ैसला मेंटेनर करते हैं, स्पेक बदलने से पहले।
- वैलिडेट करें।
pnpm validateस्कीमा जाँचता है, टोकन को लिंट करता है और हर थीम और कंट्रास्ट के हर स्तर के लिए कंट्रास्ट इनवेरिएंट की पुष्टि करता है। - जनरेट करें।
pnpm generateटोकन आउटपुट, स्कैफ़ोल्ड और स्थिति मैट्रिक्स को दोबारा बनाता है। - इम्प्लीमेंट करें, स्पेक में सूचीबद्ध हर प्लैटफ़ॉर्म पर, यूनिट, स्नैपशॉट और सुलभता के टेस्ट के साथ।
- जाँचें।
pnpm checkसब कुछ क्रम से चलाता है, ड्रिफ़्ट जाँच समेत, और उसे हरा होना चाहिए। - दर्ज करें। एक changeset जोड़ें। सभी पैकेजों के वर्शन एक साथ बढ़ते हैं, क्योंकि पैरिटी ही प्रॉडक्ट है।
किसी प्लैटफ़ॉर्म की सार्वजनिक सतह उसी कमिट में स्पेक में वही बदलाव हुए बिना कभी नहीं बदल सकती।
- दोबारा जनरेट करने पर अंतर। CI हर व्युत्पन्न फ़ाइल को दोबारा जनरेट करता है और नतीजा कमिट की हुई फ़ाइल से अलग हो तो विफल हो जाता है। जनरेट की गई फ़ाइल में हाथ से किया गया बदलाव टिक नहीं सकता।
- पैरिटी जाँच। स्पेक जिस भी प्लैटफ़ॉर्म को घोषित करता है, उसके लिए चेकर एक इम्प्लीमेंटेशन, एक टेस्ट, हर फ़िक्स्चर का एक स्नैपशॉट, और अंग्रेज़ी और जापानी में कंपोनेंट का दस्तावेज़ पेज माँगता है। साइट की बाक़ी हर भाषा में कौन-से पेज होने चाहिए, यह दस्तावेज़ साइट की एक अलग जाँच है। स्थिति मैट्रिक्स इन्हीं तथ्यों से निकाली जाती है, इसलिए वह जितना मौजूद है उससे ज़्यादा का दावा नहीं कर सकती।
- कंट्रास्ट इनवेरिएंट। जो स्कीम कंट्रास्ट में विफल होती है, वह कभी निकलती ही नहीं।
- स्नैपशॉट का अनुशासन। स्नैपशॉट में अंतर एक खोज है। बेसलाइन तभी बदलती हैं जब विज़ुअल बदलाव किसी स्पेक या टोकन के बदलाव का चाहा हुआ नतीजा हो।
पैरिटी का मतलब है वही टोकन, बराबर का विज़ुअल नतीजा, वही स्टेट और सुलभता के वही सिमैंटिक्स। इसका मतलब एक जैसा API नहीं है। Compose enabled लेता है, Flutter onPressed के null होने पर बटन को अक्षम करता है, SwiftUI .disabled(_:) इस्तेमाल करता है। हर मैपिंग स्पेक के platforms ब्लॉक में लिखी होती है और हर कंपोनेंट पेज पर दिखाई जाती है।
इंसानों और AI एजेंट पर एक ही नियम लागू होते हैं, और जितने हो सकें उतने नियम भरोसे से नहीं, टूल से लागू करवाए जाते हैं।
- परतों में नियम। रूट की एक छोटी
AGENTS.mdप्रोजेक्ट का संविधान बताती है; नेस्टेड फ़ाइलें टोकन, स्पेक और हर पैकेज के लिए स्थानीय नियम जोड़ती हैं। नेस्टेड नियम रूट के नियमों में जोड़ सकते हैं, उन्हें कमज़ोर कभी नहीं कर सकते। - लेन। किसी प्लैटफ़ॉर्म का काम उसी प्लैटफ़ॉर्म के पैकेज तक सीमित रहता है। SwiftUI इम्प्लीमेंट कर रहे एजेंट के पास Compose को छूने का कोई कारण नहीं है।
- हुक। जनरेट की गई डायरेक्टरी में संपादन,
--no-verifyऔर स्नैपशॉट बेसलाइन के अपडेट टूल के स्तर पर रोक दिए जाते हैं, और सेशन ख़त्म होने पर ड्रिफ़्ट जाँच चलती है। - स्किल। बार-बार होने वाली प्रक्रियाएँ, जैसे कंपोनेंट या टोकन जोड़ना, चरण-दर-चरण स्किल के रूप में लिखी गई हैं, ताकि वे हर बार एक ही तरह से हों।
- कोई प्रकाशन नहीं। किसी रजिस्ट्री पर रिलीज़ करना मेंटेनरों का फ़ैसला है। अपने आप चलने वाला कोई भी एजेंट या टूल यह नहीं कर सकता।
टिप्पणी
ये दस्तावेज़ भी इन्हीं नियमों पर चलते हैं। स्थिति, टोकन रेफ़रेंस और कंपोनेंट स्पेक की टेबल बिल्ड के समय रिपॉज़िटरी के डेटा से रेंडर होती हैं। सिर्फ़ गद्य हाथ से लिखा जाता है।