लेखकत्व हेडर — प्रति-फ़ाइल SPDX लाइसेंस लाइन

डाउनस्ट्रीम योगदानकर्ताओं के लिए कैनोनिकल मानक संदर्भ। यह दस्तावेज़ परियोजना विनिर्देश के Authorship & File-Header अनुभागों (Spec §0.5 + §4.6) को प्रतिबिंबित करता है; यह वह स्वतंत्र संदर्भ है जो प्रकाशित रिपॉज़िटरी के साथ शिप होता है। आर्किटेक्चरल औचित्य ADR-0002 में दर्ज है।

1. कैनोनिकल हेडर लाइनCopy Anchor Link

ईकोसिस्टम की प्रत्येक लागू फ़ाइल को अपने फ़ाइलप्रकार परिवार के टिप्पणी सिंटैक्स में एक एकल कैनोनिकल SPDX लाइसेंस-आइडेंटिफ़ायर लाइन से अनिवार्य रूप से आरंभ होना होगा; इससे पहले केवल शेबैंग, या Markdown फ़ाइलों पर YAML frontmatter, आ सकता है (§5)। यह लाइन फ़ाइल का मशीन-पठनीय लाइसेंस मार्कर है; छूट प्राप्त न होने वाली फ़ाइलों के लिए इसकी उपस्थिति पर कोई समझौता नहीं हो सकता, और इसकी सामग्री सत्य के एकल स्रोत द्वारा शासित होती है, प्रति फ़ाइल तदर्थ रूप से नहीं गढ़ी जाती। पूर्ण कॉपीराइट उपकरण रिपॉज़िटरी-रूट की LICENSE फ़ाइल में एक ही बार रहता है — इसे हर स्रोत फ़ाइल में दोहराया नहीं जाता।

1.1 सूचना सामग्री (अपरिवर्तनीय)Copy Anchor Link

कैनोनिकल सामग्री ठीक एक लाइन है:

1. SPDX-License-Identifier: MIT — FSFE द्वारा अनुरक्षित REUSE विनिर्देश के अनुसार मशीन-पठनीय लाइसेंस मार्कर; SPDX टूलचेन (reuse lint, scancode), Linux-कर्नेल टूलिंग, और डाउनस्ट्रीम लाइसेंस-स्कैनर इसे बिना अस्पष्टता के पार्स करते हैं। इसमें कोई दृश्य सीमा नहीं है, और न प्रति-फ़ाइल कॉपीराइट, वेबसाइट, ईमेल या GitHub लाइनें हैं — डिज़ाइन के अनुसार प्रति-फ़ाइल प्रोवेनेंस एकल SPDX लाइन ही है (§4 देखें)।

1.2 संदर्भ रूप (#-टिप्पणी परिवार)Copy Anchor Link

कैनोनिकल पाठ — यहाँ इसके #-टिप्पणी-सिंटैक्स रूप में लिखा गया — src/apothem/schemas/authorship-header.txt पर सत्य का स्रोत है:

# SPDX-License-Identifier: MIT

यह पाठ एकमात्र आधिकारिक स्रोत है। file-header वैलिडेटर (§8) फ़ाइलों को इस बाइट-सटीक फ़िक्स्चर के विरुद्ध जाँचता है। किसी फ़ाइल की हेडर लाइन और इस फ़िक्स्चर के बीच कोई भी विचलन (§2 के अनुसार सिंटैक्स प्रतिस्थापन के अंतर्गत) एक फ़ाइंडिंग के रूप में रिपोर्ट किया जाता है। वैलिडेटर ब्लॉकिंग है: --strict के अंतर्गत, जैसे CI और pre-commit हुक उसे चलाते हैं, एक फ़ाइंडिंग रन को विफल कर देती है (§8)।

2. प्रति-फ़ाइलप्रकार वैरिएंट (बाइट-सटीक)Copy Anchor Link

लाइन की सूचना सामग्री अपरिवर्तनीय है; केवल इसका टिप्पणी सिंटैक्स प्रति फ़ाइलप्रकार बदलता है। पूर्ण प्रति-फ़ाइलप्रकार वैरिएंट तालिका:

Markdown वैरिएंट (कैनोनिकल रेंडरिंग):

<!-- SPDX-License-Identifier: MIT -->

HTML-टिप्पणी (या MDX {/* */}) रैपर अदृश्य रूप से रेंडर होता है, इसलिए रेंडर की गई सतह स्वच्छ रहती है जबकि स्रोत के भीतर का लाइसेंस मार्कर सभी फ़ाइलप्रकारों में मशीन-पठनीय बना रहता है।

3. अपवाद सूची (श्रेणीबद्ध रूप से छूट प्राप्त)Copy Anchor Link

निम्नलिखित वर्ग SPDX हेडर लाइन से छूट प्राप्त हैं। file-header वैलिडेटर इन फ़ाइलों को बिना जाँचे पास कर देता है। नीचे के वर्ग header-exceptions.txt की ग्लॉब सूची से मेल खाते हैं:

• कानूनी और संस्करण फ़ाइलें — LICENSE, LICENSE.md, LICENSE.txt, NOTICE, और VERSION। LICENSE आधिकारिक कॉपीराइट पंक्ति वहन करती है, जिसकी उपस्थिति की पुष्टि license-author-consistency वैलिडेटर करता है।
• प्रामाणिक फ़िक्स्चर — schemas/authorship-header.txt। फ़िक्स्चर में हेडर इंजेक्ट करने से हेडर का हेडर बनेगा।
• *.svg एसेट — XML टिप्पणियाँ लाइन-टिप्पणी मार्करों के लिए भंगुर हैं, इसलिए SVG प्रोवेनेंस एसेट README और जनरेट किए गए रास्टर आउटपुट द्वारा वहन किया जाता है।
• JSON फ़ाइलें (.json) — JSON में कोई टिप्पणी सिंटैक्स नहीं है। जहाँ JSON कॉन्फ़िग के लिए श्रेय आवश्यक हो, वहाँ एक सहोदर <file>.NOTICE.md रखें।
• लॉकफ़ाइलें — हर *.lock फ़ाइल, package-lock.json, yarn.lock, pnpm-lock.yaml, और go.sum। ये फ़ाइलें मशीन-प्रबंधित हैं।
• जनरेटेड और मिनिफ़ाइड फ़ाइलें — generated/ डायरेक्टरी के अंतर्गत कोई भी फ़ाइल, और मिनिफ़ाइड बंडल (*.min.js, *.min.css)।
• वेंडर की गई तृतीय-पक्ष सामग्री — _vendor/, vendor/, third_party/, और node_modules/ के अंतर्गत फ़ाइलें। इनमें अपस्ट्रीम का अपना लाइसेंस या नोटिस होता है। अपस्ट्रीम श्रेय के ऊपर हमारा मार्कर इंजेक्ट करना लाइसेंस उल्लंघन है।
• ऑडिट, योजना और हार्नेस स्थिति — .audit/ और .apothem/ के अंतर्गत सब कुछ, जिसमें प्लान, मेमोरी, लर्निंग डेटा और कॉन्टेक्स्ट रहते हैं। इसके साथ ही कार्य-वृक्ष के मूल में projects/ और memory/, जिन पर हार्नेस का स्वामित्व है। ये वृक्ष gitignore किए गए हैं या ऑपरेटर के स्वामित्व में हैं, और प्रकाशित वृक्ष के दायरे से बाहर हैं। प्लान फ़ाइलों का प्रोवेनेंस उनके frontmatter से ट्रैक होता है (plans-discipline.md §3 देखें)।
• टेस्ट डेटा फ़िक्स्चर — tests/fixtures/ के अंतर्गत .yaml, .yml, .txt, और .json फ़ाइलें। उस वृक्ष की टेस्ट स्रोत फ़ाइलों में अब भी हेडर रहता है।
• इंजेक्टर स्मोक-टेस्ट इनपुट — tests/conformity-scenarios/fixtures/F-13-injector-smoke/ के अंतर्गत की फ़ाइलें। ये हेडर-रहित रहती हैं, क्योंकि इंजेक्टर परीक्षण जाँचता है कि इंजेक्टर उनमें हेडर जोड़ता है।
• पैकेजिंग और रिक्त मार्कर — .SRCINFO, जिसे पैकेजिंग पार्सर सख़्ती से पढ़ता है, और शून्य-बाइट मार्कर .keep, .gitkeep, और py.typed।
• बाइनरी फ़ाइलें — फ़िक्स्चर में सूचीबद्ध इमेज, फ़ॉन्ट, आर्काइव, मीडिया, और कंपाइल्ड-ऑब्जेक्ट सफ़िक्स। जो सफ़िक्स वैलिडेटर की वेरिएंट तालिका में मैप नहीं होता, वह डिफ़ॉल्ट रूप से छूट प्राप्त है।

अपवाद सूची स्वयं src/apothem/schemas/header-exceptions.txt में एक regex/glob सूची के रूप में एन्कोड की गई है और वैलिडेटर की प्रयोज्यता जाँच का इनपुट है। संशोधनों के लिए एक संरचित पूछताछ और एक नया ADR आवश्यक है।

4. लाइसेंस अन्योन्यक्रियाCopy Anchor Link

SPDX लाइन परियोजना का लाइसेंस मशीन-पठनीय रूप से घोषित करती है; LICENSE फ़ाइल उसे आधिकारिक रूप से घोषित करती है:

• SPDX-License-Identifier: MIT — REUSE विनिर्देश और SPDX मानक के अनुसार मशीन-पठनीय लाइसेंस मार्कर। स्वचालित लाइसेंस स्कैनर इस लाइन को सीधे पार्स करते हैं; SPDX अभिव्यक्ति सिंटैक्स reuse lint, scancode-toolkit, FOSSology, और Linux-कर्नेल लाइसेंस-टूलिंग के साथ परस्पर संगत है।

• रिपॉज़िटरी-रूट LICENSE — पूर्ण MIT शर्तें और कॉपीराइट धारक वहन करने वाला आधिकारिक विधिक उपकरण। यह कॉपीराइट कथन का एकमात्र स्थान है; प्रति-फ़ाइल हेडर हर फ़ाइल में कॉपीराइट दोहराने के बजाय साझा SPDX आइडेंटिफ़ायर के माध्यम से उसे अंतर्निहित रूप से संदर्भित करते हैं।

एकल-लाइन रूप। प्रति-फ़ाइल प्रोवेनेंस एकल SPDX लाइन है; कॉपीराइट उपकरण रूट LICENSE में एक ही बार रहता है। सीमायुक्त बहु-लाइन बैनर बॉक्स (एक रेखांकित फ़्रेम में लिपटी कॉपीराइट, वेबसाइट, ईमेल, संपर्क लाइनें) वैलिडेटर द्वारा अस्वीकार किए जाते हैं: वे हर फ़ाइल में संपर्क और कॉपीराइट मेटाडेटा दोहराते हैं, और ऐसा कुछ नहीं जोड़ते जो मशीन-पठनीय लाइसेंस मार्कर REUSE/SPDX/SBOM टूलिंग को पहले से प्रदान नहीं करता। src/apothem/schemas/authorship-header.txt पर बाइट-सटीक फ़िक्स्चर एकल-लाइन रूप वहन करता है; वैलिडेटर इसी फ़िक्स्चर के विरुद्ध चलता है।

क्रॉस-संदर्भ। LICENSE फ़ाइल (MIT) — विवाद की स्थिति में विधिक उपकरण ही नियंत्रक होता है। ADR-0006 बैनर-संकुचन के अनुसमर्थन का औचित्य दर्ज करता है।

5. सम्मिलन स्थितिCopy Anchor Link

• SPDX लाइन फ़ाइल की पहली सामग्री है, दो अपवादों के साथ। शेबैंग लाइन (#!/usr/bin/env bash, #!/usr/bin/env python3, इत्यादि) सदैव लाइन 1 पर रहती है, और SPDX लाइन लाइन 2 पर आरंभ होती है। YAML frontmatter वाली Markdown / MDX फ़ाइलों में frontmatter पहले आता है (अगला बिंदु)।
• YAML frontmatter वाली Markdown / MDX फ़ाइलों में frontmatter बाइट 0 पर रहता है ताकि टूलिंग उसे पार्स कर सके, और SPDX टिप्पणी समापन --- के बाद आती है, फिर बॉडी, जो उन फ़ाइलों में H1 से खुलती है जिनमें H1 होता है। scripts/inject-header.py टिप्पणी को इसी तरह रखता है।
• एक अकेली रिक्त लाइन SPDX लाइन को अगली सामग्री (H1, बॉडी, इत्यादि) से अलग करती है।

6. हेडर दृश्यता नीतिCopy Anchor Link

Markdown और MDX फ़ाइलों के लिए, SPDX लाइन हमेशा उसके टिप्पणी-आवरण (<!-- ... --> या {/* */}) के अंदर लिखी जाती है। यह केवल स्रोत में दिखती है और रेंडर किए गए पृष्ठ पर प्रकट नहीं होती। इंजेक्टर में न कोई दृश्यमान रेंडरिंग है, न प्रति-फ़ाइल ओवरराइड। रिपॉज़िटरी का कोई भी टूल फ़िक्स्चर src/apothem/schemas/header-visibility.yaml नहीं पढ़ता।

7. इंजेक्टर — scripts/inject-header.{sh,py}Copy Anchor Link

एक नियतात्मक CLI जो:

• एक या अधिक फ़ाइल पथ (या glob) लेता है।
• अपवाद सूची (§3) के माध्यम से प्रयोज्यता निर्धारित करता है।
• मौजूदा हेडर स्थिति (कैनोनिकल / विकृत / अनुपस्थित) का पता लगाता है, और मिलने वाले किसी भी गैर-कैनोनिकल बैनर ब्लॉक को हटा देता है, ताकि दोबारा चलाने पर परिणाम वही रहे।
• प्रति फ़ाइलप्रकार सही SPDX वैरिएंट (§2) रेंडर करता है।
• शेबैंग और frontmatter का सम्मान करते हुए सही स्थान (§5) पर सम्मिलित करता है।
• इंसर्शन-स्थान पर मौजूद उस SPDX लाइन में, जिसके पहले खाली पंक्ति नहीं है, खाली पंक्ति जोड़ता है, उसके ऊपर दूसरी प्रति सम्मिलित करने के बजाय।
• तीन मोड में संचालित होता है: fix-in-place (लिखता है), emit-patch (यूनिफ़ाइड diff प्रिंट करता है), check (किसी भी विचलन पर गैर-शून्य कोड के साथ बाहर निकलता है; ट्रैक किए गए वृक्ष पर कोई CI जॉब इसे नहीं चलाता)।
• इडेम्पोटेंट: दो बार चलाने पर कोई बदलाव नहीं होता।

इंजेक्टर make headers-fix टारगेट द्वारा आह्वान किया जाता है, जो scripts/inject-header.py --mode fix-in-place चलाता है।

8. वैलिडेटर — file-headerCopy Anchor Link

यह src/apothem/conformity/file_header_grep.py पर स्थित है। कार्य-वृक्ष की हर फ़ाइल के लिए, वैलिडेटर उसकी प्रयोज्यता देखता है (§3 के अनुसार) और, यदि प्रयोज्य हो, तो पुष्टि करता है कि प्रामाणिक SPDX लाइन सम्मिलन स्थान पर मौजूद है। अधिकांश परिवारों के लिए वह स्थान, वैकल्पिक shebang के बाद, फ़ाइल का शीर्ष है। Markdown और MDX फ़ाइलों के लिए YAML frontmatter ब्लॉक पहले छोड़ दिया जाता है, इसलिए प्रामाणिक लाइन, जैसा §5 अपेक्षित करता है, समापन फ़ेंस के बाद आ सकती है। MDX फ़ाइलें {/* */} रूप (§2) पर रिज़ॉल्व होती हैं और उसी के विरुद्ध जाँची जाती हैं। वैलिडेटर और इंजेक्टर प्रामाणिक ब्लॉक एक ही इंडेक्स पर रखते हैं।

src/apothem/schemas/authorship-header.txt पर बाइट-सटीक फ़िक्स्चर द्वारा समर्थित। कॉर्पस रन इस मैचर के लिए फ़ाइंडिंग की संख्या और चिह्नित फ़ाइलों का एक नमूना रिपोर्ट करता है। यह प्रति-फ़ाइल diff या कवरेज प्रतिशत प्रिंट नहीं करता। मैचर ब्लॉकिंग है: --strict के अंतर्गत, जिसे CI और pre-commit हुक उपयोग करते हैं, एक फ़ाइंडिंग रन को विफल करती है। --strict के बिना गेट फ़ाइंडिंग रिपोर्ट करता है और 0 के साथ बाहर निकलता है।

9. स्व-प्रवर्तन तंत्रCopy Anchor Link

यह अनुशासन हर भावी सत्र और हर भावी योगदानकर्ता के बाद भी बना रहना ही चाहिए। अनिवार्य प्रवर्तन सतहें:

1. src/apothem/schemas/authorship-header.txt — बाइट-सटीक कैनोनिकल फ़िक्स्चर; सत्य का एकल स्रोत।
2. scripts/inject-header.{sh,py} — यांत्रिक इंजेक्टर (§7)।
3. file-header वैलिडेटर (§8) — विचलन को ब्लॉकिंग फ़ाइंडिंग के रूप में रिपोर्ट करता है, जो --strict रन को विफल करती है।
4. Pre-commit हुक — conformity-corpus-perwrite हुक हर प्रति-Write मैचर चलाता है, जिसमें file-header वैलिडेटर (§8) भी शामिल है, --strict के साथ ट्रैक किए गए वृक्ष पर। file-header मैचर ब्लॉकिंग है, इसलिए एक फ़ाइंडिंग कमिट को रोकती है। यह हुक केवल जाँच करता है। इसमें कोई फ़िक्स मोड नहीं है, और यह इंजेक्टर (§7) को कभी नहीं चलाता, जो make headers-fix के माध्यम से चलता है।
5. CLAUDE.md अनिवार्य-व्यवहार ब्लॉक — असिस्टेंट को निर्देश देता है कि कोई भी लागू फ़ाइल बनाते समय कैनोनिकल SPDX लाइन इंजेक्ट करे।
6. GitHub Copilot निर्देश फ़ाइल .github/copilot-instructions.md पर — फ़ाइल जनरेशन पर Copilot को वही करने का निर्देश देती है।
7. PreToolUse हुक src/apothem/hooks/messages/pretooluse-{write,edit}-header-guard.md पर — लागू पथों पर Write/Edit टूल कॉल को रोकते हैं, ताकि SPDX लाइन फ़ाइल बनने के समय ही इंजेक्ट हो, न कि बाद में वैलिडेटर फ़ाइंडिंग के रूप में खोजी जाए। गार्ड का चेकर, src/apothem/hooks/lib/header_check.py, केवल मानक लाइब्रेरी का उपयोग करता है और फ़िक्स्चर तथा छूट सूची को hooks/ के बगल वाली schemas/ डायरेक्टरी से पढ़ता है, इसलिए यह Claude Code प्लगइन के अंतर्गत भी काम करता है, जहाँ apothem पैकेज इम्पोर्ट करने योग्य नहीं है। यह इंजेक्टर की वैरिएंट तालिकाएँ और सम्मिलन-स्थल नियम प्रोजेक्ट के भीतर की फ़ाइलों पर लागू करता है, और केवल ऐसे git प्रोजेक्ट में जो हेडर फ़िक्स्चर (src/apothem/schemas/authorship-header.txt) रखता है, क्योंकि SPDX लाइन इस रिपॉज़िटरी की कन्वेंशन है, न कि हर उस प्रोजेक्ट के लिए डिफ़ॉल्ट जिसे प्लगइन खोलता है।
8. PR टेम्पलेट चेकबॉक्स — योगदानकर्ता-सम्मुख अभिकथन कि हर नई फ़ाइल कैनोनिकल SPDX लाइन वहन करती है।
9. यह दस्तावेज़ (site/content/docs/reference/authorship-header.mdx) — कैनोनिकल, मानकीय व्याख्या।

यह भी देखेंCopy Anchor Link

• ADR-0002 — आर्किटेक्चरल औचित्य, विचार किए गए विकल्प।
• ADR-0006 — बैनर-संकुचन का अनुसमर्थन।
• src/apothem/schemas/authorship-header.txt — बाइट-सटीक कैनोनिकल फ़िक्स्चर।
• src/apothem/schemas/header-exceptions.txt — अपवाद सूची (regex/glob रूप)।
• scripts/inject-header.py और scripts/inject-header.sh — इंजेक्टर।
• src/apothem/conformity/file_header_grep.py — वैलिडेटर।
• परियोजना विनिर्देश §0.5 + §4.6 — यहाँ प्रतिबिंबित कैनोनिकल पाठ।