तीन हिस्सों का बँटवारा

§1तीन परतें, तीन मालिक

• astro-inkbrush (इंजन): एक न्यूनतम CMS — ब्राउज़र में ही ब्लॉक-स्तर का संपादन, ब्लॉक-स्तर का संशोधन-इतिहास और revert, टिप्पणियाँ, AI से सवाल-जवाब / पुनर्लेखन / अनुवाद, inbox से आयात। एक चीज़ और इसी की है, जो देखने में CMS की नहीं लगती: Markdown की बोली और सामग्री-रक्षक। वजह ठोस है: संपादक जो व्याकरण स्वीकारता है और पन्ना जो व्याकरण रेंडर करता है — दोनों एक ही होने चाहिए, वरना "संपादक में ठीक सहेजा, पन्ने पर ग़लत छपा" बस वक़्त की बात है। इसलिए पार्सर के नियम एक बार, इंजन में लिखे जाते हैं और तीन जगह बरते जाते हैं — साइट की रेंडरिंग, CMS की सहेजते-वक़्त की जाँच, CI की जाँचें।
• astro-inkstone (कागज़ — यही पैकेज): रूप और पाइपलाइन की साझा परत — दो संदर्भों में दो-स्तरीय डिज़ाइन-टोकन, सामग्री-स्टाइलशीट base.css और ब्राउज़ शेल्फ़ browse.css, कंपोनेंट-लाइब्रेरी, siteMarkdown पाइपलाइन-प्रीसेट, वर्गीकरण और बैकलिंक के वे सहायक जिन पर यह बगीचा चलता है, Maple Mono CN कोड-फ़ॉन्ट का subset, और रेंडर-परत की प्रोबें। साइट-पहचान इसका काम नहीं है: ब्रांड-रंग, लेआउट का chrome, रूटिंग और डिप्लॉयमेंट — इनसे इसका कोई वास्ता नहीं।
• साइट (जैसे यह बगीचा जो आप पढ़ रहे हैं): अपनी पहचान के रंग के लिए टियर-1 टोकन override करती है; अपना Sidebar और नेविगेशन-chrome खुद रखती है (इस साइट का अमल संदर्भ-उत्तर है); तय करती है कि सामग्री कैसे सजे, रूट कैसे दिखें और डिप्लॉय कहाँ हो।

याद रखने लायक़ एक पंक्ति: इंजन संपादित करता है, कागज़ रूप देता है, साइट आप हैं।

§2सीमाएँ ठीक यहीं क्यों

हर कट के पीछे एक असली मजबूरी है:

बोली इंजन की है, क्योंकि जिस जाँचकर्ता का प्लगइन-सेट साइट से अलग हो, वह जाँचकर्ता न होने से भी बुरा है — गणित-प्लगइन से वंचित जाँचकर्ता सूत्रों के braces को JSX-अभिव्यक्ति पढ़ बैठता है, और GFM-रहित जाँचकर्ता टेबल की खड़ी लकीरों को हाथ हिलाकर जाने देता है। व्याकरण एक बार लिखा जाता है और तीन जगह बरता जाता है, इसलिए वह कभी अपनी जगह से खिसक नहीं सकता।

स्टाइल कागज़ की हैं, क्योंकि जब कई साइटें अपनी-अपनी सामग्री-स्टाइलशीट पालती हैं, तो कंट्रास्ट का एक सुधार हर साइट पर अलग से लगाना पड़ता है — एक छूटी, और उस साइट का छोटा टेक्स्ट AA से नीचे जा गिरा। साझा परत में एक सुधार हर जगह एक साथ पहुँचता है।

पहचान साइट की है, क्योंकि जिस पल साझा परत किसी एक साइट का ब्रांड-रंग निगल लेती है, बाक़ी हर साइट को उससे override लड़ाने पड़ते हैं। इसीलिए दो-स्तरीय टोकन: साइट टियर-1 का कच्चा पैलेट (--p-*) override करती है और semantic व कंपोनेंट-परतें बिना छुए पीछे-पीछे चलती हैं — देखिए design-tokens।

§3ब्राउज़ की मशीनरी कहाँ रहती है

जो आप इस वक़्त नेविगेट कर रहे हैं, उस पर भी यही अनुशासन लागू है। पैकेज यांत्रिकी देता है — createTaxonomy (प्रकार/क्षेत्र/टैग का समाधान, हब से विरासत, भाषाई मिरर), createBacklinks (बैकलिंक-इंडेक्स), और लैंडिंग-पेज के नोट-कार्ड व फ़ेसेट-पंक्तियों जैसे विशुद्ध-प्रदर्शन कंपोनेंट। साइट के पास शब्दावली और रूट हैं: इस बगीचे के प्रकार और क्षेत्र उसकी अपनी रजिस्ट्री-फ़ाइल में रहते हैं, और उसके /kind/…, /domain/…, /tag/… पन्ने साधारण Astro-पन्ने हैं, जिन्हें उपभोक्ता-साइट कॉपी करके अपनी शक्ल देती है। वही बँटवारा, एक मंज़िल ऊपर: यांत्रिकी पैकेज में, अर्थ साइट में।

§4साइट को क्या मिलता है

साइट की नज़र से यह पैकेज और इंजन साथ लेने पर हाथ आता है:

• astro-inkstone/styles/tokens.css + base.css + browse.css: पहले टोकन, फिर पढ़ने का कॉलम, फिर ब्राउज़ शेल्फ़ — पूरे रूप के लिए तीन @import लाइनें;
• siteMarkdown(...): पूरी Markdown पाइपलाइन एक लाइन में, स्विचों का बखान getting-started में;
• astro-inkstone/components/ के नीचे के कंपोनेंट, ज़रूरत के मुताबिक़ पाथ से import;
• astro-inkstone/lib/ के नीचे वर्गीकरण-फ़ैक्टरी और बैकलिंक-बिल्डर, साइट की अपनी रजिस्ट्री से बँधे;
• WIKI मोड में इंजन का पूरा CMS (इसी साइट पर npm run wiki से आज़माइए);
• पाँच जाँचें: check-content, check-wikilinks और check-dist (इंजन के साथ आती हैं), ui_probe और contrast_probe (यहाँ से आती हैं) — देखिए checks।

इस बगीचे के हर पन्ने का हर रेंडरिंग-असर इसी बँटवारे की पैदाइश है — नोट ही मैनुअल हैं, और मैनुअल ही डेमो है।